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.

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

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:

where:

• $\mathrm{\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·\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:

• 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 for implementation details.

3. Asset-Liability Management: Platypus & Wombat

3.1. The asset-liability innovation

Platypus Finance (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:

Platypus and later Wombat Exchange 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:

“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 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’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), 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 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:

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

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

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 and 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 (2022) and Price-Aware Automated Market Makers: Models Beyond Brownian Prices and Static Liquidity (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:

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

5. Dynamic Pegging: Curve v2 Cryptoswap

5.1. The Repegging Innovation

Curve v2 Cryptoswap introduced dynamic repegging: the concentrated-liquidity center moves automatically with an internal price oracle.

From Curve documentation:

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

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 for the external-mark feed design.

6. Concentrated Liquidity: Gyroscope E-CLP

6.1. Elliptical Concentration

Gyroscope’s E-CLP (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 ($\varphi$): 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:

See Liquidity Shaping for spline mechanics.

7. Volatility-Based Fees: LFJ v2 Liquidity Book

7.1. The Surge Pricing Innovation

LFJ’s Liquidity Book (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·{\nu }_p}{100·\mathrm{B}\mathrm{P}\mathrm{S}}$

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:

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

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

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). The first-person account of arriving at that conclusion is in the Manifesto.

8.5. AIMM’s Mitigations

See 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 \mathrm{U}\mathrm{S}\mathrm{D}\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; what follows is only the shape of the idea and where it came from.

On this tree $\mathrm{U}\mathrm{S}\mathrm{D}\mathrm{T}\to \mathrm{D}\mathrm{A}\mathrm{I}$ turns at USDC and never reads the WBTC mark, and $\mathrm{s}\mathrm{t}\mathrm{E}\mathrm{T}\mathrm{H}\to \mathrm{W}\mathrm{E}\mathrm{T}\mathrm{H}$ 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 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

For the full topology, the cycle-safety conditions, the fee composition rules and the implementation, see 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 and academic work on Concentrated Circular Market Makers (CCMM) (Tolstikov et al.). Orbswap 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$):

The equal-price point sits at $q=r(1-1/\sqrt{n})$ along the diagonal $\overrightarrow{v}=\frac{1}{\sqrt{n}}(1,\dots ,1)$. Any reserve vector decomposes as $\overrightarrow{x}=\alpha \overrightarrow{v}+\overrightarrow{w}$ with $\overrightarrow{w}\perp \overrightarrow{v}$, giving the constraint $r^2=(\alpha -r\sqrt{n}{)}^2+\parallel \overrightarrow{w}{\parallel }^2$. Instantaneous marginal price between assets $i,j$:

Polar ticks are hyperplanes $\overrightarrow{x}·\overrightarrow{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:

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

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

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.

12. Synthesis: How AIMM Combines Prior Art

12.1. Component Attribution

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:

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)
• 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 (“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

14.2.1. DODO PMM reference formula

DODO’s PMM curve (2020 whitepaper, §3):

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.

Two mechanisms carry the risk the mark cannot outrun:

• Coverage-driven inventory skew moves the mid on flow between pushes (Inventory Management).
• Volatility, confidence and staleness terms price the push-latency window rather than merely narrowing it (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

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 · Cornell mirror
• Guéant, Lehalle & Fernandez-Tapia (2012): Optimal Portfolio Liquidation with Limit Orders
• 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; see also the CowSwap LVR exposition

DeFi Protocols:

• Uniswap: Constant product AMMs, concentrated liquidity
• Curve Finance: StableSwap, Cryptoswap, internal oracle
• Platypus Finance: Asset-Liability Management
• Wombat Exchange: Coverage ratio stableswap
• Swaap Finance: Oracle-guided, stochastic spread
• Gyroscope: Elliptic CLPs, passive curator model
• LFJ (Trader Joe): Liquidity Book, surge pricing
• Paradigm: Orbital AMM research

Research:

• Milionis et al.: LVR formalization
• Adams et al.: Concentrated liquidity
• Egorov: Cryptoswap

17. Further Reading

• AIMM Architecture, System architecture
• Manifesto, Vision and value proposition
• Spread & Fees, Symmetric vol + confidence + staleness fee model
• Oracles, External keeper-mark feed design
• Liquidity Shaping, Spline profiles
• 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)

Aggregate:

For small $S$ under constant-product, $f(D,S)\approx DS$. 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:

Active-range factor $\alpha \in [1,\mathrm{\infty })$ (often $5$-$50\times$ on blue chips) multiplies one pair only:

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

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

Holding ${\alpha }^{\prime }\approx \alpha$, under base-token flow:

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.

Per-asset reserves match ($\mathrm{\$}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\mathrm{\%}$ of nominal under realistic flow.

18.6. Cross-pair routes

UniV3 often routes $X\to \mathrm{U}\mathrm{S}\mathrm{D}\mathrm{C}\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{b}\mathrm{p}$ 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

Example ($w_h=0.7$, $N=5$, ${\gamma }_c=0.8$, ${\mu }_h=1.2$, ${\beta }_o=1.2$):

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

TVL-invariant by construction. Absolute depth scales with $T$. Concurrent multi-pair drains compress toward $1\times$.

18.10. Other venues

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.

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

19.1.2. Pricing and risk

19.1.3. Execution and ops

19.2. Per-peer summaries

Uniswap V2 - 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 - 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 - 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) - 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) - 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 - 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) - 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 - 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 - 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 - 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 - 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) - 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). 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.
• 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

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

