ERC-4626 (Tokenized Vault Standard)

What Is ERC-4626?

ERC-4626 is an Ethereum token standard that provides a unified interface for tokenized yield-bearing vaults. Finalized in March 2022, the standard was authored by Joey Santoro, t11s (transmissions11), Jet Jadeja, and Alberto Cuesta Cañada. It extends the ERC-20 token standard, meaning every ERC-4626 vault share is also a valid ERC-20 token that can be transferred, traded, or used as collateral in other protocols.

Before ERC-4626, every vault protocol designed its own deposit and withdrawal interface. Yearn's yVaults, Aave's aTokens, Compound's cTokens, and Balancer's BPTs all worked differently. Developers building aggregators, dashboards, or composable strategies had to write custom integration code for each vault type. Bugs in these adapters led to millions of dollars in losses. ERC-4626 solved this by giving the ecosystem a single ABI to build against.

How It Works

At its core, an ERC-4626 vault holds an underlying ERC-20 asset (like USDC, DAI, or WETH) and issues shares representing a depositor's proportional claim on the total assets in the vault. As the vault earns yield, the total assets grow while the share supply remains constant. This means each share is worth more over time.

Core Functions

The standard defines four mutative functions that handle all value flow into and out of the vault:

// Deposit a specific amount of underlying assets, receive shares
function deposit(uint256 assets, address receiver) returns (uint256 shares)

// Mint a specific number of shares, depositing whatever assets are required
function mint(uint256 shares, address receiver) returns (uint256 assets)

// Withdraw a specific amount of underlying assets by burning shares
function withdraw(uint256 assets, address receiver, address owner) returns (uint256 shares)

// Redeem a specific number of shares for underlying assets
function redeem(uint256 shares, address receiver, address owner) returns (uint256 assets)

The distinction between deposit/mint and withdraw/redeem is about which side of the conversion you specify. With deposit(), you say how many assets you want to put in and receive however many shares that buys. With mint(), you say how many shares you want and pay whatever asset amount is required. The same logic applies in reverse for withdrawals.

Share-to-Asset Conversion

The exchange rate between shares and assets is determined by two view functions:

function convertToShares(uint256 assets) returns (uint256 shares)
function convertToAssets(uint256 shares) returns (uint256 assets)

The math is straightforward. If a vault holds 1,000,000 USDC in total assets and has 900,000 shares outstanding, each share is worth approximately 1.111 USDC. A depositor who redeems 100 shares would receive about 111.1 USDC. This ratio changes over time as the vault accrues yield or incurs losses.

// Simplified conversion math
shares = (depositAmount * totalSupply) / totalAssets
assets = (shareAmount * totalAssets) / totalSupply

Preview and Limit Functions

ERC-4626 also requires preview functions that simulate operations without executing them, and limit functions that report maximum allowable operations:

• previewDeposit(), previewMint(), previewWithdraw(), previewRedeem(): return the expected output of each operation, accounting for fees or slippage
• maxDeposit(), maxMint(), maxWithdraw(), maxRedeem(): return the maximum amount a specific address can operate with, reflecting caps, allowlists, or available liquidity
• totalAssets(): returns the total amount of underlying assets managed by the vault, including any yield that has accrued

These functions make vault integrations predictable. A frontend or smart contract can check exact outputs before committing a transaction, eliminating guesswork.

Why Standardization Matters

The pre-ERC-4626 landscape illustrates why standardization was necessary. Consider a yield aggregator that wants to route deposits across five different lending protocols. Without a standard, the aggregator team must:

1. Study each protocol's unique interface and documentation
2. Write and audit separate adapter contracts for each integration
3. Handle edge cases specific to each protocol's accounting model
4. Maintain all adapters as underlying protocols upgrade

With ERC-4626, the same aggregator writes one integration that works with any compliant vault. This composability accelerates development, reduces audit surface area, and lowers the barrier for new protocols to plug into the existing ecosystem.

The standard also benefits end users. Wallet interfaces can display balances and yields from any ERC-4626 vault without protocol-specific logic. Portfolio trackers automatically understand share-to-asset conversions. This is the same network effect that made ERC-20 the universal token standard: once tools support the interface, every new vault gets that tooling for free.

Use Cases

Yield Aggregation

