Threat model

Every row below ends in either a strictly smaller fill or no fill at all, never in a taker getting more than the maker's unsigned SwapVM program authorized. That's why none of the parts need to be trusted on their own.

Failure 02 · caught by layer 2

Wrong or malicious reading

SMALLER FILL
Trigger
Compromised keeper key, faulty Graph pipeline, garbage data
Fails closed by
Can only derate or halt relative to the unsigned baseline, never improve it
Proven by
test_MaliciousOracle_CanOnlyEverMakeFillMoreConservative + two 257-run fuzz properties

Defence in depth

Each layer covers a case the one before it can't. Authorization stops a stranger, monotonicity limits what a compromised keeper can do, and the maker's own switch covers not trusting the pipeline right now.
I

Authorization

Only the keeper address can call pushExposure. A stranger has no write path at all.

II

Monotonicity

Even an authorized but wrong reading can only derate or halt. The fill limit never depends on trusting the oracle.

catches failure 02
III

The maker's own switch

setPausedByMaker is checked before the reading is read. One bool per maker, with no admin override.

Three questions, three answers

  • Liquidity comes from Aqua: the maker's real wallet balance, committed via ship / pull.
  • Risk is calculated by ExposureOracle → _exposureGate1D, entirely at the Aqua/SwapVM layer.
  • Uniswap v4 is an execution venue, nothing more. AquaV4Hook holds no liquidity of its own.

Why no third protocol

1inch and Uniswap already prove the whole claim: exposure-gated liquidity that doesn't depend on the venue. A third, likely half-finished integration (Aave, Morpho, Curve) would dilute that story rather than strengthen it. The project aims for depth of proof on one thesis, not breadth of protocol logos.