Glossary

A

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, ranging from benign Statistical Arbitrage to devastating Informed Order Flow.

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

See Arbitrage, Toxic Flow, LVR, 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, Sandwich Attacks, Informed Order Flow
• Timing-based: Latency Arbitrage, JIT Liquidity
• Block-ordering: MEV, Greasing, MEV Spoofing
• Price-based: Statistical Arbitrage (when purely extractive), Toxic Flow

Economic impact: Adversarial behavior imposes Adverse Selection costs on LPs, increases LVR, 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, MEV, Arbitrage, Order Flow Toxicity.

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:

Core Concepts:

• Invariant - Mathematical constraint defining price curve
• Liquidity Shaping - Dynamic adjustment of depth
• Liquidity Concentration - Range/bin-based strategies
• Price Impact - Cost of trade size
• Slippage - Deviation from expected price

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)

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)

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)

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)

AMM where liquidity is organized into discrete price “bins” (rather than continuous ticks) with dynamic fee adjustments and liquidity repositioning. Architecture: Unlike CLMM where ranges of N ticks act as local CPMM between endpoints, each DLMM bin acts as independent CSMM 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 (Trader Joe LFJ V2, Avalanche), Meteora (Solana), Cetus (Sui/Aptos), Saros (Solana). See Liquidity Range for CLMM-DLMM comparison and Concentrated Liquidity for architecture context.

CCMM (Circular/Orbital 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. Sphere invariant, polar-tick mathematics and the torus extension: Foundations §10.

AIMM (Adaptive Inventory Market Maker)

BTR’s AMM 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.

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.

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

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, 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

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 (Token), LCA, and the dex doc 1.1.3. Anchor Path Pricing for architecture details.

APR (Annual Percentage Rate)

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 paid to arbitrageurs, and nothing in the protocol rebates that.

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

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) - Price discrepancies across venues. Most common, least harmful, economically benign.
2. Latency Arbitrage - Exploits speed/network lags. Infrastructure-dependent, controversial.
3. Informed Order Flow (Alpha Toxicity) - Superior information (news, insider). Rare, devastating, pure adverse selection.
4. Markout Toxicity (Winner’s Curse) - Losses in trends. LP systematically wrong side, not information-driven.
5. Flow Internalization (PFOF) - Retail routed elsewhere, toxic flow to AMM. Structural market design issue.
6. JIT (Just-In-Time) Liquidity - Fee extraction via block-level timing. ~1% of Uniswap v3/v4 volume.

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 - it reacts to existing price differences rather than to future information, and it tightens pegs and cross-venue consistency. Not MEV: it does not alter block ordering. The LP still experiences it as adverse selection; AIMM’s defense is the fresh keeper mark, which shrinks the staleness window it feeds on.

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: speed, not secret information.

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 problem. Rare but devastating: unlike statistical arbitrage, 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.

Markout Toxicity (Winner’s 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)

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

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, which displaces the mid by the skew offset as a function of 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, Spread, 1. AIMM/1.1. Pricing.

B

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.

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.

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 Path Pricing.

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, Bundle.

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

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

Types:

• Asset Bridge: Token/NFT transfers
• Messaging Bridge: Arbitrary data and contract calls

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

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)

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

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, Block Builder.

C

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. See Spline (Cubic Interpolation).

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 on the mid + withdrawal haircuts

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, Market Order, Limit Order.

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: tick-based (Uniswap V3/V4); a range behaves as a local CPMM
• DLMM: bin-based (LFJ, Meteora); each bin behaves as a CSMM
• Quadratic / Elliptical concentration: Gyroscope 2-CLP and E-CLP

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

See: Liquidity Shaping, Liquidity Range.

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

Two-asset concentration by a quadratic on a bounded range [α, β]: more capital-efficient than a CPMM hyperbola, more forgiving than a CSMM line. Implementation: Gyroscope 2-CLP.

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 (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, 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, Statistical Arbitrage.

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:

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 measures collateralization health.

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

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

See Coverage Ratio, Reserves, Liabilities, Haircut, Liquidation.

Confidence (CI)

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{c}\mathrm{o}\mathrm{n}\mathrm{f}}$ 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), Feed (Oracle), Spread.

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 on the mid, Haircuts 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). 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, Haircut, ALM. Deep dive: Inventory Management, Parametrization.

Coverage Impact

The direction a trade pushes a leg’s 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 wall on the same size.

