Security Overview

The contract-level view of AIMM security: the adversaries the design is built against, the four layers that answer them, how storage and reentrancy are isolated, and which limitations are deliberate rather than pending. Authority, who may halt, who may upgrade, and how long each takes, is Access Control, Roles & Emergency Powers. Disclosure intake is Bug Bounty. Operational checklists live with their audience: Pool Deployment & Curation §7 for deployers and curators, Providing Liquidity §10 for LPs. A taker holds none: the slippage bound, the TTL staleness gate and the coverage toll are enforced on the swap path by the contracts, and the one caller-supplied input is minAmountOut (Basic Operations, Quotes & Routing).

1. Defense layers

2. Threat model

2.1. Adversary capabilities

2.2. Trust assumptions

Only one principal here can do something destructive. The rest are bounded by what the contracts let them call, not by an expectation that they behave.

3. Security layers

3.1. Layer 1: economic security

Manipulation resistance:

• External keeper mark: quote source is an off-venue aggregate (NX-Rates), 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: Pricing.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 only hard outflow gate: a swap, withdrawal or flash loan reverts InsufficientAmount if it would leave $R_{liq}$ below it (PoolIOLib.settle; there is no exec function). There is no coverage-ratio drainage floor: coverage prices flow, it never blocks it.

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).
• LP haircuts: an exit from an under-covered leg is haircut linearly in the deficit, and the suppression cannot be configured away (haircutSuppressorBps < 20_000 enforced at the write, == 0 forced on a coverage-walled leg). It fires at the moment an LP actually leaves, so leaving raises the coverage ratio for those who stay and there is no first-mover advantage. Coverage is never rewritten by a background process.

3.2. Layer 2: access control

Four principals, owner, treasuryOwner, guardians and risk stewards, plus the oracle signer set, with seven timelock tiers from 1 to 14 days under PROD_DELAYS. Full principal table, guardian can/cannot matrix, halt authority and the duration schedule: Access Control, Roles & Emergency Powers (SSoT).

Two properties are worth stating here because they shape everything else:

• Guardians are fail-closed only: halt, tighten, cancel; never un-halt, widen, or write params.
• Risk parameters are deliberately not timelocked: bounded instead by owner fences plus a relative step clamp (Deployment & Upgrades §7.3).

3.3. Layer 3: operational security

Per-asset feature flags (PoolConstantsLib.sol):

HALT_RISK_BIT              = 1 << 0  // Per-asset risk halt
SWAP_ENABLED_BIT           = 1 << 1  // Swap operations
LIABILITY_SWAP_ENABLED_BIT = 1 << 2  // LP position swaps
FLASH_ENABLED_BIT          = 1 << 4  // Flash loans
HALT_GUARDIAN_BIT          = 1 << 6  // Guardian emergency halt (separate source from risk)
// bits 5 and 7 are reserved; bit 3 is unallocated
HALT_MASK = HALT_RISK_BIT | HALT_GUARDIAN_BIT  // checked at every value-moving gate

Halt granularity is per-asset: there is no pool-wide pause bit, and HALT_MASK gates deposit, donate, withdrawTo and swapLiability as well as swaps. Who may set and clear each bit, and every other untimelocked lever: Access Control & Roles §4.

The operator-set thresholds are four, and only four:

3.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.

Third-party audits: none published, and no pre-launch external review completed. See §10.

4. Storage security

4.1. Standalone-contract storage isolation

Storage isolation is structural: 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, no shared storage, so slot collisions between different contracts are impossible by construction. Pool’s own internal DELEGATECALL targets, the linked libraries PoolConfig, PoolLiquidity, Pricing and NUQuartic (see AIMM Overview §2.1 for the no-Diamond architecture), are a separate case: they take Pool’s $ as a storage parameter, so the compiler resolves the slots and there is no hand-mirrored layout to drift.

• Each Pool is an ERC-1967 beacon proxy on PoolFactory (the factory is the beacon) with its own PoolStorage at slot 0. Cross-pool storage isolation is automatic; code is shared and swappable fleet-wide.
• 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).

4.2. Transient storage (EIP-1153)

Transaction-scoped only, cleared automatically at the end of the transaction: reentrancy guards, oracle price caching, flash-loan state.

5. Reentrancy protection

Pool inherits TransientGuard (shared/evm/src/base/TransientGuard.sol), which overrides Solady’s mainnet-only default so TSTORE/TLOAD is forced on every chain, and marks every external entrypoint nonReentrant: the mutex slot is Solady’s, not a hand-rolled one. A second, slot-isolated transient flag blocks reserve-crediting inflows while a flash callback is in flight. Both guards, the exploit they close and their gas: Flow Guards.

6. Oracle security

Validation on the push path, all on-chain and all fail-closed:

