A successful withdrawal request can leave a vault user without spendable assets. That is expected behaviour in an asynchronous design, where the request starts a process that finishes later. This technical explainer examines ERC-7540’s request-and-claim model and why an interface needs to communicate more than whether the first transaction succeeded.
TL;DR
- ERC-7540 separates asynchronous requests from their later claims.
- A vault can have immediate deposits and delayed redemptions.
- A pending request needs clear valuation, timing and cancellation disclosures.
The process has more than one completion point
The ERC-7540 standard defines pending, claimable and claimed stages for asynchronous requests. A vault may use asynchronous deposits, asynchronous redemptions or both. The standard also leaves some economic details to the implementation, including how an exchange rate is determined while a request is pending.
Consider a hypothetical treasury holding 1,000 vault shares. It submits an exit request for 300 shares because it expects to pay a supplier later. The request transaction confirms, but the treasury has not necessarily received the underlying asset. Treating confirmation as cash availability could lead it to promise a payment it cannot yet make.
The accounting view should therefore distinguish the remaining unrestricted position, the amount involved in the request and any assets actually available to claim. These categories answer different questions. Combining them into one balance may be convenient visually while obscuring the user’s ability to meet an immediate obligation.
Entry and exit can have different timing
Centrifuge’s vault documentation describes both fully asynchronous vaults and configurations with synchronous deposits but asynchronous redemptions. A fast deposit experience therefore does not establish that the reverse journey will take the same amount of time.
That asymmetry can make sense when a product accepts capital immediately but needs time to release it from underlying positions. The user experience should explain the difference before the deposit. Learning about a withdrawal process only when trying to leave creates a poor basis for financial planning.
For the hypothetical treasury, the relevant question is not merely whether the vault accepts a redemption request today. It is whether the expected settlement process fits the supplier’s deadline. A portfolio can be valuable while still being unsuitable for an obligation requiring funds at a precise time.
Estimates should identify what can still change
Suppose the interface estimates that the 300-share request will return 315 asset units. That figure needs a clear label. It might be an indicative calculation based on the latest valuation, a fixed entitlement already established by the vault or an amount that can change before processing. Those interpretations are economically different.
A useful display would identify the valuation basis and separate an estimate from a settled claim. It should also show relevant fees and any conditions that remain unresolved. A polished progress bar cannot provide that information unless the underlying product has defined what each stage means.
Cancellation deserves the same care. ERC-7540 does not provide a universal cancellation flow. An application should verify the particular vault’s capabilities rather than presenting a cancel button whose effect is ambiguous. Removing a request from the screen is clearly different from reversing its effect on the contract.
Operational records should follow the request through settlement
An organisation using several vaults needs enough information to reconcile each exit independently. The original instruction, the request identifier, the controlling account and subsequent settlement transactions help connect the eventual receipt of assets with the decision that initiated it.
This also makes failures easier to investigate. A request that remains pending, a claim that is ready but has not been submitted and a completed transfer to an unexpected receiver require different responses. A single status such as withdrawal processing can conceal which party is able to take the next step.
Asynchronous vaults allow applications to represent financial processes that do not finish in one transaction. Their usefulness depends on making that delay legible. The essential user question is when assets become available for the next purpose, and every stage of the interface should help answer it accurately.
Written by the News Desk and edited by Samuel Rae.
Leave a Reply