ERC-4626 Explained: How Tokenized Vault Shares Work

ERC-4626 is Ethereum’s standard interface for a tokenized vault that manages one underlying ERC-20 asset and issues ERC-20 shares representing a fractional claim on the vault. It standardizes how applications inspect assets and request deposits or redemptions; it does not specify the investment strategy, promise yield or certify a vault as safe. For builders, the important distinctions are between share-conversion estimates, operation-specific previews and vault limits—and between a familiar interface and a sound implementation.

What ERC-4626 standardizes

Published as a final Ethereum standard, ERC-4626 was created on 22 December 2021 to make tokenized vaults easier to integrate. The vault’s share token follows ERC-20 conventions, while the vault exposes a common interface for a single underlying ERC-20 asset. The standard’s examples include lending markets, aggregators and intrinsically interest-bearing tokens.

That interface makes integrations more consistent, but it deliberately leaves accounting and asset allocation to each vault. Two ERC-4626 vaults can therefore expose similar calls while using different strategies, limits, fees, custody arrangements and withdrawal conditions. Integrators still need to examine the implementation and its risks.

Function group	What it tells or does	Practical use
`asset()` and `totalAssets()`	Identify the underlying token and report the assets managed by the vault. The specification says `totalAssets()` should include compounding and must include fees charged against vault assets.	Confirm what is being deposited and how the vault accounts for its holdings.
`convertToShares()` and `convertToAssets()`	Estimate an ideal asset-to-share or share-to-asset conversion, without operation-specific fees or slippage. Both must round down.	Display an indicative exchange rate, not an execution guarantee.
`deposit()`, `mint()`, `withdraw()` and `redeem()`	Perform the state-changing exchange: deposit an exact amount of assets or mint exact shares; withdraw an exact amount of assets or redeem exact shares.	Choose the operation that matches whether the user specifies assets or shares.
`preview()` and `max()`	Preview functions estimate a particular operation under current on-chain conditions and include applicable fees. `max*()` functions report current operation limits.	Simulate the right transaction and separately check whether the vault will accept it.

What a vault share represents—and what it does not

An ERC-4626 share is a claim on a fraction of the vault’s underlying holdings under that vault’s accounting rules. Its asset value can change as the strategy earns or loses value, fees accrue, assets enter or leave, or the vault applies its own rules. ERC-4626 itself does not promise that the share will appreciate or that a withdrawal will always be immediate.

A vault share is also not automatically a fiat stablecoin. ERC-4626 standardizes a vault interface; a stablecoin’s peg, issuer obligations and redemption process come from a different design. For context on those separate questions, see our guides to U.S. stablecoin rules and Circle Arc stablecoin payments.

`convertTo`, `preview` and `max*` are not interchangeable

The names are similar, but the functions answer different questions:

convertTo*() is an idealized estimate. The ERC-4626 specification requires caller-independent results that exclude fees and slippage, and both conversion functions round down. They are useful for a rough share price, not for predicting an exact transaction outcome.
preview*() models a particular operation. For example, previewDeposit(assets) estimates the shares for a deposit under the current on-chain conditions and includes deposit fees. A preview can change before a later transaction executes, and the specification warns that preview values can be manipulated and are not always safe as price oracles.
max*() reports a limit. maxDeposit, maxMint, maxWithdraw and maxRedeem indicate what the vault currently permits for a given account. A preview is not a substitute for checking these limits.

The standard’s basic deposit and mint interfaces do not take a user-supplied minimum-share output. Morpho’s integration guidance likewise notes that ERC-4626 calls do not provide built-in slippage checks. Applications should consider how they protect users if the exchange rate changes between a quote and transaction execution—for example, through a carefully designed wrapper or other execution-time bounds.

Rounding and the first-depositor inflation attack

Vault conversions involve integer arithmetic. The standard specifies conservative rounding directions: conversions round down, while some state-changing calculations round up so that rounding does not systematically favor the user over the vault. Small deposits can therefore be sensitive to precision and the vault’s initial share-to-asset ratio.

A known risk is the inflation attack, also called a donation attack. In a vulnerable, empty vault, an attacker can make a tiny first deposit and then transfer additional underlying tokens directly to the vault, outside the deposit function. That raises the assets-per-share ratio without issuing more shares. A later deposit may then receive very few shares—or round to zero—allowing the attacker to capture value at the depositor’s expense.

OpenZeppelin documents virtual assets and shares, including a decimals offset, as ways to make this attack less economical. Such techniques are not a substitute for reviewing the vault’s accounting and testing its exact behavior. Integrators should test empty-vault initialization, tiny deposits, direct donations, rounding boundaries, fees and any user-specific limits. A transaction should also fail safely if the user would receive fewer shares than the application has quoted as acceptable.

When the standard needs an asynchronous extension

A basic vault interaction is not the right fit for every strategy: some assets take time to settle or become liquid. ERC-7540 extends ERC-4626 with asynchronous deposit and redemption requests, so a request can be submitted and claimed later rather than treated as an immediate exchange. Integrators using such a vault must handle request status and claim steps in addition to the familiar share accounting.

Frequently asked questions

Does ERC-4626 guarantee yield?

No. It defines a common interface for a tokenized vault. Returns depend on the vault’s strategy, costs, assets and risks; the standard does not promise a positive return.

Is every yield-bearing token ERC-4626?

No. ERC-4626 is one standard interface for vaults holding a single underlying ERC-20 asset. A product may be yield-bearing without implementing that interface.

Should `previewDeposit()` be used as a price oracle?

Not by default. The ERC-4626 specification says previews can be affected by on-chain conditions and are not always safe as oracles. Use the function for its intended purpose—estimating a specific operation—and review a separate oracle design where an independent price feed is needed.

What should an integrator check first?

Verify the underlying asset and accounting, inspect fees and deposit or withdrawal limits, test rounding and initial-vault behavior, and confirm how the application handles slippage and delayed redemption. Interface compatibility alone is not a security review.

Sources

If you are designing or integrating an ERC-4626 vault, contact SignorCrypto to review the architecture, integration boundaries and user-protection flows before deployment.