Aqueduct

Exposure-gated Aqua liquidity. One maker strategy, safety-checked whether it fills a swap directly through SwapVM or through a Uniswap v4 pool.

Loading deployment...

Maker exposure

Pool activity, from The Graph (Messari shape)

liquidityPools + swaps in Messari DEX-AMM field names — the same query pattern works against any standardized DEX subgraph. No RPC calls on this panel. Refreshes every 60s (cached).

Loading from subgraph…

Standards proof — paste this into any Messari DEX subgraph, same shape back
{
  liquidityPools {
    id
    inputTokens { symbol }
    swaps(first: 5, orderBy: blockNumber, orderDirection: desc) {
      tokenIn { symbol }
      amountIn
      tokenOut { symbol }
      amountOut
    }
  }
}

Swap directly via SwapVM

Calls swapVM.swap(...) straight from your connected wallet -- no contract needed as taker (SwapVM's useTransferFromAndAquaPush flag handles the transfer for you). Runs through the maker's program, including the exposure gate.

tokenIntokenOut

Connect a wallet to swap.

Swap via Uniswap v4

No v4 deployment found. Run forge script script/AqueductV4Demo.s.sol ... after the main demo script, then reload.

Strategy P (price + risk aware)

No sophisticated position found in this deployment. Run forge script script/AqueductV2Redeploy.s.sol ..., then reload.

Risk-adjusted dynamic fee (Uniswap v4)

No dynamic-fee pool found in this deployment. Run forge script script/AqueductV3DynamicFee.s.sol ... after the main demo script, then reload.

Keeper control (demo)

Stands in for the off-chain Graph pipeline (see subgraph/ + keeper/pushExposure.ts), which would push this same value automatically in production. Use it to move the maker's reported exposure and watch both swap panels react. "Malicious (100%)" pushes ExposureOracle's own real on-chain maximum -- an intentionally bad reading, still only ever able to halt a fill, never improve one.

Activity

Nothing yet -- try a swap or push an exposure reading.

The oracle can lie, but it cannot make the maker trade more than the underlying SwapVM program authorized.

Try every preset above, including "Malicious (100%)" -- every reading the keeper can post either derates a fill or halts it outright. None of them can ever produce a better fill than the maker's own unsigned program already allowed. See test_MaliciousOracle_CanOnlyEverMakeFillMoreConservative for the proof.