ERC-4626 standardizes how an application deposits assets into a tokenized vault, receives shares and later redeems them. It defines an interface and accounting expectations, not a yield strategy or a guarantee that any vault is safe. This technical reference examines the standard beyond the short glossary definition. [1]
Last updated: 2026-10-08
Document and authors
- Title: ERC-4626: Tokenized Vaults.
- Authors: Joey Santoro, t11s, Jet Jadeja, Alberto Cuesta Cañada and Señor Doggo.
- Created: December 22, 2021.
- Status: Final ERC, checked October 8, 2026.
- Rights: the specification waives copyright and related rights through CC0.
The source is an Ethereum standard, not a standalone project whitepaper. It targets shares representing holdings managed in one underlying ERC-20 asset. The vault shares implement ERC-20 and its optional metadata extensions. A nontransferable implementation may reject share transfers; ERC-2612 permit support is optional. [1] [5]
Assets and shares are different units
asset() identifies the underlying token. totalAssets() reports the assets managed by the vault, while totalSupply() measures outstanding share units. The numbers cannot be compared without conversion and decimal handling. The standard leaves strategy allocation and accounting details to implementations. [1]
For a simplified, fee-free vault with 100 asset units backing 200 share units, one share represents 0.5 asset units. Depositing 10 asset units would correspond to 20 shares if the exchange rate stays unchanged. This is an arithmetic illustration, not a quote from a live vault. Virtual balances, fees, rounding and implementation-specific accounting can change the calculation.
Four ways to enter or exit
| Operation | Amount fixed by caller | Result |
|---|---|---|
deposit |
Assets to deposit | Shares minted |
mint |
Shares to receive | Assets required |
withdraw |
Assets to receive | Shares burned |
redeem |
Shares to burn | Assets returned |
These are not interchangeable amounts. Withdrawal and redemption also distinguish the share owner from the receiver; spending another owner’s shares requires appropriate authorization. Deposit and Withdraw events record asset and share quantities. [1]
Conversions, previews and limits
convertToShares and convertToAssets give idealized, caller-independent conversions. They exclude fees and transaction-specific slippage and round down. The matching preview functions model the operation under current conditions and include its relevant fees. They do not determine whether user or global limits permit the operation. [1]
Use maxDeposit, maxMint, maxWithdraw and maxRedeem for applicable limits. A preview is not a reservation: conditions can change before execution. The standard also cautions against treating manipulable preview values as safe price oracles. An integration needs appropriate execution bounds and a valuation method suited to its purpose. [1]
Rounding and donation attacks
Different operations require opposing rounding directions. Shares issued for a fixed deposit and assets returned for a fixed redemption round down; assets required for fixed-share minting and shares required for fixed-asset withdrawal round up. Both conversion functions round down. Using the wrong direction can transfer value unintentionally. [1]
In an unprotected empty or nearly empty vault, an attacker can acquire a small share position and donate underlying tokens to increase the apparent share price. A later deposit can receive too few shares after rounding. OpenZeppelin describes virtual assets, virtual shares and a precision offset as mitigations; these are implementation choices, not protections automatically supplied by ERC-4626. [2] [3]
OpenZeppelin and Solmate provide different base implementations. Their reviewed files carry MIT and AGPL-3.0-only licenses respectively, separate from the specification’s CC0 rights. Neither an interface label nor a library inheritance claim proves a deployed contract’s correctness. [3] [4]
Asynchronous and multi-asset extensions
ERC-7540 separately defines pending, claimable and claimed requests for asynchronous deposits or redemptions. The affected preview functions must revert, and existing entry or exit methods claim fulfilled requests. A synchronous ERC-4626 integration cannot assume identical behavior. [6]
ERC-7575 separately introduces share() and supports multiple asset entry points sharing a token. It externalizes the ERC-20 share dependency and explicitly notes incomplete compatibility with base ERC-4626. Multiple assets and queues should not be attributed to the base standard itself. [7]
What compatibility does not promise
The shared interface reduces custom integration work. Integrators still need to inspect the specific contract’s accounting, fees, liquidity, permissions, upgrades, underlying token behavior and strategy risks. A share’s value can fall, and withdrawals can be limited. Compliance does not ensure positive yield or automatic support by every DeFi protocol. [1]
Social Media Sentiment
Not applicable to this standards reference. No current adoption ranking or community sentiment is inferred from its Final status.
Last updated: 2026-10
Related Terms
- ERC-4626 — the glossary definition of this vault interface.
- Vault Strategies — approaches to managing deposited assets.
- Yield Farming — seeking returns through DeFi protocols.
See Also
- Yearn — protocol-specific vault architecture and risks.
- DeFi — the broader context for composable financial contracts.
Sources
- Santoro, t11s, Jadeja, Cuesta Cañada and Señor Doggo — ERC-4626: Tokenized Vaults. The Final standard defines the single-asset share interface, preview and limit semantics, rounding, security considerations and CC0 rights.
- OpenZeppelin Contracts 5.x — ERC-4626 guide. The implementation guide illustrates donation attacks, virtual offsets and fee-aware previews.
- OpenZeppelin — ERC4626 Solidity implementation. The reviewed source shows virtual-share accounting, opposing rounding directions and the MIT software license.
- Solmate — ERC4626 Solidity implementation. The standard-linked example implements the interface differently and carries an AGPL-3.0-only header.
- ERC-2612 — Permit Extension for EIP-20 Signed Approvals. The permit extension defines signed approvals with nonces, deadlines and domain separation.
- ERC-7540 — Asynchronous ERC-4626 Tokenized Vaults. This separate Final extension adds request and claim flows and changes applicable preview behavior.
- ERC-7575 — Multi-Asset ERC-4626 Vaults. This separate Final extension supports shared external share tokens and multiple asset entry points.