Yield aggregators like Yearn V3 use ERC-4626 as their native vault interface. Users deposit assets, receive vault shares, and the aggregator deploys capital across strategies to maximize returns. Because the shares are ERC-20 compatible, they can be deposited into other ERC-4626 vaults, creating nested yield strategies. An aggregator vault could hold shares of lending vaults, which themselves hold shares of liquidity pool vaults.

Lending Markets

Lending protocols use ERC-4626 to represent deposit positions. When a user supplies USDC to a lending pool, they receive vault shares that appreciate as borrowers pay interest. Aave's wrapped aTokens and Morpho's MetaMorpho vaults both conform to ERC-4626, allowing their deposit tokens to integrate seamlessly with the broader DeFi stack.

Liquid Staking

Liquid staking protocols issue ERC-4626 vault shares representing staked ETH plus accrued rewards. The vault's totalAssets() grows as staking rewards come in, increasing the share price. Users hold a single token that automatically reflects their staking yield without needing to claim rewards.

Tokenized Real-World Assets

Tokenized Treasury bill vaults and other real-world asset products use ERC-4626 to represent yield-bearing positions in traditional financial instruments. The vault holds T-bills or money market fund shares, and the ERC-4626 interface exposes the yield to on-chain composability.

Restaking

Restaking protocols wrap staked positions in ERC-4626 vaults, allowing restaked assets to be used across additional security layers. The standard's accounting functions cleanly handle the multi-layered yield accrual that restaking introduces.

Risks and Considerations

Inflation Attack

The most well-known vulnerability in ERC-4626 vaults is the inflation attack (also called the donation attack). It targets the first depositor in a vault:

1. An attacker deposits a small amount (e.g., 1 wei) to receive 1 share
2. The attacker then directly transfers (donates) a large amount of the underlying asset to the vault contract, inflating totalAssets() without minting new shares
3. When a victim deposits, the share calculation rounds down due to the inflated exchange rate, and the victim receives 0 shares for a substantial deposit
4. The attacker redeems their 1 share and receives both their donated amount and the victim's deposit

The root cause is integer rounding in the share calculation when totalSupply is very small. Several mitigations exist:

• Virtual shares and virtual assets: the vault initializes with a non-zero offset (e.g., adding 1 to both totalSupply and totalAssets in the conversion math), making the attack economically impractical. OpenZeppelin's ERC-4626 implementation uses this approach by default with a configurable offset.
• Dead shares: the vault deployer mints and burns a small number of initial shares to a dead address, ensuring the pool starts with a meaningful share supply
• Minimum deposit thresholds: requiring deposits above a certain size reduces the rounding loss relative to the deposit amount

Rounding Direction

The ERC-4626 specification mandates specific rounding behavior: conversions should round in favor of the vault (against the user). This means deposit() and mint() should round up (user pays slightly more), while withdraw() and redeem() should round down (user receives slightly less). Incorrect rounding opens arbitrage opportunities that can drain the vault.

Non-Standard Implementations

Not all vaults that claim ERC-4626 compliance fully implement the spec. Some vaults have withdrawal delays, lock-up periods, or fee structures that cause preview functions to return inaccurate estimates. Integrators should verify behavior against the spec rather than assuming compliance from interface alone. Formal verification and thorough testing remain essential for any contract interacting with external vaults.

Fee-on-Transfer Tokens

Vaults holding fee-on-transfer or rebasing tokens require special handling. The standard assumes that the amount of assets transferred matches the amount received by the vault. Tokens that take a fee on transfer break this assumption, causing totalAssets() to report incorrectly and share pricing to drift.

ERC-4626 and the Broader Ecosystem

Since its finalization, ERC-4626 has become one of the most widely adopted Ethereum standards after ERC-20 and ERC-721. Hundreds of vaults across lending, staking, yield farming, and asset management have adopted the interface. The standard has also influenced design on other chains: Solana and Cosmos ecosystems have drawn on ERC-4626's vault abstraction concepts.

For the stablecoin ecosystem, ERC-4626 is particularly relevant. Yield-bearing stablecoins like sDAI and other wrapped savings products use ERC-4626 vaults to distribute interest to holders. A user deposits DAI into the DSR vault, receives sDAI shares, and the share price increases as the Dai Savings Rate accrues. This pattern enables stablecoins to carry yield natively, a capability that intersects with broader stablecoin yield infrastructure.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.