Async redeem semantics
Sync vs. async vault withdrawals, the settlement guard, and the never-trapped invariant.
Aqua0 vaults are per-asset, per-chain vaults (each chain's aqUSDC, for example, is a separate
contract). Locking liquidity does not mint a share and instead credits your principal, a claim
denominated in the underlying asset. This page covers when withdrawal is instant versus
request/claim, and the guarantee behind the async path.
Sync vs async
Your principal is either idle (in the vault's shared pool) or currently backing a strategy you've consented to. The vault, not you, determines the path, with idle principal withdrawing synchronously while principal backing a strategy goes through the async guard below.
| Sync (free principal) | Async (deployed principal) | |
|---|---|---|
| Applies when | Vault has enough idle balance | Withdrawal requires unwinding/settling deployed capital |
| Call | Standard synchronous withdraw | requestRedeem → wait → claimRedeem |
| Latency | Immediate, same transaction | Request now, claim once claimable |
| Amount owed | Fixed at withdrawal time | Locked in at request time |
Call the withdrawability check first if you don't know which path applies (see Status & errors for the polling pattern).
The settlement guard (never-trapped)
requestRedeem records the request and begins freeing the position (adapter unwind, or waiting on
a cross-chain settlement), though the vault doesn't move assets immediately. A pending request
becomes claimable when either of these happens.
- Attested-free means the protocol's signer attests the capital has actually been freed, or
- Timeout backstop means the
now >= requestTime + timeout[route]window has elapsed, regardless of attestation.
Every route's timeout is bounded by an immutable GLOBAL_MAX_TIMEOUT = 7 days that no owner,
governance, or upgrade path can raise, and each route's timeout is configured independently below
that ceiling. So even if the attestation path fails entirely, every request becomes claimable on
its own within 7 days, so there's no scenario where a valid request is withheld indefinitely.
Claiming
Once claimable, call claimRedeem to receive the assets. The guard is re-evaluated at claim time
using the same attested-free OR timeout-elapsed logic, so a timeout-cleared request claims
identically to an attestation-cleared one.
Per-chain isolation
Principal isn't fungible across chains, since each chain's aqUSDC is a separate vault with its own
accounting, reflecting only that chain's realized and reported PnL. That doesn't mean capital
locked on one chain is stuck there, since Chain-A capital can still back a strategy executing on
Chain-B (a deliberate, first-class case). That's precisely why the hybrid PnL model (see
Non-custodial design) needs a bounded cross-chain reporter, to
value Chain-B-deployed capital before the cross-chain settlement becomes an on-chain fact.
Status & error states
Track a pending redemption like a swap (see Status & errors).
- requested means
requestRedeemsucceeded and capital-freeing is in progress - claimable (attested) means the signer attested the capital is free, so claim now for the fastest path
- claimable (timeout) means the per-route timeout elapsed, so claim now
- claimed (terminal, success)
"Requested" is expected/normal for any deployed-capital redemption, especially cross-chain, so only escalate if a request isn't claimable well past its route's timeout.
FAQ
Can a redemption ever be permanently stuck?
No, every request is claimable within its route's timeout, capped by the immutable 7-day
GLOBAL_MAX_TIMEOUT.
Does requesting a withdrawal lock in the amount owed immediately? Yes, the amount is fixed at request time, not claim time.
Why would my withdrawal go through the async path instead of instantly? Only when the vault's idle balance can't cover it, i.e. your principal is currently backing a strategy through an adapter.