---
title: "Glossary"
description: "DeFi, TradFi, and statistical terms used in AIMM docs."
audience: both
type: explanation
status: live
lang: en
updated: "2026-09-04"
publish: true
---
# Glossary

## A {#a}

### Adverse Selection {#adverse-selection}
Risk that counterparties possess superior information about fair value. In AMMs, informed traders extract value by trading against stale prices, whether from reserves (Uniswap), internal oracles (Curve v2), or external feeds. Adverse selection is the mechanism behind [LVR](#lvr-loss-versus-rebalancing), ranging from benign [Statistical Arbitrage](#statistical-arbitrage-stat-arb) to devastating [Informed Order Flow](#informed-order-flow-alpha-toxicity).

**AIMM mitigation**: Quoting off a fresh keeper mark minimizes staleness; coverage-driven [inventory skew](#inventory-skew) shifts the mid against trades that worsen [Coverage Ratio](#coverage-ratio) (the spread itself stays symmetric).

See [Arbitrage](#arbitrage), [Toxic Flow](#order-flow-toxicity), [LVR](#lvr-loss-versus-rebalancing), [Adversarial Behavior](#adversarial-behavior).

### Adversarial Behavior {#adversarial-behavior}
**Value extraction without protocol or LP consent.** Strategies that profit by exploiting information asymmetries, timing advantages, or system inefficiencies at the expense of other market participants.

**Categories**:
- **Information-based**: [Frontrunning](#front-running), [Sandwich Attacks](#sandwich-attack), [Informed Order Flow](#informed-order-flow-alpha-toxicity)
- **Timing-based**: [Latency Arbitrage](#latency-arbitrage), [JIT Liquidity](#jit-just-in-time-liquidity)
- **Block-ordering**: [MEV](#mev-maximal-extractable-value), [Greasing](#greasing), [MEV Spoofing](#mev-spoofing)
- **Price-based**: [Statistical Arbitrage](#statistical-arbitrage-stat-arb) (when purely extractive), [Toxic Flow](#order-flow-toxicity)

**Economic impact**: Adversarial behavior imposes [Adverse Selection](#adverse-selection) costs on LPs, increases [LVR](#lvr-loss-versus-rebalancing), and widens spreads. While some extraction is unavoidable (stat arb), the defensible response is to price it: charge the adverse-selection cost in the fee rather than attempt to convert the extractor into a counterparty.

**Examples**: Sandwich attack on DEX trade (harmful), latency arbitrage against stale oracle (extractive), JIT liquidity frontrunning passive LPs (fee theft).

See [Cooperative Behavior](#cooperative-behavior), [MEV](#mev-maximal-extractable-value), [Arbitrage](#arbitrage), [Order Flow Toxicity](#order-flow-toxicity).

### AMMs (Automated Market Makers) {#amms-automated-market-makers}
**Master entry for AMM designs.** Protocols enabling decentralized trading via algorithmic pricing rather than order books. All AMMs trade off capital efficiency, slippage, and MEV exposure.

**Architecture Families**:

| Family | Examples | Capital Efficiency | Price Impact | Model |
|--------|----------|-------------------|----------|-------|
| **[CSMM](#csmm-constant-sum-market-maker)** | Component of hybrid CFMM eg. Curve | Very high | Zero | x+y=k linear |
| **[CPMM](#cpmm-constant-product-market-maker)** | Uniswap V1/V2, Raydium | Low | Convex | x·y=k hyperbolic |
| **[CFMM](#cfmm-constant-function-market-maker)** | Curve, Balancer, Gyroscope | Variable | Convex/Flat | Invariant F(x₁,...,xₙ)=k |
| **[CLMM](#clmm-concentrated-liquidity-market-maker)** | Uniswap V3/V4, Raydium CLMM, Orca | Very high | Tick-dependent | Tick-based ranges |
| **[DLMM](#dlmm-dynamic-liquidity-market-maker)** | LFJ V2, Meteora, Saros | Very high | Bin-dependent | Bin-based + dynamic fees |
| **[CCMM](#ccmm-circularorbital-constant-market-maker)** | Orbswap | Very high, pegged-only | Bounded | n-dimensional sphere |
| **[AIMM](#aimm-adaptive-inventory-market-maker)** | BTR | High (spline + σ-dispersion) | Spline-shaped | Anchor-path pricing + inventory |

**Core Concepts**:
- [Invariant](#invariant) - Mathematical constraint defining price curve
- [Liquidity Shaping](#liquidity-shaping) - Dynamic adjustment of depth
- Liquidity Concentration - Range/bin-based strategies
- [Price Impact](#price-impact) - Cost of trade size
- [Slippage](#slippage) - Deviation from expected price

#### CSMM (Constant Sum Market Maker) {#csmm-constant-sum-market-maker}
CFMM with x + y = k, giving linear pricing with zero slippage inside the feasible region. Capital-inefficient for large price moves; typically used only near tight pegs or as a component in hybrid designs (e.g., constant-sum segment near peg in stableswap curves).

#### CPMM (Constant Product Market Maker) {#cpmm-constant-product-market-maker}
Special case CFMM with two assets where x·y = k, giving a hyperbolic bonding curve. Marginal price is p = y/x (up to fees). Provides simple, path-independent pricing with convex slippage proportional to trade size relative to pool depth. Canonical design in Uniswap V2 and many Solana AMMs.

#### CFMM (Constant Function Market Maker) {#cfmm-constant-function-market-maker}
General class of AMMs where the state (reserves) of a pool lies on a level set F(x₁,...,xₙ)=k, and trades move the state along this surface. CFMM includes constant-product (CPMM), constant-sum (CSMM), weighted, stableswap, and hybrid curves. Umbrella category for most modern AMMs.

#### CLMM (Concentrated Liquidity Market Maker) {#clmm-concentrated-liquidity-market-maker}
CFMM where LP liquidity is allocated to user-chosen price ranges via ticks rather than spread over all prices. Within an LP's active range, the pool behaves like a local CPMM; outside the range, that LP's liquidity is inactive. Increases capital efficiency and fee density but requires active rebalancing and exposes LPs to out-of-range risk. Examples: Uniswap V3/V4, Raydium CLMM, Orca Whirlpools, PancakeSwap V3, Aerodrome (V3-compatible).

#### DLMM (Dynamic Liquidity Market Maker) {#dlmm-dynamic-liquidity-market-maker}
AMM where liquidity is organized into discrete price "bins" (rather than continuous [ticks](#tick)) with dynamic fee adjustments and liquidity repositioning. **Architecture**: Unlike [CLMM](#clmm-concentrated-liquidity-market-maker) where ranges of N ticks act as local [CPMM](#cpmm-constant-product-market-maker) between endpoints, each DLMM bin acts as independent [CSMM](#csmm-constant-sum-market-maker) with near-zero slippage inside the bin. LP positions are **fungible** per bin (not per individual tick). Volatility-linked fees raise spreads in volatile regimes. **Implementations**: [Liquidity Book](#liquidity-book) (Trader Joe LFJ V2, Avalanche), Meteora (Solana), Cetus (Sui/Aptos), Saros (Solana). See [Liquidity Range](#liquidity-range) for CLMM-DLMM comparison and [Concentrated Liquidity](#concentrated-liquidity) for architecture context.

#### CCMM (Circular/Orbital Constant Market Maker) {#ccmm-circularorbital-constant-market-maker}
Multi-asset AMM for **pegged assets only** (~10-50 in practice), concentrating liquidity around the peg on an n-dimensional sphere, $\sum_{i=1}^{n}(r-x_i)^2 = r^2$, with polar ticks as hyperplanes along the equal-price diagonal. Its geometry isolates risk intrinsically: a depegged asset drains asymmetrically instead of propagating loss across the pool. **Limitation**: the invariant assumes correlated assets and cannot price volatile-vs-pegged pairs, which is the domain AIMM targets. Paradigm's Orbital research, implemented by [Orbswap](https://orbswap.org). Sphere invariant, polar-tick mathematics and the torus extension: [Foundations §10](/docs/foundations#10-circularorbital-market-makers).

#### AIMM (Adaptive Inventory Market Maker) {#aimm-adaptive-inventory-market-maker}
BTR's [AMM](#amms-automated-market-makers) design that quotes off a fresh external keeper mark, applies inventory-based mid-price adjustment, and uses spline-defined liquidity depth for market impact calculation. Price comes from the mark and the depth curve rather than from a pool-wide reserve invariant; see [Invariant](#invariant).

### ALM (Asset-Liability Management) {#alm-asset-liability-management}
Accounting framework tracking what a pool *owns* (assets/reserves) separately from what it *owes* (liabilities to LPs). Enables single-sided deposits and explicit undercollateralization tracking. See: [Coverage Ratio](#coverage-ratio).

### Anchor (Token) {#anchor-token}
An asset's parent in the anchor tree, and its pricing counterpart. The parent is **not** required to be the base: an asset anchors to whichever asset it correlates with (`stETH -> ETH`, `USDT -> USDC`). The base is the root and has `anchor = address(0)`. The feed for an asset is attested in units of its anchor (parent-per-child).

### Anchor Tree {#anchor-tree}
Token topology in which every asset has exactly one anchor (parent) and every anchor chain terminates at the base token, the root. `MAX_DEPTH = 4` bounds one walk, and a path is two walks meeting at the LCA, so `MAX_PATH_LENGTH = 2 * MAX_DEPTH + 1 = 9` nodes and 8 legs. Because it is a tree, the path between any two assets is unique: up to the [lowest common ancestor](#lca-least-common-ancestor), then down. Correlated assets anchor to each other rather than to the numeraire, so a BTC-based or ETH-based pool still quotes stable-to-stable and LST-to-underlying pairs off a single correlated edge. A fully base-anchored configuration is one valid instance of the schema: every leg is then an endpoint leg and no route exercises the interior-leg path. Depth 4 is the schema and fence budget, not a requirement.

### Anchor Path Pricing {#anchor-path-pricing}
Pricing architecture that prices a swap along the unique anchor-tree path between its endpoints, separating **pricing** (how assets relate to each other) from **accounting** (measurement in base token denomination). Endpoint legs carry full spline price impact and settle against reserves. **Interior legs price at mid with inventory skew and carry no impact**, because interior reserves never move. Fee floor, confidence and staleness surcharges sum over all legs, and sigma composes in quadrature. Every node on the path is depeg-band checked. See [Anchor Tree](#anchor-tree), [Anchor (Token)](#anchor-token), [LCA](#lca-least-common-ancestor), and the dex doc `1.1.3. Anchor Path Pricing` for architecture details.

### APR (Annual Percentage Rate) {#apr}
Simple annualised rate, no compounding. On BTR metrics the pool's **fee APR** (trading fees accruing to `liquidityIndexWad`) and a leg's **hook APR** (yield from rehypothecated reserves) are reported separately and are additive when both are present, never multiplied. Fee APR is gross: realised LP return is index growth net of the [LVR](#lvr-loss-versus-rebalancing) paid to arbitrageurs, and nothing in the protocol rebates that.

### APY (Annual Percent Yield) {#apy-annual-percent-yield}
One-year return as a percentage of principal, compounding included, which makes it more accurate than APR for yield-bearing positions. Standard metric for staking yields, lending rates, and farming returns.

### Arbitrage {#arbitrage}
**Master entry for extraction taxonomy.** Strategies exploiting price discrepancies or information advantages to extract value. AIMM's approach: doesn't distinguish by trader intent, only by **coverage impact** (beneficial vs harmful trades).

**AIMM's Coverage-Based Model**:
- **Coverage-improving trades** (beneficial): Rebalance inventory, get a better mid via inventory skew
- **Coverage-worsening trades** (harmful): Worsen imbalance, get a worse mid via inventory skew (the spread stays symmetric - no directional surcharge)

**Arbitrage Taxonomy** (Hierarchy of Toxicity):
1. [Statistical Arbitrage (Stat Arb)](#statistical-arbitrage-stat-arb) - Price discrepancies across venues. Most common, least harmful, economically benign.
2. [Latency Arbitrage](#latency-arbitrage) - Exploits speed/network lags. Infrastructure-dependent, controversial.
3. [Informed Order Flow (Alpha Toxicity)](#informed-order-flow-alpha-toxicity) - Superior information (news, insider). Rare, devastating, pure adverse selection.
4. [Markout Toxicity (Winner's Curse)](#markout-toxicity-winners-curse) - Losses in trends. LP systematically wrong side, not information-driven.
5. [Flow Internalization (PFOF)](#flow-internalization-pfof---payment-for-order-flow) - Retail routed elsewhere, toxic flow to AMM. Structural market design issue.
6. [JIT (Just-In-Time) Liquidity](#jit-just-in-time-liquidity) - Fee extraction via block-level timing. ~1% of Uniswap v3/v4 volume.

#### Statistical Arbitrage (Stat Arb) {#statistical-arbitrage-stat-arb}
Exploiting temporary price differences for the same or correlated assets across venues (CEX vs DEX, L1 vs L2, cross-chain, triangular): buy the cheap venue, sell the dear one. The **most common and least harmful** form of [toxic flow](#order-flow-toxicity) - it reacts to existing price differences rather than to future information, and it tightens pegs and cross-venue consistency. **Not [MEV](#mev-maximal-extractable-value)**: it does not alter block ordering. The LP still experiences it as [adverse selection](#adverse-selection); AIMM's defense is the fresh keeper mark, which shrinks the staleness window it feeds on.

#### Latency Arbitrage {#latency-arbitrage}
Exploiting a speed advantage to trade ahead of slower participants when public prices move - classically, selling into a stale-priced L2 pool while its sequencer is still processing. Infrastructure-dependent, and more benign than [informed flow](#informed-order-flow-alpha-toxicity): speed, not secret information.

#### Informed Order Flow (Alpha Toxicity) {#informed-order-flow-alpha-toxicity}
Trading by participants who know something about fair value that the pool does not - the classic Glosten-Milgrom [adverse selection](#adverse-selection) problem. **Rare but devastating**: unlike [statistical arbitrage](#statistical-arbitrage-stat-arb), which exploits a price lag, informed flow trades *before* the price moves, so the LP loses on both the up-move and the down-move. AIMM's answer is the fresh mark plus the σ, confidence and staleness terms in the [spread](#spread).

#### Markout Toxicity (Winner's Curse) {#markout-toxicity-winners-curse}
The loss an LP takes in a sustained trend even with no direct arbitrage: the pool keeps selling the appreciating asset, so every fill looks toxic in hindsight. Measured by comparing execution price to the price 5-10 minutes later; persistently negative markout means the LP is systematically on the wrong side. Trend-driven, not information-driven.

#### Flow Internalization (PFOF - Payment for Order Flow) {#flow-internalization-pfof---payment-for-order-flow}
Market structure where wallets and aggregators give market makers or solvers first look through private mempools or intent systems. Benign retail flow is internalised at favourable terms and the residual - the toxic, imbalanced part - is routed to public AMMs, so a public pool sees a structurally worse flow mix than a venue capturing both sides. A routing problem, not a speed one.

### Avellaneda-Stoikov Framework {#avellaneda-stoikov-framework}
Market-making model that dynamically adjusts bid/ask spreads to balance inventory risk and adverse selection costs. Computes optimal spreads as function of: (1) inventory position, (2) risk aversion, (3) adverse selection costs.

**AIMM implementation**: Applied via [Inventory Skew](#inventory-skew), which displaces the mid by the skew offset as a function of [Coverage Ratio](#coverage-ratio) deviation. Unlike invariant-based pricing (x·y=k), AIMM's mark-anchored pricing models adverse selection cost through a coverage-driven mid-price skew (the spread stays symmetric).

**See**: [Inventory Skew](#inventory-skew), [Spread](#spread), `1. AIMM/1.1. Pricing`.

---

## B {#b}

### B64 Float Encoding {#b64-float-encoding}

Compact 64-bit floating-point representation of a price, packing mantissa, decimal places and exponent into a single word. It is oracle-internal: `ExternalOracle.sol` (V1) stores a mark this way, but no consumer ever sees one: `getFeed` returns a plain 1e18 WAD (`mark1e18`), and V2 replaces the encoding with a packed lane. The term is defined here because it still appears on the oracle pages; the full treatment is at [Oracles §5](/docs/3-4-oracles#5-b64-float-encoding).

Layout:
- Bits [12-63]: Mantissa (52 bits, high-aligned - `shl(12, mant)`)
- Bits [7-11]: Decimal places (5 bits)
- Bits [0-6]: Exponent + bias (7 bits)

Enables efficient on-chain storage of prices with varying magnitudes and precision.

Used where the 64-bit width buys a storage slot or wire bytes: `IOracle.FeedData` (whole feed in one 256-bit slot, -1,767 gas on a cold read) and the 22-byte signed push record. Not used where a price is computed and immediately handed out: `SwapQuote.markPrice`, `midPrice`, `hopPrices` and the `Swapped` log args are exact WAD, because ABI padding takes every non-indexed event arg to a full word and the encode would save no bytes while costing gas and mantissa precision.

**See**: [Oracles §5.5](/docs/3-4-oracles#55-where-b64-is-used-and-where-it-is-not).

### Base Token (Numéraire) {#base-token-num-raire}
Root asset in a pool's anchor tree, typically a stablecoin (USDC, USDT), WETH, or WBTC. Every anchor chain terminates at it and it is the pool's accounting basis. It is not the pricing counterpart of every asset: assets price against their own anchor, which may sit several levels below the root.

**AIMM config**: `PoolStorage.baseToken`.

**See**: [Anchor Tree](#anchor-tree), [Anchor Path Pricing](#anchor-path-pricing).

### Block Builder {#block-builder}
Entity specializing in block construction within proposer/builder separation (PBS) architecture. Builders receive transactions and bundles from mempool and searchers, simulate for validity, order to maximize value, and construct blocks for validators to propose.

**See**: [MEV](#mev-maximal-extractable-value), [Bundle](#bundle).

### BPS (Basis Points) {#bps-basis-points}
Unit equal to 1/100th of 1% (0.01%).

**AIMM precision**:
- `PBPS = 1,000,000` (0.0001% units)
- 10,000 BPS = 1%
- 100 BPS = 0.01%

### Bridge {#bridge}
Protocol infrastructure enabling asset or data transfer between independent blockchains. Introduces trust assumptions and security considerations for cross-chain verification.

**Types**:
- **[Asset Bridge](#asset-bridge-token-bridge)**: Token/NFT transfers
- **[Messaging Bridge](#messaging-bridge-arbitrary-messaging-bridge---amb)**: Arbitrary data and contract calls

**Mechanisms**: Optimistic (fraud proofs), light-client (cryptographic verification), liquidity networks.

#### Asset Bridge (Token Bridge) {#asset-bridge-token-bridge}
Bridges for moving digital assets between chains. Operates via lock-and-mint (lock source, mint wrapped on destination) or burn-and-release (burn wrapped, release from escrow). Canonical version typically on native chain.

#### Messaging Bridge (Arbitrary Messaging Bridge - AMB) {#messaging-bridge-arbitrary-messaging-bridge---amb}
Bridges enabling arbitrary data and smart contract communication between chains. More flexible than asset bridges, enable cross-chain contract calls and governance execution.

**Examples**: LayerZero, Wormhole, OP Stack bridges.

**Verification**: Cryptographic proofs (zk, merkle), optimistic protocols (fraud proofs), or light clients.

### Bundle {#bundle}
Atomic sequence of transactions submitted as a unit (typically by MEV searchers). If any transaction fails, entire bundle reverts, atomicity is critical for coordinated front-running and back-running strategies. Submitted to builders or MEV relays.

**See**: [MEV](#mev-maximal-extractable-value), [Block Builder](#block-builder).

---

## C {#c}

### Catmull-Rom Spline {#catmull-rom-spline}
Cubic interpolation with centered secant tangents. Considered and rejected for AIMM: **not monotone** in general (no sign-preservation, no magnitude clamp). The shipped method is the [clamped quartic I-spline](#quartic-i-spline). See [Spline (Cubic Interpolation)](#spline-cubic-interpolation).

### Circuit Breaker {#circuit-breaker}
Emergency mechanism that halts operations when safety thresholds are violated. In AIMM:
- `HALT_RISK_BIT` flag halts all asset operations
- Per-asset depeg price bands + base-token depeg halt (`BaseDepegged`) gate tail risk
- Confidence surcharge halts past `MAX_CONFIDENCE_HALT_BPS` (1000 bps); keeper-lag staleness widens the spread and, if extreme, blocks pricing
- Critical coverage triggers maximum [inventory skew](#inventory-skew) on the mid + withdrawal [haircuts](#haircut)

### CLOB (Central Limit Order Book) {#clob-central-limit-order-book}
Order-driven market where buy and sell limit orders are matched by price-time priority. Core market structure for traditional exchanges and some DEXes. Contrast with AMMs which use algorithmic pricing.

**See**: [AMMs](#amms-automated-market-makers), Market Order, Limit Order.

### Concentrated Liquidity {#concentrated-liquidity}
AMM design where LPs supply liquidity inside chosen price ranges rather than across all prices, raising fee density at the cost of active rebalancing and out-of-range risk.

- **[CLMM](#clmm-concentrated-liquidity-market-maker)**: tick-based (Uniswap V3/V4); a range behaves as a local [CPMM](#cpmm-constant-product-market-maker)
- **[DLMM](#dlmm-dynamic-liquidity-market-maker)**: bin-based (LFJ, Meteora); each bin behaves as a [CSMM](#csmm-constant-sum-market-maker)
- **[Quadratic](#quadratic-concentration)** / **[Elliptical](#elliptical-concentration)** concentration: Gyroscope 2-CLP and E-CLP

**AIMM approach**: depth is a pool-level spline ([Liquidity Profile](#liquidity-profile)), not a per-LP range - no range to choose and nothing to rebalance.

**See**: [Liquidity Shaping](#liquidity-shaping), [Liquidity Range](#liquidity-range).

#### Elliptical Concentration {#elliptical-concentration}
Multi-asset concentration on an elliptical curve - a circle stretched (λ), rotated (φ) and displaced (α, β), all fixed at deployment. More elegant than stacking two-asset CLMM instances for correlated baskets. Implementation: Gyroscope E-CLP.

#### Quadratic Concentration {#quadratic-concentration}
Two-asset concentration by a quadratic on a bounded range [α, β]: more capital-efficient than a [CPMM](#cpmm-constant-product-market-maker) hyperbola, more forgiving than a [CSMM](#csmm-constant-sum-market-maker) line. Implementation: Gyroscope 2-CLP.

### Cooperative Behavior {#cooperative-behavior}
**Value-aligned extraction with protocol and LP benefit sharing.** Strategies where actors profit by providing services to the protocol while sharing gains with LPs or returning value to the protocol treasury.

**Categories**:
- **Service provision**: [Backrunning](#backrun) (captures arb without harming preceding tx), beneficial JIT (provides depth for large orders with transparent fees)
- **Protocol-aligned**: Liquidations (maintain solvency), rebalancing arbitrage (bring pool to fair price)

**Characteristics**: Transparent operations, value sharing via protocol fees, long-term alignment over short-term extraction.

**Economic impact**: Cooperative behavior improves price discovery and maintains protocol health without imposing a net cost on LPs. Contrasts with [Adversarial Behavior](#adversarial-behavior), which extracts unilaterally.

**Examples**: Backrunning a liquidation without frontrunning the victim (benign), rebalancing a pool to CEX prices (beneficial stat arb), donating to LPs via `donate()` (raises the liquidity index for every holder).

See [Adversarial Behavior](#adversarial-behavior), [Statistical Arbitrage](#statistical-arbitrage-stat-arb).

### Collateral {#collateral}
**Assets deposited as security or backing for financial obligations.** In DeFi, collateral secures loans, backs derivatives positions, or provides liquidity guarantees. The ratio of collateral to obligations determines solvency and risk exposure.

**Collateralization States**:

| State | Ratio | Meaning | DeFi Context |
|-------|-------|---------|--------------|
| **Over-collateralized** | >100% | More assets than obligations | Safe, low liquidation risk |
| **Fully collateralized** | =100% | Assets equal obligations | Equilibrium, moderate risk |
| **Under-collateralized** | <100% | Obligations exceed assets | Risky, high liquidation risk |

**Common DeFi Uses**:
- **Lending protocols**: Borrowers deposit collateral (ETH) to borrow (USDC). Over-collateralization required (e.g., 150%) to absorb price volatility.
- **Derivatives**: Traders post collateral to back leveraged positions. Under-collateralization triggers liquidation.
- **Stablecoins**: Algorithmic stablecoins backed by collateral (e.g., DAI backed by ETH/USDC).
- **AMM pools**: Reserves serve as collateral backing LP token claims. [Coverage Ratio](#coverage-ratio) measures collateralization health.

**AIMM context**: Pool reserves function as collateral for LP liabilities. [Coverage Ratio](#coverage-ratio) (reserves / liabilities) measures collateralization state. Under-collateralization (<100%) triggers [Haircuts](#haircut) on withdrawals and a positive [skew offset](#inventory-skew).

**Liquidation**: When collateral value falls below required threshold, positions are forcibly closed to protect lenders and the protocol from bad debt.

See [Coverage Ratio](#coverage-ratio), [Reserves](#reserves), [Liabilities](#liabilities), [Haircut](#haircut), Liquidation.

### Confidence (CI) {#confidence}
Per-asset uncertainty attached to the keeper mark: a 1σ confidence interval in bps, pushed alongside the price and stored in the feed (`confidenceBps`). It widens the symmetric spread (the $U_{\mathrm{conf}}$ surcharge) and halts quoting past `MAX_CONFIDENCE_HALT_BPS`. Confidence is the only channel through which oracle uncertainty reaches pricing; deviation bands and push clamps never feed the spread.

**See**: [Deviation (Oracle)](#deviation-oracle), [Feed (Oracle)](#feed-oracle), [Spread](#spread).

### Coverage Ratio {#coverage-ratio}
Core pool-health metric, `reserves / liabilities`: how much actual token the pool holds per unit of LP claim.

**States**:
- **100% (= 1.0)**: Fully collateralized (equilibrium), zero skew
- **< 100%**: Undercollateralized → positive [skew offset](#inventory-skew) on the mid, [Haircuts](#haircut) on withdrawals
- **> 100%**: Overcollateralized → skew offers discount, encourages rebalancing

**Role in pricing**:
- **Skew**: a fixed piecewise-linear law of `c` alone shifts the mid ([Inventory Skew](#inventory-skew)). No per-asset dial.
- **Haircut**: linear deficit×suppression-factor penalty when coverage < 100% prevents bank runs, and restores `c` on every exit
- **Coverage wall**: convex toll `kappaCovBps` on the drained side, priced into the swap itself

**Thresholds**: skew saturates at `c ≤ 0.5` (+100) and `c ≥ 2.0` (-100); these are hardcoded constants in `computeInventorySkew`, not configuration.

**See**: [Inventory Skew](#inventory-skew), [Haircut](#haircut), [ALM](#alm-asset-liability-management). Deep dive: [Inventory Management](/docs/1-1-1-inventory-management), [Parametrization](/docs/1-1-7-parametrization).

### Coverage Impact {#coverage-impact}
The direction a trade pushes a leg's [Coverage Ratio](#coverage-ratio): coverage-improving (restoring inventory balance) or coverage-worsening (draining the leg further). AIMM does not judge trader intent, only impact: worsening flow pays more through the skew-driven mid shift and the convex [Kappa](#kappa-cov) wall on the same size.

**See**: [Arbitrage](#arbitrage), [Inventory Skew](#inventory-skew). Deep dive: [Pool §3.4](/docs/1-2-1-pool).

### Est. Coverage Impact {#est-coverage-impact}
The quote-time estimate of how a pending trade moves a leg's [Coverage Ratio](#coverage-ratio): the signed delta between the leg's coverage after the trade and before it. Positive means the size improves the leg (reserves grow relative to liabilities); negative means it degrades coverage and widens every LP's exit [haircut](#haircut). It is a preview of the quantity [Coverage Impact](#coverage-impact) classifies, computed off the leg's reserves and liabilities without executing anything.

**See**: [Coverage Impact](#coverage-impact), [Coverage Ratio](#coverage-ratio), [Haircut](#haircut). Deep dive: [Pool §5.4](/docs/1-2-1-pool).

### Coverage Toll {#coverage-toll}
A size-dependent charge, in bps of gross output, levied when a swap drains a leg whose [Coverage Ratio](#coverage-ratio) sits below par: the κ_cov wall (`covToll`/`_covToll`, charged before the fee haircut, `Pricing.sol`). Zero when κ = 0 or the trade moves the leg toward balance; growing with size, so the executable ladder widens with depth. With the [inventory skew](#inventory-skew) premium it composes the [Net Premium](#net-premium); it is never part of the fee.

**See**: [Kappa (κ_cov)](#kappa-cov), [Coverage Impact](#coverage-impact), [Net Premium](#net-premium).

## D {#d}

### Delegatecall {#delegatecall}
EVM opcode executing external contract code in caller's storage context.

**AIMM use**: confined to a single `Pool`, into its four linked libraries. Every call *between* distinct contracts (Admin↔Pool, Flash↔Pool, Factory↔Pool) is a normal external call: there is no diamond or facet pattern.

### Depeg Band / Depeg Halt {#depeg-band}
Circuit breaker around the unit of account. A spoke's mark is denominated against the pool's base token, so if the base itself moves off its reference (a stable numéraire losing its peg) every quote is silently mispriced. Each non-base asset carries a mandatory reference feed and band (`refFeedId`/`refBandBps`; `refBandBps == 0` reverts `NotConfigured`). The band is an **agreement check between two attestations of the same quantity, not a peg test**, and it is halt-only: inside it nothing is adjusted, past it the swap reverts `PriceOutsideRefBand`. A base-token breach reverts `BaseDepegged` and halts the hub rather than mispricing every spoke.

**See**: [Deviation (Oracle)](#deviation-oracle), [Feed (Oracle)](#feed-oracle), and the [Depeg Halt](/docs/3-5-depeg-halt).

### Deviation (Oracle) {#deviation-oracle}
Two live, unrelated senses. **Push trigger**: the per-asset band θ past which the keeper pushes a fresh mark before the heartbeat elapses. **Push clamp**: `maxDeviation`, a mandatory non-zero per-feed bound on how far one push may move the mark, volatility-adaptive and capped at 10× its base, revert-on-breach in `ExternalOracle`.

Neither feeds the spread: price uncertainty reaches the spread only through [confidence](#confidence).

**See**: [Confidence (CI)](#confidence), [Feed (Oracle)](#feed-oracle), [Oracles §8.3](/docs/3-4-oracles#83-deviation-bounds).

### Dispersion {#dispersion}
The width of the price range liquidity is spread over. Dispersion scales with volatility: $\sigma$ up widens the curve, $\sigma$ down tightens it, with per-asset sensitivity set by [vega](#vega) and a per-preset cap at the write plus a protocol ceiling.

**Also known as**: range breadth, depth curve width.

Formula, parameter bounds and the per-preset caps: [Liquidity Shaping](/docs/1-1-2-liquidity-shaping).

### Dual ledger (pool hooks) {#dual-ledger}
Economic reserves split as $R = R_{\mathrm{liq}} + R_{\mathrm{inv}}$. Pricing / coverage use $R$; executable cash is $R_{\mathrm{liq}}$. The `YieldHook` default buffer targets $\sim$65% invested with $\pm$5% hysteresis so typical swaps stay on the liquid path (0 CALL). Yield accrues via keeper harvest → `hookCreditYield`; losses via `hookWriteDown`. See [Pool Hooks](/docs/5-1-3-hooks).

---

## E {#e}

### ECDSA (Elliptic Curve Digital Signature Algorithm) {#ecdsa-elliptic-curve-digital-signature-algorithm}
Public-key signature algorithm over elliptic curves. Ethereum and most blockchains use ECDSA with the secp256k1 curve for transaction signing.

### EOA (Externally Owned Account) {#eoa-externally-owned-account}
Ethereum account controlled by a private key, as opposed to a smart contract account. EOAs can initiate transactions but cannot execute arbitrary code. Standard user accounts and validator accounts are EOAs. Account abstraction (EIP-4337, EIP-7702) blurs the distinction between EOAs and contract accounts.

### EIP (Ethereum Improvement Proposal) {#eip-ethereum-improvement-proposal}
**Master entry for Ethereum protocol improvements.** Formal design documents proposing changes to the Ethereum protocol. EIPs are peer-reviewed, numbered, and tracked through development stages (draft, review, last call, final). Covers core protocol upgrades (consensus, networking), client specifications, and application standards. **Every [ERC](#erc-ethereum-request-for-comment) is an EIP, but not every EIP is an ERC.**

**Key EIP Categories**:
- **Core**: Protocol-level changes (consensus, networking, VM)
- **Interface**: Application-level standards (most become ERCs)
- **Meta**: Process and governance improvements

See [ERC](#erc-ethereum-request-for-comment) for application-level standards.

#### EIP-712 (Typed Structured Data Hashing and Signing) {#eip-712-typed-structured-data-hashing-and-signing}
Standard for hashing and signing typed structured data on-chain. Users see human-readable typed data (domain, types, values) instead of opaque hex strings. Prevents signature reuse across domains and enables secure off-chain signature generation. Used by [ERC-2612](#erc-2612-erc-20-permit), [ERC-3009](#erc-3009-transfer-with-authorization), and meta-transaction systems.

#### EIP-1153 (Transient Storage) {#eip-1153-transient-storage}
Transaction-scoped storage cleared automatically at transaction end. Gas-efficient for temporary data. AIMM uses for reentrancy guards and mark caching (saves ~2,100 gas per hit vs persistent storage).

### ERC (Ethereum Request for Comment) {#erc-ethereum-request-for-comment}
**Master entry for Ethereum application-level standards.** Classification within the EIP system focused on smart contract standards and interfaces. ERCs define rules and interfaces for tokens, NFTs, and dApps. All ERCs are EIPs, but ERCs are application-focused rather than protocol-focused.

**Major ERC Categories**:
- **Token Standards**: ERC-20, ERC-721, ERC-1155
- **Token Extensions**: ERC-2612, ERC-3009, ERC-3156
- **Vault Standards**: ERC-4626, ERC-7540
- **Crosschain**: ERC-7802
- **Advanced**: ERC-8004

See [EIP](#eip-ethereum-improvement-proposal) for core protocol improvements.

#### ERC-20 (Token Standard) {#erc-20-token-standard}
Standard interface for fungible tokens. Defines transfer(), approve(), balanceOf(). Foundation for stablecoins, governance tokens, and utility tokens.

#### ERC-2612 (ERC-20 Permit) {#erc-2612-erc-20-permit}
ERC-20 extension adding permit() for off-chain signature approvals. Eliminates separate approval transactions, saving gas. Uses [EIP-712](#eip-712-typed-structured-data-hashing-and-signing) for structured signing.

#### ERC-3009 (Transfer with Authorization) {#erc-3009-transfer-with-authorization}
Enables single-transaction token transfers using off-chain signatures. Uses [EIP-712](#eip-712-typed-structured-data-hashing-and-signing) for secure signature generation.

#### ERC-3156 (Flash Loan Standard) {#erc-3156-flash-loan-standard}
Standardized interface for flash loans. Defines `IERC3156FlashLender` (lender) and `IERC3156FlashBorrower` (borrower callback). Unifies incompatible implementations from Aave, dYdX.

**AIMM**: Implements flash loan interface for capital-efficient arbitrage and liquidations.

See [Flash Loan](#flash-loan).

#### ERC-4626 (Yield-Bearing Vault Standard) {#erc-4626-yield-bearing-vault-standard}
Universal interface for tokenized vaults (lending pools, yield aggregators). Standardizes deposit/withdrawal/share mechanics, improving DeFi composability.

## F {#f}

### Feed (Oracle) {#feed-oracle}
The per-asset record carrying the keeper-pushed mark and its risk metadata - mark, $\sigma$, push timestamp, TTL, 1$\sigma$ confidence, feed flags, per-push max deviation and the NXR-signed source time - written on a deviation band $\theta$ or a heartbeat. The chain stores the signed $\sigma$ **directly**, floored each push at the realized $|\Delta\text{mark}|/\text{mark}$ as a compromised-signer backstop; there is no on-chain $\sigma$-EMA. Full struct, field widths and gating: [Internal Oracle](/docs/1-2-2-internal-oracle) and [Oracles](/docs/3-4-oracles).

### Flash Loan {#flash-loan}
Uncollateralized loan that must be repaid within the same atomic transaction. If not repaid by end of transaction, entire transaction reverts. Enabled by EVM atomicity and contract callbacks, standardized by [ERC-3156](#erc-3156-flash-loan-standard). Enables liquidations, arbitrage, and composable DeFi strategies. AIMM charges `flashFeePbps` as fee.

### Finality {#finality}
The guarantee that a transaction or block cannot be reverted or reorganized. Different consensus mechanisms provide different finality types:

| Type | Guarantee | Time | Examples |
|------|-----------|------|----------|
| **Probabilistic** | Reorg probability decreases exponentially with depth | Minutes-hours | Bitcoin PoW, Ouroboros |
| **Economic** | Reorg requires burning slashable stake | ~10-15 min | Gasper (Ethereum) |
| **Deterministic** | Mathematically impossible to revert | Seconds | Tendermint, HotStuff |
| **Soft (L2)** | Sequencer-guaranteed, not L1-backed | Instant | Arbitrum, Base pre-batch |
| **Hard (L2)** | L1-finalized batch commitment | 10-30 min | Arbitrum, Base post-batch |

**Security threshold**: BFT-style finality requires <1/3 Byzantine stake; Nakamoto-style requires <50% adversarial hashpower/stake.

See Consensus, Validator, [Sequencer](#sequencer).

### FCFS / FIFO (First-Come-First-Served / First-In-First-Out) {#fcfs-fifo-first-come-first-served-first-in-first-out}
Transaction ordering policy where transactions are processed in the order they arrive at the [sequencer](#sequencer) or validator. Used by some rollup sequencers (original Arbitrum model) to provide fair ordering without explicit [MEV](#mev-maximal-extractable-value) auctions. **Limitations**: FCFS is vulnerable to latency games, actors with faster connections to the sequencer can still front-run by submitting transactions microseconds earlier. Many chains have moved to hybrid models combining FCFS with priority fees or explicit MEV auctions ([Timeboost](#timeboost)). Contrast with [price-time priority](#price-time-priority) (CLOB ordering) and [gas auction](#gas-auction) (Ethereum L1 ordering). See [Sequencer](#sequencer), [Mempool](#mempool).

### Flow Guard {#flow-guard}
**Master entry for forbidden call flow protections.** Security mechanisms preventing illegitimate or malicious sequences of calls at transaction, block, or epoch level. Flow guards monitor and block call patterns that violate protocol invariants or enable attacks.

**Scope Levels**:
- **Transaction-level**: Single transaction execution ([Reentrancy Guard](#reentrancy-guard))
- **Block-level**: Multiple transactions within same block (time-based cooldowns)
- **Epoch-level**: Longer timeframes across multiple blocks (staking unbonding periods)

**Common Flow Guard Types**:

| Type | Scope | Protection | AIMM Implementation |
|------|-------|------------|---------------------|
| **[Reentrancy Guard](#reentrancy-guard)** | Transaction | Prevents recursive calls mid-execution | Transient storage (EIP-1153) |
| **Time-based Cooldown** | Block/Epoch | Enforces minimum time between operations | 15 s default (`DEFAULT_FLOW_COOLDOWN`), hard cap 300 s (`MAX_FLOW_COOLDOWN`) |
| **Circuit Breaker** | Epoch | Halts operations during extreme conditions | Volatility/deviation thresholds |

**AIMM-Specific Flow Guards**:
- `deposit()`/`mint()` → `withdraw()`/`redeem()`: Prevents instant LP fee extraction - `LPToken.mint` freezes the minted quantity in `locks[holder] = {stamp, frozen}` and `_beforeTokenTransfer` bounds outflow by `balance - frozen` until the cooldown elapses

Default cooldown: 15 seconds (`DEFAULT_FLOW_COOLDOWN`). Settable per pool by the Admin singleton (`Admin.setFlowCooldown` → `Pool.adminSetFlowCooldown`; stored as `flowCooldownSecs`).

See [Reentrancy Guard](#reentrancy-guard), [Circuit Breaker](#circuit-breaker), [Flow Guards](/docs/3-3-flow-guards).

---

## G {#g}

### Gamma (γ) {#gamma}
A symbol four unrelated bodies of work use for four different quantities. Disambiguation only; none of them is an AIMM configuration field.

- **Avellaneda-Stoikov risk aversion** $\gamma$ in $r = s - q\gamma\sigma^2\tau$ ([A-S framework](#avellaneda-stoikov-framework)). AIMM splits that role in two: [vega](#vega) sets the volatility-scaled half-width, and [inventory skew](#inventory-skew) sets the inventory shift under a fixed protocol law.
- **Curve V2 concentration parameter** γ, paired with `A` in the CryptoSwap invariant. Unrelated to AIMM, which quotes off an external mark and a spline instead.
- **Options gamma**, the second derivative of a position's value. Used in this glossary only when describing the convexity a [CL](#concentrated-liquidity) LP is short.
- **Contention discount** $\gamma_c \in [0.5, 1]$ in the shared-inventory efficiency model ([Capital Efficiency](/docs/foundations)).

**Skew is not an adverse-selection defense** under any name. At coverage ≈ 1 the skew is zero, so the first pick-off is untaxed, and flow that *improves* coverage gets a better price even when informed. The LVR controls are `θ` + heartbeat, `minFeePbps`, `vegaBps`, and the staleness/confidence surcharges. See [Inventory Skew](#inventory-skew), [Vega (ν)](#vega), [LVR](#lvr-loss-versus-rebalancing), [OEV](#oev-oracle-extractable-value).

### Gas Auction {#gas-auction}
Transaction ordering mechanism on Ethereum L1 where transactions compete for block inclusion based on gas price (priority fee). Higher gas price buys earlier inclusion, an implicit auction for block space and ordering priority. This is how [MEV](#mev-maximal-extractable-value) extraction occurs on L1-[searchers](#mev-searcher) bid up gas prices to ensure their transactions land in favorable positions (e.g., before a victim's transaction for [front-running](#front-running)). **Contrast with**:
- [FCFS/FIFO](#fcfs-fifo-first-come-first-served-first-in-first-out): Order by arrival time (some rollup sequencers)
- [Timeboost](#timeboost): Explicit auction for express lane priority (Arbitrum)
- [Price-Time Priority](#price-time-priority): CLOB ordering (exchanges)

Gas auctions create an adversarial environment where sophisticated actors with better gas estimation and faster infrastructure can consistently outbid retail users. This is why [MEV-protected RPCs](#mev-protected-rpc) exist, to bypass the public gas auction entirely. See [Mempool](#mempool), [Block Builder](#block-builder).

### Gas Optimization {#gas-optimization}
Techniques to reduce transaction costs:

- Transient caching (2,100 gas/hit saved)
- Packed structs (single-slot reads)
- Anchor-tree path resolution (bounded at `MAX_DEPTH = 4`, so ≤ 8 legs, no path caching)

### Grace Period {#grace-period}
Two unrelated windows share this name.

- **Timelock grace**: the window after a timelocked op matures during which it may still be executed, 7 days; past it the op expires ([Admin](/docs/1-2-3-admin)).
- **Oracle grace**: the age below which a feed owes no staleness surcharge, $g = \min(\text{ttl}/2,\ 30\,\text{s})$; $U_{\text{stale}}$ is exactly zero inside it ([Oracles](/docs/3-4-oracles)).

## H {#h}

### Half-Spread {#half-spread}
One side of the [spread](#spread): the distance from the mid to either the [bid](#bid-price) (sell side) or the [ask](#ask-price) (buy side), each half of the full bid-ask width. In AIMM a taker pays exactly one half-spread per swap, taken off the output (`Pricing._settleQuote`); the round-trip width is two half-spreads.

**See**: [Spread](#spread), [Paid Spread](#paid-spread), [Total Cost](#total-cost). Deep dive: [Spread & Fees §1](/docs/1-1-4-spread-fees).

### Bid Spread {#bid-spread}
The paid spread on the sell side: the distance from the [mid](#mid-price) down to the price a taker actually sells at. In AIMM it is one [half-spread](#half-spread) plus whatever surcharges bind on that side (staleness, confidence), and the output-side [coverage toll](#coverage-toll) when the swap drains the leg below par - so the two sides meet at the mid only when coverage sits at par and no toll binds.

**See**: [Ask Spread](#ask-spread), [Half-Spread](#half-spread), [Paid Spread](#paid-spread). Deep dive: [Spread & Fees §3](/docs/1-1-4-spread-fees).

### Ask Spread {#ask-spread}
The paid spread on the buy side: the distance from the [mid](#mid-price) up to the price a taker actually buys at. The mirror of the [bid spread](#bid-spread) above the mid, with the same composition - one [half-spread](#half-spread) plus binding surcharges and any output-side [coverage toll](#coverage-toll).

**See**: [Bid Spread](#bid-spread), [Half-Spread](#half-spread), [Paid Spread](#paid-spread). Deep dive: [Spread & Fees §3](/docs/1-1-4-spread-fees).

### Haircut {#haircut}
Penalty on a withdrawal out of a leg whose [coverage ratio](#coverage-ratio) is below 1: **linear** in the deficit and scaled by `haircutSuppressorBps` (`applyHaircut`, `PoolLiquidity.sol`). It rounds up, so the payout rounds down; it cannot be switched off (the writer rejects a suppressor at or above 20,000), and a coverage-walled leg is forced to the full haircut. Liabilities burn at full face while reserves pay out net, so every exit raises $c$ for the LPs who stay. Formula, bounds and settlement: [Inventory Management §5](/docs/1-1-1-inventory-management#5-withdrawal-haircut).

### Heartbeat {#heartbeat}
Maximum interval between keeper mark pushes for an asset when the deviation band θ has not been crossed: whichever of θ or the heartbeat comes first triggers the push. Missed heartbeats widen the spread after the grace period and stop quoting once the feed passes its TTL.

**See**: [Theta (θ)](#theta), [Grace Period](#grace-period), [Feed (Oracle)](#feed-oracle).

### Hub {#hub}
The intermediary asset of a BTR core: its base token. Within one pool a same-pool swap settles along the two assets' anchor path; when both are base-anchored that is the familiar spoke→base→spoke hop, even when quoted as a single trade. Across pools, the shared hub asset routes value between cores; which asset plays the hub is a deployment choice (see [Deployments](/docs/2-overview)). Cross-pool routing always takes the hub *out* of the source pool, so the hub carries a mandatory [Kappa](#kappa-cov) wall like any listed asset.

**See**: [Spoke](#spoke), [Anchor Tree](#anchor-tree).

### Hooks {#hooks}
BTR pool extensibility: per-asset void callbacks on `IPoolHooks` (`preOutflow`, optional `postInflow`) plus [dual ledger](#dual-ledger) ($R_{\mathrm{liq}}$ / $R_{\mathrm{inv}}$). Flags: `HOOK_PRE_OUTFLOW`, `HOOK_POST_INFLOW`. Those two callbacks are the whole surface: both return nothing, so a hook cannot override a fee or alter a quote. Example strategy: `CompoundV2YieldHook` ([rehypothecation](#rehypothecation)). See [Pool Hooks](/docs/5-1-3-hooks).

---

## I {#i}

### Impermanent Loss (IL) {#impermanent-loss-il}
Loss LPs experience when asset prices diverge from deposit ratio, compared to simply holding the assets. Called "impermanent" because if prices return to original ratio, the loss disappears. IL is a fundamental property of AMMs that continuously rebalance, arbitrage merely realizes the loss by trading against the pool. AIMM's oracle pricing and coverage-based depth reduce IL exposure.

### Internal Price Discovery {#internal-oracle}
**External** (`0`): quote = `IOracle(primary).getFeed`. The source is any on-chain adapter (Uniswap, vault NAV, Chainlink, a custom discovery contract) or an NX Rates push. Almost every asset uses this.

**Internal** (`1`): quote = synthetic peg `FeedMathLib.getPegFeed`, mark fixed at 1.0. Only for cash-collateralized 1:1 tokens; the reference feed is the depeg breaker. No reserve TWAP or VWAP, and the base asset cannot use it.

Modes mix per asset. See [Feed Oracle](#feed-oracle), [Mark Price](#mark-price), [Curation §3.2](/docs/5-1-2-pool-deployment-curation#32-oracle-configuration).

### Invariant {#invariant}
Mathematical constraint defining [AMM](#cfmm-constant-function-market-maker) price curves. **Invariant-based designs**:
- [CPMM](#cpmm-constant-product-market-maker): x × y = k (Uniswap V2)
- [CSMM](#csmm-constant-sum-market-maker): x + y = k (linear pricing)
- [CFMM](#cfmm-constant-function-market-maker) (general): F(x₁,...,xₙ) = k
- Stablecoin curves (e.g., Curve's StableSwap)

**Alternatives**: [CLMM](#clmm-concentrated-liquidity-market-maker) (tick-based ranges), [DLMM](#dlmm-dynamic-liquidity-market-maker) (bin-based), [CCMM](#ccmm-circularorbital-constant-market-maker) (n-dimensional). **Concentration variants**: [Quadratic Concentration](#quadratic-concentration) (Gyro 2-CLP: quadratic within range), [Elliptical Concentration](#elliptical-concentration) (Gyro E-CLP: elliptical with transformation params). AIMM breaks from invariant-based pricing entirely, using oracle-aware pricing instead. See [Price Impact](#price-impact), [Concentrated Liquidity](#concentrated-liquidity), and [Liquidity Range](#liquidity-range) for architectural variants.

### Inventory Skew {#inventory-skew}
The mid displacement AIMM applies as a function of [coverage](#coverage-ratio) alone - a **fixed protocol law of $c = R/L$ with no per-asset parameter** (`computeInventorySkew`, `Pricing.sol`), derived from the [Avellaneda-Stoikov](#avellaneda-stoikov-framework) reservation price.

$$\psi(c) = \begin{cases}
-100 & L = 0 \\
+100 & c \le 1/2 \\
+\lfloor 200(1-c) \rfloor & 1/2 < c < 1 \quad \text{(draining arm)} \\
-\lfloor 100(c-1) \rfloor & 1 \le c < 2 \quad \text{(filling arm)} \\
-100 & c \ge 2
\end{cases}$$

Positive below target (the pool bids the asset up to buy it back), negative above; $\psi$ is an `int8` clamped to $[-100, +100]$ by construction. The two arms are **deliberately asymmetric** and the saturation points are protocol constants with no dial. Why those slopes, why $c = 2$ is unique, and why the clamp region is unreachable in practice: [Inventory Management §3](/docs/1-1-1-inventory-management#3-inventory-skew-coverage--skew).

It moves the **mid**, never the [spread](#spread), and it is **not** an adverse-selection defense: at $c \approx 1$ it is zero, and it rewards coverage-improving flow even when that flow is informed.

## K {#k}

### Kappa (κ_cov) {#kappa-cov}
Strength of the **coverage wall**: the convex toll `kappaCovBps` priced into a swap's output when that output drains the delivering leg's coverage. The wall is **output-only**: returning inventory to a leg is never tolled. Every listed asset including the hub must carry κ > 0, and setting κ > 0 forces `haircutSuppressorBps == 0`, so a walled asset always haircuts exiting LPs ([Invariants §I-9](/docs/1-1-8-invariants#i-9-coverage-toll-is-charge-only-and-terminal-only)). Hub κ prices taking the hub out of a thin book on cross-pool hops, while same-pool spoke trades that never output the hub do not touch it.

**See**: [Coverage Ratio](#coverage-ratio), [Coverage Impact](#coverage-impact), [Haircut](#haircut).

### Knot (Spline) {#knot-spline}
Breakpoint on the cumulative-depth axis where curve segments join. AIMM curves use strictly increasing interior knots (≤ 14 segments); at degree 4 with simple knots the density is C2 (smooth) at every knot. Shape comes from nondecreasing control weights, not per-knot offsets. See [Quartic I-Spline](#quartic-i-spline).

## L {#l}

### LCA (Least Common Ancestor) {#lca-least-common-ancestor}
The deepest node of the [anchor tree](#anchor-tree) that is an ancestor of both swap endpoints. It is the turning point of the swap path: the pricer walks up from the input asset to the LCA, then down to the output asset. In a tree that path is unique, so there is no route to search and no decomposition to choose. The LCA is not necessarily the base: `USDT -> DAI` turns at USDC in a BTC-based pool and never touches the BTC mark. When the two endpoints have no common ancestor below the root, the LCA is the base token, which is the shallow case.

### Liabilities {#liabilities}
LP claims against pool reserves. Tracks what the pool owes depositors:
```solidity
struct Asset {
    uint128 reserves;      // What pool holds
    uint128 liabilities;   // What pool owes
}
```

### Debt Swap / Liability Swap {#debt-swap}
An LP re-denominating their claim from one pool leg to another in a single call, without leaving the pool: `Pool.swapLiability` burns shares on the leg in and mints shares on the leg out. **No reserves move** - only the [liabilities](#liabilities) change - so it is not a swap of assets but of what the pool owes, and to whom. It is charged the same coverage toll as an ordinary swap, so re-denominating toward an under-covered leg costs the [κ](#kappa-cov) wall, and a round trip is loss-making by construction rather than free. Both legs must carry the liability-swap risk flag. Subject to the pool's flow cooldown, so it cannot be flipped on every signal. See [Liability Swaps](/docs/4-4-liability-swaps).

### Liquidity Index {#liquidity-index}
Accrued interest multiplier for yield-bearing assets. Updated on interactions.

### Liquidity Provider (LP) {#liquidity-provider-lp}
Agent that supplies executable quotes or inventory to a market, either through limit orders in a [CLOB](#clob-central-limit-order-book) or deposits into an [AMM](#cfmm-constant-function-market-maker) pool. Earns the spread and any fees minus [adverse selection](#adverse-selection) costs and rebalancing costs. **LP risks**: [Impermanent Loss](#impermanent-loss-il), [LVR](#lvr-loss-versus-rebalancing), extraction via [Order Flow Toxicity](#order-flow-toxicity) ([Statistical Arbitrage](#statistical-arbitrage-stat-arb), [JIT](#jit-just-in-time-liquidity), [Informed Order Flow](#informed-order-flow-alpha-toxicity), [Markout Toxicity](#markout-toxicity-winners-curse)). **Related**: [Market Maker](#market-maker) (CLOB equivalent), [Liquidity Taker](#liquidity-taker), [Maker-Taker Fees](#maker-taker-fees), [Price Discovery](#price-discovery). See [Arbitrage](#arbitrage) for extraction taxonomy.

### Liquidity Taker {#liquidity-taker}
Trader who executes immediately against resting liquidity by hitting bids or lifting offers in a CLOB, or by swapping against an AMM pool. Pays the spread and market impact costs.

### Liquidity Profile {#liquidity-profile}
Pool-level spline depth curve setting price impact and capital concentration across price ranges. AIMM holds a shared per-pool table of [quartic I-spline](#quartic-i-spline) preset curves and each asset points in via `presetId`; the table is a quantized density codebook, so re-pointing a drifted asset (`UPDATE_PROFILE`) is the cheap frequent operation and writing a curve (`UPDATE_CURVE`) the rare expensive one. Live quotes scale the curve by `dispersion / dispRefPbps` on every read. No asset can be listed without a curve.

Preset table, control polygons, knot placement and the re-fit policy: [Liquidity Shaping](/docs/1-1-2-liquidity-shaping).

**Related architectures**: [Concentrated Liquidity](#concentrated-liquidity) (LP chooses range), [Liquidity Shaping](#liquidity-shaping) (dynamic adjustments), [Bonding Curve](#bonding-curve) (price discovery). Contrasts with [CLMM](#clmm-concentrated-liquidity-market-maker) (tick-based ranges) and [DLMM](#dlmm-dynamic-liquidity-market-maker) / [Liquidity Book](#liquidity-book) (bin-based segments).

### Liquidity Shaping {#liquidity-shaping}
Dynamic adjustment of the [liquidity profile](#liquidity-profile) (dispersion scaling live; preset refit/repoint under timelock) in response to market conditions, volatility, or trading activity. Enables pool operators or automated systems to concentrate liquidity where trading occurs most, improving capital efficiency and fee capture. Unlike static [bonding curves](#bonding-curve), liquidity shaping allows real-time rebalancing without modifying the [invariant](#invariant). Related to [Liquidity Bootstrapping Pool (LBP)](#liquidity-bootstrapping-pool-lbp) (time-weighted shaping) and [DLMM](#dlmm-dynamic-liquidity-market-maker) (bin-level dynamic fees).

### Bonding Curve {#bonding-curve}
Mathematical function defining the relationship between token supply and price. Traditional AMMs use fixed bonding curves (x·y=k for CPMMs, StableSwap invariant for Curve). AIMM replaces fixed invariant curves with spline-based [liquidity profiles](#liquidity-profile) that have dynamic [dispersion](#dispersion)-the curve shape responds to volatility rather than being static.

**Traditional bonding curves**: [CPMM](#cpmm-constant-product-market-maker) (hyperbolic x·y=k), [CSMM](#csmm-constant-sum-market-maker) (linear), StableSwap (concentrated around peg).

**AIMM approach**: Liquidity profiles + volatility-scaled dispersion replace bonding curves. See [Dispersion](#dispersion) for how curve width responds to market conditions.

### Liquidity Bootstrapping Pool (LBP) {#liquidity-bootstrapping-pool-lbp}
Pool design for fair token price discovery with time-weighted liquidity shaping. Early in launch, pool weights are skewed toward the existing asset (e.g., 95% USDC / 5% new token), making new tokens cheaper. Over time, weights shift (time-decreasing LBP) to equalize (50/50), creating a smooth price discovery process. Prevents whales from accumulating all tokens at launch price. **Mechanism**: [Bonding Curve](#bonding-curve) implicit in weight trajectory. **Related**: [Liquidity Shaping](#liquidity-shaping), [Price Discovery](#price-discovery), [Concentrated Liquidity](#concentrated-liquidity).

### Liquidity Range {#liquidity-range}
Price interval within which an LP allocates concentrated liquidity in [concentrated liquidity](#concentrated-liquidity) pools. **In tick-based pools**: Range = set of ticks; within range, acts as local [CPMM](#cpmm-constant-product-market-maker) between endpoints (continuous). **In bin-based pools**: Range = set of bins; each bin independently acts as [CSMM](#csmm-constant-sum-market-maker) (discrete). **Key trade-offs**: Tighter range = higher capital leverage but more rebalancing required and greater out-of-range risk. Wider range = lower leverage but less rebalancing. See [Concentrated Liquidity](#concentrated-liquidity) for pool type comparison and [Impermanent Loss](#impermanent-loss-il) for risk context. **Implementations**: Uniswap V3 ([CLMM](#clmm-concentrated-liquidity-market-maker)), Trader Joe V2 ([DLMM](#dlmm-dynamic-liquidity-market-maker)).

### Liquidity Book {#liquidity-book}
[DLMM](#dlmm-dynamic-liquidity-market-maker) architecture using discrete price bins rather than continuous ticks. Each bin acts as a local [CSMM](#csmm-constant-sum-market-maker) with near-zero slippage inside the bin. LP positions are **fungible per bin** (users hold position tokens per bin, not per individual tick). [CLMM](#clmm-concentrated-liquidity-market-maker) ranges instead act as a continuous [CPMM](#cpmm-constant-product-market-maker) between endpoints. Dynamic fee adjustments respond to volatility and bin utilization. See [Liquidity Range](#liquidity-range) for CLMM-DLMM comparison and [DLMM](#dlmm-dynamic-liquidity-market-maker) for architecture details. **Implementations**: Trader Joe V2 (Avalanche), Meteora (Solana), Cetus (Sui/Aptos), Saros (Solana).

### LP Token {#lp-token}
Fungible claim on deposited liquidity. AIMM tracks per-user, per-asset LP balances rather than pool-wide shares.

### LVR (Loss Versus Rebalancing) {#lvr-loss-versus-rebalancing}
**The loss an LP takes by holding a position through a price move, versus continuously rebalancing at market.** Unlike [impermanent loss](#impermanent-loss-il) it is **permanent**: the pool quotes away from fair value, arbitrageurs buy cheap on the way up and sell dear on the way down, and the loss stands even if price reverts. Measured on major reserve-priced AMMs at 5-7% of LP capital annually.

$$\mathcal{L} = V_{\text{rebalanced}} - V_{\text{position}}, \qquad \dot{\mathcal{L}} \approx \tfrac{\sigma^2}{8} L_{\text{active}}$$

the rate form holding for a classical CFMM centred on a stale reserve-implied price. Positive means the LP would have been better off rebalancing.

**vs IL**: IL compares the pool position to holding the tokens; LVR compares it to a strategy that never holds the pool position at all.

**AIMM qualification**: quoting off a fresh keeper mark removes **classical curve-staleness LVR** - the mid is not trapped in an invariant until someone trades. It does **not** remove adverse selection. What remains is **push-latency LVR**, extracted while the on-chain mark lags the market between pushes, bounded in intent by the deviation band θ, the heartbeat and the fee floor. Distinct from [OEV](#oev-oracle-extractable-value), which concentrates on the push transaction itself. **Nothing in the protocol rebates LVR**, and no parameter targets it.

See [OEV](#oev-oracle-extractable-value), [Impermanent Loss](#impermanent-loss-il), [Oracles: Known risks](/docs/3-4-oracles#84-known-risks-lvr--oev).

## M {#m}

### Market Making {#market-making}
Providing liquidity by continuously posting firm bid and ask quotes, standing ready to buy and sell. Market makers earn the bid-ask spread plus any venue rebates. Market making can be manual (CLOB) or automated (AMM).

### Market Maker {#market-maker}
Participant that continuously posts firm bid and ask quotes, standing ready to buy and sell, earning the bid-ask spread and any rebates. Bears inventory risk and adverse selection costs.

### Maker-Taker Fees {#maker-taker-fees}
Fee schedule where liquidity providers (makers) receive rebates or pay lower fees, while liquidity takers pay higher fees per executed trade. Incentivizes passive liquidity provision over aggressive trading. Standard model on most CEXes and some DEXes.

### Moving Average {#moving-average}
**Master entry for time-series smoothing techniques.** Methods calculating averages over rolling time windows to reduce noise and identify trends. Different weighting schemes serve different purposes in trend detection and volatility estimation.

**Types**:

| Type | Weighting | Response | AIMM Use |
|------|-----------|----------|----------|
| **[SMA](#sma-simple-moving-average)** | Equal | Slow | TWAP gives SMA mathematically |
| **[EMA](#ema-exponential-moving-average)** | Exponential decay | Fast | Off-chain volatility tracking at the source |
| **[LWMA](#lwma-linear-weighted-moving-average)** | Linear decay | Medium | Alternative to EMA |
| **[TWAP](#twap-time-weighted-average-price)** | Time-weighted | Window-dependent | Off-chain keeper aggregation only |

**AIMM implementation**: the keeper aggregates a time-decaying, volume-weighted mid off-chain and pushes it as the mark; the chain quotes that raw fresh mark. All smoothing lives at the source, so the chain holds no price EMA and no TWAP accumulator.

**See**: [Volatility](#volatility), [Internal Oracle](#internal-oracle).

#### EMA (Exponential Moving Average) {#ema-exponential-moving-average}
Weighted average prioritising recent data by exponential decay: $\text{EMA}_t = \text{EMA}_{t-1} + \alpha(x_t - \text{EMA}_{t-1})$.

**AIMM implementation**: none on-chain. Any smoothing happens at the keeper source; see [Volatility (σ)](#volatility).

#### LWMA (Linear Weighted Moving Average) {#lwma-linear-weighted-moving-average}
Linearly decaying weights, responsiveness between an [SMA](#sma-simple-moving-average) and an [EMA](#ema-exponential-moving-average). **Not used in AIMM.**

#### SMA (Simple Moving Average) {#sma-simple-moving-average}
Arithmetic mean over a fixed window, all points weighted equally: smoothest, slowest to react, no decay bias. **Not used in AIMM** - there is no on-chain accumulator of any kind; see [TWAP](#twap-time-weighted-average-price).

#### TWAP (Time-Weighted Average Price) {#twap-time-weighted-average-price}
The time-integral of price over elapsed time, $\text{TWAP} = \frac{1}{T}\int_0^T P_t\,dt$, mathematically an [SMA](#sma-simple-moving-average). Manipulation-resistant in the usual on-chain construction because an attacker must hold the manipulated price for the whole window.

**AIMM implementation: none on-chain.** There is no cumulative `price × time` state and no per-swap write ([Internal Price Discovery](#internal-oracle)). Off-chain charts rebuild TWAPs from emitted `Swapped` events instead.

### MEV (Maximal/Miner Extractable Value) {#mev-maximal-extractable-value}
The total profit a block producer can capture by strategically controlling transaction ordering, inclusion, or suppression within a block. MEV arises because transaction order confers informational advantage, actors can profit by reordering pending transactions. Extraction types differ in externality: [Frontrunning](#front-running) (harmful), [Sandwich Attacks](#sandwich-attack) (most harmful), [Backrunning](#backrun) (benign), and [MEV Spoofing](#mev-spoofing) (encrypted-mempool specific). Related to [Arbitrage](#arbitrage) taxonomy but focused on block-ordering control rather than market-structure exploitation. Measured as percentage of total block value and a significant source of LP losses in AMMs. See [MEV Searcher](#mev-searcher) for execution agents.

### MEV Strategies {#mev-strategies}

#### Front-running {#front-running}
Placing a transaction ahead of an observed pending one to profit from its price impact, at the victim's expense. Block-ordering analogue of [informed order flow](#informed-order-flow-alpha-toxicity).

#### Back-running {#backrun}
Placing a transaction immediately after another to capture the price move it caused. **Benign**: it harms nobody and is economically [statistical arbitrage](#statistical-arbitrage-stat-arb) at block granularity. Common in liquidations and DEX arbitrage.

#### Sandwich Attack {#sandwich-attack}
A [front-run](#front-running) and a [back-run](#backrun) around one victim trade: move the price against the victim, let them fill worse, then unwind. The **most damaging MEV strategy for DEX users**, and unlike a plain back-run the adverse move is deliberate.

#### JIT (Just-In-Time) Liquidity {#jit-just-in-time-liquidity}
Atomically adding liquidity just before a large swap and removing it just after, collecting fees without carrying price risk. A fee-extraction form of [toxic flow](#order-flow-toxicity); research puts it at ~1% of Uniswap v3/v4 volume, concentrated in 1-20 professional bots. AIMM's [Flow Guard](#flow-guard) blocks it by making the deposit-withdraw round trip non-atomic.

#### MEV Spoofing {#mev-spoofing}
Speculative extraction against an [encrypted mempool](#mempool): the attacker trades on metadata (size, target) rather than contents, and withholds its decryption key share if the resulting position is unfavourable - consuming block space without committing. Mitigated by non-decryption penalties and permutation schemes.

#### Greasing {#greasing}
Submitting transactions that never execute but consume blockspace and fees, extracting value from block construction itself rather than from transaction content. Also called block-stuffing when used defensively.

### Mempool {#mempool}
Buffer of pending transactions waiting to be included in a block. Architecture varies significantly by chain:

**Public Mempool** (Ethereum L1, BNB Chain): Transactions are gossiped across all nodes in the network. Anyone running a node can observe pending transactions, enabling classic [MEV](#mev-maximal-extractable-value) via public observation of orderflow. [Block builders](#block-builder) and [searchers](#mev-searcher) monitor the mempool to identify profitable reordering opportunities.

**Private Mempool / Sequencer Queue** (Arbitrum, Base, Optimism, most OP Stack rollups): Users send transactions directly to a centralized [sequencer](#sequencer), which immediately orders them without public gossip. Reduces third-party MEV but concentrates ordering power in the sequencer. The sequencer still sees all pending transactions and can extract value if malicious.

**Leader-Based Forwarding** (Solana via Gulf Stream): Transactions are forwarded directly to the current and upcoming slot leaders rather than gossiped globally. No traditional queryable mempool, but the leader (and attached infrastructure like Jito) controls ordering and can extract MEV.

**DAG-Based Mempool** (Sui via Narwhal): Transactions are gossiped into a Directed Acyclic Graph structure before consensus, with MEV concentrated around "shared object" contention rather than traditional front-running.

See [Sequencer](#sequencer), [Block Builder](#block-builder), [MEV](#mev-maximal-extractable-value), Encrypted Mempool, [MEV-Protected RPC](#mev-protected-rpc).

### MEV-Protected RPC {#mev-protected-rpc}
[RPC](#rpc-remote-procedure-call) endpoint that hides user transactions from the public [mempool](#mempool) to prevent [front-running](#front-running) and [sandwich attacks](#sandwich-attack). Transactions are sent directly to trusted [block builders](#block-builder) or private relays that commit to fair ordering.

**How it works**: Instead of broadcasting to the public mempool, the RPC sends transactions to a private relay or builder that either: (1) includes transactions without reordering against them, (2) auctions MEV opportunities to searchers but returns extracted value to users, or (3) uses threshold encryption to hide transaction content until ordering is finalized.

**Endpoints**: the current list of free public endpoints (Ethereum L1, BNB Chain, Base) and multi-chain private networks is maintained in [Slippage & Price Impact §4.3](/docs/1-1-5-slippage-price-impact#43-mev-protected-rpcs).

**Research & Further Reading**:
- [Private MEV Protection RPCs (CoW DAO)](https://arxiv.org/pdf/2505.19708v1) - Analysis of private RPC effectiveness
- [MEV on Polygon](https://arxiv.org/pdf/2508.21473v1) - Impact study
- [Cross-chain Sandwich Attacks](https://arxiv.org/pdf/2511.15245v1) - Multi-chain MEV vectors
- [UniswapX Price Improvement](https://blog.uniswap.org/UniswapX_PI.pdf) - Order flow auction design
- [Protected Order Flow Relay](https://arxiv.org/pdf/2408.02303) - Relay architecture

See [Slippage](#slippage), [MEV](#mev-maximal-extractable-value), [Mempool](#mempool), [Sequencer](#sequencer).

### Market Making & DeFi Specific Metrics {#market-making-defi-specific-metrics}
**Master entry for liquidity-provision metrics.**

| Metric | Definition | AIMM application |
|---|---|---|
| **[Bid-Ask Spread](#spread)** | Distance between best bid and best ask | A width set by σ, confidence and staleness - **not** by coverage |
| **[LVR](#lvr-loss-versus-rebalancing)** | LP loss versus a continuously rebalanced book | The cost the external mark is designed to reduce; never rebated |
| **[TVL](#total-value-locked-tvl)** | Dollar value held by the protocol | Sets absolute depth, so execution quality at a given size |
| **[Volume](#volume)** | Traded notional per period | Drives fee accrual into `liquidityIndexWad` |

Fee revenue cannot be modelled from a flat rate: the fee is half the path [spread](#spread) on the post-toll output and moves with σ, confidence, staleness and path length.

### Total Value Locked (TVL) {#total-value-locked-tvl}
**Total dollar value of all assets deposited into a protocol.** Primary metric for measuring protocol size, capital attraction, and liquidity depth.

**Calculation**:

$$\text{TVL} = \sum_i b_i \cdot p_i$$

where $b_i$ = balance of asset $i$, $p_i$ = its mark.

**Interpretation**:
- **Large TVL** ($100M+): Sufficient liquidity for most trades, tight spreads possible
- **Small TVL** ($1M): Limited liquidity, wide spreads, high price impact for medium trades
- **Growing TVL**: Indicates user confidence and capital inflow
- **Declining TVL**: Risk signal (users withdrawing due to low returns, governance issues, or security concerns)

**AIMM context**: Larger TVL means deeper liquidity and lower [price impact](#price-impact). Pool operators use TVL forecasts to plan capital requirements and spread competitiveness.

**Related**: Utilization Ratio, [Volume](#volume), Liquidity Depth.

### Volume {#volume}
**Total notional value of assets traded in a period (day, week, month).** Primary revenue driver for LP fees.

**Calculation**:

$$\text{DailyVolume} = \sum_i \text{amountIn}_i \cdot \text{priceAtSwap}_i$$

**Relationship to fees**:

There is no flat fee rate to multiply by: the fee is **half the path spread**, charged on the post-toll output, and the spread moves with $\sigma$, confidence, staleness and path length ([Spread & Fees](/docs/1-1-4-spread-fees)). Fee revenue has to be summed per swap, not modelled from a rate.

Example: 10M volume at a 0.05% fee yields 5k daily revenue.

**High-volume assets**: Generate substantial LP fee revenue, compensating for [IL](#impermanent-loss-il).

**Low-volume assets**: LPs earn minimal fees, making IL drag more significant.

**AIMM context**: Forecast expected LP yields based on historical volume patterns. Volume seasonality (weekday vs weekend, US vs Asian hours) affects spread strategy and coverage ratio targets.

**Related**: [Spread](#spread), Utilization Ratio, [Total Value Locked](#total-value-locked-tvl).

### Monotone Cubic Hermite Interpolation {#monotone-cubic-hermite-interpolation}
See [Spline (Cubic Interpolation)](#spline-cubic-interpolation).

---

## N {#n}

### Net Premium {#net-premium}
The app's label for the inventory [skew](#inventory-skew) offset plus the [coverage toll](#coverage-toll) measured against the mark - no fee, no [price impact](#price-impact). It is a row **beside** [Total Cost](#total-cost), not inside it, because it can be negative: coverage-improving flow is paid to rebalance the pool. Note the docs' terminology rule: "premium" is a UI label here, never a quantity or a parameter - the mid displacement is the **skew offset** (a level) and the spread's parts are **bands** and **surcharges** (widths). Deep dive: [Slippage & Price Impact](/docs/1-1-5-slippage-price-impact).

### Native Token {#native-token}
Chain's native currency (ETH on Ethereum). Represented by sentinel address `0xEeee...EEeE` (EIP-7528). Automatically wrapped/unwrapped by pool.

### Nonce {#nonce}
Number used once, in blockchain context, a transaction counter incremented with each transaction from an account to prevent replay attacks and ensure ordering. Also used in smart contracts (e.g., randomness) and as a proof-of-work parameter in mining.

### Order Flow Toxicity {#order-flow-toxicity}
Measure of how informative or adverse trade flow is to liquidity providers. **Umbrella term covering all types of extraction** ([Statistical Arbitrage](#statistical-arbitrage-stat-arb), [Latency Arbitrage](#latency-arbitrage), [Informed Order Flow](#informed-order-flow-alpha-toxicity), [Markout Toxicity](#markout-toxicity-winners-curse), [Flow Internalization](#flow-internalization-pfof---payment-for-order-flow)). Toxic flow indicates informed trading, speed advantages, or flow composition biases that extract value from market makers. Often proxied by metrics like VPIN or short-term price reversion patterns. See [Arbitrage](#arbitrage) for the toxicity hierarchy. Low toxicity favors passive liquidity provision.

---

## O {#o}

### On-Chain Mark {#on-chain-mark}
An `EXTERNAL` [mark](#mark-price) read directly from another on-chain contract at quote time - a Uniswap quoter or pool, a PropAMM's on-chain quote, a Chainlink feed - rather than received through an off-chain push. Because the source is itself a chain contract, a pool configured this way has zero off-chain dependency: no keeper, no signer quorum, no push infrastructure to trust or monitor. The trade-off is the source's own latency and manipulability: an AMM-pool mark moves only when someone trades against that pool, so it inherits that pool's staleness instead of eliminating it.

**See**: [Mark Price](#mark-price), [Feed (Oracle)](#feed-oracle), [Oracle](#oracle), [Oracles §7](/docs/3-4-oracles).

### Oracle {#oracle}
**Master entry for marks.** A pool reads each asset's mark from an `IOracle` contract: an on-chain discovery adapter or an NX Rates push. Cash collateral instead uses the internal par helper fixed at 1.0. The two can mix within one pool. [Inventory skew](#inventory-skew) sits around the mark.

| Type | Source | Use |
|------|--------|-----|
| **[EXTERNAL `IOracle`](#on-chain-mark)** | NX Rates, Chainlink adapter, Uniswap/vault reader, custom | **Default** |
| **[INTERNAL peg](#internal-oracle)** | `FeedMathLib.getPegFeed` | Cash-collateral 1:1 only |
| Reserve TWAP in-pool | Pool swaps | **Not** INTERNAL; ship EXTERNAL adapter if needed |

**NX Rates push path** (one EXTERNAL option): venues → signed mid → k-of-n `batchPushSigned` → θ / heartbeat.

`createPool` permissionless; listing / oracle config via Admin. EXTERNAL on-chain adapters: zero off-chain push.

**AIMM's Feed Model**:
- **Fresh mark** (`mark1e18`): the sole quote source - drives mid, spread, and depeg bands
- **Pushed σ + confidence**: carried with the mark; σ is stored directly (floored at `|Δmark|/mark`), driving the vol band and confidence surcharge
- **No on-chain EMA**: smoothing lives at the source; the chain quotes the raw fresh mark only

**Related Concepts**:
- [Deviation](#deviation-oracle) - Push trigger θ and the per-feed push clamp
- [Feed](#feed-oracle) - Oracle data structure + metadata
- Threshold Encryption - MEV-resistant oracle delivery
- [Fair Value](#fair-value) - Oracle-derived "true" price
- [Price Discovery](#price-discovery) - How markets discover fair value

See [Arbitrage](#arbitrage), [Liquidity Shaping](#liquidity-shaping), [Spread](#spread), [LVR](#lvr-loss-versus-rebalancing), [OEV](#oev-oracle-extractable-value) for AIMM applications.

### OEV (Oracle Extractable Value) {#oev-oracle-extractable-value}
**Not** "observed extractable value". [MEV](#mev-maximal-extractable-value) concentrated on the **discrete oracle update** - the k-of-n signed `batchPushSigned` transaction - as opposed to diffuse [LVR](#lvr-loss-versus-rebalancing) between updates.

On a public-mempool chain a searcher can see the pending mark move before confirmation and order swaps around it: **front-run** to pick off the still-stale mark with certain timing, **back-run** for first access to the corrected mark, or time the **heartbeat** to pre-position with zero price deviation.

**Relation to LVR**: overlap, not subset. Front-running a known push resembles push-latency LVR without the usual timing uncertainty; back-running a *correct* push can still extract from residual skew or cross-feed incoherence. Note that `STALE_Z` is zero inside the grace and does not help immediately post-push, and [inventory skew](#inventory-skew) is an ambiguous defense here - neither is a primary mitigation.

Full treatment: [Oracles: Known risks](/docs/3-4-oracles#84-known-risks-lvr--oev).

### Overcollateralized {#overcollateralized}
Coverage > 100%. Pool has more reserves than liabilities. Maximum negative skew (-100) incentivizes selling.

---

## P {#p}

### Prices {#prices}
**Master entry for price types.**

**Categories**: Quote prices (what traders see), Execution prices (what actually happens), Valuation/Risk prices (for risk management), AIMM-specific prices (protocol internals).

**AIMM cost vocabulary** - one object per word; canonical definitions live in [Slippage & Price Impact §1.1](/docs/1-1-5-slippage-price-impact#11-what-each-term-is-and-what-it-is-not):

- **mark** - the oracle price as attested by the keeper, in the child's anchor unit.
- **mid** - the mark after the inventory shift, quoted at zero volume.
- **skew** - the signed dimensionless inventory index (`int8` in [-100, +100]), a function of coverage alone; an input, never a price.
- **skew offset** - the displacement `(mid − mark)/mark` in bps that the index produces; a level that cancels on a round trip.
- **price impact** - the cost of traversing the liquidity shape from the skew anchor; one-directional.
- **spread** - the round-trip fee **width**, symmetric about the mid.
- **fee** - half the spread, charged once on the output.
- **coverage toll** - the convex charge on a drained output leg; one-directional, charge-only.
- **slippage** - the stochastic gap between quote and fill; a risk, not a pool term.

Avellaneda-Stoikov's **reservation price** is what this codebase calls the **mid**, anchored by the [skew](#inventory-skew); AIMM's depeg bounds are the feed-relative `refFeedId` / `refBandBps` pair, a separate mechanism. **Do not say "premium"**: it collapses a level and a width into one word - say *skew offset* for the mid displacement, *band* / *surcharge* for the spread's parts. Total cost is direction-asymmetric; the width and the level are not ([§1.2](/docs/1-1-5-slippage-price-impact#12-total-cost-is-direction-asymmetric-the-width-and-the-level-are-not)).

See [Price Impact](#price-impact), [Slippage](#slippage), [Volatility](#volatility), [Deviation](#deviation-oracle).

#### Bid Price {#bid-price}
Highest price that a buyer (individual, market maker, bot, or AMM) is willing to pay for an asset. Buyers offer bids at the bid price; the best (highest) bid constitutes the bid side of the market.

See [Ask Price](#ask-price), [Spread](#spread).

#### Ask Price {#ask-price}
Lowest price that a seller (individual, market maker, bot, or AMM) is willing to accept for an asset. Sellers offer asks at the ask price; the best (lowest) ask constitutes the ask side of the market.

See [Bid Price](#bid-price), [Spread](#spread).

#### Mid-Price {#mid-price}
Fair value **after inventory adjustment**, before the bid-ask spread: the on-chain mark displaced by inventory skew, quoted at zero size. In BTR pools:

$$\mathrm{mid} = \mathrm{mark} \times \bigl(1 + \mathrm{skewOffset}\bigr)$$

where $\mathrm{skewOffset}$ comes from coverage-driven [inventory skew](#inventory-skew) (and the depth spline at that skew). Traders do **not** fill at the raw mark; the mid is the reservation price that encodes pool inventory discovery.

See [Mark Price](#mark-price), [Spread](#spread), [Inventory Skew](#inventory-skew).

#### Execution Price {#execution-price}
VWAP along the liquidity spline from the skewed mid, then the output-side fee (= half the path spread). Components of the symmetric spread around mid: $S_{\mathrm{vol}} + U_{\mathrm{stale}} + U_{\mathrm{conf}}$.

See [Price Impact](#price-impact), [Slippage](#slippage), [Spread](#spread).

#### Fair Value {#fair-value}
External reference for the asset. In BTR pools this is the keeper [mark](#mark-price) (pushed), not a pool-derived TWAP.

See [Oracle](#oracle), [Mark Price](#mark-price).

#### Mark Price {#mark-price}
The level quotes anchor to (not the fill). Sources:
- **External** - any `IOracle`: NX Rates push, Chainlink adapter, Uniswap or vault reader, custom on-chain discovery.
- **Internal** - cash-collateral peg at 1.0 (`getPegFeed`) plus a depeg gate on the reference feed. Not for general assets.

**See**: [Oracles](/docs/3-4-oracles), [Internal Oracle](/docs/1-2-2-internal-oracle), [On-Chain Mark](#on-chain-mark), [Feed (Oracle)](#feed-oracle).

See [On-Chain Mark](#on-chain-mark), [Oracle](#oracle), [Feed Oracle](#feed-oracle).

#### Index Price {#index-price}
For derivatives, the median or volume-weighted average price of an asset across multiple spot markets or CEXes. Used to prevent index manipulation and to determine a mark. Independent of any single exchange.

See [Mark Price](#mark-price), [Oracle](#oracle).

### Price Impact {#price-impact}
The cost of trade **size**: how far the average fill drifts from the mid as the trade sweeps the curve, distinct from the [spread](#spread) (a width present at zero size) and from [slippage](#slippage) (an unexpected deviation between quote and execution).

In AIMM it is the curve traversal $\Gamma(q)$ from the skew-anchored mid, together with the [coverage toll](#coverage-toll) $t(q)$ when the output leg is under-covered. It is direction-asymmetric off par and exactly symmetric at $c = 1$. The buy-side traverse **saturates**: past the domain clip marginal impact is zero, so depth alone cannot stop a drain - the coverage toll is what can.

Quoted in advance in `SwapQuote`. Full derivation, the saturation argument and worked numbers: [Slippage & Price Impact](/docs/1-1-5-slippage-price-impact).

### Protocol Fee {#protocol-fee}
Portion of spread retained by protocol:

$$\begin{aligned}
\text{protocolFee} &= \frac{\text{totalFee} \cdot \text{protoSharePct}}{100} \\
\text{lpFee} &= \text{totalFee} - \text{protocolFee}
\end{aligned}$$

**See**: [LP Fee](#lp-fee), [Paid Spread](#paid-spread). Deep dive: [Spread & Fees §5](/docs/1-1-4-spread-fees).

### LP Fee {#lp-fee}
Portion of the [spread](#spread) retained by liquidity providers: the [total fee](#spread) minus the [protocol fee](#protocol-fee). In the swap recap it is one of the two rows under [Paid Spread](#paid-spread).

**See**: [Protocol Fee](#protocol-fee), [Paid Spread](#paid-spread), [Maker-Taker Fees](#maker-taker-fees), [Liquidity Provider (LP)](#liquidity-provider-lp). Deep dive: [Spread & Fees §5](/docs/1-1-4-spread-fees).

### Paid Spread {#paid-spread}
The [half-spread](#half-spread) on the side the taker pays: from mid to the best ask on a buy, to the best bid on a sell - never the full bid-ask width. In AIMM it is the output-side haircut of the path spread, booked as LP/protocol fee, and it is disclosed beside [price impact](#price-impact) rather than drawn as book depth.

**See**: [Spread](#spread), [Total Cost](#total-cost). Deep dive: [Spread & Fees §1-2](/docs/1-1-4-spread-fees).

### Partial Fills {#partial-fills}
Standard execution policy where any executable portion of an order is filled immediately, with the remainder staying open until fully executed or canceled.

### Price-Time Priority {#price-time-priority}
Matching rule in CLOBs where orders at better prices execute first, and among equal prices, earlier timestamps (earlier queue position) execute first. Determines execution priority and incentivizes liquidity provision early in price levels.

### Price Discovery {#price-discovery}
Process by which trading activity and order flow incorporate information into prices, through competition among participants.

## Q {#q}

### Quorum (k-of-n Signer Set) {#quorum}
The signer set behind the external mark. Every pushed batch needs k independent signatures from n attester keys, floored at 2-of-3 on-chain, and a peer countersigns only after re-validating the quote against its own market view, so a batch reaching the chain means k independent processes agreed on the price. That independence is a deployment property, not a contract guarantee: minimal deployments and testnets may share one signer set - **Arc currently does** - and the cumulative bound does not hold there ([Oracle Price-Push Security](/docs/3-6-oracle-price-push-security)). A single compromised key cannot move the mark; a compromised quorum is bounded by the per-push deviation clamp, the confidence halt and the depeg bands. Any signer can be revoked immediately; revoking below threshold halts pushing rather than loosening it.

**See**: [Feed (Oracle)](#feed-oracle), [Deviation (Oracle)](#deviation-oracle), and [Oracle Price-Push Security](/docs/3-6-oracle-price-push-security).

## R {#r}

### Reentrancy Guard {#reentrancy-guard}
Transaction-level [Flow Guard](#flow-guard) preventing recursive calls exploiting mid-execution state. Blocks functions from calling themselves or other protected functions during execution, preventing reentrancy attacks where malicious contracts recursively call back into the protocol before state updates complete.

**AIMM implementation**: Uses transient storage ([EIP-1153](#eip-1153-transient-storage)) for gas-efficient guards (~2,100 gas savings vs persistent storage).

See [Flow Guard](#flow-guard), [EIP-1153](#eip-1153-transient-storage).

### Rehypothecation (idle farming) {#rehypothecation}
Physical deployment of idle pool liquidity into a curated strategy (example: Venus Core via `CompoundV2YieldHook`) while the pool still prices on full $R$. Deploy on the `postInflow` callback or via the hook's own keeper/owner `rebalance()` entrypoint, not on every swap; recall only on $R_{\mathrm{liq}}$ shortfall via `preOutflow`. See [dual ledger](#dual-ledger), [Pool Hooks](/docs/5-1-3-hooks).

### Relayer {#relayer}
Service that observes events or messages on one blockchain and relays them to another, particularly for cross-chain bridges. Relayers are economically incentivized via fees to faithfully transmit information. Bridge security typically depends on relayer honesty and the protocol's ability to penalize misbehavior.

### Reserves {#reserves}
Economic token book of a pool asset (`Asset.reserves`). With hooks invested: $R = R_{\mathrm{liq}} + R_{\mathrm{inv}}$ ([dual ledger](#dual-ledger)); pricing / coverage use full $R$, executable cash is $R_{\mathrm{liq}}$. Updated on deposits, withdrawals, swaps, and hook yield / write-down. Backs LP claims via [Coverage Ratio](#coverage-ratio).

See [Collateral](#collateral), [Coverage Ratio](#coverage-ratio), [Liabilities](#liabilities), [Pool Hooks](/docs/5-1-3-hooks).

### Residual Lag Risk {#residual-lag-risk}
Term used by oracle-anchored venue docs (Metric / OMM-style active pools) for the risk that an on-chain oracle **trails the true market by more than one round-trip fee**, letting informed flow trade against a stale reference. In BTR's AIMM this family decomposes into two named parts - see [LVR](#lvr-loss-versus-rebalancing) and [OEV](#oev-oracle-extractable-value):

- **Push-latency LVR** (continuous): informed flow against a frozen `mark1e18` between keeper updates; bounded in intent by deviation threshold `θ`, heartbeat, and the `minFeePbps` floor, taxed further by σ/confidence/staleness surcharges.
- **[OEV](#oev-oracle-extractable-value)** (discrete): MEV concentrated on the oracle-push transaction itself (frontrun/backrun of a pending signed batch).

**See**: [Push-Latency LVR](#lvr-loss-versus-rebalancing), [OEV](#oev-oracle-extractable-value), [Feed Oracle](#feed-oracle), [Deviation (Oracle)](#deviation-oracle), [Oracles §8.4](/docs/3-4-oracles#84-known-risks-lvr--oev).

### Risk Config {#risk-config}
Per-asset safety state: a `flags` word (feature + halt bits) and `kappaCovBps` (the convex coverage-wall strength). Bit layout: [Pool §8](/docs/1-2-1-pool).

`RiskConfig` carries safety state only. Everything that shapes a price lives on `Asset`: `minFeePbps`, `vegaBps`, `haircutSuppressorBps`, `minLiquidity`, `presetId` and the dispersion band. [Inventory skew](#inventory-skew) is a fixed protocol law with no per-asset dial, and the [price-impact](#price-impact) denominator is the leg's own raw reserves, so neither struct carries a knob for either.

κ coupling: a listed asset carrying `kappaCovBps > 0` is forced to `haircutSuppressorBps == 0`; κ is **output-only**, so hub κ prices taking the hub *out* (cross-pool hops), and κ cannot be stripped from an asset holding a `FLAG_REQUIRES_WALL` preset. See [Invariants §I-9](/docs/1-1-8-invariants#i-9-coverage-toll-is-charge-only-and-terminal-only).

### RPC (Remote Procedure Call) {#rpc-remote-procedure-call}
Client-server protocol: clients (wallets, dApps, services) request data or submit transactions to blockchain nodes. The primary interface between applications and the chain, covering transaction submission, account balance queries, block retrieval, and contract execution calls.

## S {#s}

### MEV Searcher {#mev-searcher}
Independent network participants who identify and execute [MEV](#mev-maximal-extractable-value) opportunities using sophisticated algorithms and infrastructure. Searchers continuously monitor the mempool for profitable trades, construct transaction bundles, and submit them to block builders or MEV relays. They participate across the full spectrum of [extraction strategies](#arbitrage): from harmful ([Sandwich Attacks](#sandwich-attack), [Frontrunning](#front-running)) to benign ([Backrunning](#backrun), [JIT](#jit-just-in-time-liquidity), liquidations, [Statistical Arbitrage](#statistical-arbitrage-stat-arb)). See [Arbitrage](#arbitrage) and [MEV Strategies](#mev-strategies) for the taxonomy of extraction types.

### Sequencer {#sequencer}
Entity controlling transaction ordering and block production in rollups (Arbitrum, Optimism, Base, etc.). Acts as the leader in the rollup's consensus, submitting ordered transactions and state commitments to the base layer (Ethereum L1).

**Responsibilities**:
1. **Transaction ordering**: Receives user transactions from [mempool](#mempool), decides ordering
2. **Block production**: Groups ordered transactions into blocks, executes them
3. **State commitment**: Submits block headers/state roots to L1 smart contract
4. **Soft finality**: Provides sequencer-guaranteed block ordering (~instant)
5. **Hard finality**: Waits for L1 batch confirmation (~10-30 min)

**Finality hierarchy**:
- **Sequencer finality** (soft): Sequencer promises to include transaction (not reversible without sequencer being malicious)
- **Batch finality** (hard): State root committed to L1 smart contract (reversible only via L1 reorg)
- **L1 finality** (final): L1 batch lands in finalized Ethereum block (~12.8 min for Casper FFG)

**MEV on rollups**:
- **Arbitrum**: Originally FCFS ordering, now [Timeboost](#timeboost) auctions for priority
- **Optimism/Base**: FCFS + priority fee model (sequencer profitable to include high-fee txs)
- **Sequencer profit**: Transaction fees + MEV from reordering (if allowed)

**Centralization concerns**:
- **Single sequencer**: Centralized ordering = single point of MEV extraction
- **Censorship risk**: Sequencer could block transactions
- **Decentralization roadmap**: Most rollups planning decentralized sequencer sets

**Comparison**:
- **L1 Validator**: Proposes blocks in consensus, earns base reward + MEV
- **L2 Sequencer**: Receives transactions, orders them, earns transaction fees + MEV, submits to L1

See Consensus, [Mempool](#mempool), [MEV](#mev-maximal-extractable-value), [Block Builder](#block-builder), [Timeboost](#timeboost).

### Skew {#skew}
See [Inventory Skew](#inventory-skew).

### Slippage {#slippage}
The difference between a quoted/expected price and the actual execution price of a trade. Slippage occurs due to:
1. **Market movement**: Price changes between quote time and execution (general volatility)
2. **Price impact**: Large trades moving the market against the trader (liquidity depth)
3. **Third-party activity**: [Front-running](#front-running), [sandwich attacks](#sandwich-attack), or other [MEV](#mev-maximal-extractable-value) extraction between quote and execution

**Key distinction from [Price Impact](#price-impact)**: Price impact is the deterministic cost of trade size against available liquidity (predictable from the order book/AMM curve). Slippage is the *unexpected* deviation from quoted price due to external factors. In BTR documentation "slippage" never names the curve-traversal cost: that is price impact, and it is quoted in advance in `SwapQuote`.

**Slippage can be positive or negative**: If the market moves favorably between quote and execution, the trader receives *positive slippage* (better price than expected). This is rare on public [mempools](#mempool) due to MEV extraction.

**Where the state changes come from in this pool**: a quote is a snapshot. Between signing and
inclusion the pool can move under you - an intervening swap shifts the curve, a keeper pushes a new
oracle [mark](#mark-price) (or an old one goes stale and the pool pauses), or the coverage wall
reprices. Any of these moves the execution price away from the quoted one.

**Enforcement - revert on exceed**: the taker declares the worst acceptable outcome as
`minAmountOut` on `swap()`. If execution would deliver less, the transaction reverts:
```solidity
if (finalAmountOut < minAmountOut) revert ThresholdViolation(finalAmountOut, minAmountOut);
```
Nothing partial fills and nothing is kept: a reverted swap costs only gas.

**Choosing the allowance (swap UI)**: two modes, `fixed` is the default.
- **`fixed`** (default) - an absolute percentage, default 0.5%, snapped to a 1-2-5 ladder.
- **`auto`**, labelled "Spread based" - a percentage of the live **round-trip** [spread](#spread),
  default 50% (exactly the half-spread, which is what one swap is charged), clamped to [10, 300].

See [Price Impact](#price-impact), [Spread](#spread), [Paid Spread](#paid-spread), [MEV](#mev-maximal-extractable-value), [Mark Price](#mark-price), and [MEV-Protected RPC](#mev-protected-rpc) for related concepts. UI details: [Swapping §4](/docs/4-1-swapping#4-slippage-becomes-minout).

### Spoke {#spoke}
A non-base listed asset in a BTR core. Each spoke anchors to a parent within the [Anchor Tree](#anchor-tree) - the base or another listed asset, at most `MAX_DEPTH = 4` edges from the root - and a same-pool swap between two spokes is priced along their anchor path, settling against reserves with any interior legs priced at mid. Each spoke keeps its own inventory, [coverage ratio](#coverage-ratio), feed and risk preset; only its base-relative mark and per-leg premiums are shared across the pool.

### Monotonicity {#monotonicity}
Mathematical property where a function is always non-decreasing or non-increasing over its domain. In trading, **monotonic depth** means liquidity gets consistently deeper (or shallower) as you move away from market price, never reverses. Critical for spline-based profiles to prevent "dips" where a shallower price zone lies between deeper ones (which would create arbitrage opportunities).

**AIMM context**: Spline weights must be arranged so that depth increases monotonically from center outward. Violation causes pricing inconsistency.

See Statistical Concepts, [Spline (Cubic Interpolation)](#spline-cubic-interpolation).

### Linearity {#linearity}
In statistics: proportional relationship where doubling input doubles output (f(2x) = 2f(x)). In blockchain/trading: the **assumption is false**, price depth relationship is non-linear due to [price impact](#price-impact) and curve characteristics.

**Statistical definition**: f(ax + by) = af(x) + bf(y) (superposition property)

**AIMM context**: Price function is non-linear because depth changes curve shape. Small trades use tight spread, large trades face wider impact.

See Statistical Concepts, [Price Impact](#price-impact).

### Normalization {#normalization}
Process of scaling data to a fixed range, typically [0, 1] or [-1, 1]. Preserves the shape of distribution while fitting within bounds. Useful for comparing variables with different units.

**Formula**:

$$x_{\text{norm}} = \frac{x - \min(x)}{\max(x) - \min(x)} \in [0, 1]$$

**AIMM context**: Order size normalized relative to pool liquidity depth for consistent pricing across different assets.

**Difference from [Standardization](#standardization)**: Normalization bounds to range; standardization centers with zero mean.

See Statistical Concepts, [Standardization](#standardization).

### Standardization {#standardization}
Process of transforming data to have mean = 0 and standard deviation = 1, producing **Z-scores**. Enables comparison of variables with different scales.

**Formula**:

$$Z = \frac{X - \mu}{\sigma}$$

where $\mu$ = mean, $\sigma$ = standard deviation.

See Statistical Concepts, [Normalization](#normalization), [Volatility](#volatility).

### Density Analysis {#density-analysis}
Statistical technique measuring the concentration of observations (data points) around a central location or specific regions. In finance, analyzes where volume/liquidity clusters on price axis.

**AIMM context**: Depth placement is **volatility-driven, not volume-TWAP-driven**: each asset ships a fixed preset spline (five shapes, `wQ` in `PoolConfig`) whose band width adapts through dispersion $\kappa = \texttt{minDispersionPbps} + \sigma\cdot\nu/\texttt{BPS}$ ([Dispersion](#dispersion)). Wider measured volatility widens the band; no on-chain volume accumulator feeds knot placement - see [TWAP](#twap-time-weighted-average-price) for why AIMM keeps none.

**Application**:
1. Curator picks the preset whose depth shape matches the asset's expected trade clustering
2. Pushed $\sigma$ (and vega) scale the band around that shape per update
3. Result: tighter quoting in quiet regimes, wider bands as realized volatility rises

**Related**: [Liquidity Shaping](#liquidity-shaping), [Time-Weighted Average Price](#twap-time-weighted-average-price), [Spline (Cubic Interpolation)](#spline-cubic-interpolation).

### Spread {#spread}
The difference between the highest bid and the lowest ask: the round-trip transaction cost, and a measure of market liquidity. Narrow means liquid and cheap, wide means illiquid and expensive. Closely related to [Slippage](#slippage), [Price Impact](#price-impact), and [Volatility](#volatility). See [Bid](#bid-price) and [Ask](#ask-price) for component definitions.

**AIMM Implementation**: the spread is a **width**, not a cost total and not a fee. `SwapQuote.spreadPbps` is the round-trip width about the mid; a single swap pays **half** of it, once, on the output, on the **post-toll** amount (`Pricing._settleQuote`), so `minFeePbps` floors the spread, not the fee.

$$S = S_{\text{vol}} + U_{\text{stale}} + U_{\text{conf}}$$

Three rules the rest of the docs rely on:
- **It is symmetric** and carries no coverage or deviation term: [coverage ratio](#coverage-ratio) drives the mid through [Inventory Skew](#inventory-skew), never the spread.
- **It has no upper bound, deliberately.** A spread widened by σ, confidence or staleness is the price of that risk, and a cap would break path additivity. Trader protection is `minAmountOut`. The `uint16` saturation of `SwapQuote.spreadPbps` is a field width, not a policy.
- **"Spread" is not total cost.** See [Total Cost](#total-cost).

Derivation, aggregation over legs and the full parameter list: [Spread & Fees](/docs/1-1-4-spread-fees).

### Spline {#spline-cubic-interpolation}
**Master entry for piecewise polynomial methods.** Splines build a smooth curve through control points ([knots](#knot-spline)) without the global oscillation a single high-degree polynomial suffers. AIMM uses one to define a [liquidity profile](#liquidity-profile), giving arbitrary depth shaping instead of a fixed invariant.

The shipped curve is the [quartic I-spline](#quartic-i-spline); alternatives that were considered and rejected are recorded below. Curve mathematics, packing and gas: [Liquidity Shaping](/docs/1-1-2-liquidity-shaping).

#### Quartic I-Spline (Clamped) {#quartic-i-spline}
**Canonical AIMM curve** (`NUQuartic.sol`). The depth curve is written as a clamped quartic B-spline whose control weights are nondecreasing (Δw ≥ 0), making it the monotone integral of a nonnegative density (an I-spline). Monotonicity is a linear coefficient constraint, checked exactly on-chain; simple interior knots at degree 4 make the density **C2, smooth at every knot by construction**.

**Why monotonicity matters**: Liquidity depth must be monotone in price offset. A non-monotone segment would imply negative marginal liquidity → broken pricing and internal arbitrage.

**AIMM implementation**: packed hot-path layout (1 header slot with the interior segment directory, the density median, `dispRefPbps` and flags, + 2 slots per segment, ≤ 14 segments; the last boundary is the constant `BPS` and is not stored, which is what pays for the median); eval = 3 cold SLOADs (5.4k gas), exact O(1) range integral via stored prefix integrals = 5 cold SLOADs (11.2k gas), used for VWAP. Live quotes scale the curve linearly by dispersion/dispRefPbps, preserving monotonicity and C2 density.

See [Liquidity Profile](#liquidity-profile), [Liquidity Shaping](#liquidity-shaping), [Knot](#knot-spline).

#### Fritsch-Carlson Monotone Cubic Hermite Interpolation {#fritsch-carlson-monotone-cubic-hermite-interpolation}
Considered and rejected for AIMM. Cubic Hermite interpolation with monotonicity enforced via Fritsch & Carlson's 1980 algorithm (*SIAM J. Numer. Anal.* 17(2)): sign-preserving averaged-secant tangents + the `α² + β² ≤ 9` magnitude clamp. C1 only, and the asymmetric clamp carries a value-discontinuity risk in the density at knots. The shipped method is the [clamped quartic I-spline](#quartic-i-spline).

See [Catmull-Rom Spline](#catmull-rom-spline), [Quartic I-Spline](#quartic-i-spline).

#### Makima Spline {#makima-spline}
Cubic spline interpolation designed to minimize oscillation while preserving monotonicity. Uses modified Akima-style weighted averages of neighboring slopes and naturally handles monotone data.

**Not used in AIMM**: C1 only, monotonicity not guaranteed exactly. The shipped [quartic I-spline](#quartic-i-spline) gives exact monotonicity (linear coefficient check) plus C2 density.

See [Quartic I-Spline](#quartic-i-spline).

## T {#t}

### Theta (θ) {#theta}
The per-asset deviation band that triggers a fresh keeper mark push: when the market moves away from the last pushed mark by more than θ, the keeper pushes before the [Heartbeat](#heartbeat) elapses. Distinct from `maxDeviation`, the clamp bounding how far any single push may move the mark ([Deviation (Oracle)](#deviation-oracle)). Tighter θ cuts push-latency [LVR](#lvr-loss-versus-rebalancing) at higher push cost.

### Tick {#tick}
Discrete price point in concentrated liquidity AMMs (Uniswap v3/v4). AIMM doesn't use ticks, prices are continuous via splines.

### Timeboost {#timeboost}
Arbitrum's MEV auction system that allows users to bid for priority transaction ordering within blocks. Launched in late 2024 as an alternative to pure [FCFS/FIFO](#fcfs-fifo-first-come-first-served-first-in-first-out) ordering.

**How it works**:
1. **Express Lane**: A special ordering lane where winning bidders get their transactions included first
2. **Auction**: Users (typically [MEV searchers](#mev-searcher)) bid for express lane access in recurring auctions
3. **Revenue Distribution**: Auction proceeds go to the Arbitrum DAO treasury (potentially to ARB stakers)
4. **Non-Express Transactions**: Still processed via FCFS but after express lane transactions

**Contrast with**:
- [FCFS/FIFO](#fcfs-fifo-first-come-first-served-first-in-first-out): Pure arrival-time ordering (original Arbitrum)
- [Gas Auction](#gas-auction) (Ethereum L1): Priority via gas price, chaotic bidding wars
- Jito (Solana): Bundle auctions at validator level

**Rationale**: Rather than letting MEV leak to latency games (fast connections to sequencer) or external parties, Timeboost captures MEV value explicitly and directs it to the protocol. This makes MEV extraction transparent and economically efficient while still providing FCFS ordering for users who don't need priority.

See [Sequencer](#sequencer), [MEV](#mev-maximal-extractable-value), [FCFS/FIFO](#fcfs-fifo-first-come-first-served-first-in-first-out).

### Timelock {#timelock}
Delay before a sensitive operation may execute. Seven tiers, production
delays (`Constants.sol`):

| Tier | Delay | Covers |
|---|---|---|
| `CRITICAL` | 7 days | base-token migration, re-anchor |
| `HIGH` | 3 days | custody pointers - treasury, hook |
| `BASE` | 2 days | oracle config, signer roster |
| `LOW` | 1 hour | add asset, fees, curves, profiles |
| `UPGRADE` | 7 days | UUPS implementation + beacon fleet swap |
| `ROTATION` | 7 days | AccessControl role rotation |
| `FACTORY` | 14 days | AccessControl factory-pointer rotation (re-points pool deployment) |

Testnet runs a compressed schedule (6h/3h/2h/1h/6h/6h/12h). See
[Access Control](/docs/3-1-access-control-roles-emergency-powers).

### Toxic Flow {#toxic-flow}
Trades exploiting information asymmetry, the counterparty knows something the pool doesn't. Toxic flow is unidirectional, driven by CEX price leads, and extracts value even if prices revert (the pool loses on both the up-move and the down-move). Contrast with **rebalancing arbitrage**, which brings pool prices back to market and is net-positive for liquidity. AIMM's defense against it is the **spread** - the $\sigma$ band, the confidence surcharge and the staleness surcharge - plus a fresh mark. The coverage-driven [inventory skew](#inventory-skew) is **not** an adverse-selection defense: at $c \approx 1$ it is zero, so the first pick-off is untaxed, and it gives coverage-improving flow a better price even when that flow is informed. It manages inventory, not toxicity.

### Transient Storage {#transient-storage}
See [EIP-1153](#eip-1153-transient-storage).

### Total Cost {#total-cost}
What a taker pays on top of the mid: [Paid Spread](#paid-spread) + [Price Impact](#price-impact). The swap recap prints it as one expandable row with exactly those two detail rows; [Net Premium](#net-premium) sits outside it. Formally the fill is a product, not a sum - $\text{exec}/\text{mark} = P_{\text{skew}}\cdot\Gamma(q)\cdot(1-t(q))\cdot(1-s/2)$ - and price impact proper is $\Gamma(q)$ together with $t(q)$ on an under-covered output leg. Deep dive: [Slippage & Price Impact](/docs/1-1-5-slippage-price-impact).

### Treasury {#treasury}
Protocol-controlled address that can collect accumulated protocol fees. Subject to timelock for updates.

---

## U {#u}

### Undercollateralized {#undercollateralized}
Coverage < 100%. Pool owes more than it holds. Triggers:
- Withdrawal haircuts
- Positive inventory skew (the mid moves up)
- The convex coverage wall (`kappaCovBps`) on any swap that drains the leg further

Coverage is restored through pricing alone: every exit from an under-covered leg pays the deficit-proportional [haircut](#haircut), so leaving raises c for those who stay, and on a walled leg the convex [coverage toll](#coverage-ratio) prices each further drain superlinearly. Neither runs on a clock and neither reduces liabilities on its own; coverage is never rewritten by a background process.

### UUPS (Universal Upgradeable Proxy Standard) {#uups-universal-upgradeable-proxy-standard}
Upgrade pattern where the logic contract holds the upgrade function. **AIMM use**: `Admin` and `Flash` are UUPS implementations behind ERC-1967 proxies, gated by `UpgradeGate` at the `UPGRADE` tier. The pool fleet is not UUPS: it upgrades through the `PoolFactory` beacon.

---

## V {#v}

### Vega (ν) {#vega}
Per-asset sensitivity parameter controlling how volatility affects both the base spread and [liquidity dispersion](#dispersion). Live values are per class: $\nu = 10{,}000$ (1.0x, linear) on stable legs and on every pool's hub, 4,500 metals, 4,000 crypto majors, 3,500 equities, 3,000 FX. `vegaHardMinBps = 5{,}000` and `vegaHardMaxBps = 20{,}000` are **risk fences** enforced at the write, not a preset menu ([Parametrization](/docs/1-1-7-parametrization)).

**Formulas** (`Pricing.sol`):
- `sVol = minFeePath + σ × vegaBps / (100 × BPS)` (base spread component, in `_pathSpread`)
- `dispersion = min(minDispersionPbps + σ × vega / BPS, MAX_DISPERSION_PBPS)` (depth curve adjustment, in `_calculateDispersion`; the historic `/ (1000 × BPS)` damping was removed by the 2026-08-21 adaptive-dispersion change)

**Economic role**: Vega implements **volatility sensitivity** from [Avellaneda-Stoikov](#avellaneda-stoikov-framework). Higher vega means the pool widens spreads and concentrates liquidity when volatility spikes. **Spread composition**: the full path spread is `sVol + U_stale + U_conf`, volatility + keeper-staleness surcharge + confidence surcharge (`_pathSpread`). [Inventory skew](#inventory-skew) shifts the **mid price**, not the spread, the spread itself is symmetric and carries no inventory or deviation term. See [Volatility (σ)](#volatility), [Spread](#spread), [Dispersion](#dispersion), and [Parametrization](/docs/1-1-7-parametrization) for implementation.

### Volatility (σ) {#volatility}
Price variability measurement. AIMM does not compute volatility on-chain: NX Rates aggregates a 30-minute Parkinson (range-based) estimate off-chain and pushes a single `sigmaPbps` per feed alongside each mark, stored in `ExternalOracle.sol`. No volatility estimator runs in-pool. See [Internal Price Discovery](#internal-oracle) and [Foundations](/docs/foundations).

### VWAP (Volume-Weighted Average Price) {#vwap-volume-weighted-average-price}
In AIMM, the average price of a swap over the depth it traverses: the integral of the spline depth curve over the swept interval, divided by the interval width. Each segment stores an exact prefix integral, so computing the VWAP is O(1) in trade size. The UI's depth ladder quotes the VWAP for a hovered rung's route; an order larger than the ladder's remaining capacity shows the capacity edge instead, which is not a fillable price.

**See**: [Price Impact](#price-impact), [Spread](#spread).

## W {#w}

### WAD {#wad}
Fixed-point unit = 1e18. Used for coverage ratios, prices, and percentages requiring high precision.

### Wrapped Native {#wrapped-native}
ERC-20 version of native token (WETH for ETH). AIMM auto-wraps/unwraps for native token support.

### Weight (Spline) {#weight-spline}
Control weight of the [quartic I-spline](#quartic-i-spline) curve (`wQ`, pbps·Q). Nondecreasing weights (Δw ≥ 0) guarantee a monotone depth curve; the weight profile sets where density concentrates. Validated on-chain at every curve install.

---

## Related Documentation {#related-documentation}

- [Market Fit](/docs/foundations): BTR vs peer AMM comparison (Uniswap V2/V3/V4, Curve V1/V2, Balancer, DODO, Maverick, LFJ LB, Platypus, Wombat, OrbSwap)
- [Foundations §18](/docs/foundations#18-capital-efficiency): shared-inventory multiplier (VCR, `N-1`× base-pair depth, contention discount γ)
- [Foundations §10 OrbSwap](/docs/foundations): Sphere invariant, polar-tick mathematics, torus extension
- [Architecture Overview](/docs/1-overview)
- [Inventory Management](/docs/1-1-1-inventory-management)
- [Spread & Fees](/docs/1-1-4-spread-fees)
- [Parameters Reference](/docs/1-1-7-parametrization)