Security Overview

The contract-level view of AIMM security: the adversaries the design targets, the four layers that address them, and which limitations are intended rather than pending. Every layer is specified on its own page; this one is the threat model and the routing table.

Operational checklists live with their audience: Pool Deployment & Curation §7 for deployers and curators, Providing Liquidity §10 for LPs, Slippage & Price Impact §5.1 for takers. On the swap path the contracts enforce the TTL staleness gate and the coverage toll; the caller supplies minAmountOut and deadline.

1. Defense layers

2. Threat model

2.1. Adversary capabilities

2.2. Trust assumptions

Only the Owner can act destructively protocol-wide. Every other role is bounded by what the contracts let it call, not by an expectation that it behaves. Loss columns read as the worst case with that principal fully compromised. The treasury is a pointer the Owner rotates on the GOVERNANCE tier, so the Owner row covers fee custody too.

• Owner writes risk parameters, curves, oracle config and hooks, upgrades the fleet, and un-halts. On an official pool it is the only principal that can un-halt; a seated third-party pool admin clears its own risk bit immediately and the guardian bit after the LISTING delay. Upgrades are timelocked, risk parameters are not (Risk Steward).
• Guardian cannot un-halt, upgrade or move value; compromising it stops the protocol; it cannot drain it. A halt shuts deposits and exits as well as swaps, so its cost to users is a freeze, not a loss (Guardian).
• Treasury calls Admin.claimTreasury and nothing else, minting the protocol’s accrued fee share, held as pending LP shares, to itself. Reserves, liabilities, LP positions and parameters are out of reach (Treasury).
• Mark signers are the mark’s authority. A price is accepted because k of n registered signers signed that exact blob, never because of who submitted it (Mark Relayer).
• Oracle relayer holds no signing key: its surface is delay, withhold and reorder inside the 120 s segment window, a liveness actor, and the chain gates on staleness. List, window and roster commitment: Mark Relayer §3.4.
• Pool admin is a seat the protocol owner names in the initdata it passes to the owner-only PoolFactory.createPool: authority over that pool only, none over official pools, other pools or protocol state. Treat an uncurated pool as operated by whoever holds its seat (Pool Deployment & Curation §2).

3. Layer 1: economic security

Manipulation resistance:

• External keeper mark: quote source is an off-venue signed aggregate, not pool reserve state; reserve moves cannot move the quote.
• No write-on-swap: a swap never mutates a feed, so there is no accumulator to manipulate.
• Inventory skew bounds: PricingLib.computeInventorySkew returns a dimensionless int8 clamped to $[-100,100]$, saturating at coverage $c\le \frac{1}{2}$ and $c\ge 2$. One skew unit maps to ${10}^4/200=50$ bps of curve-x displacement, so the clamp caps the coverage-driven mid shift at $\pm 5000$ bps of the curve, then clamps into range. Spline depth and spread are separate terms, so this is not a cap on total price impact. The bounds are fixed in code, not operator-set.
• Reserve floor: the per-asset minLiquidity is the hard floor on every outflow. A swap, withdrawal or flash loan reverts InsufficientAmount if it would leave $R_{liq}$ below it (PoolIOLib.settle; there is no exec function). Quoted outflows (swap, cross exit, liability swap) also stop at the leg’s coverage floor $c^{*}={\kappa }_{\mathrm{c}\mathrm{o}\mathrm{v}}/({\kappa }_{\mathrm{c}\mathrm{o}\mathrm{v}}+\mathrm{B}\mathrm{P}\mathrm{S})$: the quote clamps gross output there and refuses a larger size (Inventory Management §6.2).

Incentive alignment:

• Coverage-aware pricing: the symmetric spread plus inventory-skew mid shift and convex coverage toll make coverage-worsening flow pay more (no directional fee term in the spread itself).
• One LP settlement rate: every mint and exit settles at the pool-level solvency rate C, which no exit can move by exiting. A cross exit converts face · C and a same-asset exit is allocated min(c_leg, C) pro-rata, less the exit toll (Inventory Management §5.2), so there is no first-mover advantage and nothing to gain by slicing. A real loss on any leg is shared pro-rata by every LP in the pool, except a yield-venue loss, which is written down on that leg alone (Hooks §5.2). Each leg’s notional is bounded by its deposit cap and its claim-book share by the weight cap maxLiabWeightBps (Inventory Management §5.3; values per pool: deployed instances). Coverage is never rewritten by a background process.

Layers 2 and 3 are specified elsewhere: Access Control for principals, timelock tiers and halt authority, Guards for the per-asset flag bits and risk thresholds.

4. Layer 4: code security