See: Arbitrage, Inventory Skew. Deep dive: Pool §3.4.

Est. Coverage Impact

The quote-time estimate of how a pending trade moves a leg’s 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. It is a preview of the quantity Coverage Impact classifies, computed off the leg’s reserves and liabilities without executing anything.

See: Coverage Impact, Coverage Ratio, Haircut. Deep dive: Pool §5.4.

Coverage Toll

A size-dependent charge, in bps of gross output, levied when a swap drains a leg whose 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 premium it composes the Net Premium; it is never part of the fee.

See: Kappa (κ_cov), Coverage Impact, Net Premium.

D

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

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), Feed (Oracle), and the Depeg Halt.

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.

See: Confidence (CI), Feed (Oracle), Oracles §8.3.

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

Dual ledger (pool hooks)

Economic reserves split as $R=R_{\mathrm{l}\mathrm{i}\mathrm{q}}+R_{\mathrm{i}\mathrm{n}\mathrm{v}}$. Pricing / coverage use $R$; executable cash is $R_{\mathrm{l}\mathrm{i}\mathrm{q}}$. 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.

E

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)

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)

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 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 for application-level standards.

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-3009, and meta-transaction systems.

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)

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 for core protocol improvements.

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-20 extension adding permit() for off-chain signature approvals. Eliminates separate approval transactions, saving gas. Uses EIP-712 for structured signing.

ERC-3009 (Transfer with Authorization)

Enables single-transaction token transfers using off-chain signatures. Uses EIP-712 for secure signature generation.

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.

ERC-4626 (Yield-Bearing Vault Standard)

Universal interface for tokenized vaults (lending pools, yield aggregators). Standardizes deposit/withdrawal/share mechanics, improving DeFi composability.

F

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 $\left|\mathrm{\Delta }\mathrm{m}\mathrm{a}\mathrm{r}\mathrm{k}\right|/\mathrm{m}\mathrm{a}\mathrm{r}\mathrm{k}$ as a compromised-signer backstop; there is no on-chain $\sigma$-EMA. Full struct, field widths and gating: Internal Oracle and Oracles.

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. Enables liquidations, arbitrage, and composable DeFi strategies. AIMM charges flashFeePbps as fee.

Finality

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

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

See Consensus, Validator, Sequencer.

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 or validator. Used by some rollup sequencers (original Arbitrum model) to provide fair ordering without explicit MEV 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). Contrast with price-time priority (CLOB ordering) and gas auction (Ethereum L1 ordering). See Sequencer, Mempool.

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)
• Block-level: Multiple transactions within same block (time-based cooldowns)
• Epoch-level: Longer timeframes across multiple blocks (staking unbonding periods)

Common Flow Guard Types:

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, Circuit Breaker, Flow Guards.

G

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). AIMM splits that role in two: vega sets the volatility-scaled half-width, and 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 LP is short.
• Contention discount ${\gamma }_c\in [0.5,1]$ in the shared-inventory efficiency model (Capital Efficiency).

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, Vega (ν), LVR, OEV.

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 extraction occurs on L1-searchers bid up gas prices to ensure their transactions land in favorable positions (e.g., before a victim’s transaction for front-running). Contrast with:

• FCFS/FIFO: Order by arrival time (some rollup sequencers)
• Timeboost: Explicit auction for express lane priority (Arbitrum)
• 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 exist, to bypass the public gas auction entirely. See Mempool, Block Builder.

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

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).
• Oracle grace: the age below which a feed owes no staleness surcharge, $g=\min (\mathrm{t}\mathrm{t}\mathrm{l}/2,30\mathrm{s})$; $U_{\mathrm{s}\mathrm{t}\mathrm{a}\mathrm{l}\mathrm{e}}$ is exactly zero inside it (Oracles).

H

Half-Spread

One side of the spread: the distance from the mid to either the bid (sell side) or the ask (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, Paid Spread, Total Cost. Deep dive: Spread & Fees §1.

Bid Spread

The paid spread on the sell side: the distance from the mid down to the price a taker actually sells at. In AIMM it is one half-spread plus whatever surcharges bind on that side (staleness, confidence), and the output-side 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, Half-Spread, Paid Spread. Deep dive: Spread & Fees §3.

Ask Spread

The paid spread on the buy side: the distance from the mid up to the price a taker actually buys at. The mirror of the bid spread above the mid, with the same composition - one half-spread plus binding surcharges and any output-side coverage toll.

See: Bid Spread, Half-Spread, Paid Spread. Deep dive: Spread & Fees §3.

Haircut

Penalty on a withdrawal out of a leg whose 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.

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 (θ), Grace Period, Feed (Oracle).

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). Cross-pool routing always takes the hub out of the source pool, so the hub carries a mandatory Kappa wall like any listed asset.

