Async redeem semantics

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.

Check withdrawability first if you don't know which path applies. The position endpoint (GET /api/vaults/positions/{chainId}/{asset}/{lp}) reports it alongside your balances, so a UI never has to offer a withdraw the vault would refuse.

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.

1. Attested-free means the protocol's signer attests the capital has actually been freed, or
2. 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. Claimable bounds when you can claim, and the claim pays out once the freed capital is physically back in the vault, so a claim that arrives before the capital does reverts cleanly and can simply be retried.

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 requestRedeem succeeded and capital-freeing is in progress
• claimable (composer-struck) means the settlement was struck on-chain, so claim now for the fastest path (the response's composerStruck field carries this, and it is three-state, true, false, or null for not yet known)
• 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? Every request becomes claimable within its route's timeout, capped by the immutable 7-day GLOBAL_MAX_TIMEOUT. The payout itself lands once the freed capital is back in the vault, and a claim before then reverts and can be retried.

Does requesting a withdrawal lock in the amount owed immediately? The request escrows your shares immediately. The payout is capped by your surviving principal, so a strategy loss realized between request and claim reduces what the claim pays.

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.