ERC-7540 extends the ERC-4626 vault standard with asynchronous deposits and redemptions: investors submit a request, the request becomes claimable once the fund has processed it, and the investor (or an operator) then claims shares or assets. This mirrors how real funds work — subscriptions settle after cash clears, redemptions are honoured at the next NAV or window — and it has become the standard building block for on-chain RWA funds.
Key takeaways
- Lifecycle: Pending → Claimable → Claimed, for deposits, redemptions or both.
- New functions:
requestDeposit,requestRedeem,pendingDepositRequest,claimableDepositRequest,pendingRedeemRequest,claimableRedeemRequest, plus an operator model (setOperator,isOperator). - A vault can be async for redemptions only (common for credit funds) or for both directions.
- It builds on ERC-7575, so the share token can be separate from the vault entry point.
Why asynchronous vaults are needed
ERC-4626 requires a deposit or redemption to complete in one transaction. That works for DeFi strategies with instant liquidity, but not for:
- Tokenized treasury funds where cash must settle and shares are issued at the next NAV strike.
- Private credit pools where capital is lent out and redemptions depend on repayments.
- Real estate funds with monthly or quarterly redemption windows and gates.
- Any fund needing off-chain checks (KYC refresh, sanctions screening) before accepting money.
The request lifecycle
| Stage | What happens | Key functions / events |
|---|---|---|
| Request | Investor locks assets (deposit) or shares (redeem) in the vault | requestDeposit, requestRedeem, DepositRequest, RedeemRequest |
| Pending | Fund administrator processes: cash settlement, NAV strike, liquidity | pendingDepositRequest, pendingRedeemRequest |
| Claimable | Vault marks the request fulfilled at a known exchange rate | claimableDepositRequest, claimableRedeemRequest |
| Claimed | Controller calls deposit/mint or withdraw/redeem to receive shares or assets |
Standard ERC-4626 calls with a controller |
The controller owns the request; an operator approved via setOperator can manage requests on the controller’s behalf — useful for custodians, distributors and automated claim bots.
Because pricing is unknown at request time, the preview functions for async flows revert; integrators must read pending and claimable amounts instead.
Design choices for an RWA fund
- Which directions are async? Many credit vaults accept instant deposits but queue redemptions.
- Request IDs. Use ID
0for simple aggregated requests or unique IDs per request for epoch-based processing. - Epochs and NAV. Decide when requests are batched and priced, and where NAV comes from (administrator, oracle, on-chain accounting).
- Cancellation. The base standard does not mandate cancellation; add it if your offering documents allow it.
- Eligibility. Restrict who can request and who can hold shares — combine with identity checks or an ERC-7943 interface on the share token.
- Gates and pro-rating. If redemptions exceed liquidity, decide how partial fulfilment is allocated.
- Fees and slippage. Apply them at fulfilment so claimable amounts are final.
Operational flow example: a tokenized credit fund
- An investor with a verified identity calls
requestDeposit(1,000,000 USDC). - At the daily cut-off the administrator strikes NAV, invests funds and calls the vault’s fulfilment function.
- The request becomes claimable for, say, 987,654 shares.
- The investor (or their custodian as operator) claims shares.
- Months later the investor calls
requestRedeem; the fund queues it until the next monthly window and repayments provide liquidity.
Security and audit focus
- Accounting separation between pending, claimable and vault assets.
- Correct rounding in fulfilment maths.
- Operator permissions — an operator can claim to arbitrary receivers if not constrained.
- Admin fulfilment functions behind multisig and timelocks.
- Re-entrancy around asset transfers on claim.
Example interface excerpt
// Simplified excerpt of the ERC-7540 surface for async redemptions.
function requestRedeem(uint256 shares, address controller, address owner) external returns (uint256 requestId);
function pendingRedeemRequest(uint256 requestId, address controller) external view returns (uint256 pendingShares);
function claimableRedeemRequest(uint256 requestId, address controller) external view returns (uint256 claimableShares);
function setOperator(address operator, bool approved) external returns (bool);
function isOperator(address controller, address operator) external view returns (bool);
event RedeemRequest(address indexed controller, address indexed owner, uint256 indexed requestId, address sender, uint256 shares);
event OperatorSet(address indexed controller, address indexed operator, bool approved);
After a request becomes claimable, the controller (or an operator) calls the familiar ERC-4626 redeem or withdraw with the controller as the owner of the request to receive assets.
Epoch-based processing for a tokenized fund
Many fund platforms batch requests into epochs that mirror the fund’s dealing calendar:
| Step | Timing | Action |
|---|---|---|
| Request window | Day 1–5 | Investors submit deposit and redemption requests |
| Cut-off | Day 5, 17:00 UTC | Requests for this epoch are fixed |
| NAV strike | Day 6 | Administrator publishes NAV via oracle |
| Fulfilment | Day 6 | Operator fulfils requests at NAV, applying gates if needed |
| Claim | Day 6 onward | Investors or custodians claim shares/assets |
Unique request IDs per epoch make it easy to reconcile with the fund administrator’s dealing records.
Redemption gates and pro-rating
If redemption requests exceed available liquidity:
- Calculate available liquidity for the epoch.
- Fulfil requests pro-rata (e.g. 40% of each request).
- Leave the remainder pending for the next epoch, or let investors cancel if offering terms allow.
Encode these rules carefully and disclose them — they are exactly the kind of logic investors scrutinise during stress.
Operational integrations
- Fund administrator: NAV feed and dealing reconciliation.
- Custodian / bank: cash movements for subscriptions and redemptions.
- Transfer agent: official register, if the token is not the register.
- KYC provider: eligibility of controllers and receivers.
- Monitoring: alerts for unusual request volumes or failed fulfilments.
Frequently asked questions
Partly. Synchronous parts behave like ERC-4626; async parts require integrators to support the request functions and handle reverting previews.
Yes. The standard allows async deposits, async redemptions or both.
An address approved by the controller to manage requests and claims on its behalf, such as a custodian or automation service.
It is widely used by on-chain RWA fund platforms because it matches subscription and redemption processes with settlement delays.
The base standard doesn’t define cancellation; many implementations add it (sometimes with its own async flow). Match it to the fund’s offering documents.
Investors, or an operator/relayer on their behalf — often the platform, to keep the experience simple.
NUVZ is the RWA and Web3 engineering brand of ESS ENN Associates (est. 1993). Our team has designed and shipped tokenization platforms for real estate, education loans, solar PPAs, energy, carbon credits, bank deposits and trade documents. About us · Case studies
This article is for general information only and is not legal, tax or investment advice. Token standards evolve — always confirm the current status of an ERC at eips.ethereum.org and take advice from qualified counsel in each jurisdiction before issuing tokens.
