The dashboard says a customer holds 100 vault shares. They press Withdraw. The strategy needs time to turn its holdings into the underlying asset. The customer wants to know: did I ask for my money, is it ready, or did I receive it?
A share valuation and an available withdrawal answer different questions. A product that displays one number for both will eventually promise something its contracts cannot deliver.
Show what can leave now
For a synchronous vault, ERC-4626 separates conversion previews from limits. A preview estimates an outcome; it does not tell the frontend how much this account can redeem right now. The relevant limit and the contract's actual execution still matter.
Some vaults need asynchronous exits because assets cannot be returned atomically. ERC-7540 extends the vault interface with asynchronous requests. In its redemption flow, requested shares leave the owner's custody on submission. The request becomes claimable and the user or an authorized operator must separately claim. The implementation determines the applicable rate; the original estimate need not equal the final payout.
Design three receipts, not one progress spinner
Pending: show how many shares entered the request and whether anything can be claimed yet. Do not show the same shares as available for another request.
Claimable: show what the actual vault exposes to this controller. There may be partial fulfillment. Distinguish what is available now from what is still queued and show when that state was last verified.
Claimed: distinguish what was received from the original estimate. Keep the transaction with the position history. If the user opens another tab, current contract state must govern what they can withdraw; a cached page cannot authorize the action.
Test the promise the interface makes
Write acceptance cases against the specific implementation. Can an unauthorized wallet claim for the controller? Does a partial claim leave the remainder pending? What happens if state changes between loading and signing? Avoid promising a cancellation path or settlement date unless the vault actually supports it.
An operator view should separate strategy liquidity, amounts queued, claimable amounts and payouts. That is also how to tell whether an apparent missing balance is a UX issue, a data issue or a contract issue.
Try Withdrawal Queue Lab
Request 100 fictional shares, make 40 claimable and collect the partial payout. Try to claim early, as a different controller or twice. The lab uses a fixed illustrative conversion rate, a single request and no contracts or market prices. It illustrates the lifecycle, not a complete implementation of the standard.
What dOrg would build first: one vault adapter and withdrawal UI with a request receipt, partial claim support, and contract and interface tests for stale state and unauthorized claims. Bring one vault and its liquidity rules.