Non-custodial design
What "non-custodial" means in Aqua0's vault model, and what it does not mean.
This page describes the current vault architecture, a per-asset shared pool with non-transferable, per-strategy consent positions. It supersedes earlier descriptions of prior liquidity models.
What it means
Locked liquidity sits in a per-asset, per-chain AssetVault (each chain's aqUSDC, for
example, is a separate contract), not a team-controlled wallet, and the team cannot move locked
assets to an arbitrary address through ordinary contract calls. Locking liquidity does not mint a
tradeable share token, it credits your principal instead, a scalar claim denominated in the
underlying asset.
Your principal backs the vault's strategies by consent, not by a token transfer, recorded as a non-transferable, read-only position rather than something you can sell or move to someone else. Capital is either idle (sitting in the vault's shared pool) or deployed (currently sourced out to a strategy you've consented to back, working through a registered adapter such as JIT liquidity or a cross-chain strategy). Realized gains and fees accrue to a separate withdrawable balance, credited in proportion to your actual participation in that strategy, and there's no share price to track.
Sync versus async withdrawal
- Free principal (idle capital) withdraws instantly, with no request/wait step.
- Deployed principal withdraws asynchronously, first requesting then claiming once the protocol frees the capital (adapter unwind / settlement). This is the flow used when your principal is currently backing a strategy rather than sitting idle.
See Async redeem semantics for the full request/claim lifecycle if you're integrating against it.
The never-trapped guarantee
An async redemption request becomes claimable when either of the following happens.
- the capital is attested free (the protocol's signer confirms the position has been unwound/settled), or
- a timeout backstop elapses, regardless of attestation.
Every timeout is bounded by an immutable, compile-time ceiling of 7 days that no owner, governance, or upgrade can raise. So even if attestation fails entirely, every request becomes claimable on its own within 7 days, with no discretionary step required. Each route's timeout is configured independently and can never be tuned past that 7-day ceiling. The claim itself pays out once the freed capital is physically back in the vault, and a claim that arrives before the capital does reverts cleanly and can be retried.
What non-custodial does not mean
It does not eliminate the following risks.
- smart contract risk (the vault, adapters, and Composer are new contracts under audit, see Audits & security process)
- chain risk
- bridge/messaging risk in cross-chain flows
- off-chain trust in narrowly-scoped signing keys (see below), where the team can't arbitrarily redirect funds, but this isn't fully trustless, since a small number of bounded, monitored roles have real (though limited) power.
Bounded, monitored roles
Vault access control is role-based, each role a distinct key held by a distinct signer, and every role is scoped narrowly enough that no single one can drain the vault.
- No key can move locked assets to an arbitrary address, since capital only moves through registered, allow-listed venues.
- Pausing and resuming are separate powers, so a single compromised key can freeze the vault but can't also unfreeze and drain it, since resuming requires a separate, slower authorization.
- Upgrading the vault implementation passes through a timelock delay, giving a response window before any change takes effect.
The hybrid PnL model, the one place off-chain trust remains
Your withdrawable balance is not fully self-attested. Same-chain realized PnL is settlement-derived and trustless, applying straight from the settlement event whenever an adapter settles a position, and no key can move this number.
Cross-chain in-flight PnL works differently, since capital deployed on another chain, before the bridge/message finalizes, can't be observed on-chain in real time.
At beta's settings, a report can move a strategy's valuation by at most 25 bps per day. The rate is tunable by governance, but every setting is clamped by an immutable per-epoch ceiling that no owner action can raise. The clamp bounds the rate of change, not a lifetime total, and every report is reconciled against the real settlement amount well before drift could add up to anything material. A compromised reporting key can therefore nudge a valuation by a bounded amount per epoch. It cannot drain the vault, move funds, or hide a real loss. That is a materially narrower trust assumption than a withdrawal-authorizing role, and it exists only to cover the in-flight cross-chain gap that same-chain settlement can't observe on its own.
A small number of narrowly-scoped, monitored roles carry real but bounded power over this design, covering reporting in-flight cross-chain PnL, routing deployed capital through registered venues, and upgrading the implementation. Each is constrained so a single key compromise can't immediately drain funds, but compromise of any is still a serious incident. See Risks & disclosures for the full breakdown.
Permit or refuse cross-chain fronting for one pair or destination chain
Narrows what the matcher will choose for this LP. It moves no funds and carries no capital authority, and the chain does not enforce it: the hard on-chain off switch remains the filler participation registry. Wallet-bound so an LP can only set their own preference.
Risks & disclosures
The main risks users and integrators should understand.