ERC-4626 is a tokenized vault standard that defines how a smart contract accepts deposits, issues share tokens, and computes redemption values for an underlying ERC-20 asset. Authored by Joey Santoro (Fei Protocol), Transmissions11, and Jet Jadeja and finalized in April 2022 as EIP-4626, the standard makes any yield-bearing or share-tracking vault interchangeable with another from an integrator's perspective.
This article explains the ERC-4626 interface, how share-pricing math works, the standard's adoption across Aave, Yearn v3, Morpho Blue, and Pendle, and the security considerations integrators should know — including the inflation attack that hit early implementations.
What Is ERC-4626?
ERC-4626 is an extension of ERC-20: an ERC-4626 vault is itself an ERC-20 token whose balance represents a claim on the vault's underlying asset. The standard adds eight functions and four events for deposit, withdraw, mint, redeem, and the conversion math between assets and shares. The vault holds one underlying asset (USDC, WETH, DAI) and issues shares (avUSDC, yvUSDC, mUSDC) that gain value as yield accrues.
Before ERC-4626, every vault implementation used different function names: Yearn v2 had deposit and withdraw with idiosyncratic share semantics, Compound had mint and redeem, Aave had deposit on a Pool contract that minted aTokens. Each integration was bespoke. ERC-4626 collapsed the surface area to one interface. Total value in ERC-4626-compliant vaults exceeded $30 billion across chains by April 2026, per DeFiLlama yield-aggregator data.
How ERC-4626 Vaults Work
An ERC-4626 vault has two unit types: assets (the underlying ERC-20, e.g., USDC) and shares (the vault's own token). The vault tracks totalAssets() and totalSupply() of shares. When a depositor adds assets, the vault mints shares proportional to their fraction of totalAssets(). When they redeem shares, the vault burns shares and returns the proportional asset balance.
The four core operations:
deposit(uint256 assets, address receiver) returns (uint256 shares)— caller supplies assets, vault mints shares.mint(uint256 shares, address receiver) returns (uint256 assets)— caller specifies share amount, vault pulls the required assets.withdraw(uint256 assets, address receiver, address owner) returns (uint256 shares)— caller specifies asset amount to withdraw, vault burns the required shares.redeem(uint256 shares, address receiver, address owner) returns (uint256 assets)— caller burns shares, vault returns the proportional assets.
The conversion functions convertToShares and convertToAssets let integrators preview a deposit or withdrawal without executing it. The preview functions previewDeposit, previewMint, previewWithdraw, and previewRedeem return the same values but factor in fees the vault may charge.
Share-Pricing Math
The share-to-asset conversion is the heart of ERC-4626. The standard specifies it as proportional: shares represent a pro-rata claim on the vault's assets.
For a deposit, the vault calculates: shares = assets * totalSupply / totalAssets. For a redeem: assets = shares * totalAssets / totalSupply. When yield accrues to the vault (the vault's underlying balance grows from interest, lending revenue, or strategy returns), totalAssets increases while totalSupply stays constant. Each existing share now claims more underlying asset — the share price went up.
This is why share tokens trade at a premium to the underlying. A user who deposits 100 USDC into an Aave aUSDC vault when the share price is 1:1 receives 100 aUSDC shares. Six months later, after lending revenue accrues, those 100 shares might redeem for 105 USDC. The vault tracked the yield by growing totalAssets; the user's share count never changed.
Production Implementations
Major DeFi vaults across the top chains implement ERC-4626 in 2026.
Aave v3 aTokens
Aave v3 aTokens are ERC-4626-compatible representations of supplied assets. A user supplies USDC to Aave's USDC market and receives aUSDC, which is itself an ERC-20 and exposes ERC-4626 share semantics. Aave's developer docs document the full interface. Aave v3 TVL has been volatile in April 2026 following the KelpDAO incident; check defillama.com/protocol/aave-v3 for the current value.
Yearn v3 Vaults
Yearn v3, launched in 2023, replaced Yearn v2's bespoke deposit/withdraw with full ERC-4626 compliance. Yearn v3 docs describe the strategy-and-allocator architecture. Each Yearn v3 vault is a single ERC-4626 contract that delegates to multiple strategies, with the allocator rebalancing capital between them.
Morpho Blue Markets
Morpho Blue, deployed in early 2024, exposes each isolated lending market as an ERC-4626 vault. Morpho Blue documentation details the market parameters: loan token, collateral token, oracle, IRM, and LLTV. MetaMorpho vaults are ERC-4626 wrappers that allocate across multiple Morpho Blue markets.
Pendle Principal Tokens
Pendle splits a yield-bearing asset into a principal token (PT) and a yield token (YT). The underlying SY (Standardized Yield) wrapper implements ERC-4626 to give Pendle a uniform interface across yield sources like Lido stETH, Aave aUSDC, and Ethena sUSDe.
The Inflation Attack and Mitigations
Early ERC-4626 implementations were vulnerable to a "donation" or "inflation" attack. An attacker could deposit one wei of shares as the vault's first depositor, then donate a large amount of assets directly to the vault contract (bypassing deposit), inflating the share-to-asset ratio. A subsequent depositor's convertToShares calculation would round down to zero shares, donating their deposit to the attacker.
The OpenZeppelin ERC4626 implementation mitigates this with virtual offset shares: the vault tracks an internal offset that prevents zero-share rounding for small deposits. Solmate's implementation uses a slightly different mitigation. Production deployments should pull from one of these audited libraries rather than write the math from scratch. OpenZeppelin's blog post on the attack details the math.
Tradeoffs and Limitations
ERC-4626 is a single-asset standard. A vault that holds multiple underlying assets (a balanced portfolio, an LP position with two tokens, a basket) cannot fit cleanly. EIP-7575 extends the standard for multi-asset vaults but adoption is early.
The standard does not specify withdrawal queue behavior. A vault with illiquid strategies may need to delay withdrawals; ERC-4626 allows this via the maxWithdraw and maxRedeem functions returning zero, but the standard does not define how a queued withdrawal completes. Yearn v3, Morpho, and Pendle each handle this differently.
ERC-4626 also does not handle cross-chain vault accounting. A vault deployed on multiple chains must coordinate share supply and asset balance through external messaging — a problem cross-chain standards like ERC-7802 address separately.
Why ERC-4626 Matters for Stablecoin Treasury
Stablecoin treasury teams routing capital across yield sources benefit when every source exposes the same interface. A treasury that holds USDC and wants to allocate across Aave, Morpho, and Yearn v3 calls deposit(amount, treasury) on each vault and receives shares in return. Eco's stablecoin orchestration network composes ERC-4626 vaults inside cross-chain intent flows: a single intent can deposit USDC on Arbitrum into an Aave market, with the destination vault address treated as a standard ERC-4626 endpoint. Read the programmable stablecoin treasury overview for how vault standards compose with treasury automation.
Common Adapter Patterns
Most ERC-4626 integrations are not greenfield. They sit on top of older lending pools, staking contracts, or yield aggregators that predate the standard, so adapters do the bridging. Four patterns recur across production deployments. The wrapper-vault pattern wraps a non-4626 contract (legacy Compound v2 cTokens or Curve gauge positions) inside a thin 4626 facade that translates the standard methods into the underlying protocol's calls. The share-token transfer pattern treats vault shares as fully fungible ERC-20s, so a recipient can receive yield-bearing positions directly without unwinding. ERC-2612 permit support on the share token itself lets users sign a single approval for both deposit and a downstream action like supplying the shares as collateral, collapsing two transactions into one. Gas considerations dominate the design choice: each adapter call adds an external function hop, and on Ethereum mainnet a poorly-batched 4626 deposit can cost two to three times what the native protocol's deposit would. Production adapters batch reads with a single multicall and route writes through a router contract that consolidates approvals, which is how Yearn v3 and Morpho Blue keep effective gas overhead under 15 percent versus calling the underlying directly.
FAQ
Is ERC-4626 backward compatible with ERC-20?
Yes. An ERC-4626 vault is itself an ERC-20 token — the share token. Wallets and DeFi protocols that consume ERC-20 tokens can transfer, approve, and trade vault shares without knowing the vault is ERC-4626-compliant. The 4626 functions are additive on top of the ERC-20 interface.
What is the difference between deposit and mint in ERC-4626?
Deposit takes an exact asset amount and mints whatever share count corresponds. Mint takes an exact share count and pulls whatever asset amount is required. Most users call deposit; mint is useful when an integrator wants to target a precise share balance regardless of the current price.
How do ERC-4626 vaults track yield?
The vault's totalAssets grows as yield accrues, while totalSupply of shares stays constant. Each share now claims a larger fraction of the underlying. The share price (assets per share) increases over time. Users do not receive new share tokens; their existing shares appreciate.
Can ERC-4626 vaults charge fees?
Yes. The standard accommodates fees via the difference between conversion and preview functions. convertToShares returns the gross conversion. previewDeposit returns the net after fees. Vaults may take performance fees on yield, deposit/withdrawal fees, or management fees on assets under management.
What is the inflation attack on ERC-4626?
An attacker as the first depositor manipulates the share-to-asset ratio by donating assets directly to the vault, causing subsequent small deposits to round down to zero shares. OpenZeppelin and Solmate implementations mitigate the attack with virtual offset shares. Vaults built without these mitigations have lost user funds in production.