Solidity =0.8.36 (exact pragma), custom error types, and the build-time artifact guards that pin storage layout (ArtifactGuards.t.sol, AdminFlashUUPS.t.sol). The test suite covers unit, integration, fuzz and invariant cases; specific proofs are cited at the property they establish rather than claimed in aggregate here.

Assurance is internal, run as perpetual auditing, with its methodology public in the audits repository; campaign counts, findings and third-party reports: Audits.

5. Storage security

5.1. Standalone-contract storage isolation

Every contract is standalone with its own default storage layout, and cross-contract calls between distinct singletons (Admin↔Pool, Flash↔Pool) are standard external calls with no shared storage. Slot collisions between distinct contracts cannot occur.

Pool’s own DELEGATECALL targets are a separate case: PoolConfigLib, PoolLiquidityLib and PricingLib (with NUQuarticLib behind PoolConfigLib), plus AdminParamsLib on Admin’s side (AIMM Overview §2.1). Each takes its caller’s storage as a storage parameter, so the compiler resolves the slots and there is no hand-mirrored layout to drift.

• Each Pool is a PoolProxy: an ERC-1967 proxy holding its implementation in its own slot, whose upgradeTo answers PoolFactory only. Its PoolStorage sits at slot 0. Cross-pool storage isolation is automatic; code is shared and the factory moves the whole fleet.
• The mark store lives in the Pool implementation’s own storage: pools read it by a 1-3 byte STATICCALL into Pool.fallback, and pushes and store governance DELEGATECALL the store logic (MarkStoreP8) from the implementation. It is one store per chain, not per pool.
• The Admin and Flash singletons are UUPS contracts behind ERC-1967 proxies (UpgradeGate, placed first so its 50 reserved slots lead the layout); their state is keyed by (pool, ...).
• The reference Pool impl follows an append-only rule on PoolStorage: existing fields’ offsets and types are frozen across upgrades (new fields appended only). ArtifactGuards.t.sol pins it at build time, asserting Pool declares exactly one storage entry ($ at slot 0).
• ERC-7201 namespaced storage is not used anywhere: plain default storage at slot 0 is sufficient since DELEGATECALL targets are fixed at compile time (no Diamond/module-registry pattern).

5.2. Transient storage (EIP-1153)

Transaction-scoped only, cleared automatically at the end of the transaction: reentrancy guards and flash-loan state. Marks are not cached: one pool call loads each leg’s mark word once and reads it from memory. The guards built on it, the exploit they close and their gas: Flow Guards.

6. Oracle security

Push-path validation (source-time window, per-lane band, k-of-n quorum), the formula and the quorum ceremony: Mark Relayer §3.3. Multi-source aggregation happens off-chain; the chain sees a single mark.

There is one mode and no fallback switch. Degradation escalates in this order:

Thresholds and readers: Mark Relayer, Flow Guards.

7. Upgrade security

Pools are not per-instance immutable: one GOVERNANCE-tier fleet upgrade replaces the code of every pool, third-party pools included, with no opt-out. Admin and Flash upgrade separately as UUPS singletons under the same tier, and PoolFactory, the LPToken implementation and the linked libraries have no upgrade path at all. The mark store moves only with the Pool implementation. Procedure, grace window, cancel authority and storage-layout obligation: Admin.

8. Emergency procedures

Runbook and authority: Access Control for the lever list and delays, Guardian Routines for the procedure. Disclosure intake: Audits.

9. Known limitations

9.1. Economic bounds

9.2. Oracle limitations

The mark is an off-chain aggregate, signed by a $k$-of-$n$ attester set and relayed by an allowlisted relayer. Three attack surfaces. The on-chain guards cover the second and third; they barely cover the first. Push-path mechanics: Mark Relayer.

Surface 1 has no cryptographic answer: the pipeline’s pre-signing refusals (Mark Relayer §1.2) catch a minority venue moving, not a coordinated majority, and the bands bound the rate of change, not correctness. What is left is the capital cost of moving a majority of the weighted book, which is low for a thin asset, so listing is a curation decision (Pool Deployment & Curation §7). Where the reference tier shares the primary’s signer set, surface 2’s cumulative bound is gone (Mark Relayer §4.4).

The keeper controls timing, not content; the on-chain bound is the relayer list and the 120 s window, the rest is operational: leader election with failover across a configured keeper set, a per-feed staleness alarm at $\max (2·\mathrm{h}\mathrm{e}\mathrm{a}\mathrm{r}\mathrm{t}\mathrm{b}\mathrm{e}\mathrm{a}\mathrm{t},\mathtt{t}\mathtt{t}\mathtt{l}\mathtt{S}\mathtt{e}\mathtt{c}\mathtt{s}/2)$, and a periodic manifest-parity check against the mark pipeline’s roster. Cadence and outage bound how well the pool tracks the market and when it stops trading; they are not paths to a wrong price.

10. Related documentation