ERC-4626

What Is ERC-4626?

ERC-4626 is an Ethereum token standard that defines a common interface for tokenized vaults holding one underlying ERC-20 asset.

A tokenized vault accepts an underlying crypto asset and issues fungible share tokens that represent a proportional claim on the assets managed by the vault.

The official ERC-4626 specification standardizes deposits, withdrawals, share minting, share redemption, exchange-rate previews, and vault limits.

ERC-4626 is a Final Ethereum Request for Comments standard.

It was created to make yield-bearing vaults easier for wallets, decentralized applications, aggregators, and other smart contracts to integrate.

The standard is sometimes called the Tokenized Vault Standard.

ERC-4626 does not define one investment strategy or guarantee that deposited assets will earn a return.

It defines how compatible vaults communicate their asset accounting and entry or exit functions.

What Is a Tokenized Vault?

A tokenized vault is a smart contract that manages crypto assets and issues tokens representing claims on those assets.

A user deposits the vault’s supported underlying asset and receives vault shares.

The vault may lend assets, stake them, provide liquidity, hold them in reserve, or use another strategy defined by its code.

If the strategy earns income, the value represented by each share can increase.

If the strategy loses assets, the value represented by each share can decrease.

A vault share is therefore not automatically equal to one unit of the underlying asset.

Its value depends on the relationship between the vault’s managed assets and the total number of shares in circulation.

Why Was ERC-4626 Created?

Tokenized vaults existed before ERC-4626, but they often used different functions, accounting rules, and terminology.

An application integrating several vaults needed a separate adapter for each implementation.

Custom adapters increased development work and created more opportunities for accounting mistakes.

ERC-4626 introduced a shared interface so compatible vaults could use the same basic deposit, withdrawal, minting, redemption, and preview methods.

This standardization improves composability because one application can interact with many vaults through a familiar set of functions.

Standardization does not make the underlying strategies identical.

Every vault can still have different assets, fees, risks, limits, administrators, and investment logic.

Underlying Assets and Vault Shares

ERC-4626 distinguishes between assets and shares.

The asset is the ERC-20 token deposited into and withdrawn from the vault.

The share is the ERC-20 token issued by the vault to represent a claim on its managed assets.

For example, a user might deposit 100 units of an underlying token and receive 100 shares when the initial conversion rate is one asset per share.

If the vault later grows to 110 assets while only 100 shares exist, each share represents approximately 1.1 assets.

If the vault loses ten assets instead, each share may represent approximately 0.9 assets.

The exact result depends on the vault’s accounting, fees, rounding, and strategy performance.

ERC-4626 Shares Are ERC-20 Tokens

An ERC-4626 vault must implement ERC-20 for its share token.

Share holders can therefore have ERC-20 balances, allowances, transfers, and approvals.

The vault must also implement the optional ERC-20 metadata functions for its share name, symbol, and decimals.

A vault may make its shares non-transferable by reverting when users call

or .

This means ERC-4626 compatibility does not guarantee that shares can be freely traded.

Projects may restrict share transfers for technical, regulatory, accounting, or risk-management reasons.

The asset Function

The

function returns the contract address of the vault’s underlying ERC-20 token.

This address tells applications which asset is used for deposits, withdrawals, and vault accounting.

The standard requires the function not to revert.

Users should verify the returned token address rather than relying only on an asset name or symbol.

Different tokens can use the same display symbol.

A standard ERC-4626 vault manages one underlying ERC-20 asset.

Separate extensions are needed for native blockchain assets or vault structures with several asset entry points.

The totalAssets Function

The

function reports the amount of underlying assets managed by the vault.

It should include yield that has already become part of the vault’s managed holdings.

It must also account for fees charged against assets held by the vault.

The function should not revert.

The reported amount may include assets deployed through an external strategy rather than tokens sitting directly at the vault address.

Users should inspect how the implementation calculates managed assets.

Incorrect or manipulable accounting can produce misleading share prices and unsafe deposits.

How the ERC-4626 Exchange Rate Works

