Since the beginning of my career I haveprobably audited around 50+ vault contracts, the most basic ERC4626 standardvault, vaults for concentrated liquidity protocols and multi-asset vaults withvarious strategies behind it. I have audited them all. Below I will share myexperience with you on the most common issues for basic ERC4626 vaults:
At the heart of ERC-4626 vaults lies theprinciple of share calculation, a crucial process that determines how much ofthe vault's underlying assets each token represents. Here’s the catch: Timingis Key. Shares must be calculated before any transfer of amounts. Why? Becauseif this calculation is done post-transfer, the totalAssets variable would havealready changed — inflated by deposits or deflated by withdrawals. This couldlead to inaccurate and unfair share distribution. Talking about basic vaults, theshare calculation is mostly the same, for advanced vaults you need to becreative to find manipulation techniques.
Handling fees is a subtle art in ERC-4626vaults, which is often implemented by developers. The process should looksomething like this: First, extract the fee from the owner's amount. Then, withthe remaining amount, calculate the shares. Ideally, you want the fees to betransferred in before the actual share calculation, this way the depositor willnot regain a part of his fees. Additionally, for the first deposit there shouldnot be a fee, since that would be lost then.
Rounding is a necessary evil incomputational finance. However, in the world of ERC-4626, it's essential toensure that rounding is always to the disadvantage of the user. This approach,albeit seemingly harsh, is a safeguard against fractional discrepancies thatcould otherwise be exploited.
Be vigilant about standard sharemanipulation tactics, including the notorious inflation attack. This occurswhen the share calculation mechanism is manipulated such that the divisor isvery large, rounding the to received shares down or to zero.
A less obvious but equally dangerousvulnerability is the flash-theft attack. This can happen if fees aren't aggregatedbefore a deposit. In such scenarios, an attacker can exploit the fee mechanismto unjustly benefit at the expense of other users' fees.
Incorrect fee calculation can lead tosignificant discrepancies in asset distribution. This usually stems from errorsin the formula or its implementation, leading to either overcharging orundercharging fees.
To navigate these complexities, alwayscircle back to the foundational formulas of ERC-4626:
For Share Calculation: shares = assets *supply / totalAssets
For Asset Calculation: assets = shares *totalAssets / totalShares
The most intriguing (and often challenging)issues arise in custom implementations of these vaults. When developers tweakthe standard share calculation formula, it opens the door to uniquevulnerabilities and requires a keen eye to audit effectively.
