I2: Token
May 19, 2026 · View on GitHub
Control Objective
If a project integrates with external Token smart contracts, it is necessary to approach them with limited trust and check that they do not introduce unexpected behavior into our system.
Ensure that a verified contract satisfies the following high-level requirements:
- Contract follows a tested and stable Token standard,
- The properties of the Token that we enter into our system are known and properly handled.
- Vulnerabilities identified in various Token implementations have been taken into account during implementation.
Category “I2” lists requirements related to the Token smart contract as one of the components with which the project integrates.
Security Verification Requirements
| # | Description |
|---|---|
| I2.1 | Verify if the external Token implementation is compliant with the standard implementation. |
| I2.2 | Verify if the rules on which a new external Token can be added to the system have been defined (no restrictions, any tokens added by Governance, etc.). |
| I2.3 | Verify that the allowlist approach is used when only selected tokens are introduced to the system. |
| I2.4 | Verify if the external Token implementation is non-standard (e.g. deflationary, fee-on-transfer, block list) it has been taken into consideration and do not block/affect deposits and withdrawals. |
| I2.5 | Verify that if the external Token implementation includes external calls, it has been taken into consideration (e.g., protection against reentrancy). |
| I2.6 | Verify that the external Token magnitude (decimals) are known and that all operations are executed with the correct magnitude. |
| I2.7 | Verify that the external Token supply is specified and corresponds to the documentation. |
| I2.8 | Verify that the external Tokens of any user cannot be locked or frozen by any entity (e.g., owner). |
| I2.9 | Verify that the reentrancy attack has been considered when using the token contracts with callbacks (e.g. ERC-777, ERC-721, ERC-1155). |
| I2.10 | Verify that transfer of external Tokens has been successful, comparing the balances before and after it. |
| I2.11 | Verify that project contracts handles correctly both types of tokens, those that return false on an error and those that revert. |
| I2.12 | Verify that the contract reverts on failed transfer. |
| I2.13 | Verify that the protocol handles double-entry tokens (tracking user balances in a contract represented by two addresses) correctly or forbids them. |
| I2.14 | Use OpenZeppelin's SafeERC20 for interacting with ERC20 tokens. |
| I2.15 | Verify that integrations with rebasing tokens (stETH, USDM, AMPL) either correctly track share-based balances or explicitly reject such tokens at the allowlist level. |
| I2.16 | Verify that integrations with low-decimal tokens (USDC=6, GUSD=2, WBTC=8) do not lose precision and do not allow share/asset price griefing through dust amounts. |
| I2.17 | Verify that integrations tolerate tokens that revert on zero-value transfers or on transfers to the zero address. |
| I2.18 | Verify that the project monitors blocklist/sanctions actions by issuers of permissioned tokens (USDC, USDT, BUSD) and has a documented response if a protocol-held address is blocklisted. |
| I2.19 | Verify that EIP-2612 permit calls into untrusted tokens are wrapped in try/catch, because not all tokens implement permit and some implementations are malicious. |
References
For more information, see also:
- Token Interaction Checklist Consensys
- Token Integration Checklist ToB
- The Dangers of Token Integration
- Token Implementation Best Practice
- iToken Duplication Incident Report
- The Dangers of Surprising Code
- ERC20 standard peculiarities
Smart contract audit
Request an audit of your project by SCSVS authors. Contact a specialist.