Summary

Proportional AMMs (PropAMMs) are on-chain DEX pools where a professional market maker updates prices using off-chain algorithms rather than a fixed bonding curve. They enable LP returns competitive with CEX market making by eliminating LVR (Loss-Versus-Rebalancing). However, they introduce new MEV vectors: aggregators can display “phantom liquidity” from stale PropAMM quotes (5–10 bps better than available), and random spread fluctuations make routing comparisons unreliable.

What Makes PropAMMs Different

Traditional AMMs (Uniswap v2/v3, Curve)

  • Price determined by a bonding curve (constant product, concentrated liquidity, stableswap)
  • Price adjusts only when trades happen
  • LPs face LVR: every time the “true” price moves, arbitrageurs trade at the stale on-chain price
  • LPs earn fees but lose to arbitrage — in volatile markets, losses often exceed fees

PropAMMs

  • Price determined by an off-chain market maker who updates on-chain via oracle transactions
  • Market maker prices based on CEX data, order books, volatility models
  • Price updates before arbitrageurs can act → no stale-price exposure
  • LPs can earn competitive returns without bearing LVR

Example: Unichain’s PropAMM integration allows Citadel Securities to operate as an on-chain market maker, posting two-sided quotes that update sub-second based on Nasdaq data. LPs provide capital; market maker provides pricing.

The “New Information First” Requirement

For PropAMMs to work, the oracle update (price refresh) must land in the block before any arbitrage trade exploiting the same price movement.

Block N timeline:
  Position 1: Oracle update (ETH/USDC → $2,001)
  Position 2: User swap at updated $2,001 price ✓
  
Without ordering guarantee:
  Position 1: Arbitrage trade at stale $2,000 (exploits LP)
  Position 2: Oracle update (arrives too late)

This requires protocol-level ordering guarantees. On Solana, oracle update transactions with high priority fees typically land first (fee-per-compute). On Ethereum, there’s no such guarantee — a rich arbitrageur can outbid an oracle update.

Andrea Canidio (2026) proposes “pure write” transaction types that land at the top of every block — a design primitive that would make PropAMMs viable across all EVM chains.

PropAMM Shenanigans: Two Attack Patterns

Pattern 1: Phantom Liquidity (Flashblocks-based)

Setup: Some L2s divide slots into Flashblocks (sub-block periods of ~200ms). Aggregators query PropAMM state at the beginning of a Flashblock.

Attack:

  1. Aggregator queries PropAMM at Flashblock start → sees spread of 3 bps
  2. Market maker updates prices within the Flashblock → spread widens to 8 bps
  3. User’s trade executes at Flashblock end → actual spread is 8 bps
  4. User was shown 3 bps at quote time; executed at 8 bps

Statistical signature: PropAMMs accessed by aggregators show better spreads at query time than at execution time. The delta (phantom spread improvement) is 5–10 bps on average.

Pattern 2: Random Spread Fluctuations

Setup: PropAMM spreads are not constant — market makers widen spreads during uncertainty, volatility, or low liquidity periods.

Attack (passive, not intentional):

  1. Aggregator queries at a moment of tight spreads (market conditions favorable)
  2. Displays tight spread to user
  3. User clicks “trade” — by now, market conditions changed, spread is wider
  4. User gets worse execution than displayed

Statistical signature: PropAMM spread time series shows autocorrelation patterns. Aggregators that snapshot at “favorable” moments show systematic positive bias vs. actual execution.

Mitigations

For Aggregators

  • Re-quote at execution time: don’t display a quote without re-verifying it is still valid at submission
  • Time-to-stale warning: display how long ago the quote was obtained
  • Execution price guarantee: only display quotes the aggregator can commit to (with slippage tolerance)

For PropAMMs

  • TEE-based commitment: market maker runs in a TEE that attests to the price at query time; aggregator can verify the commitment
  • On-chain TTL: quotes expire after N blocks; aggregator must re-query if expired

At the Protocol Level

  • Sub-slot execution (TOOL): shorter sub-slots (200ms) reduce the window between quote and execution
  • Oracle-first ordering: protocol guarantees oracle updates land before swaps (as Canidio proposes)

PropAMMs and Block Building

PropAMMs create a specific MEV structure:

  • Oracle frontrunning: MEV bot observes oracle update in the mempool → executes a trade that profits from the incoming price change (before the oracle update executes)
  • Oracle backrunning: MEV bot executes a beneficial trade immediately after the oracle update (valid arbitrage, not manipulation)
  • Sandwich via oracle: MEV bot inserts a buy before the oracle update and a sell after → profits from the price change itself

These are distinct from standard AMM sandwich attacks and require oracle-aware MEV protection.

Relationship to LVR Research

From the AMM LP perspective, PropAMMs are the solution to LVR:

  • Constant product AMMs: LVR ≈ σ²/(8f) per unit capital (σ = volatility, f = fee rate)
  • PropAMMs: LVR ≈ 0 (oracle updates preempt arbitrage)
  • Net LP return on PropAMMs: fees only, no arbitrage losses

This makes PropAMMs far more capital-efficient for LPs in volatile markets. The tradeoff: market maker takes the spread (not LPs), so LP returns are fee-based rather than spread-based.

Key Sources

  • PropAMM Shenanigans (2026) — phantom liquidity; Flashblocks mechanism; spread fluctuations; statistical signatures
  • What Network Effects Mean for L1s (Andrea Canidio, Mar 2026) — LVR analysis; oracle-first principle; Prop-AMM viability conditions