Skip to content
Financial Context Wiki

ERC-4626 first-deposit inflation attack: How rounding can erase shares

Learn how a direct donation can manipulate an empty ERC-4626 vault's exchange rate, round a depositor's shares to zero, and how implementations and users can limit the risk.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

A first-deposit inflation attack targets an empty or nearly empty ERC-4626 vault. An attacker deposits a tiny amount to receive the first shares, then transfers underlying assets directly to the vault. This donation increases totalAssets() without increasing totalSupply(), making each existing share more valuable.

If the victim’s deposit is converted at that manipulated rate, integer division can round the output down to very few shares or zero. The victim’s assets remain in the vault while the attacker, as the holder of the outstanding shares, can redeem the inflated claim. This is an exchange-rate manipulation and slippage problem, not a defect in the ERC-4626 interface itself.

How it works

In a simple vault with no fees or protective offsets, shares minted for a deposit are approximately assets * totalSupply / totalAssets. ERC-4626 requires share calculations for a given asset amount to favor the vault by rounding down. Under normal exchange rates the rounding loss is tiny, but when the share price has been inflated, a deposit worth less than one share can lose 100% to rounding.

The attack depends on implementation details. A direct ERC-20 transfer may raise the vault’s accounted assets without minting shares, particularly when totalAssets() reads the vault’s token balance. The attacker must also get ahead of the victim while supply is very low. Vaults that use different accounting or explicit defenses may not be vulnerable in the same way.

Example

Assume a vulnerable empty vault begins at a 1:1 rate. The attacker deposits 1 asset unit and receives 1 share, then donates 999 units directly. The vault now has 1,000 assets backing 1 share. A victim deposits 999 units, so the naive calculation is 999 * 1 / 1,000 = 0 shares after integer rounding.

The vault then holds 1,999 assets while only the attacker’s 1 share exists. If the deposit permits a zero-share result and there are no fees or other constraints, the attacker can redeem that share for all 1,999 assets: the original 1-unit deposit, the 999-unit donation, and the victim’s 999-unit deposit. The attacker’s gross profit is the victim’s 999 units, before transaction costs.

Risks and defenses

Implementers can reduce the risk by seeding meaningful initial liquidity, burning or locking initial shares, enforcing a minimum nonzero share output, or using an exchange-rate design with virtual assets and virtual shares. OpenZeppelin’s implementation adds virtual amounts and supports extra share precision through a decimals offset; the virtual shares capture part of any donation, making manipulation unprofitable or substantially more expensive under the documented model. Each defense has assumptions and should be tested against direct transfers, rounding boundaries, fees, losses, and unusual token behavior.

Users and integrators should treat previewDeposit() as a quote, not a guaranteed minimum. Submit deposits through a function or router that enforces a minimum acceptable number of shares and reverts when the bound is missed. Before depositing into a new or thinly supplied vault, inspect totalAssets(), totalSupply(), the implementation’s conversion formula, and whether unsolicited token transfers affect accounting. A favorable front-end quote does not protect a transaction whose execution can be reordered.

Common misconceptions

  • Myth 1: ERC-4626 itself guarantees a safe exchange rate. The standard defines a common interface and rounding behavior; it does not make every implementation immune to exchange-rate manipulation.

  • Myth 2: Calling previewDeposit() immediately before deposit() guarantees that output. On-chain state can change between calls or before execution. The deposit path needs an enforceable minimum-share bound.

  • Myth 3: Rejecting only zero-share deposits eliminates the attack. It prevents the most extreme outcome, but an attacker may still cause a deposit to receive a small number of shares and suffer a large rounding loss. Defenses should bound acceptable slippage, not merely require a nonzero result.

Sources

Navigation

Search the wiki...