ERC-4626 tokenized vault

Reading depth

Each view includes the earlier layers; the complete engineer or auditor page is shown by default.

BeginnerCore purpose and mental modelPractitionerAdds mechanisms and economicsEngineer or auditorAdds state and verification

Dependency check

Advanced detail assumes prerequisite knowledge

Before using practitioner mechanisms or engineer and auditor checks, review any unfamiliar dependency. These paths come from canonical depends_on relationships; Web3 Academy does not track completed lessons.

Review 10 dependencies

• AssetRequired through Asset versus claim

  1. ERC-4626 tokenized vault
  2. Vault
  3. Fee
  4. Asset versus claim
  5. Asset

• ClaimRequired through Asset versus claim

  1. ERC-4626 tokenized vault
  2. Vault
  3. Fee
  4. Asset versus claim
  5. Claim

• TokenRequired through Asset versus claim

  1. ERC-4626 tokenized vault
  2. Vault
  3. Fee
  4. Asset versus claim
  5. Token

• Asset versus claimRequired through Fee

  1. ERC-4626 tokenized vault
  2. Vault
  3. Fee
  4. Asset versus claim

• Claim tokenRequired through Vault share

  1. ERC-4626 tokenized vault
  2. Vault share
  3. Claim token

• FeeRequired through Vault

  1. ERC-4626 tokenized vault
  2. Vault
  3. Fee

• Net asset valueRequired through Vault

  1. ERC-4626 tokenized vault
  2. Vault
  3. Net asset value

• StrategyRequired through Vault

  1. ERC-4626 tokenized vault
  2. Vault
  3. Strategy

• VaultDirect prerequisite

  1. ERC-4626 tokenized vault
  2. Vault

• Vault shareDirect prerequisite

  1. ERC-4626 tokenized vault
  2. Vault share

ERC-4626 standardizes an ERC-20 share interface for vaults that accept one underlying ERC-20 asset, while leaving strategy, valuation, controls, and safety to each implementation.

Category: Products and vaultsContainer outline category cue

System record

Start with the economic purpose, participants, resources, and entitlements before studying implementation detail.

Why it exists

ERC-4626 gives wallets, aggregators, and protocols common deposit, mint, withdraw, redeem, conversion, preview, limit, asset, and total-assets methods for tokenized vault integration.

Traditional-finance analogy

Standard account and dealing interface for an investment vehicle is the closest comparison recorded for this concept.

Where the analogy stops

• Interface conformance does not specify the investment mandate, asset quality, valuation method, liquidity, governance, fees, or legal rights behind a vault.
• Public conversion and preview methods can differ by fees, slippage, limits, rounding, and manipulable state, so integrators must use the operation-specific method.

Main actors

• ActorDepositor, minter, withdrawer, or redeemer
• ActorShare owner and receiver
• ActorERC-4626 vault implementation
• ActorUnderlying ERC-20 asset contract
• ActorWallet, router, aggregator, or integrating protocol
• ActorStrategy, governance, or upgrade authority

Assets and claims

Assets — controlled or transformed resources

Assets are resources the mechanism moves, holds, values, or transforms.

• AssetOne underlying ERC-20 accounting asset
• AssetAssets managed by the vault
• AssetERC-20 vault shares

Claims — entitlements and corresponding dependencies

Claims are rights to value, repayment, redemption, control, or another party's performance; each depends on an obligation or system that must honor it.

• ClaimShareholder claim under vault accounting
• ClaimDeposit, mint, withdrawal, or redemption execution entitlement

ERC-4626 standardizes how one-underlying-asset vaults expose ERC-20 shares, conversions, previews, limits, deposits, mints, withdrawals, and redemptions.

Why it exists

Without a shared interface, every wallet, router, aggregator, and protocol needs custom adapters for each tokenized vault. ERC-4626 defines common method meaning so integrators can reason consistently about assets and shares while still reviewing each implementation.

Traditional-finance analogy

A standard account and dealing interface for an investment vehicle is a useful analogy. The interface does not specify the investment mandate, asset quality, valuation method, liquidity, fees, governance, controls, or legal rights. It says how software asks questions and performs exchanges, not whether the product is sound.

Asset and share interface state changes

An ERC-4626 vault is also an ERC-20 share token and names one ERC-20 asset(). totalAssets() reports managed assets under the implementation’s accounting. The share token is a pooled share and normally a redeemable claim under the vault’s current limits; it is not the underlying asset itself. Four state-changing paths separate whether the caller specifies assets or shares:

Table: Asset and share interface state changes

User intent	Exact input or output	Operation-specific quote	Limit query
Deposit assets	Exact assets in; shares out	previewDeposit	maxDeposit
Mint shares	Exact shares out; assets in	previewMint	maxMint
Withdraw assets	Exact assets out; shares burned	previewWithdraw	maxWithdraw
Redeem shares	Exact shares burned; assets out	previewRedeem	maxRedeem

The convertToShares and convertToAssets methods describe idealized average conversion and exclude operation-specific fees and slippage. Preview methods aim to model the current operation; maximum methods express current limits. They are not interchangeable.

Conversion and rounding

For a simplified nonempty proportional vault:

idealShareConversion = assets * totalSupply / totalAssets
idealAssetConversion = shares * totalAssets / totalSupply

The standard requires opposing rounding directions that favor the vault rather than letting users extract value through rounding. Empty and nearly empty states need a defined initial rate and defense against donation or inflation attacks; the simplified equations alone are not a safe implementation.

Step-by-step integration