The vault exchange rate describes how many underlying assets correspond to a given number of shares.

A simplified calculation divides total managed assets by total share supply.

Real implementations may add virtual assets, virtual shares, fees, offsets, or strategy-specific accounting.

The exchange rate can increase when the vault earns yield or receives donated assets.

It can decrease when the vault loses assets or recognizes bad debt.

The exchange rate is not necessarily a market price from an external trading venue.

It is an accounting relationship defined by the vault contract.

The convertToShares Function

The

function estimates how many shares correspond to a specified amount of underlying assets under ideal conditions.

It is intended as an average conversion calculation rather than an exact promise for one transaction.

The result must not include deposit fees.

It must not change according to the identity of the caller.

It must not reflect temporary vault limits or conditions that apply only to one user.

The standard requires the conversion to round down toward zero.

An application needing the likely result of an actual deposit should use

instead.

The convertToAssets Function

The

function estimates how many underlying assets correspond to a specified number of vault shares under ideal conditions.

It must not include withdrawal fees.

It must not vary according to the caller.

It also rounds down toward zero.

The function can be useful for portfolio displays and general accounting.

It should not be treated as a guaranteed withdrawal quote because real exits can be affected by fees, limits, available liquidity, and changing vault state.

Deposit vs. Mint

The

and functions both enter an ERC-4626 vault, but they define the transaction from different directions.

With

, the user specifies the exact amount of underlying assets to contribute.

The vault calculates how many shares the receiver obtains.

With

, the user specifies the exact number of shares the receiver should obtain.

The vault calculates how many underlying assets must be supplied.

This distinction is important when an application needs either a fixed input amount or a fixed output amount.

The deposit Function

The

function transfers an exact amount of underlying assets into the vault and issues shares to a selected receiver.

Most implementations require the caller to approve the vault to spend the underlying ERC-20 asset first.

The transaction must revert if the full asset amount cannot be deposited.

This can occur because of a deposit limit, insufficient approval, insufficient balance, a paused vault, or another restriction.

A successful deposit must emit a standardized

event.

The function returns the number of shares issued to the receiver.

The mint Function

The

function issues an exact number of vault shares to a receiver.

The caller provides the amount of underlying assets required by the vault’s current accounting.

The transaction must revert if the requested number of shares cannot be minted.

The required asset amount can include entry fees when the vault charges them.

A successful mint must emit the

event because both deposit and mint operations represent entry into the vault.

Withdraw vs. Redeem

The

and functions both exit an ERC-4626 vault.

With

, the caller specifies the exact amount of underlying assets the receiver should obtain.

The vault calculates how many shares must be burned.

With

, the caller specifies the exact number of shares to burn.

The vault calculates how many assets the receiver obtains.

The owner of the shares and the recipient of the withdrawn assets can be different addresses.

When the caller is not the share owner, the caller generally needs sufficient ERC-20 share allowance.

The withdraw Function

The

function sends an exact amount of underlying assets to a receiver and burns the required shares from an owner.

The function must revert if the requested assets cannot be withdrawn.

Possible reasons include insufficient shares, insufficient allowance, liquidity limits, withdrawal restrictions, or a paused strategy.

The number of shares burned may include an exit fee reflected through the conversion process.

A successful withdrawal must emit the standardized

event.

The redeem Function

The

function burns an exact number of shares and sends the corresponding assets to a receiver.

The function returns the amount of underlying assets delivered.

It must revert when the complete share amount cannot be redeemed.

The returned asset amount can be reduced by an exit fee.

A successful redemption must emit the

event.

ERC-4626 Preview Functions

ERC-4626 includes preview functions that estimate the outcome of an entry or exit transaction under current on-chain conditions.

The functions are

, , , and .

Unlike the general conversion functions, previews should include applicable fees.

They should model the result as closely as possible without changing blockchain state.

A preview can become outdated before a transaction executes because another transaction may change the vault’s assets, supply, fees, or limits.

Applications should combine previews with slippage controls rather than assuming the quoted result is guaranteed.

previewDeposit and previewMint

