What is ERC-4626?

The origin story.#

1. Dec 2021 ERC-4626 is created to standardize tokenized vault integration across DeFi. ↗
2. 2022 Vault adapters and libraries converge around the standard as DeFi protocols seek one interface for yield-bearing shares.
3. 2023+ Implementation-level issues like empty-vault inflation attacks become part of standard ERC-4626 audit checklists.

What ERC-4626 actually is.#

// EIP-4626 — tokenized vault over one ERC-20 asset
function asset() external view returns (address assetTokenAddress);
function totalAssets() external view returns (uint256 totalManagedAssets);

function convertToShares(uint256 assets) external view returns (uint256 shares);
function convertToAssets(uint256 shares) external view returns (uint256 assets);

function maxDeposit(address receiver) external view returns (uint256 maxAssets);
function previewDeposit(uint256 assets) external view returns (uint256 shares);
function deposit(uint256 assets, address receiver) external returns (uint256 shares);

function maxMint(address receiver) external view returns (uint256 maxShares);
function previewMint(uint256 shares) external view returns (uint256 assets);
function mint(uint256 shares, address receiver) external returns (uint256 assets);

function maxWithdraw(address owner) external view returns (uint256 maxAssets);
function previewWithdraw(uint256 assets) external view returns (uint256 shares);
function withdraw(uint256 assets, address receiver, address owner) external returns (uint256 shares);

function maxRedeem(address owner) external view returns (uint256 maxShares);
function previewRedeem(uint256 shares) external view returns (uint256 assets);
function redeem(uint256 shares, address receiver, address owner) external returns (uint256 assets);

event Deposit(address indexed sender, address indexed owner, uint256 assets, uint256 shares);
event Withdraw(address indexed sender, address indexed receiver, address indexed owner, uint256 assets, uint256 shares);

What's broken about ERC-4626.#

1. 01

   The vault is still a black box.#

   ERC-4626 standardizes the interface, not the strategy. It does not tell integrators where assets are deployed, how risk is priced, whether the strategy can be paused, what oracle it uses, or whether withdrawals depend on an async queue. The spec explicitly leaves accounting and allocation details to vault implementations.

   −

   ERC-4626 totalAssets() + previews

   interface only ·strategy opaque ·off-chain review

   becomes

   +

   LSP4 + ERC-725Y typed metadata + risk disclosures

   discoverable ·structured ·attached to asset/account

   workarounds tried

   • vault due diligence
   • strategy adapters
   • risk registries
   • off-chain monitoring
2. 02

   Rounding and donation attacks are implementation risks.#

   The standard defines share/asset conversion behavior, but an empty or low-liquidity vault can be vulnerable if the implementation lets an attacker donate assets and skew the exchange rate before a user's deposit. OpenZeppelin documents virtual shares/assets and precision offsets as defenses, but the ERC itself is not the defense.

   −

   ERC-4626 convertToShares(assets)

   rounding ·donation risk ·empty vault hazard

   becomes

   +

   implementation virtual shares/assets + slippage checks

   must be designed ·not solved by LSP ·audit required

   workarounds tried

   • virtual offset
   • dead shares
   • seeded initial liquidity
   • minimum deposit checks
   • first-deposit guards
3. 03

   Preview functions are not price oracles.#

   previewDeposit and friends should approximate same-transaction outcomes, but the spec warns that preview values can be manipulated by on-chain conditions. convert functions are allowed to be inexact and can be implemented more robustly, but integrators still need to know which view function they are using and why.

   −

   ERC-4626 previewDeposit / previewRedeem

   manipulable ·not oracle ·context-sensitive

   becomes

   +

   LSP20 inline call verification

   policy checks ·preconditions ·account-side guards

   workarounds tried

   • TWAP-style convert functions
   • slippage parameters
   • same-block simulation
   • vault-specific quote adapters
4. 04

   Approve/deposit keeps the ERC-20 allowance UX.#

   Depositing the underlying asset usually means approving the vault, then calling deposit or mint. ERC-4626 can use ERC-2612 permit when supported, but it inherits the underlying token's approval model and the share token's allowance model.

   −

   ERC-4626 asset.approve(vault) + deposit

   two-step UX ·allowance risk ·token-dependent

   becomes

   +

   LSP6 + LSP25 scoped controller + relayed call

   account permissions ·gasless ·batched intent

   workarounds tried

   • EIP-2612 permit
   • Permit2
   • multicall routers
   • smart account batching
   • allowance revocation

   read the deep-dive →

5. 05

   Fees and withdrawal constraints are not uniform.#

   The interface has max functions and preview functions, but fee policy, withdrawal queues, cooldowns, locks, and emergency states remain implementation-specific. Two ERC-4626 vaults can both be compliant while presenting very different liquidity guarantees.

   −

   ERC-4626 maxWithdraw(owner)

   underestimates limits ·policy-specific ·not a guarantee

   becomes

   +

   ERC-725Y standardized disclosure keys

   metadata layer ·indexable ·wallet-readable

   workarounds tried

   • max* checks
   • fee-aware previews
   • strategy disclosures
   • vault-specific UI warnings

LUKSO designed it differently.#

• LSP6 Key Manager Use account-level permissions to scope vault interactions instead of handing a dapp blanket authority over the user's whole account. →
• LSP25 Execute Relay Call Relayed vault deposits or withdrawals without requiring the user to hold native gas. →
• LSP7 Digital Asset A receiver-aware fungible asset layer if the underlying asset or share representation is issued inside the LSP ecosystem. →
• LSP4 Digital Asset Metadata Attach structured metadata, strategy descriptions, risk links, and verification data to vault-like assets. →
• LSP1 Universal Receiver Let accounts react to incoming share tokens or strategy receipts through one receiver hook. →

ERC-4626 vs LSP stack in one table.#

When to use which.#

FAQ.#

• 01

  What is ERC-4626? #

  ERC-4626 is Ethereum's tokenized vault standard. It extends ERC-20 share tokens with a common API for deposits, mints, withdrawals, redemptions, share/asset conversion, limits, previews, and vault events.

• 02

  Is ERC-4626 an ERC-20 token? #

  Yes. ERC-4626 vault shares are ERC-20 tokens. The standard adds vault-specific functions on top of the ERC-20 share interface.

• 03

  Does ERC-4626 support more than one underlying asset? #

  No. The standard is for a vault with a single underlying ERC-20 asset returned by asset(). Multi-asset vaults need another interface or adapters.

• 04

  What is the ERC-4626 inflation attack? #

  It is a first-deposit or low-liquidity attack where an attacker manipulates the share/asset exchange rate, often by donating assets to the vault, so a victim's deposit mints too few shares. Defenses are implementation-level, such as virtual offsets, seeded liquidity, and minimum output checks.

• 05

  Do LSPs replace ERC-4626? #

  No. ERC-4626 is the right vault accounting interface. LSPs complement it by improving account permissions, token metadata, receiver hooks, and relayed execution around vault interactions.

Keep reading.#

• key manager → LSP6
• execute relay call → LSP25
• digital asset → LSP7
• digital asset metadata → LSP4
• universal receiver → LSP1
• all ERC ↔ LSP mappings → matrix
• start from your problem → problems