Since the beginning of my career I have probably audited around 50+ vault contracts, the most basic ERC4626 standard vault, vaults for concentrated liquidity protocols and multi-asset vaults with various strategies behind it. I have audited them all. Below I will share my experience with you on the most common issues for basic ERC4626 vaults:
Share Calculation:
At the heart of ERC-4626 vaults lies the principle of share calculation, a crucial process that determines how much of the vault's underlying assets each token represents. Here’s the catch: Timing is Key. Shares must be calculated before any transfer of amounts. Why? Because if this calculation is done post-transfer, the totalAssets variable would have already changed — inflated by deposits or deflated by withdrawals. This could lead to inaccurate and unfair share distribution. Talking about basic vaults, the share calculation is mostly the same, for advanced vaults you need to be creative to find manipulation techniques.
Fee Application:
Handling fees is a subtle art in ERC-4626 vaults, which is often implemented by developers. The process should look something like this: First, extract the fee from the owner's amount. Then, with the remaining amount, calculate the shares. Ideally, you want the fees to be transferred in before the actual share calculation, this way the depositor will not regain a part of his fees. Additionally, for the first deposit there should not be a fee, since that would be lost then.
Rounding:
Rounding is a necessary evil in computational finance. However, in the world of ERC-4626, it's essential to ensure that rounding is always to the disadvantage of the user. This approach, albeit seemingly harsh, is a safeguard against fractional discrepancies that could otherwise be exploited.
Standard Share Manipulation Vectors:
Be vigilant about standard share manipulation tactics, including the notorious inflation attack. This occurs when the share calculation mechanism is manipulated such that the divisor is very large, rounding the to received shares down or to zero.
The Flash-Theft Attack:
A less obvious but equally dangerous vulnerability is the flash-theft attack. This can happen if fees aren't aggregated before a deposit. In such scenarios, an attacker can exploit the fee mechanism to unjustly benefit at the expense of other users' fees.
Incorrect Fee Calculation:
Incorrect fee calculation can lead to significant discrepancies in asset distribution. This usually stems from errors in the formula or its implementation, leading to either overcharging or undercharging fees.
The Golden Rules of Share Calculation:
To navigate these complexities, always circle back to the foundational formulas of ERC-4626:
For Share Calculation: shares = assets * supply / totalAssets
For Asset Calculation: assets = shares * totalAssets / totalShares
Custom Implementations:
The most intriguing (and often challenging) issues arise in custom implementations of these vaults. When developers tweak the standard share calculation formula, it opens the door to unique vulnerabilities and requires a keen eye to audit effectively.
Share Calculation:
At the heart of ERC-4626 vaults lies the principle of share calculation, a crucial process that determines how much of the vault's underlying assets each token represents. Here’s the catch: Timing is Key. Shares must be calculated before any transfer of amounts. Why? Because if this calculation is done post-transfer, the totalAssets variable would have already changed — inflated by deposits or deflated by withdrawals. This could lead to inaccurate and unfair share distribution. Talking about basic vaults, the share calculation is mostly the same, for advanced vaults you need to be creative to find manipulation techniques.
Fee Application:
Handling fees is a subtle art in ERC-4626 vaults, which is often implemented by developers. The process should look something like this: First, extract the fee from the owner's amount. Then, with the remaining amount, calculate the shares. Ideally, you want the fees to be transferred in before the actual share calculation, this way the depositor will not regain a part of his fees. Additionally, for the first deposit there should not be a fee, since that would be lost then.
Rounding:
Rounding is a necessary evil in computational finance. However, in the world of ERC-4626, it's essential to ensure that rounding is always to the disadvantage of the user. This approach, albeit seemingly harsh, is a safeguard against fractional discrepancies that could otherwise be exploited.
Standard Share Manipulation Vectors:
Be vigilant about standard share manipulation tactics, including the notorious inflation attack. This occurs when the share calculation mechanism is manipulated such that the divisor is very large, rounding the to received shares down or to zero.
The Flash-Theft Attack:
A less obvious but equally dangerous vulnerability is the flash-theft attack. This can happen if fees aren't aggregated before a deposit. In such scenarios, an attacker can exploit the fee mechanism to unjustly benefit at the expense of other users' fees.
Incorrect Fee Calculation:
Incorrect fee calculation can lead to significant discrepancies in asset distribution. This usually stems from errors in the formula or its implementation, leading to either overcharging or undercharging fees.
The Golden Rules of Share Calculation:
To navigate these complexities, always circle back to the foundational formulas of ERC-4626:
For Share Calculation: shares = assets * supply / totalAssets
For Asset Calculation: assets = shares * totalAssets / totalShares
Custom Implementations:
The most intriguing (and often challenging) issues arise in custom implementations of these vaults. When developers tweak the standard share calculation formula, it opens the door to unique vulnerabilities and requires a keen eye to audit effectively.