See: Spoke, Anchor Tree.

Hooks

BTR pool extensibility: per-asset void callbacks on IPoolHooks (preOutflow, optional postInflow) plus dual ledger ($R_{\mathrm{l}\mathrm{i}\mathrm{q}}$ / $R_{\mathrm{i}\mathrm{n}\mathrm{v}}$). 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). See Pool Hooks.

I

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

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, Mark Price, Curation §3.2.

Invariant

Mathematical constraint defining AMM price curves. Invariant-based designs:

• CPMM: x × y = k (Uniswap V2)
• CSMM: x + y = k (linear pricing)
• CFMM (general): F(x₁,…,xₙ) = k
• Stablecoin curves (e.g., Curve’s StableSwap)

Alternatives: CLMM (tick-based ranges), DLMM (bin-based), CCMM (n-dimensional). Concentration variants: Quadratic Concentration (Gyro 2-CLP: quadratic within range), Elliptical Concentration (Gyro E-CLP: elliptical with transformation params). AIMM breaks from invariant-based pricing entirely, using oracle-aware pricing instead. See Price Impact, Concentrated Liquidity, and Liquidity Range for architectural variants.

Inventory Skew

The mid displacement AIMM applies as a function of coverage alone - a fixed protocol law of $c=R/L$ with no per-asset parameter (computeInventorySkew, Pricing.sol), derived from the Avellaneda-Stoikov reservation price.

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.

It moves the mid, never the 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

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). 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 Impact, Haircut.

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.

L

LCA (Least Common Ancestor)

The deepest node of the 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

LP claims against pool reserves. Tracks what the pool owes depositors:

struct Asset {
    uint128 reserves;      // What pool holds
    uint128 liabilities;   // What pool owes
}

Debt Swap / Liability 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 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 κ 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.

Liquidity Index

Accrued interest multiplier for yield-bearing assets. Updated on interactions.

Liquidity Provider (LP)

Agent that supplies executable quotes or inventory to a market, either through limit orders in a CLOB or deposits into an AMM pool. Earns the spread and any fees minus adverse selection costs and rebalancing costs. LP risks: Impermanent Loss, LVR, extraction via Order Flow Toxicity (Statistical Arbitrage, JIT, Informed Order Flow, Markout Toxicity). Related: Market Maker (CLOB equivalent), Liquidity Taker, Maker-Taker Fees, Price Discovery. See Arbitrage for extraction taxonomy.

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

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

Related architectures: Concentrated Liquidity (LP chooses range), Liquidity Shaping (dynamic adjustments), Bonding Curve (price discovery). Contrasts with CLMM (tick-based ranges) and DLMM / Liquidity Book (bin-based segments).

Liquidity Shaping

Dynamic adjustment of the 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, liquidity shaping allows real-time rebalancing without modifying the invariant. Related to Liquidity Bootstrapping Pool (LBP) (time-weighted shaping) and DLMM (bin-level dynamic fees).

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 that have dynamic dispersion-the curve shape responds to volatility rather than being static.

Traditional bonding curves: CPMM (hyperbolic x·y=k), CSMM (linear), StableSwap (concentrated around peg).

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

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 implicit in weight trajectory. Related: Liquidity Shaping, Price Discovery, Concentrated Liquidity.

Liquidity Range

