Security model
What AquaQoS trusts, which paths it enforces, what project reviews covered, and what remains open.
Internal review only
Every review below is internal to the project. There has been no external audit. Nothing here authorizes real funds or establishes solvency, profitability or market safety.
Trust assumptions
- Authentic dependencies. The configured Aqua and router addresses must host the pinned code. The constructor checks code length and the router's Aqua getter, which cannot rule out a counterfeit or a proxy. Deployment must verify runtime bytecode, as the fork and Sepolia proofs did.
- Honest standard ERC-20 tokens. Rebasing, fee-on-transfer, callback-bearing, malicious balance-reporting and arbitrary allowance-revoking tokens are unsupported.
- The owner may pause. Pausing ends the capacity commitment. It is the exit path, not a hidden guarantee.
Enforced boundaries
| Path | Enforcement |
|---|---|
| Program shape | Exactly guard, XYC, salt. Anything else fails with InvalidGuardProgram |
| Fee recipes | The vault cannot ship them; nonempty fee state fails with UnsupportedFees |
| Maker hooks, receiver, unwrap | Fixed traits: hooks disabled, receiver is the vault, unwrap off. Changing them changes the Aqua key |
| Taker callbacks | Run after the reservation; nested sibling fills see it |
| Same-order reentry | Rejected by SwapVM's per-order lock (UnexpectedLock) |
| Owner callbacks mid-fill | Every lifecycle call fails with TransactionInProgress |
| Other apps | Aqua keys balances by app; another app's pull from the vault fails |
| Allowance | The full guarantee allowance floor is preserved on every output |
| Vault surface | No generic call, delegatecall, arbitrary approval or upgrade entrypoint |
Allowance-floor correction
The first output policy checked transferable inventory against remaining entitlements only.
Because standard tokens can decrement even a maximum approval, and Aqua.push is
permissionless, enough trading could leave restored entitlement without transferable backing.
The implemented rule requires allowance >= sum(g) + sum(r) + d on every output. A follow-up
review confirmed the correction within the supported token and dependency assumptions.
Review record
| Date | Scope | Result |
|---|---|---|
| 2026-09-06 | Router, vault and canonical programs | Allowance accounting issue identified and corrected; prototype limits accepted |
| 2026-09-08 | Independent review of callback and conservatism tests | No production or blocking test defect |
| 2026-09-09 | Release review of authorization, programs, floors and exits | No new blocker in the v0 domain |
| 2026-09-10 | Independent internal source review | No release-blocking defect in the v0 domain |
| 2026-09-11 | Independent internal review before Sepolia | No critical, high, medium or low defect demonstrated in v0 scope |
Threat model and residual risk
The most important residual risks are owner-key compromise, admitting a token outside the supported standard-ERC-20 domain, callback sequences beyond the tested depth, and the bounded cost of reading sibling state. The deployment is intentionally non-production: its public Sepolia tokens are valueless and owner-mintable.
| Boundary | Current control | Residual condition |
|---|---|---|
| Owner lifecycle | Immutable owner, paused-state exit, no generic call or upgrade path | A compromised owner can pause, dock and withdraw the group |
| Token semantics | Immutable pair and real-balance/allowance checks | Rebasing, fee-on-transfer, callback-bearing and malicious tokens are unsupported |
| Nested execution | Transient reservations, per-order locks and rollback tests | Mixed-direction and deeper nesting need broader coverage before scope expands |
| Evidence and release | Pinned inputs, retained receipts and source-match checks | Public testnet proof is not an external audit or authorization for real-value use |
Accepted limitations
| Limit | Consequence |
|---|---|
| One immutable pair, canonical fee-free XYC, at most eight strategies | Other recipes are unsupported |
| Honest standard ERC-20 behavior | One DAI/WETH fork run does not extend support to arbitrary tokens |
| Reservations last until transaction end | Some safe sequential fills in one transaction are rejected |
| Full guarantee allowance floor | Low allowance can reject otherwise backed fills |
| Input-ledger saturation and XYC overflow | Eligibility does not promise settlement; failures roll back |
| Bounded fuzzing and gas measurements | No exhaustive proof and no universal gas bound |
Remaining test breadth: mixed-direction and deeper callback nesting, successful nesting after outer output settlement, combined finite-allowance and payment routes, explicit zero-output rollback, and universal callback or token gas bounds. These are coverage limits, not demonstrated defects.
Verify
- Full threat modelView source on GitHub · docs/THREAT_MODEL.md
- v0 implementation reviewView source on GitHub · docs/SECURITY_REVIEW_V0.md
- Release reviewView source on GitHub · docs/SECURITY_REVIEW_RELEASE.md
- Review before SepoliaView source on GitHub · docs/SECURITY_REVIEW_SEPOLIA.md
- Release verification and accepted limitsView source on GitHub · docs/RELEASE_VERIFICATION.md