ERC-4626 is a standard interface for tokenized vaults on Ethereum. A vault takes deposits of one token and issues shares that represent a claim on the pool. The standard fixes the names and the behavior of the deposit, withdraw, mint and redeem functions, so that any application can integrate any vault the same way.
In fund language it is a standardized subscription and redemption form: the same fields in the same order, whichever fund is on the other side. It is one of several vault standards, and choosing between them depends mostly on how quickly the underlying assets settle.
What problem does ERC-4626 solve?
Before the standard, every vault had a different interface, and the specification names the problem directly: lending markets, yield aggregators and interest-bearing tokens each implemented deposits and share accounting their own way, making integration slow and error prone.
The cost of that falls on whoever touches more than one venue: a team allocating across three lending markets wrote three sets of deposit logic, three balance readers and three accounting adapters, then maintained all nine as each protocol upgraded. With a common interface it becomes one integration. The rest is a list of addresses. The standard has been Final since it was published, and the vault share is itself required to be an ERC-20 token, so wallets, custodians and accounting systems can read a position without any special handling of their own.
What does the standard actually define?
A fixed set of functions and two events that every conforming vault exposes. They fall into four groups.
asset()andtotalAssets()report the token the vault holds and how much of it the vault currently manages.deposit()andmint()put assets in and issue shares.withdraw()andredeem()return shares and pay assets out.convertToShares()andconvertToAssets()give an estimated exchange rate in either direction. The fourpreviewfunctions give the exact result of a specific operation at current conditions, fees included.maxDeposit(),maxMint(),maxWithdraw()andmaxRedeem()report the limits, so an integrator can ask before it tries.
Every deposit emits a Deposit event and every exit emits a Withdraw event. Anyone reconstructing a position history reads those.
How do shares and assets relate?
A share is a proportional claim on the vault's assets, and its value is total assets divided by shares outstanding. Deposit into a vault holding 100 units against 100 shares and you receive one share per unit, and if the strategy earns and total assets reach 110 against the same 100 shares, each share is worth 1.1 units. Nothing is sent to the holder. The claim is simply worth more. This is the same arithmetic as net asset value per unit in a fund.
Rounding is specified rather than left to the implementer. Vaults round down when issuing shares or paying assets out to a user, and round up when calculating what a user must supply, so the rounding error accrues to the vault rather than to the holders already in it.
Where ERC-4626 stops working
The standard assumes a deposit or a redemption can complete inside a single transaction. The asynchronous extension states the limitation plainly: ERC-4626 optimizes for atomic deposits and redemptions up to a limit, and that approach fails for systems with asynchronous actions or delays.
For a lending market it is not a constraint. Supply and withdraw both finish in one block. For a tokenized treasury with a subscription cutoff, a fund share with a notice period, or any position behind a KYC check, the interface has nothing that means "requested, not yet done." The standard is also explicit that its preview functions can be manipulated by changing onchain conditions and are not always safe to use as a price oracle, and that integrators should review a vault's implementation for ways of losing deposits before connecting to it.
None of that makes the standard a poor one: it did the job it was written for, and that job was distribution, one container shape that any application could integrate against.
What an institution needs beyond ERC-4626
Where a mandate involves assets that settle on different clocks, the interface question stops being cosmetic and starts driving the fund structure. What each standard can express, and what it cannot, decides where a strategy holding both instant and delayed positions ends up. What ERC-7540 is covers the asynchronous model on its own terms. The accounting and share-price edge cases follow from that choice rather than preceding it.
Frequently asked questions
Is ERC-4626 a vault, or a standard?
It is a standard, not a product. It describes the interface a vault presents to the outside world. Two vaults can both be ERC-4626 compliant and hold entirely different assets, run entirely different strategies and carry entirely different risk, because compliance describes how you talk to the vault and says nothing about what is inside it.
Does ERC-4626 require the vault share to be a token?
Yes. The specification requires the share to be ERC-20 compliant. That is why a vault position shows up in a wallet, can be transferred, and can be read by an accounting system without a custom connector.
Can an ERC-4626 vault hold more than one asset?
Not within the standard. ERC-4626 describes shares of a single underlying ERC-20 token. asset() returns one address. Multi-asset structures use ERC-7575, an adaptation of ERC-4626 that supports multiple assets or entry points for the same share token, and it adds a share method returning a share token that can live outside the vault.
Does the standard say anything about security?
It sets rounding direction to protect the vault, and it warns that preview functions are manipulable and not always safe as price oracles, but beyond that it puts the obligation on the integrator, recommending that anyone connecting to a vault review the implementation for ways of losing user deposits first.