{"id":"ERC-7540","name":"Asynchronous ERC-4626 Vaults","status":"Final","chain":"both","category":{"id":"defi","name":"DeFi Patterns","description":"Vaults, bonds, and financial primitives"},"journeyStages":[{"id":"status","name":"Status & Confirmation","description":"Waiting for and confirming outcomes"},{"id":"management","name":"Asset Management","description":"Managing assets over time"}],"uxImpact":"ERC-7540 adds optional asynchronous deposit and/or redemption flows to ERC-4626 vaults. A deployed vault can keep one side synchronous while requests on the other side settle later, which helps real-world-asset, illiquid, and delayed-settlement strategies expose their timing clearly.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-7540","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-7540","summary":"ERC-7540 adds optional asynchronous deposit and/or redemption flows to ERC-4626 vaults. A deployed vault can keep one side synchronous while requests on the other side settle later, which helps real-world-asset, illiquid, and delayed-settlement strategies expose their timing clearly.","applicability":{"whenToUse":["Your users expect instant withdrawal but vault has illiquid assets.","Your product addresses: real-world-asset vaults need delayed settlement beyond synchronous ERC-4626 flows.","Your UI should clear \"request → wait → claim\" flow sets proper expectations.","You are designing a request-wait-claim flow experience with visible states and recovery paths."],"whenToAvoid":["The deployed vault supports only synchronous ERC-4626 deposit and redemption flows.","The product has no pending-request, claim, or settlement state to communicate.","There is no delayed asset or share settlement in the user journey.","No token balances, swaps, lending, or yield flows appear in the product."]},"designerTakeaways":["You can clear \"request → wait → claim\" flow sets proper expectations in the interface.","You can use an ERC-4626-compatible async interface for RWA vaults when the deployed side supports it.","Design the flow to support trackable request status with estimated completion."],"problemsSolved":[{"problem":"Users expect instant withdrawal but vault has illiquid assets","oldWay":"Transaction reverts with confusing error, or vault has exit penalties","newWay":"Clear \"request → wait → claim\" flow sets proper expectations","impact":"critical"},{"problem":"Real-world-asset vaults need delayed settlement beyond synchronous ERC-4626 flows","oldWay":"Custom vault interfaces, each with different UX","newWay":"Standardized async interface extends ERC-4626 for delayed RWA settlement","impact":"high"},{"problem":"Users don't know when their withdrawal will complete","oldWay":"Vague \"processing\" messages with no timeline","newWay":"Trackable request status with estimated completion","impact":"high"},{"problem":"No standard way to show pending positions","oldWay":"Each vault has custom UI for pending deposits/withdrawals","newWay":"Standardized pending request queries enable consistent UI","impact":"medium"}],"uxPatterns":[{"name":"Request-Wait-Claim Flow","description":"Request/redeem flow with clear status when redemption is asynchronous","userFlow":["User submits a withdrawal request when the redemption side is asynchronous","System shows pending status with timeline","User can track request progress","Notification when claimable","User claims when ready"]},{"name":"Pending Requests Dashboard","description":"Overview of all pending deposits and withdrawals","userFlow":["User views dashboard of pending requests","Each request shows progress and timeline","Ready requests have prominent claim button","Completed requests move to history"]},{"name":"Async Deposit Flow","description":"Deposit flow with delayed share minting when the deposit side is asynchronous","userFlow":["User enters deposit amount for an asynchronous deposit side","Show clear settlement timeline","User understands it's not instant","Submit request locks funds","Track progress until claimable","Claim shares when ready"]},{"name":"Request Cancellation","description":"Allow users to cancel pending requests when possible","userFlow":["User wants to cancel pending request","Check if still in cancellation window","Show deadline for cancellation","Confirm cancellation","Funds returned to original state"]}],"uiComponents":[{"name":"RequestProgressStepper","description":"Visual progress through a request and claim lifecycle when the selected vault exposes those states.","states":["requested","processing","claimable","claimed"],"props":["currentStep","estimatedTime","requestId"]},{"name":"PendingRequestCard","description":"Show pending request details from the selected vault/provider, including timing only when supplied.","states":["pending","processing","ready","claiming"],"props":["requestType","amount","vault","progress","eta"]},{"name":"SettlementTimeline","description":"Display vault/provider-supplied settlement steps and dates; use unknown timing when unavailable.","states":["upcoming","in-progress","completed"],"props":["steps[]","currentStep","estimatedDates"]},{"name":"ClaimableAlert","description":"Notify when the selected vault reports a request as claimable.","states":["ready","claiming","claimed"],"props":["requestId","amount","vaultName","onClaim"]}],"antiPatterns":[{"pattern":"Hiding that deposits/withdrawals are async","why":"Users expect instant fulfillment, feel trapped when delayed","instead":"Show settlement timeline BEFORE they submit request","severity":"critical"},{"pattern":"No progress updates while waiting","why":"Users anxious about their funds, support tickets","instead":"Show percentage progress and estimated time remaining","severity":"high"},{"pattern":"Auto-claiming without user action","why":"User may want control over when shares/assets enter wallet","instead":"Notify user and let them claim when ready","severity":"high"},{"pattern":"Using DeFi-instant language for async vaults","why":"\"Deposit\" implies instant, misleading for async","instead":"Use \"Request Deposit\" or \"Submit Request\" language","severity":"medium"}],"keyTakeaways":["When a selected deposit or redemption side is asynchronous, show its request → wait → claim lifecycle; synchronous sides may settle immediately.","Show any vault/provider-supplied settlement timeline before the user commits; label estimates and unknown timing.","Track request state from vault/provider data, and show estimates only when available.","Notify users when the vault reports a request as claimable; do not imply a universal notification or timing guarantee."],"technicalNotes":"ERC-7540 lets a vault implement asynchronous deposit, asynchronous redemption, or both; an unimplemented side remains synchronous ERC-4626. Deposit-side requests use requestDeposit(), pendingDepositRequest(), and claimableDepositRequest(), then the deployed deposit/mint claim path; redemption-side requests use requestRedeem(), pendingRedeemRequest(), and claimableRedeemRequest(), then the deployed withdraw/redeem claim path. previewDeposit/previewMint revert only for an asynchronous deposit side, and previewRedeem/previewWithdraw only for an asynchronous redemption side. Detect each side and the deployed controller/operator rules before presenting request or claim states.","lastUpdated":"2026-09-18","specConstraints":[{"id":"async-or-sync-side","constraint":"A vault implements an asynchronous deposit or redemption flow, and any unimplemented side remains synchronous ERC-4626.","appliesTo":"application","normativity":"normative","specQuote":"[ERC-7540 Vaults](./eip-7540.md) MUST implement one or both of asynchronous deposit and redemption Request flows. If either flow is not implemented in a Request pattern, it MUST use the ERC-4626 standard synchronous interaction pattern.","specSection":"Specification — Request Flows","specUrl":"https://ercs.ethereum.org/ERCS/erc-7540#request-flows","designImplication":"Detect deposit and redemption behavior separately. Show request and claim states only for the asynchronous side."},{"id":"deposit-preview-reverts","constraint":"Asynchronous deposit vaults revert `previewDeposit` and `previewMint` for every caller and input.","appliesTo":"application","normativity":"normative","specQuote":"2. `previewDeposit` and `previewMint` MUST revert for all callers and inputs.","specSection":"Specification — Request Flows","specUrl":"https://ercs.ethereum.org/ERCS/erc-7540#request-flows","designImplication":"Do not render a synchronous preview quote for an asynchronous deposit side. Use a request flow with a clearly labeled estimate or unknown rate."},{"id":"redemption-preview-reverts","constraint":"Asynchronous redemption vaults revert `previewRedeem` and `previewWithdraw` for every caller and input.","appliesTo":"application","normativity":"normative","specQuote":"3. `previewRedeem` and `previewWithdraw` MUST revert for all callers and inputs.","specSection":"Specification — Request Flows","specUrl":"https://ercs.ethereum.org/ERCS/erc-7540#request-flows","designImplication":"Do not promise an immediate redemption quote when the selected side is asynchronous. Show the request and later claim states instead."},{"id":"request-claim-lifecycle","constraint":"A request must pass through a separate Claim state, and the user pulls the assets or shares with the claim call.","appliesTo":"application","normativity":"normative","specQuote":"Requests MUST NOT skip or otherwise short-circuit the Claim state. In other words, to initiate and claim a Request, a user MUST call both request* and the corresponding Claim function separately, even in the same block. Vaults MUST NOT \"push\" tokens onto the user after a Request, users MUST \"pull\" the tokens via the Claim function.","specSection":"Specification — Request Lifecycle","specUrl":"https://ercs.ethereum.org/ERCS/erc-7540#request-lifecycle","designImplication":"Use a request, pending, claimable, and claimed journey. Never imply that submitting a request has already delivered the result."},{"id":"request-id-fungibility","constraint":"Requests sharing a nonzero request ID become claimable together at the same exchange rate and pro-rata rate.","appliesTo":"application","normativity":"normative","specQuote":"Requests of the same `requestId` MUST be fungible with each other (except in the special case `requestId == 0` described below). I.e. all Requests with the same `requestId` MUST transition from Pending to Claimable at the same time and receive the same exchange rate between `assets` and `shares`. If a Request with `requestId != 0` becomes partially claimable, all requests of the same `requestId` MUST become claimable at the same pro-rata rate.","specSection":"Specification — Request Ids","specUrl":"https://ercs.ethereum.org/ERCS/erc-7540#request-ids","designImplication":"Group requests by request ID and show the rate and claimability state consistently across that group."},{"id":"pending-claimable-view-semantics","constraint":"Pending and claimable view methods must report only the corresponding state and must not vary by caller.","appliesTo":"application","normativity":"normative","specQuote":"MUST NOT include any `assets` in Claimable state for `deposit` or `mint`.","specSection":"Specification — Methods — pendingDepositRequest","specUrl":"https://ercs.ethereum.org/ERCS/erc-7540#pendingdepositrequest","designImplication":"Use the vault-reported pending and claimable values as separate UI states. Do not show one user a claimable amount that another user cannot observe."},{"id":"deposit-request-failure","constraint":"A deposit request must revert when the requested assets cannot be accepted because of limits, slippage, or missing approval.","appliesTo":"application","normativity":"normative","specQuote":"MUST revert if all of `assets` cannot be requested for `deposit`/`mint` (due to deposit limit being reached, slippage, the user not approving enough underlying tokens to the Vault contract, etc).","specSection":"Specification — Methods — requestDeposit","specUrl":"https://ercs.ethereum.org/ERCS/erc-7540#requestdeposit","designImplication":"Explain whether a request failed because of the vault limit, slippage, or allowance. Do not show the request as pending after the transaction reverted."},{"id":"redemption-request-failure","constraint":"A redemption request must revert when the requested shares cannot be accepted because of limits, slippage, or insufficient shares.","appliesTo":"application","normativity":"normative","specQuote":"MUST revert if all of `shares` cannot be requested for `redeem` / `withdraw` (due to withdrawal limit being reached, slippage, the owner not having enough shares, etc).","specSection":"Specification — Methods — requestRedeem","specUrl":"https://ercs.ethereum.org/ERCS/erc-7540#requestredeem","designImplication":"Give redemption failure copy that distinguishes limits, price movement, and insufficient shares before offering a retry."},{"id":"erc4626-backwards-compatibility","constraint":"The interface remains backward compatible with ERC-4626, while the asynchronous methods have different specifications.","appliesTo":"application","normativity":"backwards-compatibility","specQuote":"## Backwards Compatibility\n\nThe interface is fully backward compatible with [ERC-4626](./eip-4626.md). The specification of the `deposit`, `mint`, `redeem`, and `withdraw` methods is different as described in [Specification](#specification).","specSection":"Backwards Compatibility","specUrl":"https://ercs.ethereum.org/ERCS/erc-7540#backwards-compatibility","designImplication":"Keep ERC-4626 terminology where it still applies, but disclose which deposit or redemption side uses request and claim states."},{"id":"async-estimates-stale","constraint":"Pending and claimable request views are estimates that can be outdated, and the final exchange rate depends on the vault implementation.","appliesTo":"application","normativity":"security-considerations","specQuote":"The view methods for viewing Pending and Claimable request states (e.g. pendingDepositRequest) are estimates useful for display purposes but can be outdated.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-7540#security-considerations","designImplication":"Label pending and claimable amounts as vault-reported estimates. Do not present them as guaranteed final proceeds."},{"id":"pending-assets-can-stall","constraint":"Shares or assets can remain stuck in Pending state unless the vault provides an appropriate cancellation or fungibility mechanism.","appliesTo":"application","normativity":"security-considerations","specQuote":"Shares or assets locked for Requests can be stuck in the Pending state.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-7540#security-considerations","designImplication":"Show an unresolved pending state and the vault’s cancellation or recovery option when available. Do not promise a universal settlement time."},{"id":"operator-asset-share-control","constraint":"An approved operator can transfer vault assets and control vault shares, so the user must trust that operator.","appliesTo":"application","normativity":"security-considerations","specQuote":"### Operators\n\nAn operator has the ability to transfer the `asset` of the vault from the approver to any address, and simultaneously grants control over the `share` of the vault. \n\nAny user approving an operator must trust that operator with both the `asset` and `share` of the Vault.","specSection":"Security Considerations — Operators","specUrl":"https://ercs.ethereum.org/ERCS/erc-7540#operators","designImplication":"Name the operator and disclose the asset and share authority before approval. Keep operator approval distinct from a normal deposit or withdrawal action."},{"id":"request-controller-disambiguation","constraint":"A request is identified by both its request ID and its controller.","appliesTo":"application","normativity":"normative","specQuote":"Multiple requests may have the same `requestId`, so a given Request is discriminated by both the `requestId` and the `controller`.","specSection":"Specification — Request Ids","specUrl":"https://ercs.ethereum.org/ERCS/erc-7540#request-ids","designImplication":"Bind request history and claim actions to both identifiers. Do not merge requests that share an ID but have different controllers."},{"id":"router-claim-abstraction","constraint":"Routers, relayers, message signing, or account abstraction may combine the request and claim steps into one user-facing action.","appliesTo":"application","normativity":"rationale","specQuote":"The 2-step approach used in the standard may be abstracted into a 1-step approach from the user perspective through the use of routers, relayers, message signing, or account abstraction.","specSection":"Rationale — Not Allowing Short-circuiting for Claims","specUrl":"https://ercs.ethereum.org/ERCS/erc-7540#not-allowing-short-circuiting-for-claims","designImplication":"A product may present one user-facing action when an integration wraps request and claim safely, but it must still show the underlying pending and claimable states."},{"id":"claimable-state-discovery","constraint":"The standard does not require an event when a request becomes claimable, so products need a vault-specific status source.","appliesTo":"application","normativity":"rationale","specQuote":"The state transition of a Request from Pending to Claimable happens at the Vault implementation level and is not specified in the standard. Requests may be batched into the Claimable state, or the state may transition automatically after a timestamp has passed. It is impractical to require an event to emit after a Request becomes Claimable at the user or batch level.","specSection":"Rationale — No Event for Claimable State","specUrl":"https://ercs.ethereum.org/ERCS/erc-7540#no-event-for-claimable-state","designImplication":"Read the vault's supported status views or provider data and avoid an event-only notification promise."}],"sources":[{"label":"ERC-7540 official specification","url":"https://ercs.ethereum.org/ERCS/erc-7540","type":"official-spec"}],"lastReviewed":"2026-09-18"},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-7540","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-7540","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-7540","markdown":"https://www.eipsfordesigners.com/standards/ERC-7540/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-7540/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-7540","official":"https://ercs.ethereum.org/ERCS/erc-7540","discussion":"https://ethereum-magicians.org/search?q=ERC-7540"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}