Price interval within which an LP allocates concentrated liquidity in concentrated liquidity pools. In tick-based pools: Range = set of ticks; within range, acts as local CPMM between endpoints (continuous). In bin-based pools: Range = set of bins; each bin independently acts as CSMM (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 for pool type comparison and Impermanent Loss for risk context. Implementations: Uniswap V3 (CLMM), Trader Joe V2 (DLMM).

Liquidity Book

DLMM architecture using discrete price bins rather than continuous ticks. Each bin acts as a local CSMM with near-zero slippage inside the bin. LP positions are fungible per bin (users hold position tokens per bin, not per individual tick). CLMM ranges instead act as a continuous CPMM between endpoints. Dynamic fee adjustments respond to volatility and bin utilization. See Liquidity Range for CLMM-DLMM comparison and DLMM for architecture details. Implementations: Trader Joe V2 (Avalanche), Meteora (Solana), Cetus (Sui/Aptos), Saros (Solana).

LP Token

Fungible claim on deposited liquidity. AIMM tracks per-user, per-asset LP balances rather than pool-wide shares.

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

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, which concentrates on the push transaction itself. Nothing in the protocol rebates LVR, and no parameter targets it.

See OEV, Impermanent Loss, Oracles: Known risks.

M

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

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

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

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:

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, Internal Oracle.

EMA (Exponential Moving Average)

Weighted average prioritising recent data by exponential decay: ${EMA}_t={EMA}_{t-1}+\alpha (x_t-{EMA}_{t-1})$.

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

LWMA (Linear Weighted Moving Average)

Linearly decaying weights, responsiveness between an SMA and an EMA. Not used in AIMM.

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)

The time-integral of price over elapsed time, $\mathrm{T}\mathrm{W}\mathrm{A}\mathrm{P}=\frac{1}{T}{\int }_0^T{P}_{t}dt$, mathematically an SMA. 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). Off-chain charts rebuild TWAPs from emitted Swapped events instead.

MEV (Maximal/Miner 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 (harmful), Sandwich Attacks (most harmful), Backrunning (benign), and MEV Spoofing (encrypted-mempool specific). Related to 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 for execution agents.

MEV Strategies

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.

Back-running

Placing a transaction immediately after another to capture the price move it caused. Benign: it harms nobody and is economically statistical arbitrage at block granularity. Common in liquidations and DEX arbitrage.

Sandwich Attack

A front-run and a back-run 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

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; research puts it at ~1% of Uniswap v3/v4 volume, concentrated in 1-20 professional bots. AIMM’s Flow Guard blocks it by making the deposit-withdraw round trip non-atomic.

MEV Spoofing

Speculative extraction against an encrypted 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

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

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 via public observation of orderflow. Block builders and searchers 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, 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, Block Builder, MEV, Encrypted Mempool, MEV-Protected RPC.

MEV-Protected RPC

RPC endpoint that hides user transactions from the public mempool to prevent front-running and sandwich attacks. Transactions are sent directly to trusted block builders 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.

Research & Further Reading:

• Private MEV Protection RPCs (CoW DAO) - Analysis of private RPC effectiveness
• MEV on Polygon - Impact study
• Cross-chain Sandwich Attacks - Multi-chain MEV vectors
• UniswapX Price Improvement - Order flow auction design
• Protected Order Flow Relay - Relay architecture

See Slippage, MEV, Mempool, Sequencer.

Market Making & DeFi Specific Metrics

Master entry for liquidity-provision metrics.

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

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:

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. Pool operators use TVL forecasts to plan capital requirements and spread competitiveness.

Related: Utilization Ratio, Volume, Liquidity Depth.

Volume

Total notional value of assets traded in a period (day, week, month). Primary revenue driver for LP fees.

Calculation:

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

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, Utilization Ratio, Total Value Locked.

Monotone Cubic Hermite Interpolation

See Spline (Cubic Interpolation).

N

Net Premium

The app’s label for the inventory skew offset plus the coverage toll measured against the mark - no fee, no price impact. It is a row beside 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.

Native Token

Chain’s native currency (ETH on Ethereum). Represented by sentinel address 0xEeee...EEeE (EIP-7528). Automatically wrapped/unwrapped by pool.

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

Measure of how informative or adverse trade flow is to liquidity providers. Umbrella term covering all types of extraction (Statistical Arbitrage, Latency Arbitrage, Informed Order Flow, Markout Toxicity, Flow Internalization). 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 for the toxicity hierarchy. Low toxicity favors passive liquidity provision.

O

On-Chain Mark

An EXTERNAL mark 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, Feed (Oracle), Oracle, Oracles §7.

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 sits around the mark.

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 - Push trigger θ and the per-feed push clamp
• Feed - Oracle data structure + metadata
• Threshold Encryption - MEV-resistant oracle delivery
• Fair Value - Oracle-derived “true” price
• Price Discovery - How markets discover fair value

See Arbitrage, Liquidity Shaping, Spread, LVR, OEV for AIMM applications.

OEV (Oracle Extractable Value)

Not “observed extractable value”. MEV concentrated on the discrete oracle update - the k-of-n signed batchPushSigned transaction - as opposed to diffuse LVR 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 is an ambiguous defense here - neither is a primary mitigation.

Full treatment: Oracles: Known risks.

Overcollateralized

Coverage > 100%. Pool has more reserves than liabilities. Maximum negative skew (-100) incentivizes selling.

P

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:

• 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; 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).

