--- title: "Foundations" description: "Theoretical lineage and design choices behind AIMM." audience: both type: explanation status: live lang: en updated: "2026-08-29" publish: true --- # Foundations > AIMM is assembled from published work rather than invented whole: an inventory-based market-making model from quantitative finance, asset-liability accounting from stableswap design, oracle-anchored quoting from earlier on-chain market makers, and concentrated-liquidity research. This page traces each borrowed mechanism to its source, states what AIMM changed, and records the designs that were evaluated and deliberately not adopted. The vision the design serves is in the [Manifesto](/docs/manifesto). ## 1. Introduction The sections group by what they do: - **Sections 2 to 8 and 13 to 17** trace the published work AIMM borrows from, naming the mechanism taken and the point where AIMM diverges. - **Sections 10 and 13** cover constructions that were evaluated and **not** built, with the reasons. - **Sections 9, 11, 18 and 19** compare BTR's own design against that prior art. The mechanisms themselves are specified in [AIMM](/docs/1-overview), not here. ## 2. Inventory-Based Market Making: The Avellaneda-Stoikov Framework ### 2.1. Origins AIMM's pricing traces to [Marco Avellaneda and Sasha Stoikov's 2008 paper](https://people.orie.cornell.edu/sfs33/LimitOrderBook.pdf) "High-Frequency Trading in a Limit Order Book," which formalized how a rational market maker quotes asymmetrically against inventory risk. A market maker holding excess inventory carries directional exposure. Rather than quoting symmetrically around mid, the optimal strategy adjusts quotes to encourage trades that reduce inventory. ### 2.2. The Reservation Price Avellaneda-Stoikov introduces the **reservation price**: $$r = s - q \cdot \gamma \cdot \sigma^2 \cdot \tau$$ where: - $r$ = reservation price - $s$ = mid-market price - $q$ = inventory quantity (positive = long, negative = short) - $\gamma$ = risk aversion parameter - $\sigma$ = price volatility - $\tau$ = time remaining (T - t) > $\tau = T - t$ is the **finite-horizon residual** in the AS-2008 formulation. AIMM, as an infinite-horizon AMM, uses the **stationary-limit reformulation** (Guéant-Lehalle-Fernandez-Tapia 2012) - the $\gamma\sigma^2\tau$ inventory penalty is replaced by its stationary analog. When inventory $q > 0$ (long), the reservation price shifts below market: the maker sells lower to reduce exposure. The converse applies for short positions. ### 2.3. Optimal Spread The optimal bid-ask spread depends on volatility, order arrival intensity, and risk aversion: $$\Delta = \gamma \cdot \sigma^2 \cdot \tau + \frac{2}{\gamma} \cdot \ln\left(1 + \frac{\gamma}{k}\right)$$ where: - $\Delta$ = optimal bid-ask spread - $k$ = order arrival intensity parameter Higher volatility or risk aversion widens the spread; more frequent order flow tightens it. > **Framework assumptions:** the AS-2008 optimal half-width assumes a finite horizon and exponential order-arrival intensity $\lambda = A \cdot \exp(-k\delta)$. The stationary reformulation noted in §2.2 applies here too. ### 2.4. AIMM's Adaptation AIMM translates these continuous-time concepts to discrete blockchain execution: | Avellaneda-Stoikov | AIMM Analog | |--------------------|-------------| | Inventory $q$ | Coverage ratio deviation from target | | Volatility $\sigma$ | Single realized-vol `sigmaPbps` pushed with the keeper mark | | Risk aversion $\gamma$ | Per-asset `vegaBps` (spread width); the inventory-shift slope is a fixed constant, not a parameter | | Order intensity $k$ | Implicit in spline depth calibration | - **Volatility band** $S_v$ corresponds to the (symmetric) spread component - **Inventory skew** shifts the **mid** (reservation price) based on coverage impact - coverage-improving trades get a better mid, coverage-worsening a worse mid - The spread itself stays **symmetric** around that mid (no directional surcharge); coverage never adds a spread term See [Spread & Fees](/docs/1-1-4-spread-fees) for implementation details. --- ## 3. Asset-Liability Management: Platypus & Wombat ### 3.1. The asset-liability innovation [Platypus Finance](https://medium.com/platypus-finance/platypuss-asset-liability-management-eli5-92a1ee85b17) (2021) brought **asset-liability management (ALM)** to DeFi. Traditional AMMs like Uniswap track only **reserves**, the tokens currently held. Platypus introduced a dual-ledger model: - **Assets**: Tokens the pool currently holds - **Liabilities**: Tokens the pool owes to LPs This distinction enables: 1. **Single-sided deposits**: LPs deposit one token without forced pairing 2. **Explicit coverage tracking**: Pool health visible as assets/liabilities ratio 3. **Natural supply/demand growth**: Each token accumulates independent liability ### 3.2. Coverage Ratio The **coverage ratio** = Assets / Liabilities measures pool solvency: | Coverage | State | Implications | |----------|-------|--------------| | > 100% | Overcollateralized | Excess reserves, premium withdrawal value | | = 100% | Balanced | LPs receive exact deposited amounts | | < 100% | Undercollateralized | Withdrawal haircut applies | Platypus and later [Wombat Exchange](https://www.wombat.exchange/Wombat_Whitepaper_Public.pdf) proved this model works at scale for stableswaps. ### 3.3. Limitations of first-generation asset-liability management Platypus and Wombat use coverage ratio as a **slippage modifier** on a modified invariant curve. The pricing mechanism remains constrained by curve geometry: coverage affects *where* you trade on the curve, not *how* the curve is shaped. From [Wombat Whitepaper](https://medium.com/wombat-exchange/the-wombat-whitepaper-tl-dr-ab4be5dbf71d): > "Wombat introduces a new invariant curve and the concept of asset-liability to remove scalability barriers." ### 3.4. AIMM's Extension AIMM extends asset-liability management in three directions: - **Price is decoupled from reserves entirely.** Price derives from oracles and spline profiles; reserves determine *depth*, not *direction*. - **Inventory skew is coverage-aware.** Avellaneda-Stoikov's inventory adjustment applies through a reservation-price (mid) shift, not through fee asymmetry - the spread stays symmetric. - **Coverage restores itself through pricing** rather than through a write-down of LP claims. The **withdrawal haircut** makes every exit from an undercollateralized leg pay a deficit-proportional penalty, so each exit raises $c$ for those who stay. The **convex coverage wall** (`kappaCovBps`) tolls any swap that drains a walled leg further, superlinearly as $c$ falls. Both act on the trade path; liabilities are never rewritten. See [Inventory Management](/docs/1-1-1-inventory-management) for coverage mechanics. ### 3.5. Oracle-Anchored Proactive Market Making: DODO PMM Platypus/Wombat contributed the *coverage-ratio* half of AIMM's inventory skew; [DODO](https://docs.dodoex.io/)'s **Proactive Market Maker (PMM)** contributed the other half: **oracle-anchored, inventory-aware quote adjustment**. DODO (2020) was the first on-chain AMM to abandon reserve-derived price discovery for an imported mark with a curve shaped around it, the direct on-chain ancestor of AIMM's mark-centered pricing. PMM prices around an oracle mid `i` with a slippage coefficient `k`: - `k → 0` collapses the curve toward **constant-sum** (flat, stableswap-like): very tight around `i`; - `k → 1` recovers **constant-product** (Uniswap-like) impact; - the quote is **inventory-aware**: as the pool's inventory of one asset depletes, PMM shifts its price to make that asset *dearer to buy and cheaper to sell*, pulling rebalancing flow back toward a target. The pool *leans* against imbalance rather than passively pricing off `x·y=k`. **What AIMM inherits from DODO PMM:** - **Pricing around an imported oracle mark, not reserves.** AIMM quotes off the fresh keeper mark exactly as PMM quotes off `i`, the move that removes the CFMM stale-price LVR channel. - **Inventory-aware mid shift.** AIMM's `computeInventorySkew` is the same intuition as PMM's inventory-driven price adjustment: the mid leans against coverage imbalance to attract corrective flow. (The §2 Avellaneda-Stoikov reservation price is the continuous-time optimal-control statement of the same object; PMM is its first on-chain, discrete instantiation.) - **A tunable flatness knob.** PMM's `k` (constant-sum ↔ constant-product) is the spiritual predecessor of AIMM's vol-scaled dispersion + quartic I-spline curve, the shape control that concentrates depth near the mark for tight pairs and widens it under volatility. **What AIMM changes:** PMM is a two-asset, per-pair curve with a single global `k`, static post-deploy, and (in DODO's classic deployment) Chainlink-anchored. AIMM generalizes to a **multi-asset anchor-tree singleton**, replaces the single `k` with a **per-asset preset depth curve + coverage-driven skew** that adapt on every swap, prices off a **self-owned keeper mark** (deviation-θ + heartbeat) rather than a third-party feed on the quote path, and layers explicit symmetric volatility / confidence / staleness spread premiums. --- ### 3.6. Shared-pool single-sided deposit: GMX GLP and GM GMX is the closest cousin to the deposit shape above, and the closest thing to a counter-example worth stating precisely: both generations let a provider deposit one asset into a pool that holds several, which is the same surface a user meets on BTR. What differs is what the provider owns afterwards, and what they are exposed to. **GLP (V1)** is one global basket. A depositor mints with any index asset and receives GLP, a claim on the whole composition, so the position stops being the asset that was deposited: deposit BTC and you hold the index. Composition is steered by target weights and a dynamic mint and burn fee that is cheaper for an underweight token and dearer for an overweight one, which is a fee-side version of the same rebalancing pressure BTR applies on the mid. **GM (V2)** is a set of isolated two-token markets, a long token and a short token, for instance WETH against USDC. Single-sided deposit is allowed, but the receipt is priced as `(pool value + net pending PnL) / supply`, so a one-sided depositor still ends up holding both sides of that market plus the traders' open profit and loss. Deposits and withdrawals carry a price impact that pays for improving the pool's balance and charges for worsening it: the mechanism closest in spirit to coverage-driven inventory skew anywhere in production. Three differences are structural rather than parametric. **What the provider ends up holding.** GLP converts a deposit into an index share, and GM converts it into a two-sided market share. BTR keeps the claim on the leg it was deposited into: liabilities are tracked per leg, the receipt is a per-leg token, and a withdrawal returns that same asset. A BTR provider is long exactly what they chose to be long, which is why the position needs no rebalancing rather than being rebalanced for them. **What the provider is counterparty to.** GMX is a perpetuals venue, so a GLP or GM holder is the house against leveraged directional traders, and trader profit is paid out of pool value. BTR is spot. A provider faces adverse selection on swap flow, which the spread and the inventory skew exist to price, and no directional trader position is ever paid out of their claim. Most of what follows descends from this one difference. **What "coverage" means.** GMX bounds exposure with a reserve factor, `available liquidity = pool tokens × reserve factor − reserved tokens`, and enforces it by **blocking**: when available liquidity reaches zero a provider waits for positions to close before withdrawing. There is no haircut, because there is no per-asset solvency figure to be short against. BTR's coverage is exactly that figure, assets over liabilities on a single leg ([§3.2](#32-coverage-ratio)), and it is enforced by **pricing**: the mid skews against whoever drains the leg, the convex wall tolls the drain, and an exit below par is haircut so the deficit stays with whoever realises it. GMX makes the queue wait; BTR makes the trade pay. The shared ancestor is worth naming: single-sided deposit into a pool of several assets is a Platypus idea that GMX productionised at scale first, and the fact that GMX did it for a perpetuals book is what pushed it toward a pooled index claim rather than per-leg liabilities. ## 4. Oracle-Guided Pricing: Swaap's Matrix Market Maker ### 4.1. The Swaap Innovation [Swaap Finance](https://www.swaap.finance/whitepaper.pdf) introduced the **Matrix Market Maker (MMM)**, a stochastic, asymmetric, oracle-guided, multi-asset AMM that decouples price discovery from market making. From [Swaap's introduction](https://www.swaap.finance/blog/introducing-swaap-protocol): > "Swaap's v1 model, the MMM, is an oracle-guided, multi-asset AMM. Its goal is to function like a passive Index ETF, aiming for near-zero impermanent loss by decoupling price discovery (from oracles) from the act of market-making." ### 4.2. Stochastic Spread Mechanism Swaap adjusts spreads on real-time volatility rather than charging a fixed fee: > "Instead of simple volume-based fees, Swaap uses a 'stochastic spread mechanism.' This model adjusts fees based on real-time market volatility data, protecting liquidity providers during turbulent periods by charging higher premiums for riskier trades." This directly influenced AIMM's volatility band $S_v$. ### 4.3. Geometric Mean Product Swaap's constant geometric mean product enables multi-asset pools where each asset maintains target weight: $$\prod_i x_i^{w_i} = k$$ where: - $x_i$ = quantity of asset i - $w_i$ = weight of asset i - $k$ = constant product This allows portfolio-like behavior; the pool rebalances to maintain allocations. ### 4.4. Swaap v2 Architecture [Swaap v2](https://www.swaap.finance/v2-whitepaper.pdf) evolved toward RfQ (Request for Quote) infrastructure: > "Swaap Maker is a non-custodial RfQ market-making infrastructure. It provides optimal liquidity services with built-in defensive modules or 'safeguards' allowing for on-chain max drawdown circuit breaker, last look, and other dynamic forms of funds protection." This hybrid on-chain/off-chain model prioritizes professional market makers over passive LPs. ### 4.5. AIMM's Divergence AIMM shares Swaap's oracle-first philosophy but differs architecturally: | Aspect | Swaap | AIMM | |--------|-------|------| | **Price source** | External oracles | Keeper mark (fresh per-asset, deviation-θ + heartbeat) plus per-asset depeg price bands | | **Pool structure** | Weighted portfolio | Coverage-based asset-liability accounting | | **Spread mechanism** | Stochastic (vol-based) | Symmetric vol + confidence + staleness surcharges; coverage drives inventory skew on the mid | | **Target users** | Professional market makers | Passive LPs | AIMM quotes off the keeper's fresh mark rather than a lagging internal average, and gates tail risk with per-asset depeg bands checked against an independent reference feed. See [Oracles](/docs/3-4-oracles) and [Depeg Halt](/docs/3-5-depeg-halt). ### 4.6. The Optimal-Pricing Theory: Bergault, Bertucci, Bouba and Guéant Swaap's MMM and AIMM are two *implementations* of one theory, the most direct academic parent of AIMM's design: the oracle-AMM optimal-pricing line of **Bergault, Bertucci, Bouba and Guéant**, *[Automated Market Makers Designs beyond Constant Functions](https://arxiv.org/abs/2212.00336)* (2022) and *[Price-Aware Automated Market Makers: Models Beyond Brownian Prices and Static Liquidity](https://arxiv.org/abs/2405.03496)* (2024), which extends the Avellaneda-Stoikov market-making objective (§2) from a single quoting agent to an AMM that references an imported mark. Their result: for a maker quoting bid/ask **markups** `δ(t,z)` around an imported mark `S_t`, maximizing excess-PnL-vs-HODL under a quadratic-variation risk penalty, the mean-variance-optimal quotes are **markups linear in the inventory-value deviation and in trade size, with slope driven by the effective instantaneous variance**: holding under Heston-Bates, Stein-Stein-with-jumps, and Hawkes price/flow dynamics, i.e. explicitly *beyond* the Brownian, static-liquidity assumptions of earlier AMM analyses. AIMM's shipped pricing forms map onto that prescription almost one-for-one: | Bergault et al. optimal object | AIMM shipped form | |--------------------------------|-------------------| | Quote off an imported mark `S_t`, not reserves | Fresh keeper mark `mark1e18` (deviation-θ + heartbeat) | | Markup **linear in inventory** | `computeInventorySkew`, linear coverage skew on the mid | | Spread **scales with instantaneous volatility** | σ-scaled `sVol` band | | Markup **increasing in trade size** | Quartic-curve VWAP over the traversed depth | | Liquidity **not statically fixed** | vol-scaled dispersion + timelocked preset refit/repoint (`UPDATE_CURVE` / `UPDATE_PROFILE`) | | Lagged-oracle pick-off term | $\sigma\sqrt{\tau}$ staleness surcharge | Validation against the papers concluded AIMM is a **faithful on-chain implementation of this optimal-quote structure**. §2 (Avellaneda-Stoikov) is the *inventory-theory root*, §4.1-4.5 (Swaap) is a *peer implementation*, and this line is the *optimal-AMM theory AIMM instantiates*. The LVR cost this pricing is built to avoid is formalized separately by Milionis, Moallemi, Roughgarden & Zhang (*[Automated Market Making and Loss-Versus-Rebalancing](https://arxiv.org/abs/2208.06046)*, 2022). --- ## 5. Dynamic Pegging: Curve v2 Cryptoswap ### 5.1. The Repegging Innovation [Curve v2 Cryptoswap](https://docs.curve.finance/assets/pdf/whitepaper_cryptoswap.pdf) introduced **dynamic repegging**: the concentrated-liquidity center moves automatically with an internal price oracle. From [Curve documentation](https://docs.curve.finance/cryptoswap-exchange/overview/): > "Thanks to a repegging algorithm which is run after each swap, Curve V2 allows swaps to occur near the equilibrium point." ### 5.2. Internal Oracle Curve v2 maintains an exponential moving average (EMA) of trade prices: > "Internally, Curve v2 has a price oracle given by an exponential moving average applied in N-dimensional price space." This internal oracle determines where to concentrate liquidity, not just how to price trades. ### 5.3. Profit-Loss Accounting Cryptoswap tracks `xcp_profit` and `xcp_profit_real` to ensure repegging doesn't destroy LP value: > "It undoes p adjustment if it causes xcp_profit_real-1 to fall lower than half of xcp_profit-1." This constrains curve updates to scenarios where accumulated fee revenue exceeds incurred losses. ### 5.4. Permanent Loss Risk Unlike Uniswap's "impermanent" loss (recoverable if price returns), Curve v2 can cause **permanent** loss: > "Crypto Pool is vulnerable to permanent loss (which cannot be recovered even if the price does) due to changes in the curve itself when repegging the equilibrium price." The curve shape changes, locking in losses even if prices recover. ### 5.5. AIMM's Approach AIMM quotes off the keeper mark and performs no dynamic invariant update: | Aspect | Curve v2 | AIMM | |--------|----------|------| | **Price reference** | Single internal EMA | External keeper mark (fresh per-asset, deviation-θ + heartbeat) | | **Curve updates** | Automatic repegging | Preset curves (timelocked refit/repoint; dispersion-scaled live) | | **Loss type** | Permanent (curve changes) | Impermanent (reserves change) | | **Newton iteration** | ~35k gas per swap | None (direct spline evaluation, O(1) integral) | Preset curves avoid permanent loss from curve drift: shape changes go through timelock, never through trade-path repegging. The pool quotes the raw keeper mark; no on-chain price EMA is maintained. See [Oracles](/docs/3-4-oracles) for the external-mark feed design. --- ## 6. Concentrated Liquidity: Gyroscope E-CLP ### 6.1. Elliptical Concentration [Gyroscope's E-CLP](https://docs.gyro.finance/pools/e-clps) (Elliptic Concentrated Liquidity Pool) uses elliptical curves for asymmetric liquidity concentration: > "Elliptic CLPs allow trading along the curve of an ellipse. Similar to other CLPs, E-CLPs are designed to concentrate liquidity within price bounds." The ellipse is formed by transforming a circle: - **Stretch** ($\lambda$): Elongates the curve - **Rotation** ($\phi$): Tilts the concentration - **Displacement** ($\alpha$, $\beta$): Shifts price bounds ### 6.2. Capital Efficiency E-CLPs gain capital efficiency over StableSwap: > "By putting liquidity only where it is needed, E-CLPs can improve capital efficiency by upwards of 75% over StableSwap pools." ### 6.3. Passive Management Unlike Uniswap v3's LP-managed positions, E-CLP parameters are set by pool deployers: > "Unlike any other form of concentrated AMM curve, Gyroscope's E-CLPs provide passive liquidity management; instead of users setting price bounds themselves, the pool deployer takes on the responsibility of calibrating and establishing the trading parameters upon launch." AIMM takes the same stance on who shapes the curve - the LP does not pick a range - but places that authority differently: E-CLP parameters sit with the pool deployer, whereas every AIMM pool resolves one chain-wide owner and the deploying address gains no keys. ### 6.4. Limitations Elliptical curves have geometric constraints: 1. **Single-peaked distribution**: Cannot create bimodal liquidity profiles 2. **Smooth concentration**: Cannot create sharp edges or plateaus 3. **Symmetric options limited**: Rotation helps but doesn't enable arbitrary asymmetry E-CLPs approximate most desired curves but cannot express: - Double-peaked distributions (liquidity at two price points) - Flat regions with sharp cutoffs - Inverse or concave profiles ### 6.5. AIMM's Alternative Spline-based profiles lift those limits: | Capability | E-CLP | AIMM Splines | |------------|-------|--------------| | **Single peak** | Yes | Yes | | **Flat regions** | Limited | Yes (flat-topped table at the mark, shipped shape) | | **Sharp cutoffs** | No | Yes (support ends hard at the curve's own offset bound) | | **Arbitrary shapes** | No | Yes (quartic I-spline; density is a free per-asset design input) | See [Liquidity Shaping](/docs/1-1-2-liquidity-shaping) for spline mechanics. --- ## 7. Volatility-Based Fees: LFJ v2 Liquidity Book ### 7.1. The Surge Pricing Innovation [LFJ's Liquidity Book](https://github.com/traderjoe-xyz/LB-Whitepaper) (formerly Trader Joe v2) introduced **surge pricing**: fees that rise with market volatility. > "Liquidity Book introduces a fee structure that has two components, a base fee and a variable fee. The variable fee is adjusted to account for volatility. The more volatile the assets are in a Liquidity Pool, the higher the variable fee will be." ### 7.2. Volatility Accumulator LFJ measures instantaneous volatility through a **Volatility Accumulator (VA)** without external oracles: > "The VA is able to calculate instantaneous volatility for each Liquidity Pool, without relying on any outside oracles by tracking transactions across bins." Bin crossings indicate price movement; more crossings per trade = higher volatility. ### 7.3. Rationale Surge pricing compensates LPs during periods of maximum adverse selection: > "Impermanent Loss can be viewed as a cost of the price discovery, so it is highest during the most volatile times when the market tries to correctly price assets. Surge Pricing generates additional fees from trades, used to compensate LPs for the Impermanent Loss they experience during market volatility." ### 7.4. AIMM's Implementation AIMM's volatility band directly implements surge pricing concepts: $S_v = \sum_i f_{\min,i} + \frac{\sigma_p \cdot \nu_p}{100\cdot\text{BPS}}$ where: - $S_v$ = volatility band, in PBPS (1 unit = 0.0001%) - $f_{\min,i}$ = the per-leg `minFeePbps` floors - there is **no hardcoded base**; the base is the configured floor - $\sigma_p$ = path volatility (quadrature over legs), PBPS-based ($10^4$ = 1%) - $\nu_p$ = endpoint-maximum `vegaBps` - BPS = 10,000 Key differences: | Aspect | LFJ v2 | AIMM | |--------|--------|------| | **Volatility measurement** | Bin crossings (VA) | Single realized $\sigma$ pushed with the keeper mark | | **Fee components** | Base + variable | Base + volatility + confidence + staleness (all symmetric) | | **Inventory awareness** | No | Yes (coverage shifts the mid, not the spread) | | **Multi-hop aggregation** | Per-hop | Sum over legs; σ composes in quadrature | --- ## 8. CLMM/DLMM Trade-offs and Their Mitigations > Mainstream concentrated-liquidity DEXs have addressed several of these via V4 hooks, custom curves, and active management. ### 8.1. The Concentrated Liquidity Tradeoff Uniswap v3's concentrated liquidity buys capital efficiency at three costs: **Amplified Impermanent Loss**: Narrower ranges magnify IL when prices move out of range: > "Concentrated positions can experience more significant impermanent loss than V2 positions if prices move beyond your range." [Kaiko Research](https://research.kaiko.com/insights/jit-2) **Active Management Burden**: LPs must continuously rebalance: > "LPs, especially smaller LPs, are constrained in the degree to which they can actively manage their concentrated liquidity positions. As a result, their positions tend to drift out of range, suffering from IL and failing to capture any trading fees." **Net Losses for Most LPs**: the majority underperform holding: > "Between V3's launch and September 20th, analyzed pools saw over $100B in trading volume, earning LPs approximately $200M in fees. However, LPs lost more than $260M to impermanent loss, resulting in a net loss of over $60M." [Rekt News](https://rekt.news/uniswap-v3-lp-rekt) ### 8.2. JIT Liquidity Dynamics Concentrated liquidity enables **Just-In-Time (JIT) liquidity**: add depth before a large trade, capture the fees, remove it in the same block. > "Just In Time Liquidity is an occurrence unique to Uniswap V3's concentrated liquidity. A large amount of liquidity is added by a JIT bot when they see a large trade in the mempool. It is then removed immediately after within the same block." JIT bots extract value from passive LPs: > "This liquidity added before the trade reduces price impact for the trader by increasing the pool size, but dilutes the trading fees distributed amongst existing LPs." Research identified 36,671 JIT attacks over 20 months generating 7,498 ETH profit. ### 8.3. Capital Intensity JIT is "a whales' game": > "JIT transactions are significantly larger than regular transactions, generally with a minimum size of $10 million." Retail LPs cannot compete with sophisticated market makers. ### 8.4. What the venue does not supply The quotes above describe the symptom (positions drift out of range, most LPs underperform holding), but they under-describe the cause. A concentrated-liquidity DEX supplies pool infrastructure. It does not supply market making, and the gap between the two is where the work and the losses sit. Three separate cost centres live in that gap, none of which the venue exposes a primitive for: 1. **Range selection**, the one the literature measures. A position earns nothing outside its bounds. 2. **Venue selection.** Fee tiers are not interchangeable. The same pair at 5 bps and at 30 bps behaves as two different businesses, and which one pays depends on the regime: a quiet tape favours the tight tier, a moving one the wide tier, because the fee has to cover what the move costs the position. Capital has to move between pools, not only between ranges. 3. **Execution.** Rebalancing inventory is itself a trade at size, and a naive one gives back the edge it was rebalancing to capture. Doing it properly means splitting across venues, routing through aggregators (atomic and intent-based) and measuring realised cost against the decision price. Each is a quantitative problem with an infrastructure bill attached, and the DEX's contribution to all three is the same: none. That is what "active management burden" understates. The difficulty is not that management is manual; it is that the venue's design makes a full market-making operation the price of participating, while presenting the position to depositors as passive. The architectural response taken here is to move all three inside the pool: the mark comes from outside so there is no range to select, one pool spans the asset set so there is no tier to choose, and inventory is priced rather than traded, so there is no rebalance to execute. The last of those has a precondition the first two do not: pricing substitutes for rebalancing only where flow comes back the other way, and a pair pool cannot net across legs at all; an imbalance there can only be traded out. A multi-asset core can net internally, provided its legs are correlated enough that flow draining one tends to arrive against another, which is why cores are grouped by asset class rather than by whatever is available to list ([Pool Composition](/docs/2-3-pool-composition#why-several-cores-rather-than-one)). The first-person account of arriving at that conclusion is in the [Manifesto](/docs/manifesto#12-the-constraint). ### 8.5. AIMM's Mitigations | LP concern | CLMM/DLMM | AIMM | |---------|-----------|------| | **Active management** | manual | Curator-managed profiles | | **IL amplification** | range-dependent | Coverage-based (reserves change, not curve) | | **JIT exposure** | hook-mitigated | Reduced (no discrete tick crossings) | | **LP sophistication** | range-dependent | Not required | See [Toxic Flow Mitigation](/docs/1-1-6-toxic-flow-mitigation) for detailed defenses. --- ## 9. Multi-Asset Routing: Prior Art ### 9.1. The Multi-Asset Routing Problem Multi-asset pools face combinatorial explosion: N tokens require N(N-1)/2 pairs for direct trading. Prior solutions: **Approach 1: All-pairs liquidity** (Balancer) - Every pair has explicit depth - Geometric mean invariant across all assets - Capital inefficient for large N **Approach 2: Base currency routing** (Traditional FX) - All quotes relative to base (USD) - $A \to B$ trades route through $A \to \text{USD} \to B$ - Standard in foreign exchange markets **Approach 3: Graph-based routing** (DEX aggregators) - Build graph of available pairs - Find optimal path considering liquidity and fees - External computation, not pool-native ### 9.2. AIMM's Anchor Tree AIMM's answer is a **multi-anchor tree** rooted at the base token: every asset has exactly one anchor (parent), chosen for **correlation** rather than for being the numeraire, and a swap prices along the unique path via the lowest common ancestor. The depth bound, path length, leg accounting, cycle-safety conditions and fee composition are specified in [Anchor Path Pricing](/docs/1-1-3-anchor-path-pricing); what follows is only the shape of the idea and where it came from. ```mermaid flowchart TB WBTC[WBTC base] --> WETH WBTC --> USDC WETH --> stETH WETH --> weETH USDC --> USDT USDC --> DAI ``` On this tree $\text{USDT} \to \text{DAI}$ turns at USDC and never reads the WBTC mark, and $\text{stETH} \to \text{WETH}$ is a single edge off one stETH/ETH feed. That is the whole point of choosing parents by correlation. Why a tree (not a flat star): a correlated pair should be one edge with its own feed, its own $\sigma$ and its own fee floor. Forcing it through an uncorrelated numeraire adds two uncorrelated marks to a pair that has none. What the tree does **not** buy: a parent-depeg breaker. An anchored child inherits its parent's depeg risk with no automatic breaker - see [Anchor Path Pricing §7.1](/docs/1-1-3-anchor-path-pricing#71-what-reffeedid-is-and-what-it-is-not) for why `refFeedId` cannot express one. ### 9.3. Precedents This structure mirrors traditional finance: - **FX markets**: Cross-rates derived from USD pairs - **Equity markets**: Market makers quote against cash - **Crypto exchanges**: BTC or USDT as base pairs The on-chain implementation stays cheap because the path is **unique**: two walks to the lowest common ancestor, bounded by `MAX_DEPTH = 4`. No search, no candidate ranking, no path caching. ### 9.4. Benefits | Aspect | All-Pairs (Balancer-style) | Anchor Tree | |--------|---------------------------|-------------| | **Pair / pool count (deployment)** | $O(N^2)$ | $O(N)$ | | **Quote complexity (per swap)** | $O(1)$ direct, $O(N)$ to optimize | Two walks bounded by depth 4, no search | | **Capital efficiency** | Diluted | Concentrated at each anchor | | **Gas cost** | Per-pair depth | ≤ 8 legs, interiors priced at mid only | | **Adding tokens** | $N$ new pairs | 1 new edge, attached where it correlates | For the full topology, the cycle-safety conditions, the fee composition rules and the implementation, see [Anchor Path Pricing](/docs/1-1-3-anchor-path-pricing). --- ## 10. Circular/Orbital Market Makers ### 10.1. Polar Coordinate AMMs Recent research explores AMMs using polar coordinates on an n-dimensional sphere. The polar-tick mathematics and sphere/superellipse invariants below trace to [Paradigm's Orbital paper](https://www.paradigm.xyz/2024/06/orbital) and academic work on [Concentrated Circular Market Makers (CCMM)](https://arxiv.org/abs/2510.05428) (Tolstikov et al.). [Orbswap](https://orbswap.org/lite-paper) is one implementing DEX; its lite-paper presents the formulas as images and is not the canonical mathematical source - citations below are to Paradigm/CCMM. **Sphere invariant** (n stablecoins, reserves $x_i$, radius $r$): $$\sum_{i=1}^{n}(r - x_i)^2 = r^2$$ The equal-price point sits at $q = r(1 - 1/\sqrt{n})$ along the diagonal $\vec{v} = \frac{1}{\sqrt{n}}(1,\dots,1)$. Any reserve vector decomposes as $\vec{x} = \alpha\vec{v} + \vec{w}$ with $\vec{w} \perp \vec{v}$, giving the constraint $r^2 = (\alpha - r\sqrt{n})^2 + \|\vec{w}\|^2$. Instantaneous marginal price between assets $i, j$: $$\frac{\partial x_i}{\partial x_j} = \frac{r - x_j}{r - x_i}$$ **Polar ticks** are hyperplanes $\vec{x}\cdot\vec{v} = k$. On a tick boundary the pool degenerates to a lower-dimensional sphere of radius $s = \sqrt{r^2 - (k - r\sqrt{n})^2}$. Orbswap's litepaper extends this to a **superellipse** invariant for tunable concentration; v1 introduces "superellipse ticks for concentrated liquidity." ### 10.2. The Torus Model Combining an interior spherical tick with a lower-dimensional boundary sphere yields a torus: $$r_{int}^2 = (\vec{x}\cdot\vec{v} - k_{bound} - r_{int}\sqrt{n})^2 + (\|\vec{x} - (\vec{x}\cdot\vec{v})\vec{v}\| - \sqrt{r_{bound}^2 - (k_{bound} - r_{bound}\sqrt{n})^2})^2$$ > "By rotating the sphere around the circle, we obtain a single torus, or donut shape." Reported capital efficiency vs Curve for n=5 stables (per the Paradigm Orbital paper): ~15× at a 0.90 depeg threshold, ~150× at 0.99 - pegged-only in v1; LST extensions are theoretical. Risk-isolation claim (Paradigm Orbital / Orbswap litepaper): *"if one of the stablecoins depegs, the others can all trade at efficient prices, while the depegged one will become worthless much faster than a traditional AMM curve."* This is structural: the sphere geometry penalizes any single coordinate diverging far from the diagonal, so a depeg asymmetrically drains the bad asset rather than dragging the pool. ### 10.3. Why AIMM Didn't Pursue This AIMM did not adopt the construction, for three reasons: **Mathematical Complexity**: - Polar coordinate transforms add computational overhead - Torus invariants require more complex Newton iterations - Debugging and auditing more difficult **Limited Flexibility**: - Optimized for symmetric stablecoin pools - Asymmetric liquidity profiles harder to express - Assumes correlated assets (stablecoins) **LP Comprehension**: - Polar "ticks" less intuitive than price ranges - Visualization tools more complex - Position management opaque **AIMM's Alternative**: - Cartesian splines are computationally simpler - Arbitrary liquidity profiles via clamped quartic I-splines (C2 density, monotone by construction) - Direct price/depth correspondence - Easier visualization and debugging Orbital/Orbswap and AIMM occupy adjacent but distinct niches. | Dimension | Orbital / Orbswap (CCMM) | AIMM (BTR) | |---|---|---| | **Asset scope** | Pegged only (stables, can extend to LSTs at matching pegs) | Any volatility profile, mixed pools | | **Risk isolation** | Intrinsic via sphere geometry - depeg drains the bad asset | Via anchor-tree topology - per-edge bands/skew isolate a bad asset and its subtree, but share the oracle path; no parent-depeg breaker exists | | **Capital efficiency (stables)** | ~15-150× Curve at near-peg ticks | Tight-walled preset (central-normal plateau) | | **Capital efficiency (mixed-vol)** | N/A (invariant breaks for volatile pairs) | Native via anchor-path pricing | | **Multi-hop / N-asset routing** | Implicit through n-sphere | Explicit anchor-tree path (unique, ≤ 8 legs) | | **Oracle dependency** | None (curve-derived prices) | Yes (oracle mid + inventory skew) | | **Math elegance** | High - closed-form invariant | Lower - quartic I-spline + Avellaneda-Stoikov composite | | **Asymmetric depth** | Hard (sphere is symmetric) | Native via Avellaneda-Stoikov inventory skew, not a directional shape | For a pure stables / pure LST pool, Orbital is likely the better technical primitive. For mixed-volatility deployments (USDC + WBTC + WETH + LSTs together), AIMM is the only viable design here - the spherical invariant cannot price volatile-vs-pegged. Where the two **do** compete is BTR's stables-pool deployments; there Orbswap has a real edge on intrinsic depeg isolation, and AIMM compensates via oracle-sync, inventory feedback, and regime-adaptive fees rather than via geometry. --- ## 11. Spline-Based Liquidity Profiles ### 11.1. Novel Contribution AIMM's spline-based liquidity curves appear to be **novel** in DeFi AMM design: a literature search found no prior implementations of interpolating/shape-constrained splines for AMM pricing functions. ### 11.2. Mathematical Foundation AIMM uses a **clamped quartic I-spline**: the depth curve is the monotone integral of a C2 density. Fritsch-Carlson monotone cubic Hermite interpolation was considered and rejected: C1 only, with a value-discontinuity risk in the density at knots under its asymmetric tangent clamp. Properties that made the family the right choice here: - **Monotone by construction**: nondecreasing control weights (Δw ≥ 0) make the curve nondecreasing at any spline degree; a linear coefficient check replaces per-segment tangent clamps (a non-monotone segment would imply negative marginal liquidity, breaking pricing) - **C2 density**: simple interior knots at degree 4 make the density smooth at every knot; no jumps in marginal liquidity - **Local control**: moving one control weight only affects nearby segments - **Exact O(1) integration**: stored prefix integrals make VWAP cost flat in trade size ### 11.3. Advantages Over Alternatives | Curve Type | Pros | Cons | AMM Examples | |------------|------|------|--------------| | **Constant product** | Simple, proven | No concentration | Uniswap v2 | | **StableSwap** | Good for pegs | Single parameter (A) | Curve v1 | | **Concentrated ticks** | High efficiency | Active management | Uniswap v3/v4 | | **Elliptical** | Asymmetric concentration | Limited shapes | Gyroscope | | **Splines** | Arbitrary profiles | Curator trust | AIMM | Splines express profiles parametric curves cannot: - Multi-modal distributions (liquidity at multiple price points) - Flat regions with sharp edges - Asymmetric tails - Profiles fitted to historical trade density ### 11.4. Why it is affordable on chain The objection to splines in an AMM is cost. It does not bite here: the curve is stored packed, evaluation is a directory lookup plus a Horner evaluation, and a range integral is a difference of stored prefix integrals, so traversal cost is **flat in trade size** rather than scaling with the interval crossed. That is what makes an arbitrary shape competitive with a closed-form invariant. Packing, slot layout, exact gas figures and the curve mathematics: [Liquidity Shaping](/docs/1-1-2-liquidity-shaping). --- ## 12. Synthesis: How AIMM Combines Prior Art ### 12.1. Component Attribution | AIMM Feature | Primary Influence | Secondary Influence | |--------------|-------------------|---------------------| | Inventory mid-shift (reservation price) | Avellaneda-Stoikov (theory) → DODO PMM (first on-chain) | Swaap MMM | | Coverage ratio (the imbalance *metric* the mid-shift consumes) | Platypus/Wombat | | | Liability accounting | Platypus | | | Single-sided deposit into a multi-asset pool | Platypus (the mechanism) | GMX GLP (the first at scale, as a pooled index claim rather than per-leg liabilities, [§3.6](#36-shared-pool-single-sided-deposit-gmx-glp-and-gm)) | | External keeper mark (fresh per-asset) | Swaap MMM (oracle-guided) | Curve v2 (internal-oracle inspiration) | | Confidence + staleness surcharges | Novel (feed-CI + keeper-lag priced into spread) | | | Volatility fees | LFJ v2 Surge | Swaap stochastic spread | | Inventory skew on the mid | Novel (combines DODO PMM inventory shift + AS reservation price + coverage) | | | Spline profiles | Novel | Computer graphics literature | | Anchor-tree routing | FX markets | Balancer weighted pools | ### 12.2. Novel Contributions AIMM's original contributions: 1. **Symmetric multi-premium spread + inventory skew**: Volatility band + confidence + staleness surcharges (all symmetric); coverage-driven inventory skew adjusts the mid-price 2. **Spline-based liquidity profiles**: First known AMM using interpolating splines 3. **External keeper mark quoting**: pool quotes off a fresh per-asset mark (deviation-θ + heartbeat). This removes the classical stale-curve LVR channel; it does **not** remove push-latency LVR or OEV, and nothing in the protocol rebates either 4. **Coverage-aware inventory skew**: Avellaneda-Stoikov inventory adjustment via a reservation-price (mid) shift, not fee asymmetry 5. **Multi-anchor tree**: efficient multi-asset pricing without $N^2$ pairs (unique path via the lowest common ancestor, depth ≤ 4, so ≤ 8 legs) ### 12.3. Design Philosophy AIMM takes an **opinionated** stance on DeFi AMM design: > Most liquidity providers don't want to run market-making strategies. They want to deposit capital and earn yield. That drives every choice away from LP flexibility (Uniswap v3) toward curated, professionally-managed liquidity profiles. --- ## 13. RFQ & Intent-Based Protocols ### 13.1. The Intent Paradigm **Intent-based protocols** outsource execution to specialized solvers or market makers: instead of trading against an AMM, users express desired outcomes and solvers compete to fulfill them. **Key Intent/RFQ Protocols**: | Protocol | Mechanism | Centralization Point | |----------|-----------|---------------------| | **CoW Swap** | Batch auction with solver competition | Solver whitelist, off-chain matching | | **UniswapX** | Dutch auction with fillers | Filler network, off-chain discovery | | **1inch Fusion** | Auction-based order fulfillment | Resolver network, off-chain pricing | | **0x RFQ** | Request-for-quote from market makers | Market maker API, off-chain quotes | | **Hashflow** | Signed quotes from professional MMs | MM signatures, off-chain pricing | | **DeBridge** | Cross-chain intent fulfillment | Solver network, multi-chain | | **NEAR Intents** | Chain-abstracted intent execution | Relay network | ### 13.2. Tradeoffs of Intent Systems **Advantages**: - Better execution for sophisticated users - MEV protection through batch auctions - Cross-chain composability **Disadvantages**: - **Solver centralization**: Limited number of active solvers - **Off-chain dependencies**: Quote servers, APIs, signature aggregation - **Permissioned access**: Not anyone can become a solver - **Latency requirements**: Solvers need fast infrastructure - **Regulatory surface**: Identifiable entities providing quotes ### 13.3. Why AIMM Chose Not to Go This Route Intent protocols sacrifice **permissionlessness** for execution quality. AIMM maintains: - **Anyone can provide liquidity** without approval - **Anyone can trade** without solver intermediation - **No quote intermediary**: the pool prices the swap itself; the only off-chain component is the mark push ([Oracles](/docs/3-4-oracles)) - **No whitelisted counterparties**: asset listing is curated, participation is not The tradeoff: slightly worse execution during extreme conditions vs. full decentralization at all times. --- ## 14. Oracle-Based & Hybrid AMMs ### 14.1. The Oracle-AMM Design Space A parallel line of AMMs prices proactively off oracles rather than reactively off reserves, reducing LVR by quoting closer to true market value. **Oracle-Based AMM Research**: The [UAMM paper](https://arxiv.org/abs/2402.01928) ("UAMM: Price-oracle based Automated Market Maker") formalizes this design space, showing that oracle-based pricing can theoretically eliminate LVR at the cost of oracle dependency. ### 14.2. Hybrid Protocol Comparison | Protocol | Pricing Mechanism | Centralization Point | LVR Mitigation | |----------|-------------------|---------------------|----------------| | **DODO PMM** | Proactive MM with oracle | External oracle dependency | Good | | **Swaap v1** | Oracle-based stochastic spread | Chainlink/Pyth dependency | Good | | **Swaap v2** | Off-chain pricing engine | Off-chain quoter, RFQ hybrid | Excellent | | **Valantis HOT** | RFQ solver as MEV blocker | Solver whitelist | Excellent | | **Balancer Weighted (oracle)** | Oracle price feeds for weights | Oracle dependency | Moderate | | **Balancer LSD pools** | LST price feeds | Oracle dependency | Moderate | | **Bancor v2/v3** | Off-chain "fair value" feeds | Bancor-controlled oracle | Good | #### 14.2.1. DODO PMM reference formula DODO's PMM curve ([2020 whitepaper](https://dodoex.github.io/docs/docs/pmm), §3): $$ P_{excess} = i \cdot \left(1 - k + k \cdot (B_0/B)^2\right), \quad B > B_0 $$ $$ P_{deficit} = \frac{i}{1 - k + k \cdot (B/B_0)^2}, \quad B < B_0 $$ where $i$ is the oracle/market mid-price, $B$ is base reserves, $B_0$ is target base reserves (set by oracle), and $k \in [0, 1]$ controls slippage curvature. AIMM's `computeInventorySkew` is inspired by this excess/deficit symmetry but uses a piecewise-linear surrogate over coverage ratio $c$, not a quadratic over reserve ratio $B/B_0$. ### 14.3. The Oracle Dependency Problem All oracle-based designs share one vulnerability: **if the oracle fails, the AMM fails.** Failure modes: - **Oracle manipulation**: Flash loan or multi-block attacks - **Oracle latency**: Stale prices during volatility - **Oracle downtime**: No trading possible - **Oracle compromise**: Malicious price injection Hybrid designs (Swaap v2, Valantis) add solver/quoter dependency on top of this. ### 14.4. AIMM's Middle Path These designs establish that fighting price lag is what reduces LVR, so AIMM quotes at truth: the pool prices off a fresh per-asset mark pushed on a deviation band $\theta$ or a heartbeat, not off reserves and not off an internal lagging average. Feed modes, signer quorum and the per-asset depeg bands are specified in [Oracles](/docs/3-4-oracles). Two mechanisms carry the risk the mark cannot outrun: - **Coverage-driven inventory skew** moves the mid on flow between pushes ([Inventory Management](/docs/1-1-1-inventory-management)). - **Volatility, confidence and staleness terms** price the push-latency window rather than merely narrowing it ([Spread & Fees](/docs/1-1-4-spread-fees)). --- ## 15. Permissionless Design Philosophy ### 15.1. Core Principle **Permissionless operation is non-negotiable** for a DeFi primitive. Any centralization creates: - **Regulatory surface**: Identifiable operators can be compelled - **Single points of failure**: Downtime, hacks, key compromise - **Rent extraction**: Gatekeepers can extract value - **Censorship risk**: Transactions can be blocked ### 15.2. What "Permissionless" Means for AIMM | Layer | Permissionless | Details | |-------|-----------------|---------| | **Liquidity provision** | Yes | Anyone can deposit, no whitelist | | **Trading** | Yes | Anyone can swap, no KYC | | **Price discovery** | Partly: keeper-pushed | Mark signed by a k-of-n quorum, submitted by anyone; signer set governed on-chain ([Oracles](/docs/3-4-oracles)) | | **Pool creation** | Yes | Anyone can deploy pools | | **Governance** | Yes | Token-based, on-chain voting | ### 15.3. Contrast with Centralized Alternatives **Intent/RFQ Systems** (CoW, UniswapX, 1inch Fusion): - Solver/filler whitelist required - Off-chain infrastructure dependency - Centralized matching/auction **Oracle-Based AMMs** (DODO, Swaap v1, Bancor): - Oracle provider dependency - Oracle feed curation - Fallback mechanisms vary **Hybrid Systems** (Swaap v2, Valantis): - Off-chain quoter dependency - Solver/market maker whitelist - Complex trust assumptions **AIMM**: - Trading remains fully permissionless: no solver set, no market-maker whitelist, no manager lease - Pool deployment is permissionless (`createPool`); listing assets and oracle writes go through protocol Admin / AccessControl - A pool that uses EXTERNAL with an on-chain `IOracle` adapter (Uniswap, vault NAV, …) runs with **zero off-chain dependency**. INTERNAL peg mode also needs no push for the mid, but only fits cash-collateral 1:1 tokens - Pricing on the NX Rates path depends on the k-of-n signed keeper mark (timelocked signer add, immediate revoke); that is one EXTERNAL option, not a requirement - Per-asset depeg bands against a second BTR-operated reference feed on a distinct oracle address; no third-party oracle-network quote dependency ### 15.4. Implications for Resilience - **No regulatory chokepoint**: No single entity to subpoena - **Bounded key compromise**: privileged keys are scoped and revocable - a k-of-n oracle signer set with immediate revoke, and parameter changes queued through `Admin.requestOp` timelocks - **Bounded feed downtime**: a stalled mark is priced through the staleness premium; once the feed TTL expires, legs on that feed fail closed rather than quoting a stale price - **Geographic resilience**: Works from any jurisdiction - **Censorship resistance**: No transaction filtering --- ## 16. Acknowledgments AIMM builds on decades of research: **Academic Foundations**: - Avellaneda & Stoikov (2008): "High-Frequency Trading in a Limit Order Book," *Quantitative Finance* 8(3), [DOI:10.1080/14697680701381228](https://doi.org/10.1080/14697680701381228) · [Cornell mirror](https://people.orie.cornell.edu/sfs33/LimitOrderBook.pdf) - Guéant, Lehalle & Fernandez-Tapia (2012): [Optimal Portfolio Liquidation with Limit Orders](https://arxiv.org/abs/1206.4810) - Fritsch & Carlson (1980): Monotone Piecewise Cubic Interpolation, *SIAM J. Numer. Anal.* 17(2) - Parkinson (1980): "The Extreme Value Method for Estimating the Variance of the Rate of Return," *Journal of Business* 53(1) - Garman & Klass (1980): "On the Estimation of Security Price Volatilities from Historical Data," *Journal of Business* 53(1) - Milionis, Moallemi, Roughgarden & Zhang (2022): [Automated Market Making and Loss-Versus-Rebalancing](https://arxiv.org/abs/2208.06046); see also the [CowSwap LVR exposition](https://docs.cow.fi/cow-amm/concepts/the-problem-of-lvr) **DeFi Protocols**: - [Uniswap](https://uniswap.org): Constant product AMMs, concentrated liquidity - [Curve Finance](https://curve.fi): StableSwap, Cryptoswap, internal oracle - [Platypus Finance](https://platypus.finance): Asset-Liability Management - [Wombat Exchange](https://wombat.exchange): Coverage ratio stableswap - [Swaap Finance](https://swaap.finance): Oracle-guided, stochastic spread - [Gyroscope](https://gyro.finance): Elliptic CLPs, passive curator model - [LFJ (Trader Joe)](https://lfj.gg): Liquidity Book, surge pricing - [Paradigm](https://paradigm.xyz): Orbital AMM research **Research**: - [Milionis et al.](https://arxiv.org/abs/2208.06046): LVR formalization - [Adams et al.](https://uniswap.org/whitepaper-v3.pdf): Concentrated liquidity - [Egorov](https://curve.fi/files/crypto-pools-paper.pdf): Cryptoswap --- ## 17. Further Reading - [AIMM Architecture](/docs/1-overview), System architecture - [Manifesto](/docs/manifesto), Vision and value proposition - [Spread & Fees](/docs/1-1-4-spread-fees), Symmetric vol + confidence + staleness fee model - [Oracles](/docs/3-4-oracles), External keeper-mark feed design - [Liquidity Shaping](/docs/1-1-2-liquidity-shaping), Spline profiles - [Toxic Flow Mitigation](/docs/1-1-6-toxic-flow-mitigation), Defense mechanisms --- ## 18. Capital efficiency A BTR pool holds 5-15 blue-chip assets in one contract, so one reserve backs every market its asset participates in instead of being split across pair pools. This section quantifies what that sharing is worth: it defines a volume-per-capital metric, derives depth per dollar for a pair-pinned concentrated-liquidity venue and for a BTR pool, then composes the two with contention, cross-pair routing and mark-sync effects. The output is a range with its assumptions stated, not a headline multiplier. ### 18.1. Volume capital ratio (VCR) $$ \mathrm{VCR}(S)=\frac{V(S)}{T} $$ | Symbol | Meaning | |--------|---------| | $T$ | Total TVL (USD) across the venue | | $V(S)$ | Expected 24h volume at average slippage $S$ | | $N$ | Number of listed assets | | $P$ | Number of directed markets | | $D_{ij}$ | USD notional of asset $j$ available vs $i$ before slippage exceeds $S$ | | $S$ | Slippage threshold | | $w_{ij}$ | Volume weight on market $(i,j)$ | | $f$ | Venue slippage function | Aggregate: $$ \mathrm{VCR}(S)\approx\sum_{i,j} w_{ij}\, f(D_{ij}, S) $$ For small $S$ under constant-product, $f(D,S)\approx D\,S$. Shared inventory changes $D_{ij}$. ### 18.2. UniV3 baseline (pair-pinned) With $N$ assets, UniV3 needs $P=N(N-1)/2$ pair pools. Even TVL split: $$ T_p=\frac{2T}{N(N-1)},\qquad D_{ij}=\frac{T}{N(N-1)} $$ | Symbol | Meaning | |--------|---------| | $T_p$ | TVL per pair pool | | $D_{ij}$ | Per-side depth on pair $(i,j)$ before concentration | Active-range factor $\alpha\in[1,\infty)$ (often $5$-$50\times$ on blue chips) multiplies one pair only: $$ D_{ij}^{V3}=\alpha\cdot\frac{T}{N(N-1)} $$ ### 18.3. BTR pool (shared inventory) One pool, $N$ assets, even split: $R_i=T/N$. Anchor-path pricing quotes every directed pair off a common tree ([Pricing](/docs/1-1-3-anchor-path-pricing)). For the base token $h$ (e.g. USDC), depth on $(h,j)$ is the full $R_h=T/N$, independent of $j$ (subject to §18.5): $$ D_{hj}^{\mathrm{BTR}}=\alpha'\cdot\frac{T}{N} $$ | Symbol | Meaning | |--------|---------| | $R_i$ | Reserves of asset $i$ | | $h$ | Base token (numeraire) | | $\alpha'$ | Pool concentration factor (near mark; comparable to UniV3 $\alpha$ on blue chips) | Holding $\alpha'\approx\alpha$, under base-token flow: $$ \frac{D_{hj}^{\mathrm{BTR}}}{D_{hj}^{V3}}=\frac{T/N}{T/(N(N-1))}\approx N-1 $$ Indicative: $N=5$ → $\sim 3$-$5\times$; $N=10$ → $\sim 5$-$10\times$; $N=15$ → $\sim 8$-$14\times$ (before contention discount). ### 18.4. Numerical example: N = 5, T = $1B Assets: USDC (base token), WBTC, WETH, SOL, BNB. Even split. | Quantity | UniV3 | BTR pool | |---|---|---| | Pool count | 10 | 1 | | TVL per pool | $\$100\mathrm{M}$ | $\$1\mathrm{B}$ | | USDC per USDC-pair | $\$50\mathrm{M}$ | $\$200\mathrm{M}$ (shared) | | Base-pair direct depth | $\$50\mathrm{M}\times\alpha$ | $\$200\mathrm{M}\times\alpha'$ | | Base-pair multiplier | $1\times$ | $\sim 3$-$5\times$ | | Cross pair (WBTC-SOL) | 1 pool, 1 fee, 1 slip | 2-hop in one pool, 1 fee, 1 contract | Per-asset reserves match ($\$200\mathrm{M}$ USDC either way). The multiplier removes an artificial partition; it does not invent capital. ### 18.5. Contention The $(N-1)\times$ multiplier assumes non-concurrent trades. Aggregate outflow of the base token in one block is still capped at $R_h=T/N$. If concurrent sizes $S_1,S_2$ hit two base-token pairs, the second trade sees $R_h-S_1$ and quotes with skew. Expected-case multiplier stays near $(N-1)$; worst-case concurrent drain on every base-token pair goes toward $1\times$. Indicative hold: $\sim 70$-$90\%$ of nominal under realistic flow. ### 18.6. Cross-pair routes UniV3 often routes $X\to\mathrm{USDC}\to Y$ across two pools (2 fees, 2 slips, extra gas). A BTR pool does $X\to Y$ along one anchor-tree path in one call (1 fee, 1 slip event, interior legs at mid without impact). On a $100\,\mathrm{bp}$ slip budget, fee drag alone is typically lower on the single-pool path. ### 18.7. Oracle sync A mark push re-prices every spoke in the same block. UniV3 pools are arbed individually after an external move (LVR to LPs). Classical CFMM LVR scales like $\sigma^2\alpha/8$ per unit time (Milionis et al.); quoting at the mark cuts the stale mid channel. Treat fee-margin uplift as $\beta_o\in[1.0,1.3]$ in §18.8 (conservative). ### 18.8. Composition $$ \frac{E_{\mathrm{BTR}}}{E_{V3}}\approx\beta_o\Bigl(w_h\cdot(N-1)\cdot\gamma_c+w_n\cdot\mu_h\Bigr) $$ | Symbol | Meaning | |--------|---------| | $E$ | Effective execution / VCR proxy | | $w_h$, $w_n$ | Base-token vs cross volume weights ($w_h+w_n=1$) | | $\gamma_c$ | Contention discount $\in[0.5,1]$ (typical $0.7$-$0.9$) | | $\mu_h$ | Cross-pair fee+gas multiplier $\in[0.8,1.3]$ | | $\beta_o$ | Oracle-sync fee-margin uplift $\in[1.0,1.3]$ | Example ($w_h=0.7$, $N=5$, $\gamma_c=0.8$, $\mu_h=1.2$, $\beta_o=1.2$): $$ \frac{E_{\mathrm{BTR}}}{E_{V3}}\approx 1.2\cdot(0.7\cdot 4\cdot 0.8+0.3\cdot 1.2)\approx 3.1\times $$ ### 18.9. Scenario table Under $w_h\approx 0.7$, $\gamma_c\approx 0.8$, $\mu_h\approx 1.2$, $\beta_o\approx 1.2$: | $N$ | Approx. uplift | Base-pair raw ($\approx N-1$) | |-----|----------------|------------------------------| | 3 | $\sim 2$-$3\times$ | $\sim 2$-$3\times$ | | 5 | $\sim 3$-$5\times$ | $\sim 3$-$5\times$ | | 10 | $\sim 5$-$10\times$ | $\sim 5$-$10\times$ | | 15 | $\sim 8$-$14\times$ | $\sim 8$-$14\times$ | TVL-invariant by construction. Absolute depth scales with $T$. Concurrent multi-pair drains compress toward $1\times$. ### 18.10. Other venues | Venue | Topology | Shared inventory | Base-pair depth ($N=5$, $T=\$1\mathrm{B}$) | |---|---|---|---| | UniV3 | $N(N-1)/2$ pairs | No | $\$50\mathrm{M}\times\alpha$ | | UniV4 | Shared storage, isolated pools | No | $\$50\mathrm{M}\times\alpha$ | | Curve V2 | Basket (typically $\le 8$) | Yes within basket | $\sim\$200\mathrm{M}$ (stableswap) | | Balancer Weighted | Weighted basket | Yes within basket | Weight-dependent | | **BTR pool** | Anchor tree, $N=5$-$15$ | **Yes** | **$\$200\mathrm{M}\times\alpha'$** | UniV4 shares storage, not liquidity. Curve/Balancer share inventory under different invariants. BTR combines basket sharing with mark-anchored depth. ### 18.11. Summary Base-token pair depth scales $\approx(N-1)\times$ against pair-pinned CL under base-token flow. Composed with cross-pair routing and mark sync, indicative VCR uplift for $N=5$-$15$ is roughly $3$-$10\times$ (deployment-dependent). The contention bound holds: per-block outflow of an asset remains capped at $T/N$. --- ## 19. AMM landscape This section places BTR against the AMMs it borrows from and competes with, on dimensions that can be read off code or public on-chain activity: topology, capital efficiency, LVR exposure, oracle dependency, execution and operations. It then covers the Solana proprietary-AMM cohort, which shares BTR's design intent but not its cost environment, and closes with a mapping from each peer mechanism to its closest BTR analogue. The case for the design, as opposed to the comparison, is in the [Manifesto](/docs/manifesto). ### 19.1. Comparison matrix Legend: **CE** = capital efficiency at peg / in-distribution. **LVR** = loss-versus-rebalancing exposure. **Async** = whether trade splitting changes total fill (path-dependence). **+Asset** = marginal cost to add an Nth asset. **Anchor** = mark / oracle dependency. Spot venues only. Perpetuals venues are compared separately in [§3.6](#36-shared-pool-single-sided-deposit-gmx-glp-and-gm), because a pool whose providers are counterparty to leveraged trader profit and loss does not have a meaningful reading on CE at peg, LVR or async fills, and forcing one into these columns would invent numbers rather than compare them. #### 19.1.1. Topology | Protocol | Max assets | Asset fit | +Asset cost | Permissioning | |---|---|---|---|---| | **Uniswap V2** [^1] | 2 | any | New pair deploy | Permissionless | | **Uniswap V3** [^2] | 2 | volatile-tuned | New pool + fee tier | Permissionless | | **Uniswap V4** [^3] | 2 (singleton vault) | any | Cheap pool clone | Permissionless + hook curation | | **Curve V1 Stableswap** [^4] | 2-4 (8 max) | stable peg | New pool + gauge | Permissionless + gauges | | **Curve V2 Cryptoswap** [^5] | 3 typical | volatile mixed | New pool | Permissionless | | **Balancer V2/V3** [^6] | 8 weighted / 5 stable | mixed weighted | New pool | Permissionless | | **DODO V1/V2 (PMM)** [^7] | 2 | any | New pool | Curated PMM + permissionless | | **Maverick V1/V2** [^8] | 2 | volatile | New pool | Permissionless | | **LFJ Liquidity Book** [^9] | 2 | volatile-tuned | New pool | Permissionless | | **Platypus** [^10] | 5-15 singleton | stable | `addAsset` | Curated add-asset | | **Wombat** [^11] | 5-15 singleton | stable + LST | `addAsset` | Curated | | **OrbSwap (CCMM)** [^12] | ~10-50 practical | stable / pegged | `addAsset` | Permissionless | | **BTR** | 5-15 (anchor tree) | stable + LST + blue-chip | `addAsset` spoke | Curated whitelist | #### 19.1.2. Pricing and risk | Protocol | CE (in-dist.) | LVR | Oracle dep. | Regime adaptation | Depeg robustness | |---|---|---|---|---|---| | **Uniswap V2** [^1] | Low (full-range) | High (constant fee) | None | None (immutable) | Peg-agnostic (isolated) | | **Uniswap V3** [^2] | High in-range; 0 OOR | Per-tick; JIT-exposed | None | Per-LP manual rebalance | Isolated | | **Uniswap V4** [^3] | V3 + hook-extensible | V3 unless hook mitigates | Optional (hooks) | Hook-driven | Isolated | | **Curve V1 Stableswap** [^4] | Very high near peg | Low at peg; high off-peg | None | Slow `A` governance | Joint invariant (cascade) | | **Curve V2 Cryptoswap** [^5] | High near EMA | High on repeg | Internal EMA | EMA repeg + admin γ/A | Repeg permanent loss | | **Balancer V2/V3** [^6] | Moderate (geomean) | High (constant weights) | None / optional hooks | None / hook-driven | Proportional absorption | | **DODO V1/V2 (PMM)** [^7] | High (mid-concentrated) | Moderate (oracle mid) | Hard (Chainlink) | Static admin re-param | Oracle halt on deviation | | **Maverick V1/V2** [^8] | Very high (mode bins) | Lower (auto-shift) | None | Mode auto-rebalance | Isolated | | **LFJ Liquidity Book** [^9] | Very high (bins) | Lower (surge fee) | None | Vol-reactive fee | Isolated | | **Platypus** [^10] | Very high (coverage) | Low at c=1; high under-covered | Hard (Chainlink) | Static governance | Joint solvency risk [^10] | | **Wombat** [^11] | Very high | Same family as Platypus | Hard | Static governance | Per-asset isolated | | **OrbSwap (CCMM)** [^12] | Very high in polar tick | Bounded by tick width | None (math) | Static immutable | Math-isolated per asset | | **BTR** | High (spline + σ-disp) | Priced (premiums + skew) | EXTERNAL keeper mark | Algorithmic σ/skew + timelock spline | Per-asset halt; no cross-amplify | #### 19.1.3. Execution and ops | Protocol | Path-indep. | Composability | MEV surface | LP onboarding | TVL / age | Gas / swap | |---|---|---|---|---|---|---| | **Uniswap V2** [^1] | Yes | Cross-contract hops | Sandwich, JIT-light | Trivial deposit ratio | $1B+ / 5y | ~100k | | **Uniswap V3** [^2] | Yes | Cross hops + tick crossings | Sandwich, JIT-pro | Range selection | $4B+ / 4y | ~120-200k | | **Uniswap V4** [^3] | Yes | Singleton flash accounting | V3 + hook-specific | Hook cognitive load | $1B+ / 1y | ~80-150k | | **Curve V1 Stableswap** [^4] | Yes | Metapool / router | Sandwich, depeg cascade | Proportional deposit | $2B+ / 5y | ~150-250k | | **Curve V2 Cryptoswap** [^5] | Yes | Router | Repeg MEV | Tri-asset proportional | $500M+ / 3y | ~250-400k | | **Balancer V2/V3** [^6] | Yes | Vault batch + flash | Sandwich, weight-arb | Deployer weight choice | $800M+ / 4y | ~150-300k | | **DODO V1/V2 (PMM)** [^7] | Yes | Per-pair | Oracle stale MEV | i + k params | $50M+ / 4y | ~120-180k | | **Maverick V1/V2** [^8] | Yes | Per-pool | Sandwich, mode-flip | Mode choice | $100M+ / 2y | ~150-250k | | **LFJ Liquidity Book** [^9] | Yes | Bin-routed | Bin-jump, surge gaming | Bin selection | $50M+ / 2y | ~150-300k | | **Platypus** [^10] | Yes | Singleton all-to-all | Oracle + coverage arb [^10] | Single-sided | $30M post-exploit / 3y | ~100-150k | | **Wombat** [^11] | Yes | Singleton all-to-all | Same family | Single-sided | $80M+ / 3y | ~100-150k | | **OrbSwap (CCMM)** [^12] | Yes | Singleton orbital | Sandwich in tick | Polar tick selection | Early / 2025 | High (n-dim) | | **BTR** | Yes | Anchor tree (≤8 legs) | Truth quoting + dyn fees | Single-sided, no range | New / 2026 | ~168-199k measured | ### 19.2. Per-peer summaries **Uniswap V2** [^1] - `x·y=k` two-asset CPMM, full-range LP. Trivially path-independent, gas-cheap, zero parameter risk. Capital-inefficient (most TVL idle far from spot), high unpriced LVR. Still dominant for long-tail pairs because deployment friction is zero. **Uniswap V3** [^2] - Tick-based concentrated liquidity. LP nominates a price range; in-range behaves as local CPMM. Massive in-range CE, but out-of-range = 0 active liquidity; manual rebalance; JIT bots professionalized fee extraction. **Uniswap V4** [^3] - Singleton `PoolManager` + hooks + flash accounting + native ETH. Pool math is V3; the delta is (a) one contract holds all pool state → cheaper multi-hop / flash loans, (b) hooks can rewrite fee logic and even curves. **Per-pool logic is still pair-isolated**: no shared inventory across pairs in the singleton. Hooks fragment liquidity by configuration. **Curve V1 (Stableswap)** [^4] - Hybrid invariant flattens to constant-sum near peg, bends to constant-product far from it; `A` controls flat-region width. Up to 8 assets, 2-4 typical. Joint invariant: one asset depeg drains the pool across all assets to varying degrees (UST May 2022 - pool fully cratered; USDC March 2023 SVB - 3pool drained but recovered within days). **Curve V2 (Cryptoswap)** [^5] - Stableswap + EMA price oracle + dynamic repeg governed by `γ` damping + PnL accounting. Tri-volatile around a slowly-drifting internal anchor. Capital-efficient near EMA peg; off-peg execution poor; repeg events incur permanent loss. **Balancer V2/V3** [^6] - Weighted geomean invariant up to 8 assets, plus stable / composable-stable variants. V2's Vault is a singleton storage layer; per-pool math is still pairwise (no shared liquidity across pools in the Vault). V3 adds hooks. **DODO V1/V2 (PMM)** [^7] - Proactive Market Maker uses Chainlink anchor `i` + slip coef `k`. Accuracy depends on oracle freshness. `k=0` → CSMM, `k=1` → CPMM. Parameters static post-deploy; no regime adaptation. **Maverick V1/V2** [^8] - Two-asset CL with **mode-based auto-rebalance**: Static (V3-like), Right/Left (bins trail directional moves), Both (symmetric trail). Pool itself shifts LP bins on each swap, removing manual rebalance. Pair-isolated. **LFJ Liquidity Book** [^9] - Discrete price bins, each bin a local CSMM. LP positions fungible per-bin. Variable fee accumulator surges spreads under realized vol. Halfway between V3 ticks and an order book. **Platypus** [^10] - Singleton stable AMM with **coverage ratio** (`assets/liabilities`) per token driving slippage. Single-sided deposits, `addAsset` cheap. Original asset-liability AMM. Feb 16 2023 ~$8.5M flash-loan exploit - root cause: `emergencyWithdraw` in `MasterPlatypus` did not check outstanding USP debt, allowing the attacker to withdraw collateral while leaving USP minted against it. Coverage-mechanism arbitrage demonstrated joint-solvency risk. **Wombat** [^11] - Platypus fork with per-asset isolation: each asset has its own coverage curve, ringfencing per-asset solvency. Same coverage-slippage family; extended to LSTs. **OrbSwap (CCMM, Orbital)** [^12] - Polar-coordinate / n-sphere AMM (Paradigm research). Pegged assets sit on an n-dim sphere; per-asset "polar tick" lets one asset exit the sphere on depeg without dragging the rest, giving **mathematical isolation**. Pre-production; verification cost scales with N. **BTR** - Each BTR pool is a curated **multi-asset singleton** (5-15 blue-chip target: stables, LSTs, ETH, BTC, majors). Pipeline: (1) keeper mark (fresh per-asset `mark1e18`, pushed on deviation-θ + heartbeat; removes classical curve LVR, not push-latency LVR or OEV); (2) coverage-based **inventory skew** adjusts mid (inspired by Platypus + Avellaneda-Stoikov); (3) **spline-shaped depth** (clamped quartic I-spline, C2 density, preset curves) with vol-scaled dispersion for market impact; (4) symmetric spread = vol band + confidence + staleness surcharges around adjusted mid (no directional term); (5) **multi-anchor tree pricing**: each asset quotes against its own anchor (its correlated parent, not necessarily the base), and a swap prices along the unique path via the lowest common ancestor, depth ≤ 4 and therefore ≤ 8 legs, endpoints settling and interiors priced at mid with skew (no path search, vs Curve V2 / Wombat pairwise / multi-hop routing cost). **EXTERNAL-mark feed**: keeper mark primary for quoting, with a per-asset agreement band against a second attestation of the same pair and a base-token parity halt ([Oracles](/docs/3-4-oracles)). **Capital-efficiency multiplier**: one USDC unit counterparties N pairs simultaneously through shared base-token inventory; depth-per-dollar scales with asset count instead of fragmenting across N(N-1)/2 pairs. Regime adaptation is **algorithmic** (dispersion ← σ; skew ← coverage) plus **admin-mutable spline** under timelock. `addAsset` attaches one new edge in one call. ### 19.3. Where BTR wins, where BTR loses **BTR's niche: blue-chip multi-asset singleton with regime-adaptive policy.** - **Multi-asset composability**: anchor-tree pricing executes USDC→stETH, DAI→WBTC etc. in one swap inside one contract (at most 8 legs, only the endpoints settling) - no router fanout, no per-hop slip stacking, since interior legs price at mid without impact. Uniswap V4's singleton lowers gas but still traverses pair-pools sequentially. The anchor tree collapses N(N-1)/2 pair routing to one bounded path. - **Add-asset cost**: `addAsset` call (Platypus/Wombat lineage) vs. full pool deployment (Uniswap / Curve / Balancer). Nth asset is O(1). - **Regime adaptation**: spline + vol-scaled dispersion + coverage-driven skew updates on every swap. Curve V1 needs governance to rotate `A`; Curve V2 repegs parametrically but lossily; Uniswap is static unless hook-mediated; Platypus/Wombat curves are static. - **Policy flexibility against DODO and Platypus**: explicit symmetric multi-premium fees (vol + confidence + staleness) + admin-mutable spline vs. DODO's static `i/k` and Platypus's static slip function. - **Density-shaping range (a capability of the maths, not a measured capture)**: the depth density is a free per-asset choice (integral of a chosen monotone C2 density), not a fixed invariant. Offset resolution is 1 pbps (0.01 bp, ~100x finer than a Uniswap v3 1-bp tick); the wall $W$ is continuous below 0.5 bp; tails are hard-cut at $\pm W$ by construction (100% of capital inside the band, no stranded depth) where constant-product and Curve have unbounded support. This is a claim about depth, not about realized fee capture. Detail: [Liquidity Shaping §4](/docs/1-1-2-liquidity-shaping#4-preset-central-normal-plateau). - **Behind Curve V1 on stable-stable in-peg**: amplified invariant gives marginally better near-peg execution for pure stable pairs at scale, with 5+ years of audit hardening and mature gauge incentives. BTR competes on multi-asset breadth and adaptivity, not single-purpose peg concentration. - **Behind Uniswap V3/V4 on the long tail**: permissionless pair deployment + tick model fits unknown / experimental pairs better than a curated blue-chip singleton. Long-tail is correctly served by V3/V4. - **Behind OrbSwap on mathematical isolation**: orbital geometry gives provable per-asset depeg isolation; BTR uses an operational depeg-halt circuit breaker. ### 19.4. Architectural cheat sheet | Protocol | Pipeline | Character | |----------|----------|-----------| | Uniswap V2 | reserves → invariant → price | static, 2 assets | | Uniswap V3/V4 | reserves + ticks → local CPMM → price | static, 2 assets, manual range | | Curve V1 | reserves + A → amplified invariant → price | static-A, N stables, joint risk | | Curve V2 | reserves + A,γ + EMA → repegged invariant → price | param-EMA, 3 volatile, repeg loss | | Balancer | reserves + weights → geomean invariant → price | static-weights, ≤8 assets | | DODO | oracle + i,k → PMM price | static, 2 assets, oracle-anchored | | Maverick | bins + mode → auto-shifted CL → price | mode-static, 2 assets | | LFJ LB | bins + var-fee → discrete CSMM → price | vol-reactive, 2 assets | | Platypus | reserves + coverage → slip fn → price | static, N stables, joint risk | | Wombat | reserves + per-asset coverage → slip fn → price | static, N stables, isolated | | OrbSwap | n-sphere + polar tick → price | static, N pegged, math-isolated | | BTR | keeper mark + coverage skew + spline σ-disp + sym vol/conf/stale fee | adaptive, N blue-chip, anchor-tree | ### 19.5. PropAMMs (proprietary oracle AMMs): the Solana frontier The peers in §19.1 are public-invariant AMMs. One high-performing class sits outside that matrix: **PropAMMs** (also called proprietary or "dark" AMMs), on-chain programs that replace a fixed bonding curve with **active, model-based quoting** driven by an off-chain pricing engine. Industry write-ups (Jump Crypto, Solana Foundation, Chorus One) describe the same pattern: fair-value estimation off-chain → frequent on-chain parameter/oracle pushes → executable liquidity that behaves like a colocated market maker inside the DEX. The current Solana leaders are **BisonFi, HumidiFi, Tessera, and SolFi**; the broader set includes **Obric, ZeroFi**, and **Lifinity** [^13] (the first Solana oracle DEX, quoting off Pyth). They are the closest analogues to BTR's *design intent*, so the landscape has to place BTR against them, not only against Uniswap and Curve. On EVM, **Swaap v2** [^18] sits very close to the same definition, an oracle/RfQ-referenced market-making AMM with vol-scaled pricing. The difference is transparency: Swaap publishes a whitepaper; the Solana PropAMM cohort generally does not. #### 19.5.1. Microstructure: PropAMM against BTR | Dimension | Typical Solana PropAMM | BTR (code) | |---|---|---| | Fair value | Off-chain model → push mark/params every slot or sub-second | Keeper mark via `ExternalOracle.batchPushSigned` (k-of-n; NXR REST → deviation-θ + heartbeat) | | Inventory | Private MM inventory; often opaque to LPs | On-chain assets/liabilities → coverage skew (Platypus/Wombat lineage + Avellaneda-Stoikov reservation) | | Depth / size response | Closed-source; empirically near size-invariant spreads on majors | On-chain quartic I-spline preset curves + vol-scaled dispersion (`Pricing` / `NUQuartic`) | | Spread | Model-driven; often sub-bps on SOL majors at small size | Symmetric vol + confidence + staleness surcharges around skewed mid (`minFeePath` floor in PBPS) | | Multi-asset | Usually pair-isolated programs | Multi-asset singleton + multi-anchor tree (unique path via the LCA) | | Transparency | Closed method; open on-chain footprint only | Open contracts + docs; method is the product ([Manifesto §2.6](/docs/manifesto#26-the-transparency-thesis)) | | Chain economics | ~400 ms slots, ~$0.0001 fees → high push cadence viable | EVM gas → θ/heartbeat, not brute-force Hz | Canonical pricing pipeline (do not duplicate here): [Inventory Management](/docs/1-1-1-inventory-management) → [Liquidity Shaping](/docs/1-1-2-liquidity-shaping) → [Anchor Path Pricing](/docs/1-1-3-anchor-path-pricing) → [Spread & Fees](/docs/1-1-4-spread-fees). #### 19.5.2. What they are - **Oracle-referenced pricing, not a fixed invariant.** Like BTR pools, they replace the constant-function curve with a curve *centered on an imported mark*. Lifinity quotes off Pyth; the proprietary cohort computes quote math **off-chain** and pushes parameters on-chain. - **Very high push cadence.** The defining edge is update frequency: reported on-chain metrics put HumidiFi around **17-75 parameter updates per second** (peaks near 74×, on the order of ~143 compute units per update), with peers in the ~10-13× range (SolFi ~13, Tessera ~11, ZeroFi ~10). - **Economical only on Solana.** That cadence is affordable because Solana offers ~400 ms slots and ~$0.0001 fees. The edge is **latency-and-cost-bound to that environment.** **Proprietary, but observable in behavior.** The quoting algorithm is closed. The on-chain footprint is not: update frequency, quoted spread and size-response curve are all measurable from public activity. The cadence and spread figures above are third-party observations of that footprint, and carry no claim about the algorithm producing them. #### 19.5.3. Why BTR stays competitive on EVM - **Their cadence edge does not port to EVM, and BTR does not try to match it.** A naive EVM re-implementation (2-12 s blocks, higher gas) cannot brute-force 74 updates/second; that specific edge is Solana-native and would be uneconomic to copy on Ethereum or its L2s. - **But the *core* oracle-AMM advantage is structural, not latency-bound.** Quoting off an imported mark, rather than a stale, reserve-derived price, is what eliminates the CFMM's stale-price LVR channel. The oracle-AMM literature shows optimized oracle AMMs beat CFMMs for LPs **even with a lagged oracle**, under adverse selection and systematic arbitrage (Milionis et al. [^14]; Bergault et al. [^15][^16]). Higher gas and slower blocks lengthen the *lag term*; they do not remove the structural LVR reduction. BTR inherits the structural advantage without needing the cadence. - **Deviation-θ + heartbeat is the correct gas-aware EVM adaptation.** Instead of brute-forcing frequency, BTR pushes a fresh mark only when it deviates past a per-asset band θ or a heartbeat elapses. This bounds oracle lag *cheaply*, the gas-aware analogue of the Solana cohort's high-frequency push. Between pushes, inventory skew (an Avellaneda-Stoikov reservation price [^17] around the frozen mark) keeps the pool repricing on flow, so the curve is not static between updates. - **The depth curve itself is recalibratable on-chain.** Curves live in a shared per-pool preset table of quartic I-splines that assets point into by `presetId`; between refits, live quotes scale the curve linearly by `dispersion / dispRefPbps`, so width tracks volatility with no governance action. Two timelocked levers queue through `Admin.requestOp`: `UPDATE_CURVE` refits a shared preset in place and propagates to every asset pointing at it, `UPDATE_PROFILE` repoints one asset at a different preset and dispersion band. Both change pricing shape only; reserves, liabilities and coverage are untouched. Shipped preset contents and the refit-versus-repoint cadence: [Liquidity Shaping](/docs/1-1-2-liquidity-shaping). In summary: BTR concedes the raw push-cadence race on Solana's terms and competes where the durable advantage lives, the structural LVR reduction of oracle-centered quoting, delivered gas-efficiently on EVM, plus multi-asset breadth (§19.1) and an open, verifiable method ([Manifesto §2.6](/docs/manifesto#26-the-transparency-thesis)). ### 19.6. Uniswap V3/V4, DODO, Wombat, Curve: pricing analogies Deep mechanics stay in the linked pricing pages. | Peer mechanism | Closest BTR analogue | Deliberate difference | |---|---|---| | **Uniswap V3** ticks / in-range CPMM | Quartic I-spline preset curve = continuous depth schedule around mark | No LP-chosen ranges; admin/timelock presets, shared multi-asset inventory | | **Uniswap V4** singleton + hooks | One Pool contract holds N assets; `Flash` singleton for loans | Still not pair-isolated CL math; hooks ≠ BTR pool policy (policy is native) | | **DODO PMM** `i` + `k` | Keeper mark ≈ `i`; spline/dispersion ≈ size impact (`k`) | Dynamic σ/confidence/staleness + coverage skew; not static post-deploy `i/k` | | **Curve V1** amplified stable invariant | Near-peg CE via tight stable spline + low `minFee` | No joint amplified invariant → no UST-style cross-asset drain; depeg halt per asset | | **Curve V2** EMA repeg | External mark replaces internal EMA | No repeg PnL accounting; mark is pushed truth, not slow internal oracle | | **Wombat / Platypus** coverage slip | Coverage ratio skews **mid** (reservation), not a static slip fn alone | Skew + spline + multi-premium spread; star routing vs pairwise / multi-hop routing cost | | **PropAMM** (Solana) off-chain quote engine | Same *intent*: quote at truth, shrink LVR | Open on-chain method + EVM θ/heartbeat; multi-asset singleton | Raydium AMM v4 / CPMM (Solana constant-product, historically hybrid with OpenBook) is a classical CFMM peer, closer to Uniswap V2 than to BTR; CLMM is the V3 analogue. It is omitted from the §19.1 matrix to avoid diluting the oracle-AMM comparison; treat it as V2/V3-class for pricing purposes. ### 19.7. References [^1]: Adams, H. *Uniswap V2 Core* (2020). https://uniswap.org/whitepaper.pdf [^2]: Adams, H. et al. *Uniswap V3 Core* (2021). https://uniswap.org/whitepaper-v3.pdf [^3]: Uniswap Labs. *Uniswap V4 Core* (2024). https://github.com/Uniswap/v4-core [^4]: Egorov, M. *StableSwap - efficient mechanism for Stablecoin liquidity* (2019). https://docs.curve.finance/assets/pdf/stableswap-paper.pdf [^5]: Egorov, M. *Automatic market-making with dynamic peg* (2021). https://docs.curve.finance/assets/pdf/whitepaper.pdf [^6]: Balancer Labs. *Balancer V2 Vault* / *V3 Hooks* (2021, 2024). https://docs.balancer.fi/ [^7]: DODO Team. *DODO: A Next-generation On-chain Liquidity Provider Powered by PMM* (2020). https://docs.dodoex.io/ [^8]: Maverick Protocol. *Maverick AMM Whitepaper* (2022). https://docs.mav.xyz/ [^9]: Trader Joe / LFJ. *Liquidity Book Whitepaper* (2022). https://docs.lfj.gg/concepts/concentrated-liquidity [^10]: Platypus Finance. *Platypus: An Open Liquidity Pool Protocol for Stableswap* (2021). https://cdn.platypus.finance/Platypus_Finance_Whitepaper.pdf [^11]: Wombat Exchange. *Wombat: 4th-Gen Multichain-Native Stableswap* (2022). https://docs.wombat.exchange/ [^12]: Paradigm / OrbSwap. *Orbital AMM Lite Paper* (2025). https://orbswap.org/lite-paper [^13]: Lifinity. *Proactive Market Making on Solana* (docs). https://docs.lifinity.io/ [^14]: Milionis, J., Moallemi, C. C., Roughgarden, T., Zhang, A. L. *Automated Market Making and Loss-Versus-Rebalancing* (2022). https://arxiv.org/abs/2208.06046 [^15]: Bergault, P., Bertucci, L., Bouba, D., Guéant, O. *Automated Market Makers Designs beyond Constant Functions* (2022). https://arxiv.org/abs/2212.00336 [^16]: Bergault, P., Bertucci, L., Bouba, D., Guéant, O. *Price-Aware Automated Market Makers: Models Beyond Brownian Prices* (2024). https://arxiv.org/abs/2405.03496 [^17]: Avellaneda, M., Stoikov, S. *High-frequency trading in a limit order book*. Quantitative Finance 8(3), 217-224 (2008). [^18]: Swaap Labs. *Swaap v2: a Market Making Protocol* (whitepaper, 2023). https://www.swaap.finance/ > **Note on proprietary-AMM figures (§19.5).** Update-cadence and compute-unit figures for HumidiFi, Obric, SolFi, Tessera, and ZeroFi are third-party on-chain observations from public Solana analytics, not vendor-published specifications; these venues are closed-source and do not publish their methodology. Treat the numbers as indicative orders of magnitude.