# Security Review Details ## Scope * [GitHub Repository](https://github.com/dinngo/protocolink-contract) * * * * * * * * * * * ## 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? --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.protocolink.com/smart-contract/security-review-details.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.