What Is ERC-4626? The Tokenized Vault Standard Explained

ERC-4626 is the Ethereum standard for tokenised vaults. It defines one common set of functions for depositing a single ERC-20 token into a vault, receiving vault shares in return, and converting between the two, so any wallet, lending market or aggregator can integrate any compliant vault the same way. The vault's shares are themselves a token, and their value in the underlying asset rises as the vault earns.

This guide covers the interface, the shares-versus-assets maths with a worked example, the inflation attack, the async and multi-asset extensions, and how non-EVM chains such as Sui handle vault shares.

What is ERC-4626?

ERC-4626, titled "Tokenized Vaults", was created on 22 December 2021 by Joey Santoro, t11s, Jet Jadeja, Alberto Cuesta Cañada and Señor Doggo. It is a Standards Track ERC with Final status, and it builds on ERC-20 and ERC-2612 (permit signatures), according to the EIP page. Its abstract describes it as a "standard API for tokenized Vaults representing shares of a single underlying EIP-20 token".

Before it existed, every yield aggregator, lending market and staking wrapper wrote its own vault interface. Any app that wanted to support ten vaults needed ten adapters, each a new place for bugs. ERC-4626 replaced that with one shape, in the same way ERC-20 did for fungible tokens.

The standard fixes the interface, not the strategy: a risky or malicious vault can be fully compliant. For the broader picture of what vaults do with your money, see crypto vaults explained.

The ERC-4626 interface, function by function

A compliant vault is an ERC-20 token (the shares) plus the functions below. Each one comes from the specification.

Function	What it does
asset()	The underlying token, for example USDC.
totalAssets()	All underlying assets the vault manages, including in strategies.
convertToShares / convertToAssets	The ideal exchange rate, ignoring fees and limits.
deposit(assets, receiver)	You choose how many assets to put in; the vault mints the matching shares.
mint(shares, receiver)	You choose how many shares you want; the vault pulls the assets needed.
withdraw(assets, receiver, owner)	You choose how many assets to take out; the vault burns the shares needed.
redeem(shares, receiver, owner)	You choose how many shares to burn; the vault sends the matching assets.
previewDeposit / previewMint / previewWithdraw / previewRedeem	Simulate each action at the current block, including fees.
maxDeposit / maxMint / maxWithdraw / maxRedeem	The most an address can deposit, mint, withdraw or redeem right now.

Two events, Deposit and Withdraw, give indexers one pattern to track every compliant vault.

Why the preview and max functions matter

The preview functions show what you would actually get in this block, after fees, which is what a front end should display before you sign. The max functions expose caps, pauses and liquidity limits, so a router can avoid a transaction that is bound to fail.

The spec warns that totalAssets, convertToShares and convertToAssets are "estimates useful for display purposes", and that the preview functions can be manipulated and are not always safe to use as price oracles. Our guide to price oracles explains why.

Shares vs assets: a worked example

The core of every vault is one ratio:

share price = totalAssets ÷ totalSupply of shares

Take a USDC vault that holds 1,000 USDC and has issued 1,000 shares. Each share is worth 1 USDC.

The strategy earns. Interest of 50 USDC arrives. Total assets are now 1,050 and there are still 1,000 shares, so each share is worth 1.05 USDC. Nobody's share count changed; the price did.
Alice deposits 210 USDC. She receives 210 × 1,000 ÷ 1,050 = 200 shares. The vault now holds 1,260 USDC against 1,200 shares, and the price is still 1.05. Her deposit did not dilute anyone.
The vault earns again. Total assets reach 1,320 USDC. The price is 1,320 ÷ 1,200 = 1.10.
Alice redeems her 200 shares. She gets 200 × 1.10 = 220 USDC, a 10 USDC gain, before any fees.

This is why ERC-4626 tokens such as Sky's sUSDS never increase your balance; each token simply redeems for more of the asset over time. Our USDS and sUSDS guide walks through that case.

Rounding always favours the vault

Real numbers rarely divide cleanly. The spec says that when the vault issues shares for a deposit, or pays out assets for shares, it should round down. When it calculates how many shares you must burn, or how many assets you must supply, it should round up. The convertTo functions must always round down.

Every rounding error therefore leaves a tiny amount in the vault rather than letting one user extract it from the others.

The inflation attack and how vaults defend against it

Rounding has one dangerous edge case: a nearly empty vault. The inflation or donation attack is described in OpenZeppelin's ERC-4626 documentation.

An attacker becomes the first depositor and mints a tiny number of shares, say one share for the smallest unit of USDC.
Before the next user's deposit lands, the attacker sends a large amount of USDC straight to the vault contract as a "donation". No shares are minted for it, but totalAssets jumps, so the price of that single share balloons.
The victim's deposit is converted at the inflated price and rounds down to zero, or to far fewer shares than it should.
The attacker redeems their share and walks away with most of the victim's deposit.

The attack usually relies on front-running a vault's first deposits.

Mitigations

Virtual shares and assets. OpenZeppelin added this defence to its ERC4626 contract in version 4.9.0, released on 23 May 2023, per its changelog. The maths behaves as if the vault always holds some extra shares and one extra unit of assets, which absorb part of any donation. OpenZeppelin says the attack is unprofitable even with an offset of zero, and that bigger offsets make it far more costly.
Seeding the vault. Some teams make a small first deposit themselves at launch and never withdraw it, so there is never an "empty vault" moment to exploit.
Internal accounting. Tracking totalAssets internally, rather than reading the token balance, ignores donations.
Slippage checks. Requiring a minimum number of shares out makes the deposit revert instead.