estimates the number of shares produced by depositing a specified asset amount.

It should return no more shares than the actual deposit would issue in the same transaction state.

estimates the number of assets required to mint a specified number of shares.

It should return at least as many assets as the actual mint would require in the same transaction state.

These rounding directions protect the vault from promising users more favorable results than the state-changing functions can provide.

previewWithdraw and previewRedeem

estimates the number of shares that must be burned to receive a specified asset amount.

It should return at least as many shares as the actual withdrawal would require in the same transaction state.

estimates the number of assets obtained by redeeming a specified number of shares.

It should return no more assets than the actual redemption would provide in the same transaction state.

These functions help interfaces explain costs before asking users to authorize an exit.

Maximum Deposit and Mint Limits

The

function reports the largest asset amount that can currently be deposited for a receiver.

The

function reports the largest number of shares that can currently be minted for a receiver.

These values should account for global limits and receiver-specific restrictions.

If deposits are disabled, the relevant maximum should return zero instead of reverting.

If no practical limit exists, a vault can return the maximum unsigned integer value.

A maximum is not a reservation because vault conditions can change before the user’s transaction executes.

Maximum Withdrawal and Redemption Limits

The

function reports the largest asset amount that an owner can currently withdraw.

The

function reports the largest share amount that an owner can currently redeem.

These limits can reflect share balances, liquidity restrictions, lockups, paused operations, and other vault rules.

A vault may hold valuable assets while reporting a low maximum withdrawal because those assets are not immediately liquid.

Applications should not assume that the vault’s total assets are always available for instant redemption.

ERC-4626 Events

ERC-4626 defines

and events in addition to normal ERC-20 share events.

The

event records the caller, share owner, deposited asset amount, and issued share amount.

The

event records the caller, asset receiver, share owner, withdrawn asset amount, and burned share amount.

Applications can use these events to track vault entry and exit activity.

ERC-20

events also record the minting, burning, and transfer of vault shares.

Indexers should understand the relationship between these events to avoid counting one vault action twice.

Vault Yield and Share Value

An ERC-4626 vault normally reflects yield through an increasing amount of assets represented by each share.

The contract does not need to send new shares to every holder whenever yield is earned.

Instead, the same number of shares can become redeemable for more underlying assets.

A vault can also distribute value through another accounting method when its implementation remains compliant.

Users should verify how and when strategy earnings are recognized by

.

Pending, unrealized, or externally reported yield may not be immediately withdrawable.

Vault Fees

ERC-4626 permits vaults to charge fees.

Possible charges include entry fees, exit fees, management fees, performance fees, and strategy expenses.

The standard does not prescribe one fee structure or maximum rate.

Preview functions should reflect fees that apply to the simulated operation.

General conversion functions should exclude fees.

Users should review who receives the fees, how they are calculated, whether administrators can change them, and whether they are charged in assets or shares.

A high advertised yield can become much smaller after all fees and losses are included.

Rounding and Small Deposits

ERC-4626 calculations use integer arithmetic because smart contracts cannot issue fractions smaller than the share token’s minimum unit.

Rounding can therefore cause a depositor to receive slightly fewer shares than an exact mathematical calculation suggests.

The loss becomes more significant when a deposit produces only a very small number of share units.

In an extreme case, a deposit can round down to zero shares.

A user who deposits assets and receives zero shares effectively transfers value to existing share holders.

Applications should reject deposits that produce an unacceptably small number of shares.

What Is an ERC-4626 Inflation Attack?

An inflation attack manipulates a vault’s asset-to-share conversion rate, especially when the vault is empty or has very little liquidity.

An attacker can make a small initial deposit and then transfer underlying assets directly to the vault without minting additional shares.

This donation increases the assets associated with the attacker’s existing shares.

A later user’s deposit may then round down to very few shares or zero shares.

The attacker can redeem the original shares and capture part or all of the victim’s deposited assets.

The current ERC-4626 security guide explains this first-deposit manipulation and its relationship with rounding.

Defending Against Inflation Attacks

