# What is ERC-7540? Source: https://o2ocapital.com/learn/erc-7540-explained Published: 2026-10-15 Updated: 2026-10-23 Data as of: 2026-10-15 Last reviewed: 2026-10-23 For information only: nothing on this site is an offer to sell, or a solicitation of an offer to buy, any security. Open to eligible non-U.S. institutional investors only. As of 15 October 2026, O2O Capital Partners is pre-launch: no vault or vault token is live. [Niche private credit onchain](https://o2ocapital.com/learn/niche-private-credit-onchain) ERC-7540 is an Ethereum standard that extends the ERC-4626 tokenized vault standard with asynchronous deposits and redemptions. A user submits a request, the request stays pending until the vault can settle it, then becomes claimable, and the user claims the shares or assets. This lets vaults that hold real-world assets, which settle on offchain payment cycles, keep the standard vault interface. By [Peter Gaffney](https://o2ocapital.com/team/peter-gaffney), Co-Founder, O2O Capital Partners; former Head of Research, Security Token Advisors O2O Research is general market commentary for information only. It is not investment advice, a recommendation or an offer of any security, including interests in any O2O vault. O2O may seek business relationships with protocols, curators or issuers it writes about. ## Key facts Each figure shows its source and the date it describes. - **ERC-7540 status on eips.ethereum.org**: Final. As of October 15, 2026. Source: [eips.ethereum.org](https://eips.ethereum.org/EIPS/eip-7540) - **ERC-7540 created**: 2023-10-18. As of October 15, 2026. Source: [eips.ethereum.org](https://eips.ethereum.org/EIPS/eip-7540) The created date as the standard's page shows it. - **ERC-4626 status on eips.ethereum.org**: Final. As of October 15, 2026. Source: [eips.ethereum.org](https://eips.ethereum.org/EIPS/eip-4626) - **ERC-7575 status on eips.ethereum.org**: Final. As of October 15, 2026. Source: [eips.ethereum.org](https://eips.ethereum.org/EIPS/eip-7575) ## 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](https://eips.ethereum.org/EIPS/eip-7540), 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. **Figure: The ERC-7540 request lifecycle.** A request is made, waits as pending, becomes claimable, then is claimed. The user always makes two calls. Alt text: Deposit and redeem lanes each pass four stages, request, pending, claimable, claimed, with the functions the page names, plus the operator and the rules of the cycle. 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. **Figure: ERC-4626, ERC-7540 and ERC-7575 compared.** ERC-4626 is synchronous, ERC-7540 adds requests, ERC-7575 lets several assets share one share token. Values read from eips.ethereum.org, retrieved 15 October 2026. Alt text: Three columns compare what each standard standardizes, how deposits and redemptions settle, where the share token lives and what each requires. All three are Final. | Field | ERC-4626 | ERC-7540 | ERC-7575 | | - | - | - | - | | Title | Tokenized Vaults | Asynchronous ERC-4626 Tokenized Vaults | Multi-Asset ERC-4626 Vaults | | Status | Final | Final | Final | | What it standardizes | One interface for vaults holding a single underlying ERC-20 token | Request-based deposits and redemptions for ERC-4626 vaults | Several assets or entry points sharing one share token | | Deposits and redemptions | Complete in one transaction, up to the vault's limits | Settle by request: pending, then claimable, then claimed, on one side or both | Follow ERC-4626 at each entry point | | Share token | The vault itself is the ERC-20 share token | Follows ERC-7575, so the share token may be the vault or a separate contract | Named by a `share` function; may be the vault itself or a separate ERC-20 token | | Requires | EIP-20, EIP-2612 | EIP-20, EIP-165, EIP-4626, EIP-7575 | EIP-20, EIP-165, EIP-2771, EIP-4626 | *Values are read from each standard's page on eips.ethereum.org, retrieved 15 October 2026. Pages: [ERC-4626](https://eips.ethereum.org/EIPS/eip-4626), [ERC-7540](https://eips.ethereum.org/EIPS/eip-7540) and [ERC-7575](https://eips.ethereum.org/EIPS/eip-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](https://eips.ethereum.org/EIPS/eip-7575), 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: **Figure: What happens between request and claim.** Offchain steps take time, so the vault accepts the request at once and settles it when they are done. Alt text: The vault accepts the request and it stays pending while the fund converts stablecoins, buys assets or raises cash, strikes the NAV and checks the investor; then it is claimable and the user claims it. - 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?](https://o2ocapital.com/learn/nav-priced-vault-tokens) 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: **Figure: Integrator checklist.** Eight checks for applications that hold, display or accept asynchronous vault shares. Alt text: Eight numbered checks: asynchronous flows, preview functions, requests that are not yet shares, exchange rates, status views, operators, cancellation and share token location. - 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](https://eips.ethereum.org/EIPS/eip-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](https://eips.ethereum.org/EIPS/eip-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](https://eips.ethereum.org/EIPS/eip-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](https://eips.ethereum.org/EIPS/eip-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](https://eips.ethereum.org/EIPS/eip-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](https://eips.ethereum.org/EIPS/eip-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](https://eips.ethereum.org/EIPS/eip-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](https://eips.ethereum.org/EIPS/eip-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](https://eips.ethereum.org/EIPS/eip-4626)). ## Sources 1. Ethereum Improvement Proposals, [ERC-4626: Tokenized Vaults](https://eips.ethereum.org/EIPS/eip-4626). Retrieved October 15, 2026. 2. Ethereum Improvement Proposals, [ERC-7540: Asynchronous ERC-4626 Tokenized Vaults](https://eips.ethereum.org/EIPS/eip-7540). Retrieved October 15, 2026. 3. Ethereum Improvement Proposals, [ERC-7575: Multi-Asset ERC-4626 Vaults](https://eips.ethereum.org/EIPS/eip-7575). Retrieved October 15, 2026. ## Related - [Niche private credit onchain](https://o2ocapital.com/learn/niche-private-credit-onchain) - [What is a NAV-priced vault token?](https://o2ocapital.com/learn/nav-priced-vault-tokens) - [What is tokenized private credit?](https://o2ocapital.com/learn/what-is-tokenized-private-credit) - [Real-World Asset Vaults Begin their Institutional Track Record](https://o2ocapital.com/research/rwa-vaults-institutional-track-record) To report an error or ask about a source, use the [contact form](https://o2ocapital.com/?audience=other#contact).