See Price Impact, Slippage, Volatility, Deviation.

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, Spread.

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, Spread.

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:

where $\mathrm{s}\mathrm{k}\mathrm{e}\mathrm{w}\mathrm{O}\mathrm{f}\mathrm{f}\mathrm{s}\mathrm{e}\mathrm{t}$ comes from coverage-driven 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, Spread, Inventory Skew.

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{v}\mathrm{o}\mathrm{l}}+U_{\mathrm{s}\mathrm{t}\mathrm{a}\mathrm{l}\mathrm{e}}+U_{\mathrm{c}\mathrm{o}\mathrm{n}\mathrm{f}}$.

See Price Impact, Slippage, Spread.

Fair Value

External reference for the asset. In BTR pools this is the keeper mark (pushed), not a pool-derived TWAP.

See Oracle, 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, Internal Oracle, On-Chain Mark, Feed (Oracle).

See On-Chain Mark, Oracle, Feed Oracle.

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, Oracle.

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 (a width present at zero size) and from slippage (an unexpected deviation between quote and execution).

In AIMM it is the curve traversal $\mathrm{\Gamma }\left(q\right)$ from the skew-anchored mid, together with the coverage toll $t\left(q\right)$ 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.

Protocol Fee

Portion of spread retained by protocol:

See: LP Fee, Paid Spread. Deep dive: Spread & Fees §5.

LP Fee

Portion of the spread retained by liquidity providers: the total fee minus the protocol fee. In the swap recap it is one of the two rows under Paid Spread.

See: Protocol Fee, Paid Spread, Maker-Taker Fees, Liquidity Provider (LP). Deep dive: Spread & Fees §5.

Paid Spread

The 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 rather than drawn as book depth.

See: Spread, Total Cost. Deep dive: Spread & Fees §1-2.

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

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

Process by which trading activity and order flow incorporate information into prices, through competition among participants.

Q

Quorum (k-of-n Signer Set)

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). 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), Deviation (Oracle), and Oracle Price-Push Security.

R

Reentrancy Guard

Transaction-level 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) for gas-efficient guards (~2,100 gas savings vs persistent storage).

See Flow Guard, EIP-1153.

Rehypothecation (idle farming)

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{l}\mathrm{i}\mathrm{q}}$ shortfall via preOutflow. See dual ledger, Pool Hooks.

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

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

See Collateral, Coverage Ratio, Liabilities, Pool Hooks.

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 and OEV:

• 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 (discrete): MEV concentrated on the oracle-push transaction itself (frontrun/backrun of a pending signed batch).

See: Push-Latency LVR, OEV, Feed Oracle, Deviation (Oracle), Oracles §8.4.

Risk Config

Per-asset safety state: a flags word (feature + halt bits) and kappaCovBps (the convex coverage-wall strength). Bit layout: Pool §8.

RiskConfig carries safety state only. Everything that shapes a price lives on Asset: minFeePbps, vegaBps, haircutSuppressorBps, minLiquidity, presetId and the dispersion band. Inventory skew is a fixed protocol law with no per-asset dial, and the 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.

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

MEV Searcher

Independent network participants who identify and execute MEV 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: from harmful (Sandwich Attacks, Frontrunning) to benign (Backrunning, JIT, liquidations, Statistical Arbitrage). See Arbitrage and MEV Strategies for the taxonomy of extraction types.

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, 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 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, MEV, Block Builder, Timeboost.

Skew

See Inventory Skew.

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, sandwich attacks, or other MEV extraction between quote and execution