One defense uses virtual assets and virtual shares when calculating the exchange rate.

These virtual amounts establish a safer initial rate before users make real deposits.

A decimal offset can also give shares greater precision than the underlying asset.

Greater precision makes it harder for a normal deposit to round down to zero shares.

Current maintained implementations can include these protections, but not every deployed ERC-4626 vault uses them.

Applications should also require minimum share output and reject unfavorable deposits.

Seeding a vault with permanently locked liquidity is another possible design, although it creates different operational considerations.

Slippage Risk

Slippage occurs when the actual deposit or withdrawal result differs from the amount a user expected.

Another transaction can change the exchange rate between the preview and execution of the user’s transaction.

Fees, donations, strategy reports, losses, and other deposits or withdrawals can also alter the result.

The base ERC-4626 entry and exit functions do not include explicit minimum-output or maximum-input parameters.

The ERC-5143 extension proposes overloaded functions with slippage controls for direct user interactions.

An application can also use a router or wrapper that checks the final result against a user-defined limit.

Share Price Manipulation and Oracles

Applications sometimes use an ERC-4626 share’s conversion rate as a source of value.

This can be dangerous when the rate can be changed by direct donations, delayed accounting, low liquidity, or a manipulable strategy.

A lending protocol using vault shares as collateral must understand how easily

and share supply can change.

One transaction may create a temporary rate that is unsafe as a price oracle.

An ERC-4626 conversion function reports vault accounting and should not automatically be treated as a manipulation-resistant market price.

Integrations may need independent pricing, time-weighted data, rate limits, or other safeguards.

Reentrancy and Token Transfer Risk

Deposits and withdrawals interact with external token contracts.

A malicious or unusual token can execute callbacks, return unexpected values, charge transfer fees, or modify balances in a nonstandard way.

External strategy contracts can also call back into the vault.

Developers should update critical accounting in a safe order and use appropriate reentrancy protection.

The Solidity security guidance explains why every external contract call should be treated as a potential control transfer.

Protecting only one entry function may be insufficient when an attacker can reenter through another vault function.

Nonstandard Underlying Tokens

Fee-on-transfer tokens can cause the vault to receive fewer assets than the amount requested by the depositor.

Rebasing tokens can change the vault’s balance without an ordinary transfer.

Tokens with blocked addresses or pause controls can prevent withdrawals.

Tokens with unusual decimal values can increase conversion and display complexity.

An upgradeable underlying token can change its behavior after the vault is deployed.

Vault developers should measure actual token movement and test the behavior of the specific asset rather than assuming perfect ERC-20 behavior.

Strategy and Liquidity Risk

ERC-4626 standardization does not limit what the vault does with deposited assets.

A strategy may involve lending, staking, liquidity provision, derivatives, bridges, or external custody.

Each activity introduces separate smart contract, market, counterparty, oracle, liquidation, and liquidity risks.

A vault may report valuable assets while being unable to retrieve them quickly.

It may also recognize losses when an external position becomes insolvent.

Users should evaluate the strategy and not only the ERC-4626 interface.

Administrator and Upgrade Risk

An ERC-4626 vault can contain administrator roles that control fees, limits, strategies, pauses, or emergency withdrawals.

An upgradeable vault can change its implementation after users receive shares.

Upgrades can repair vulnerabilities but can also introduce malicious or unsafe behavior.

A compromised administrator may redirect assets, approve a harmful strategy, or block normal exits.

Users should inspect upgrade authority, time locks, multisignature requirements, emergency powers, and role separation.

ERC-4626 compliance does not mean that a vault is decentralized or immutable.

ERC-4626 and Native ETH

The base ERC-4626 standard requires one underlying ERC-20 token.

Native ETH is not an ERC-20 contract, so it does not directly satisfy this requirement.

A vault can use a tokenized representation of ETH as its underlying ERC-20 asset.

The Final ERC-7535 extension adapts the ERC-4626 interface for vaults whose underlying asset is native ETH.

Users should confirm whether a vault expects native ETH or an ERC-20 representation because sending the wrong asset may fail or become inaccessible.

