🧑‍💻Security Review Details

Scope

• GitHub Repository

• https://github.com/dinngo/protocolink-contract/blob/master/src/Agent.sol

• https://github.com/dinngo/protocolink-contract/blob/master/src/AgentImplementation.sol

• https://github.com/dinngo/protocolink-contract/blob/master/src/Router.sol

• https://github.com/dinngo/protocolink-contract/blob/master/src/callbacks/CallbackFeeBase.sol

• https://github.com/dinngo/protocolink-contract/blob/master/src/callbacks/BalancerV2FlashLoanCallback.sol

• https://github.com/dinngo/protocolink-contract/blob/master/src/libraries/ApproveHelper.sol

• https://github.com/dinngo/protocolink-contract/blob/master/src/libraries/CallbackLibrary.sol

• https://github.com/dinngo/protocolink-contract/blob/master/src/libraries/DataType.sol

• https://github.com/dinngo/protocolink-contract/blob/master/src/libraries/Delegation.sol

• https://github.com/dinngo/protocolink-contract/blob/master/src/libraries/FeeLibrary.sol

• https://github.com/dinngo/protocolink-contract/blob/master/src/libraries/TypedDataHash.sol

Contract Details

Router

• Users can use only their respective Agent without others permission and an Agent is dedicated to one user.

• The Router has two privileged roles, owner and pauser.

• The Execution-related functions in the Router

  • are the only ways to reach the Agent.

  • should not be re-entered.

Agent

• The execute function and the executeWithSignerFee() function can only be called by the Router.

• The initialize() function is required upon creation and can only be called once.

• The callback is allowed to re-enter the Agent via the executeByCallback() function once only if the callback address is provided in the logic.

• Users receive refunds only if their token balances on Agent exceed the DUST threshold. The DUST threshold does not consider token decimals.

• If users fail to provide the correct tokensReturn, tokens stay in their Agent. To withdraw the tokens, users need to send another transaction.

Callback

• Callback can be deployed by anyone.

• If a callback re-enters an Agent with malicious logics, the Agent's token approvals would be abused.

Utility

• Utility can be deployed by anyone.

• Utility is used for scenarios that the Agent cannot handle directly. For example, the Agent transfers the ID back to the user through Utility after minting Maker CDPs.

Security Assumptions

• The addresses provided to the Router should be trustworthy, including to, callback, and token within the logics. If malicious contracts are included in to, callback, or token, only the user initiating the transaction should be affected. Even though the to (e.g., a Uniswap Router address) in logics is trustworthy, it is important to note that the execution would trigger other malicious code (e.g., a malicious token.transfer() in a swap process). Measures should be in place to block attacks such as transferring assets temporarily held by the Agent or abusing token approvals on the Agent.

• Owner should be trustworthy since the owner is able to call privilege functions like setFeeRate().

• Delegatee should be trustworthy since the delegatee is able to send transactions on behalf of its users.

Areas of Concern

The team's concerns with the contracts are around

Router

• Would the Router go into an unexpected state and act unexpectedly?

• Would reentrancy be possible when executing a transaction?

• Would the user be directed to an unexpected Agent?

• Could an attacker execute transactions on a user’s Agent without permission?

• Could the signature be forged?

Agent

• Would tokens be stuck in the Agent forever?

• Would the Agent execute any logics that is not provided by a user?

• Would a callback re-enters the Agent more than once?