For users, the lesson is to be cautious about being among the first depositors in a brand-new, unaudited vault.

Extensions: ERC-7540 and ERC-7575

ERC-4626 assumes deposits and withdrawals settle instantly, which doesn't fit real-world-asset or slow-to-unwind strategies. Two later standards, both Final, fill the gaps.

ERC-7540: asynchronous vaults

ERC-7540, created on 18 October 2023, adds a request step. You call requestDeposit or requestRedeem, the request sits as Pending while the vault processes it, becomes Claimable, and you then finish with the normal deposit, mint, redeem or withdraw call. The spec says requests must not skip the claimable stage. There is deliberately no requestWithdraw: asynchronous exits go through requestRedeem.

ERC-7575: multi-asset vaults

ERC-7575, created on 11 December 2023, lets several entry points in different assets share one share token, and lets the share token live in a separate contract from the vault. Each vault exposes a share() function pointing to that token. The spec itself notes the trade-off: because the vault need not be its own ERC-20, it is "not fully compatible with ERC-4626".

Who uses ERC-4626?

A few verified examples, checked on 15 October 2026:

Yearn V3. Yearn says its v3 vaults "are designed to interoperate using the ERC-4626 standard", per its docs.
Morpho Vault V2. The Vault V2 repository states it is "ERC-4626 and ERC-2612 compliant", with one documented quirk: its maxDeposit, maxMint, maxWithdraw and maxRedeem functions always return zero. Our Morpho vaults explainer covers how curators run these vaults.
Sky's sUSDS. Sky's developer docs describe sUSDS as "fully compliant with the ERC-4626 standard", with no fees on the deposit and withdraw route.

Because these share tokens follow one interface, they plug into other protocols as collateral, fixed-yield legs or inputs to yield aggregators.

What ERC-4626 does not guarantee

"ERC-4626 compliant" tells you how to talk to a vault, not whether it is a good place for your money. The EIP's own security section warns that fully permissionless uses "could fall prey to malicious implementations". Before depositing, check:

Where the yield comes from. Our guide to yield-generating stablecoins breaks down the sources.
Who controls the strategy. Look for timelocks on owner or curator changes, and for audits.
Exit terms. A vault can be compliant and still limit withdrawals through its max functions, or use an ERC-7540 request queue.
Fees. Entry, exit and performance fees show up in the preview functions, not in convertToAssets.

Our checklist on how to check a DeFi protocol is safe applies to any vault, standard or not.

How non-EVM chains handle vault shares

ERC-4626 only applies on EVM chains. Other chains build vaults on their own token primitives.

Sui is a good example. Its coin standard describes Coin<T> as the type for fungible tokens, with a TreasuryCap object required to mint or burn them. A Sui vault typically holds the treasury capability for its own share coin, mints shares on deposit and burns them on withdrawal, and prices them as net assets divided by supply: the same idea as ERC-4626, but with no shared function names. Sui's docs list no vault-share standard, so each protocol defines its own interface.

Where JewelSwap fits: JewelSwap's Ember Loop on Sui follows this pattern. You deposit USDC and receive jeLOOP, a normal Sui coin priced at the vault's net asset value divided by jeLOOP supply, and exits are queued withdrawal tickets, much like an ERC-7540 request. Ember Loop is a public beta, it is unaudited, it uses leverage, and US and UK residents should not use it. The Ember Loop docs and our Ember Loop explainer cover the mechanics, fees and risks.

Frequently asked questions

What is ERC-4626 in simple terms?

ERC-4626 is the Ethereum standard for tokenised vaults. It gives every vault the same functions for depositing one ERC-20 token, receiving share tokens, and converting between shares and assets, so apps can integrate any compliant vault without custom code.

Is ERC-4626 the same as ERC4626?

Yes. ERC-4626, ERC4626 and EIP-4626 all refer to the same "Tokenized Vaults" standard, created on 22 December 2021 and now marked Final.

What is the difference between deposit and mint in ERC-4626?

With deposit you choose the amount of the underlying asset to put in and receive however many shares that buys. With mint you choose the number of shares you want and the vault takes however many assets they cost. Withdraw and redeem are the same pair for exits.

What is the ERC-4626 inflation attack?

It targets an almost empty vault. An attacker mints a tiny number of shares, then donates assets directly to the vault to inflate the share price, so the next depositor's shares round down to zero or close to it. Virtual shares and assets, seeding the vault at launch and minimum-shares checks all defend against it.

Does ERC-4626 make a vault safe?

No. It standardises the interface, not the strategy. A compliant vault can still lose money through bad loans, smart contract bugs, oracle problems or a malicious implementation, so check the strategy, controls, fees and exit terms separately.

Is there an ERC-4626 equivalent on Sui?

Not as a formal standard. Sui vaults usually issue their own share coin using Sui's coin standard and price it as net assets divided by supply. JewelSwap's jeLOOP, from the beta Ember Loop vault, is one example.

Keep reading

This article is educational and isn't financial advice. Standard details are from the Ethereum EIP pages and protocol documentation as checked on 15 October 2026, and implementations change over time. JewelSwap operates the Ember Loop vault mentioned here, which is an unaudited beta.

Viktor Vostrikov

Co-Founder

About the author.

Co-Founder at JewelSwap & Chief Strategy Officer at iDenfy. Viktor brings his successful track record of superb development & project management.