Synchronous and Asynchronous Vaults

Standard ERC-4626 is designed mainly for atomic entry and exit flows.

A deposit, mint, withdrawal, or redemption normally completes within one blockchain transaction when allowed.

Some strategies need a request period before assets or shares become claimable.

The ERC-7540 standard extends ERC-4626 with asynchronous deposit and redemption requests.

This can support strategies involving delayed settlement, limited liquidity, cross-chain activity, or off-chain assets.

An asynchronous vault should not be evaluated as though every ERC-4626 exit were immediately available.

Single-Asset and Multi-Asset Vaults

A standard ERC-4626 vault has one underlying ERC-20 asset and one vault share token.

Some vault systems need several asset entry points that all produce the same share token.

The ERC-7575 standard adapts ERC-4626 for multi-asset vault structures and can separate the vault entry point from the share token.

This extension adds different integration and interface-detection requirements.

A contract should not claim ordinary ERC-4626 behavior while silently accepting several unrelated assets through undocumented accounting.

Does ERC-4626 Have an Interface ID?

The base ERC-4626 specification does not require ERC-165 interface detection.

This differs from standards such as ERC-721, which define mandatory ERC-165 support.

Applications commonly detect ERC-4626 through its functions, published ABI, verified source code, registry information, or project documentation.

Calling one familiar function is not enough to prove complete compliance.

An integration should confirm the full interface and test the vault’s required behavior.

How Developers Can Implement ERC-4626

Developers should begin with a maintained and reviewed implementation rather than creating vault accounting from the beginning.

The current ERC-20 and ERC-4626 API documentation provides a reusable implementation intended to be extended with a strategy.

The implementation still requires developers to define how assets are deployed, valued, recovered, and protected.

Developers should test deposits, mints, withdrawals, redemptions, fees, rounding, direct donations, empty-vault behavior, losses, and unusual underlying tokens.

Invariant tests should verify that users cannot withdraw more assets than their shares justify.

Security reviews should also cover administrators, external strategies, price feeds, upgrade paths, and emergency procedures.

How Users Can Evaluate an ERC-4626 Vault

The first step is to verify the vault and underlying asset contract addresses.

The second step is to identify the strategy that produces the expected return.

The third step is to review entry, exit, management, performance, and strategy fees.

The fourth step is to inspect the current assets, share supply, conversion rate, and available withdrawal limits.

The fifth step is to check whether the vault includes first-deposit and inflation-attack protections.

The sixth step is to review administrator, upgrade, pause, and emergency powers.

The seventh step is to understand whether withdrawals are synchronous, delayed, queued, or dependent on external liquidity.

The eighth step is to examine audits and incident history without treating an audit as a guarantee.

The ninth step is to apply slippage limits and avoid transactions that would issue an extremely small number of shares.

The tenth step is to test an unfamiliar vault with a limited amount before exposing significant assets.

Example of an ERC-4626 Deposit

Suppose a vault manages 1,000 units of an underlying asset and has 1,000 shares in circulation.

Each share represents approximately one asset before fees and rounding.

A user asks

how many shares a deposit of 100 assets would produce.

The preview returns 99 shares because the vault charges an entry fee and rounds according to its implementation.

The user approves the vault to spend 100 underlying tokens.

The user then calls

with 100 assets and selects a receiving address.

The vault transfers the assets, updates its accounting, mints 99 shares, and emits a

event.

If the strategy later earns assets without issuing more shares, those 99 shares may become redeemable for more underlying tokens.

If the strategy loses value, the same shares may become redeemable for less.

Common ERC-4626 Mistakes

One common mistake is assuming that one vault share always equals one underlying asset.

Another mistake is using

as a guaranteed deposit quote.

A third mistake is submitting a deposit without a minimum acceptable share result.

A fourth mistake is ignoring rounding losses on small deposits.

A fifth mistake is assuming that

equals the tokens held directly by the vault address.

A sixth mistake is using the vault exchange rate as a secure price oracle without manipulation analysis.