Key distinction from 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 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 (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:

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, default 50% (exactly the half-spread, which is what one swap is charged), clamped to [10, 300].

See Price Impact, Spread, Paid Spread, MEV, Mark Price, and MEV-Protected RPC for related concepts. UI details: Swapping §4.

Spoke

A non-base listed asset in a BTR core. Each spoke anchors to a parent within the 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, feed and risk preset; only its base-relative mark and per-leg premiums are shared across the pool.

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

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

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:

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

Difference from Standardization: Normalization bounds to range; standardization centers with zero mean.

See Statistical Concepts, 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:

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

See Statistical Concepts, Normalization, Volatility.

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 =\mathtt{m}\mathtt{i}\mathtt{n}\mathtt{D}\mathtt{i}\mathtt{s}\mathtt{p}\mathtt{e}\mathtt{r}\mathtt{s}\mathtt{i}\mathtt{o}\mathtt{n}\mathtt{P}\mathtt{b}\mathtt{p}\mathtt{s}+\sigma ·\nu /\mathtt{B}\mathtt{P}\mathtt{S}$ (Dispersion). Wider measured volatility widens the band; no on-chain volume accumulator feeds knot placement - see TWAP 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, Time-Weighted Average Price, Spline (Cubic Interpolation).

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, Price Impact, and Volatility. See Bid and Ask 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.

Three rules the rest of the docs rely on:

• It is symmetric and carries no coverage or deviation term: coverage ratio drives the mid through 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.

Derivation, aggregation over legs and the full parameter list: Spread & Fees.

Spline

Master entry for piecewise polynomial methods. Splines build a smooth curve through control points (knots) without the global oscillation a single high-degree polynomial suffers. AIMM uses one to define a liquidity profile, giving arbitrary depth shaping instead of a fixed invariant.

The shipped curve is the quartic I-spline; alternatives that were considered and rejected are recorded below. Curve mathematics, packing and gas: Liquidity Shaping.

Quartic I-Spline (Clamped)

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 Shaping, Knot.

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.

See Catmull-Rom Spline, Quartic I-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 gives exact monotonicity (linear coefficient check) plus C2 density.

See Quartic I-Spline.

T

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 elapses. Distinct from maxDeviation, the clamp bounding how far any single push may move the mark (Deviation (Oracle)). Tighter θ cuts push-latency LVR at higher push cost.

Tick

Discrete price point in concentrated liquidity AMMs (Uniswap v3/v4). AIMM doesn’t use ticks, prices are continuous via splines.

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 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) 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: Pure arrival-time ordering (original Arbitrum)
• 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, MEV, FCFS/FIFO.

Timelock

Delay before a sensitive operation may execute. Seven tiers, production delays (Constants.sol):

Testnet runs a compressed schedule (6h/3h/2h/1h/6h/6h/12h). See Access Control.

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

See EIP-1153.

Total Cost

What a taker pays on top of the mid: Paid Spread + Price Impact. The swap recap prints it as one expandable row with exactly those two detail rows; Net Premium sits outside it. Formally the fill is a product, not a sum - $\mathrm{e}\mathrm{x}\mathrm{e}\mathrm{c}/\mathrm{m}\mathrm{a}\mathrm{r}\mathrm{k}=P_{\mathrm{s}\mathrm{k}\mathrm{e}\mathrm{w}}·\mathrm{\Gamma }\left(q\right)·(1-t(q\left)\right)·(1-s/2)$ - and price impact proper is $\mathrm{\Gamma }\left(q\right)$ together with $t\left(q\right)$ on an under-covered output leg. Deep dive: Slippage & Price Impact.

Treasury

Protocol-controlled address that can collect accumulated protocol fees. Subject to timelock for updates.

U

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, so leaving raises c for those who stay, and on a walled leg the convex coverage toll 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)

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

Vega (ν)

Per-asset sensitivity parameter controlling how volatility affects both the base spread and liquidity 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).

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. 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 shifts the mid price, not the spread, the spread itself is symmetric and carries no inventory or deviation term. See Volatility (σ), Spread, Dispersion, and Parametrization for implementation.

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 and Foundations.

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, Spread.

W

WAD

Fixed-point unit = 1e18. Used for coverage ratios, prices, and percentages requiring high precision.

Wrapped Native

ERC-20 version of native token (WETH for ETH). AIMM auto-wraps/unwraps for native token support.

Weight (Spline)

Control weight of the 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

• Market Fit: BTR vs peer AMM comparison (Uniswap V2/V3/V4, Curve V1/V2, Balancer, DODO, Maverick, LFJ LB, Platypus, Wombat, OrbSwap)
• Foundations §18: shared-inventory multiplier (VCR, N-1× base-pair depth, contention discount γ)
• Foundations §10 OrbSwap: Sphere invariant, polar-tick mathematics, torus extension
• Architecture Overview
• Inventory Management
• Spread & Fees
• Parameters Reference