What is ERC-7540?

What problem does ERC-7540 solve?

ERC-4626 is the Ethereum standard for tokenized vaults. It gives every compliant vault the same interface for depositing, withdrawing and reading balances, so a wallet, a lending market or an aggregator can work with any of them without custom code. Under ERC-4626, a deposit or a redemption completes in a single transaction, up to whatever limit the vault sets. Once the limit is reached, no new deposit or redemption can be made.

That works for a vault whose assets are already onchain and can be moved at once. It does not fit a vault that must wait before it can act. The motivation section of the ERC-7540 page on eips.ethereum.org, retrieved on 15 October 2026, names the kinds of systems it has in mind: real-world asset protocols, undercollateralized lending, cross-chain lending, liquid staking tokens and insurance safety modules. Each has a delay built into how money comes in or goes out.

ERC-7540 adds a request step to ERC-4626. A user asks to deposit or to redeem, the vault settles the request later, and the user then completes it with the same deposit, mint, redeem and withdraw functions that ERC-4626 already defines. A vault can make deposits asynchronous, redemptions asynchronous, or both. Any side it leaves out keeps the ordinary ERC-4626 behavior.

ERC-7540 also requires the vault to implement ERC-7575, a standard that separates the vault contract from the share token, and ERC-165, which lets other contracts ask the vault which interfaces it supports.

How does the request lifecycle work?

The standard defines four stages that every request passes through. For a deposit:

1. Request. The user calls requestDeposit, and the vault takes the user's assets at once. For a redemption the call is requestRedeem, and the vault takes control of the user's shares, either locking them or burning them.
2. Pending. The request has been made and the vault has not yet processed it. pendingDepositRequest and pendingRedeemRequest show the amount waiting for each controller, the account that owns the request.
3. Claimable. The vault has processed the request, and the user can now collect the result. claimableDepositRequest and claimableRedeemRequest show the amount ready.
4. Claimed. The user calls deposit or mint to receive the shares for a deposit request, or redeem or withdraw to receive the assets for a redemption request.

A few rules shape the cycle. A request may become claimable immediately, but it may not skip the claimable stage: the user always makes two calls, one to request and one to claim, even in the same block. The vault never pushes tokens to the user; the user pulls them with the claim call. Each request returns a request ID, and requests with the same ID move from pending to claimable together, at the same exchange rate. A vault that returns an ID of zero tracks requests by controller alone.

Owners can also approve an operator, an account that may manage requests on their behalf. The standard adds setOperator and isOperator for this, and new versions of deposit and mint that name the controller whose request is being claimed.

How do ERC-4626, ERC-7540 and ERC-7575 compare?

The three standards come from the same family. ERC-4626 sets the base vault interface, ERC-7575 lets one share token have several vault entry points, and ERC-7540 adds requests on top of both.

Values are read from each standard's page on eips.ethereum.org, retrieved 15 October 2026. Pages: ERC-4626, ERC-7540 and ERC-7575.

ERC-7575 matters here because of the share token. Under ERC-4626 the vault contract is itself the token that holders own. ERC-7575 adds a share function that can point to a separate token, so several vault contracts, each taking a different asset, can issue the same share. The ERC-7575 page, retrieved 15 October 2026, notes that such vaults are not fully compatible with ERC-4626, because the ERC-20 token functions are removed from the vault contract.

Why do real-world asset vaults need asynchronous settlement?

A vault that holds a real-world asset, such as a loan, a fund share or a Treasury bill, settles part of every transaction offchain. Several things have to happen before a deposit can become shares or a redemption can become stablecoins:

• The fund converts stablecoins into the currency its assets are bought in, through a bank or an exchange, on banking days and before cut-off times.
• The fund buys the assets, or sells or collects them to raise cash, on the payment cycles of the markets they trade in. Private loans may not be saleable at all on short notice, so cash for redemptions comes from repayments.
• The fund's administrator strikes the net asset value on a schedule, and every deposit and redemption in that period takes the same price.
• The fund checks that each new holder is on its list of approved investors before issuing shares.

An ERC-4626 vault would have to keep enough cash to pay every redemption at once, or refuse new requests when it could not. ERC-7540 lets the vault accept the request at once and settle it when the offchain steps are done. Because requests with the same ID settle together at the same exchange rate, a vault can gather the requests for one period and settle them all at the next NAV. What is a NAV-priced vault token? explains how that NAV is calculated and posted onchain.

What should integrators check?

Applications that hold, display or accept asynchronous vault shares face questions that ERC-4626 vaults never raised. The ERC-7540 text on eips.ethereum.org, retrieved 15 October 2026, supports the checks below:

• Which flows are asynchronous. A vault may make deposits, redemptions or both asynchronous, and it must answer ERC-165 queries that say which. Integrations can use this to handle every kind of vault with one contract (ERC-7540).
• Preview functions. For an asynchronous deposit flow, previewDeposit and previewMint must revert, and for an asynchronous redemption flow, so must previewRedeem and previewWithdraw. Code that relies on previews to quote a price has to read the vault's state another way (ERC-7540).
• Requests that are not yet shares. Assets in a pending deposit request have left the user's wallet and have not yet become shares, and shares in a pending redemption are no longer in the owner's custody. Balances and collateral values should account for both (ERC-7540).
• Exchange rates. The rate between shares and assets is set by each vault. A pending redemption may stop earning yield, and the amount received at the claim can differ from the value at the time of the request (ERC-7540).
• Status views. The pending and claimable amounts are estimates useful for display and can be out of date. The standard defines no event for the move to claimable, so applications check the claimable amounts themselves (ERC-7540).
• Operators. An approved operator can move the vault's asset from the approving account and controls its shares, so approving one means trusting it with both (ERC-7540).
• Cancellation. The standard leaves out a way to cancel a pending request and suggests a separate proposal for it. Its security notes warn that assets or shares can be stuck in the pending state, so integrators check whether a given vault offers its own cancellation (ERC-7540).
• Share token location. Under ERC-7575, the share token may be a separate contract from the vault, so balances are read from the address the share function returns (ERC-7575).

The ERC-4626 text adds a general warning that applies here too: a contract can follow the interface without following the specification, so integrators review each vault's code before accepting it (ERC-4626).