C4: Vault
May 19, 2026 · View on GitHub
Control Objective
If a project builds a Vault smart contract, it is necessary to follow the standard and create a secure contract based on it. Learn from past mistakes that have been identified and have solutions ready.
Ensure that a verified contract satisfies the following high-level requirements:
- Contract follows a tested and stable Vault standard,
- Stores user funds securely,
- Vulnerabilities identified in various Vault implementations have been taken into account during implementation.
Category “C4” lists requirements related to the Vault smart contract as one of the project components.
Security Verification Requirements
| # | Description |
|---|---|
| C4.1 | Verify that the user's balance is updated based on funds received and not the funds declared to be sent. |
| C4.2 | Verify that only the user has access to their funds unless they explicitly allow their funds to be managed. |
| C4.3 | Verify that the user can safely withdraw their funds at any time, even during an emergency pause. |
| C4.4 | Verify that if there is a Vault in the system, then users' funds are stored on it. |
| C4.5 | Verify that shares are distributed in proportion to the user's deposited funds. |
| C4.6 | Verify that the same amount of shares for different users allows the same amount of funds to be withdrawn. |
| C4.7 | Verify that a user depositing the same amount earlier will get more rewards than the one who deposits the same amount later. |
| C4.8 | Verify that depositing rounds down the assets and withdrawing rounds up. |
| C4.9 | Verify that the transferred amount is confirmed by checking balances before and after the deposit if the vault is going to support fee-on-transfer tokens (or any token is allowed). |
| C4.10 | Verify that the vault is allowed to transfer tokens only from msg.sender to prohibit stealing from users who approved the vault contract. |
| C4.11 | Verify that the deposit and withdraw business logic is consistent and symmetrical, especially when re-sending tokens to the same address (from == to). |
| C4.12 | Verify that the vault is protected against the first-depositor inflation/donation attack on ERC-4626 share price (virtual shares/offset, dead-share seed, or initial deployer deposit). |
| C4.13 | Verify that zero-asset deposits and zero-share mints either revert or are otherwise handled to prevent share-price griefing. |
| C4.14 | Verify that ERC-4626 previewDeposit / previewMint / previewWithdraw / previewRedeem match the result of the corresponding state-changing call in the same block. |
| C4.15 | Verify that ERC-4626 maxDeposit / maxMint / maxWithdraw / maxRedeem accurately reflect operational limits including pauses, caps, and assets temporarily held by strategies. |
| C4.16 | Verify that share-price calculations account for assets deployed in external strategies, including pending losses, and not just idle vault balance. |
| C4.17 | Verify that strategy migrations cannot trap user funds and that emergency withdrawal paths bypass the strategy if it is compromised. |
References
For more information, see also:
- Vault | Solidity 0.8
- EIP-4626
- ERC4626 Tokenized Vault Standard
- Securing ERC4626 Implementations
- Yearn Finance Vault Audit
Smart contract audit
Request an audit of your project by SCSVS authors. Contact a specialist.