A seventh mistake is assuming that all managed assets are available for immediate withdrawal.

An eighth mistake is evaluating the standard while ignoring the vault’s underlying strategy.

A ninth mistake is treating an audit as proof that losses cannot occur.

A tenth mistake is assuming that ERC-4626 compliance guarantees fair fees, safe administrators, or profitable yield.

FAQ

What does ERC-4626 mean?

ERC-4626 is the Ethereum Tokenized Vault Standard for vaults that issue ERC-20 shares representing claims on one underlying ERC-20 asset.

Is ERC-4626 an ERC-20 token?

An ERC-4626 vault must implement ERC-20 for its vault shares.

What is the underlying asset?

The underlying asset is the ERC-20 token accepted for deposits and delivered through withdrawals.

What is an ERC-4626 share?

A share is a fungible token representing a proportional claim on the assets managed by the vault.

Does one share always equal one asset?

No, the conversion rate changes according to managed assets, share supply, fees, rounding, profits, and losses.

Does ERC-4626 guarantee yield?

No, it standardizes vault interactions and does not guarantee that a strategy will earn a positive return.

What is the difference between deposit and mint?

specifies the asset input, while specifies the desired share output.

What is the difference between withdraw and redeem?

specifies the desired asset output, while specifies the number of shares to burn.

What does totalAssets return?

It returns the amount of underlying assets managed by the vault according to its accounting logic.

Do preview functions guarantee the final result?

No, the vault state can change before transaction execution, so applications should use slippage protection.

Can ERC-4626 vaults charge fees?

Yes, vaults can charge entry, exit, management, performance, or other disclosed fees.

What is an ERC-4626 inflation attack?

It is an attack that manipulates an early vault exchange rate so a victim’s deposit rounds down to very few shares or zero shares.

How can a vault reduce inflation-attack risk?

Possible defenses include virtual assets, virtual shares, greater share precision, locked initial liquidity, and minimum-output checks.

Can an ERC-4626 vault lose money?

Yes, strategy losses, exploits, bad debt, market movements, administrator compromise, and external failures can reduce share value.

Can ERC-4626 shares be transferred?

They normally support ERC-20 transfers, but a vault is allowed to make its shares non-transferable.

Can ERC-4626 use native ETH?

The base standard requires an ERC-20 asset, while ERC-7535 adapts the interface for native ETH vaults.

Can an ERC-4626 vault manage several underlying assets?

The base standard manages one asset, while extensions such as ERC-7575 support multi-asset structures.

Does ERC-4626 support delayed withdrawals?

The base standard focuses on atomic operations, while ERC-7540 extends it with asynchronous request and claim flows.

Does ERC-4626 require ERC-165 support?

No, the base ERC-4626 specification does not require ERC-165 interface detection.

Is an ERC-4626 vault safe because it follows a standard?

No, compliance improves interoperability but does not prove that the strategy, accounting, contracts, or administrators are safe.

Conclusion

ERC-4626 is Ethereum’s standard interface for tokenized vaults that manage one underlying ERC-20 asset and issue ERC-20 shares.

It standardizes deposits, mints, withdrawals, redemptions, conversion estimates, preview functions, vault limits, and entry or exit events.

The standard makes vaults easier for wallets and smart contracts to integrate without forcing every vault to use the same investment strategy.

Vault shares represent proportional claims rather than fixed one-to-one balances with the underlying asset.

Their value can rise through strategy income or fall through losses, fees, bad debt, and security failures.

Rounding, slippage, direct donations, and first-deposit inflation attacks require careful protection.

Developers should use maintained implementations, test empty-vault behavior, protect external calls, and provide minimum-output controls.

Users should evaluate the underlying strategy, liquidity, fees, administrator powers, upgrade system, and withdrawal process rather than relying only on ERC-4626 compatibility.

Extensions can adapt the standard for native assets, asynchronous settlement, slippage protection, and multi-asset structures.

Understanding ERC-4626 helps crypto users distinguish standardized vault accounting from the separate financial and technical risks of the strategy managing their assets.