• A per-feed TTL revert.
• A mandatory per-feed push clamp (maxDeviation, enforced in _checkDeviation; maxDeviation == 0 reverts at addFeed and updateFeed), volatility-adaptive and hard-capped, so a compromised signer quorum is bounded to a monitorable step per push rather than a one-shot move.
• A k-of-n distinct-signer quorum per batch.

Multi-source aggregation happens off-chain in the keeper (NX-Rates); the chain sees a single mark. Formula and terms: Oracles §8.3. Quorum ceremony: 3.6 §4.

There is one mode and no fallback switch. Degradation is a ladder of reverts:

Thresholds and readers: Oracles §8.2, Depeg Halt §2.

7. Upgrade security

Pools are not per-instance immutable. Upgrades happen by swapping the implementation on the shared beacon at PoolFactory, which re-points every live pool at once, third-party pools included, with no opt-out and no version pinning. Admin and Flash upgrade separately as UUPS singletons under the same UPGRADE tier. Procedure, grace window, cancel authority and the storage-layout obligation: Deployment & Upgrades §4.

PoolFactory, the LPToken implementation, ExternalOracle and the four linked libraries have no upgrade path at all: none sits behind a proxy. Replacing any of them is a redeployment plus a repoint, which for an oracle means a per-asset UPDATE_ORACLE op at the BASE tier (Deployment & Upgrades §4.3).

8. Emergency procedures

Runbook and authority: Access Control, Roles & Emergency Powers §4. Disclosure intake: Bug Bounty.

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 unpermissioned submitter. That is three places a price can be attacked, and they are not interchangeable: the on-chain guards answer the second and third well and the first barely at all. Push-path mechanics: 3.6 §5.

Surface 1 has no cryptographic answer, by construction. What exists is off-chain and statistical: NX Rates refuses to sign a composite that carries fewer than min_accepted_providers accepted venues (2 on mainnet), too few genuinely-ticking legs, or a composite uncertainty above its class ceiling (20 bps pegged, 150 bps volatile); per-source weight is capped at $\mathrm{c}\mathrm{l}\mathrm{a}\mathrm{m}\mathrm{p}(\sqrt{{HHI}_{\mathrm{w}\mathrm{i}\mathrm{n}\mathrm{s}\mathrm{o}\mathrm{r}\mathrm{i}\mathrm{z}\mathrm{e}\mathrm{d}}},·)$ so no single venue carries the mark. Every one of those catches a minority venue moving: dispersion widens the composite CI and the quote is refused. A coordinated majority move does the opposite: the legs agree, the CI stays tight, and the composite is signable and correctly signed. Downstream, the deviation band bounds how fast that mark can walk the pool and the reference band adds nothing at all, because the reference is built from the same aggregation. Stated precisely: both bound the rate of change, neither bounds correctness. The real defense is the capital cost of moving a majority of the weighted book, plus monitoring, and for a thin asset that cost is low, which is why listing is a curation decision (Pool Deployment & Curation §7).

A stale or off-market price is refused before it is signed, off-chain, not on-chain. Each NX Rates replica countersigns a peer-proposed blob only after re-validating every record against its own live market view:

• Price within the feed’s cosign_tolerance_bps (per-feed, bounded to $[0.01,5]$ bps).
• sourceTs skew and age bounds.
• Agreement with its own provider-observation timestamp.
• $\sigma$ within an understatement floor and an overstatement ceiling.
• Confidence below the on-chain halt threshold.

Below quorum nothing is served, so one compromised or lagging replica cannot get a bad price signed. What the chain cannot do is verify that this happened: on-chain, a batch is a valid $k$-of-$n$ signature and a TTL, nothing more. Read the co-signing check as the defense against a minority compromise, and the guards in surface 2 as the defense against the quorum itself.

Where the reference oracle shares the primary’s signer set, surface 2’s cumulative bound is gone. One compromised quorum signs the mark and the reference together, the refBand walks in lockstep and never trips, and only the per-push rate limit and the guardian levers survive. This is a per-chain deploy property, not a protocol property: verify it by comparing SignerGranted logs on the two oracle addresses. Arc shares a set today (3.6 §4.6).

The keeper’s lever is choice, not content. The blob is public and batchPushSigned takes its authority from the signatures, so anyone holding a valid blob can land it: that bounds censorship, not timing. Within the TTL a relayer still chooses which fresh blob lands and when, and up to the grace window the quote carries no staleness premium, so a small deliberate delay costs it nothing; that is the same push-ordering OEV a public mempool grants any observer, and it is why the keeper prefers a private relay (§2.1). There is no on-chain mitigation for it. It is bounded operationally:

• 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)$.
• A periodic manifest-parity check against the NX Rates roster.

Availability is a real limitation, but it is not the manipulation model. 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. Audit status

Third-party audit is pending. Until those reports are published, treat the contracts as experimental: the assurance behind them today is the internal review, the test suite and the invariant proofs described on this page, not an independent opinion. Reports will be linked here when they land; there is no placeholder page in the meantime. See Risk Disclaimer.

11. Related documentation