1. Verify the underlying token, share token, implementation, upgrade authority, and strategy.
2. Read the operation’s maximum and operation-specific preview at the intended state.
3. Apply caller-side minimum shares or assets and maximum assets or shares as slippage protection where the integration supports it.
4. Set only the required token allowance and execute deposit, mint, withdraw, or redeem.
5. Reconcile emitted events, actual transfers, returned values, share supply, and total-assets accounting.
6. Handle pauses, queues, asynchronous extensions, fee changes, and nonstandard token behavior explicitly.

Capital flow transfers underlying assets. Claim flow mints, transfers, approves, and burns shares. Return flow changes totalAssets() or share supply only through the concrete implementation’s named strategy, payer, fee, or issuance rule. Information flow includes conversions, previews, limits, fees, balances, and events. Risk flow reaches shareholders through strategy loss, accounting, rounding, liquidity, or control and can propagate when an integrator treats those values as a manipulation-resistant oracle without analysis.

Return source and loss allocation

ERC-4626 defines no yield source. A vault’s strategy may receive borrower interest, trader fees, network payments, issuer income, or sponsor incentives; new token issuance can instead impose dilution on non-recipients. The interface does not determine which source applies. Loss reduces the assets represented by vault shares and is therefore borne by vault-share holders unless funded reserves, insurance, a manager guarantee, or a subordinated claim absorbs it first. The standard also does not guarantee liquidity, solvency, principal, governance quality, or an executable one-to-one redemption.

Engineer or auditor lens

Test every normative method and event, exact rounding direction, first deposit, donations, virtual offsets, decimals, zero and maximum inputs, preview-to-execution bounds, maximum limits, fee inclusion, allowances, third-party owner and receiver roles, reentrancy, callbacks, unusual ERC-20 behavior, total-assets manipulation, same-block oracle use, upgrades, pauses, and loss reporting.

The ERC-4626 specification is the normative source for interface behavior and security considerations. OpenZeppelin’s current ERC-4626 implementation documentation describes one implementation and its donation or inflation defense. Review the deployed code and version rather than assuming a library name proves behavior. The implementation documentation was reviewed 2026-08-10.

Common misunderstandings

• “ERC-4626 means yield-bearing.” The standard defines a vault interface; a vault can gain, lose, or hold value without yield.
• “convertToAssets is the redemption quote.” The relevant preview and maximum methods capture different current-operation rules.
• “Standards compliance means audited or safe.” Strategy, accounting, token behavior, controls, and upgrades remain implementation-specific.

Revisit the underlying vault and vault share.

Machine-readable model

Key equations

Canonical expressions come from the structured concept record. KaTeX renders the notation, while the plain-text expression and variable table keep its meaning and units inspectable without JavaScript. Read the narrative above for the model's domain, assumptions, and rounding rules.

1. Equation 1

   $$\mathrm{idealShareConversion} = \frac{\mathrm{assets} \times \mathrm{totalSupply}}{\mathrm{totalAssets}}$$

   Plain-text equation: idealShareConversion = assets * totalSupply / totalAssets

   Variables and units for equation 1

   Symbol	Meaning	Unit
   idealShareConversion	Ideal Share Conversion	share or claim units
   assets	Assets	selected underlying-asset units
   totalSupply	Total Supply	share or claim units
   totalAssets	Total Assets	selected underlying-asset units

2. Equation 2

   $$\mathrm{idealAssetConversion} = \frac{\mathrm{shares} \times \mathrm{totalAssets}}{\mathrm{totalSupply}}$$

   Plain-text equation: idealAssetConversion = shares * totalAssets / totalSupply

   Variables and units for equation 2

   Symbol	Meaning	Unit
   idealAssetConversion	Ideal Asset Conversion	selected underlying-asset units
   shares	Shares	share or claim units
   totalAssets	Total Assets	selected underlying-asset units
   totalSupply	Total Supply	share or claim units

Assurance contract

Security properties

These structured statements define desired behavior. Their stable IDs can bind tests, invariants, specifications, audit findings, or proof results without turning descriptive review advice into an assurance claim.

Desired · not evaluated: No test, audit, or proof result is implied until scoped evidence is linked to this property.

1. SP-01Desired · not evaluated

   Deposit, mint, withdraw, and redeem use the standard's opposing user-protective rounding directions and operation-specific previews

2. SP-02Desired · not evaluated

   Conversion estimates, previews, maximum limits, fees, actual execution, and share allowances satisfy their distinct interface contracts

3. SP-03Desired · not evaluated

   Empty and low-liquidity states cannot let an attacker capture a later depositor's value through donation and rounding

4. SP-04Desired · not evaluated

   Integrators validate the concrete strategy, total-assets accounting, token behavior, controls, upgrades, and loss paths beyond interface conformance

Prerequisites

Direct dependencies recorded by this concept's canonicaldepends_on relationships.

• VaultPath 67

  A vault is an on-chain asset container that accepts or controls assets, applies accounting and access rules, and may deploy capital through one or more strategies.

• Vault sharePath 68

  A vault share is a proportional claim whose asset value depends on the vault's recognized net assets, eligible share supply, fees, rounding, and redemption rules.

Learn next

Concepts that directly depend on this one, ranked by the recommended learning path. Check each page for additional prerequisites.

No concept directly builds on this page in the current graph; use the guided learning paths to choose another branch.

Knowledge check

Quiz

Answer in your own words, then open the model answer.

What problem does ERC-4626 tokenized vault exist to address?

Model answer

ERC-4626 gives wallets, aggregators, and protocols common deposit, mint, withdraw, redeem, conversion, preview, limit, asset, and total-assets methods for tokenized vault integration.

Mark as understood