Canonical pricing pipeline (do not duplicate here): Inventory Management → Liquidity Shaping → Anchor Path Pricing → 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. ; Bergault et al. ). 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 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.

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

19.6. Uniswap V3/V4, DODO, Wombat, Curve: pricing analogies

Deep mechanics stay in the linked pricing pages.

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

Adams, H. Uniswap V2 Core (2020). https://uniswap.org/whitepaper.pdf

Adams, H. et al. Uniswap V3 Core (2021). https://uniswap.org/whitepaper-v3.pdf

Uniswap Labs. Uniswap V4 Core (2024). https://github.com/Uniswap/v4-core

Egorov, M. StableSwap - efficient mechanism for Stablecoin liquidity (2019). https://docs.curve.finance/assets/pdf/stableswap-paper.pdf

Egorov, M. Automatic market-making with dynamic peg (2021). https://docs.curve.finance/assets/pdf/whitepaper.pdf

Balancer Labs. Balancer V2 Vault / V3 Hooks (2021, 2024). https://docs.balancer.fi/

DODO Team. DODO: A Next-generation On-chain Liquidity Provider Powered by PMM (2020). https://docs.dodoex.io/

Maverick Protocol. Maverick AMM Whitepaper (2022). https://docs.mav.xyz/

Trader Joe / LFJ. Liquidity Book Whitepaper (2022). https://docs.lfj.gg/concepts/concentrated-liquidity

Platypus Finance. Platypus: An Open Liquidity Pool Protocol for Stableswap (2021). https://cdn.platypus.finance/Platypus_Finance_Whitepaper.pdf

Wombat Exchange. Wombat: 4th-Gen Multichain-Native Stableswap (2022). https://docs.wombat.exchange/

Paradigm / OrbSwap. Orbital AMM Lite Paper (2025). https://orbswap.org/lite-paper

Lifinity. Proactive Market Making on Solana (docs). https://docs.lifinity.io/

Milionis, J., Moallemi, C. C., Roughgarden, T., Zhang, A. L. Automated Market Making and Loss-Versus-Rebalancing (2022). https://arxiv.org/abs/2208.06046

Bergault, P., Bertucci, L., Bouba, D., Guéant, O. Automated Market Makers Designs beyond Constant Functions (2022). https://arxiv.org/abs/2212.00336

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

Avellaneda, M., Stoikov, S. High-frequency trading in a limit order book. Quantitative Finance 8(3), 217-224 (2008).

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.