Standards

ERC-4626 Vaults

ERC-4626 is the tokenized vault standard where users deposit an asset and receive vault shares that represent a claim on the vault's assets.

Users put tokens into a vault, get shares back, and later redeem those shares for assets.

ERC-4626 Vaults Explained in Detail

ERC-4626 is a standard interface for tokenized vaults. Users deposit an asset and receive vault shares. Shares represent a claim on the vault's assets.

The core audit question is simple: does the vault mint and burn shares fairly under all asset, share, fee, and rounding states?

Smart contract example

The first deposit path deserves close review. When totalSupply() is near zero, an attacker can deposit a tiny amount, donate assets directly to the vault, and force later depositors to receive too few shares.

Auditors should review deposit, mint, withdraw, redeem, convertToShares, convertToAssets, and every preview* function together.

ERC-4626 Vaults in Auditing

ERC-4626 bugs often look like normal accounting until value moves. Small rounding errors can become exploitable when the vault is empty, thinly liquid, or integrated by another protocol that trusts the share price.

Integrators may also treat ERC-4626 shares as safe collateral without accounting for donations, stale accounting, or manipulated totalAssets(). If another protocol trusts the share value, this can become an oracle manipulation issue.

Red flags in code

  • First deposit has no minimum liquidity, virtual shares, or other inflation mitigation.

  • totalAssets() can be changed by direct token transfers or flash-loaned balances.

  • preview* functions do not match the actual state-changing functions.

  • Rounding favors the wrong party.

  • Fees are applied inconsistently between preview and execution.

  • External strategies report assets without validation or delay.

  • Integrations trust convertToAssets() as an oracle.

How to test or review it

  • Test empty vault, one-share vault, direct donation, tiny deposit, large deposit, full withdrawal, and partial withdrawal.

  • Compare preview outputs against actual execution.

  • Simulate attacker-controlled donations before victim deposits.

  • Add invariant testing for asset conservation and share fairness.

  • Check whether downstream protocols can be manipulated through vault share pricing.

  • Review related price manipulation risk when vault shares are used as collateral or oracle inputs.

Sources