ERC-7540 is an extension of the ERC-4626 vault standard for vaults that cannot settle a deposit or a redemption inside a single transaction. Instead of one call, the investor submits a request, waits while the vault fulfills it, then claims the shares or the assets. The waiting is part of the interface rather than a workaround.
If ERC-4626 is a standardized subscription form for a fund that prices and settles the moment you sign it, ERC-7540 is the version for a fund with a dealing cutoff, and the choice between them comes down to whether every asset a strategy holds can move in one block.
Why was an asynchronous vault standard needed?
A large class of assets cannot deliver on demand, and ERC-4626 has no way to say so. The specification is direct about it: ERC-4626 optimizes for atomic deposits and redemptions up to a limit, and that approach fails for systems with asynchronous actions or delays.
Before the extension existed, teams either held a liquidity buffer large enough to pay redemptions instantly, a drag on returns that works only until the buffer drains, or built a bespoke queue outside the standard that every integrator then had to learn separately. ERC-7540 gives the delay a shape an integrator can read from the contract.
How does the request and claim model work?
A request moves through three states: Pending, Claimable, then Claimed. For a deposit:
- The investor calls
requestDepositand the assets leave their wallet. The request is now Pending and shows up inpendingDepositRequest. - Fulfillment happens on the vault's own schedule, the amount moves out of pending and into
claimableDepositRequest, and the standard deliberately does not specify when this happens, because a vault may batch requests or release them after a timestamp. - The investor calls the ordinary ERC-4626
depositormintto take delivery of the shares.
Redemptions run the mirror image through requestRedeem, pendingRedeemRequest and claimableRedeemRequest, with one difference that matters operationally: the shares leave the holder's custody at request time rather than at claim time.
Two details matter. First, a request must not skip the claim step: the standard says a user must call both the request function and the claim function separately, even in the same block. That is why the two-step shape holds even when the vault is fast. Second, the price is not locked at request time. The specification warns that the shares received on deposit may not equal convertToShares(assets) measured when the request was made, because the price can change in between.
Which assets need it?
Anything with a settlement delay, a compliance gate, or a redemption window. The specification lists the cases it was written for: real-world asset protocols, undercollateralized lending, cross-chain lending, liquid staking tokens, and insurance safety modules.
Read that list from an allocator's side and the common factor is that something offchain or off-clock has to happen before the money is free. A tokenized treasury fund has a dealing cutoff and a transfer agent, a KYC-gated position needs a check to clear before an address can hold the share at all, and a staked asset has an exit queue set by the network rather than by the vault. In every case the vault genuinely does not know, at the moment of the request, exactly what it will be able to pay or when, so a standard that forces an answer in the same transaction can only return a wrong figure or revert.
A vault does not have to be asynchronous in both directions: deposits can be instant while redemptions queue, or the reverse, and integrators detect which case they are dealing with through ERC-165 interface checks.
What ERC-7540 leaves out
It describes the request, not the fulfillment. The standard is explicit that the transition from Pending to Claimable happens at the implementation level and is outside the specification, and that there is no event marking it. It also has no cancellation flow, on the reasoning that canceling a request may not be straightforward or even technically feasible and should be a separate proposal, and that proposal now exists: ERC-7887, Cancelation for ERC-7540 Tokenized Vaults, adding asynchronous cancelation flows so assets are not stuck in a pending request indefinitely. It is at Draft status.
Three further constraints matter before designing around it. The preview functions must revert for all callers and inputs on the asynchronous side of a vault, so there is no onchain quote before committing, and approving an operator grants control over both the assets and the shares, a hazard the specification flags in its security considerations. And the reference implementation in the specification is described by its own authors as incomplete pseudocode, used for example only and in no way intended for production.
The standard handles the common case well. What it does not handle is one fund whose deposit flow needs to be instant for some holdings and queued for others, because the setting is per vault flow, not per position.
A fund holding both fast and slow assets
That mismatch describes most institutional strategies: a lending position that settles in a block sitting beside a tokenized treasury that settles on a business-day cycle, inside one mandate. Every state transition in a request carries an operational question, and the two standards differ in what they can express about the answer. If the settlement side is the unfamiliar part, start with what settlement means onchain and off.
Handling both clocks in one accounting model is the specific problem Railnet's state machine was built for.
Frequently asked questions
Is ERC-7540 a replacement for ERC-4626?
No. It is an extension and is backward compatible with ERC-4626, reusing deposit, mint, withdraw and redeem as the claim step, so a vault that needs no delay stays on ERC-4626. Integrators can support both from one contract by checking the ERC-165 interface identifiers.
Can I cancel a pending request?
Not through the standard. ERC-7540 deliberately leaves cancellation out, noting that it may not be straightforward or technically feasible and that a separate proposal should cover it, and ERC-7887 is the draft proposal that adds it, so some vaults already implement it, but it is not Final and an integrator cannot assume it exists. Assets can therefore sit in Pending.
Do I know the price when I submit a request?
No. The specification warns that the shares received on claim may differ from what convertToShares showed at request time, because the price can move in between, and it requires the relevant preview functions to revert on the asynchronous side. In fund terms this is forward pricing: you subscribe before the price is struck.
How long does a request stay pending?
The standard does not say, by design. Fulfillment timing is set by the vault implementation and the asset underneath it, and requests may be batched or released after a timestamp, so it is a diligence question for each vault rather than something the interface guarantees.