A one-second oracle makes Amini and Feinstein's SPY pool roughly six times deeper while cutting its annual loss to arbitrageurs to about 0.001 bps. The depth multiple is our arithmetic from an oracle weight of about 0.84; the loss is about $0.10 on a $1,000,000 position. Feed quality determines how much of that result survives. Under L1 (60-second delay, 25 bps deviation trigger, hourly heartbeat), a plain constant-product pool has lower LVR until tracking error reaches 11 bps. The authors also find that a well-tuned L1 pool can match its risk profile at significantly higher capital efficiency. In this backtest, the feed matters more than the oracle weight λ.

The quote comes from two prices

A conventional AMM quotes from inventory: its marginal price depends on the reserve ratio r = y/x and changes when someone trades. A tokenized equity gets its price discovery off-chain. Arbitrageurs bring the pool's quote into line and collect loss-versus-rebalancing (LVR), the pool's shortfall against holding the same inventory while trading at the external price.

Amini and Feinstein call their oracle-priced designs OP-AMMs. Their quoted log-price depends on r and the oracle log-price π. The rule must increase with r and be non-expansive in π. They prove that, when oracle pass-through is bounded strictly below one, the quote is always a weighted blend of the oracle and a fixed-point price implied solely by reserves.

The examples and backtest use the geometric-average design (GA). On a constant-product (CPMM) base, its rule is log price = λπ + (1−λ) log r, with λ setting the oracle weight. Hold the oracle fixed and the curve is CES, with a closed form. At λ = 0, it becomes Uniswap V2.

How much depth does the oracle buy?

With an accurate oracle, a great deal. GA local depth is 1/(1−λ) times baseline depth, using the CPMM liquidity parameter that matches the curve's curvature. Given a perfect oracle, CPMM LVR runs at Vσ²/8 per unit time; GA LVR runs at (1−λ)Vσ²/8.

The comparison with reserve-only curves is sharper. For any information-agnostic design, including concentrated liquidity, normalized LVR per unit of relative depth stays at σ²/8. More concentrated liquidity raises both depth and loss proportionally. Oracle information moves the GA off that line: against an equally deep reserve-only pool, its perfect-oracle gain has a factor of (1−λ)².

Noise eats into the gain.

If oracle error is uncorrelated and has volatility σ_η, the GA's LVR coefficient beats the baseline's only when σ_η < sqrt((1−λ)/λ)·σ. Our arithmetic puts that threshold near 0.44σ at λ ≈ 0.84. It comes from the paper's Ornstein-Uhlenbeck noisy-oracle model in Section 3. The backtest uses a lagged-mid oracle instead, so 0.44σ does not transfer to its Pull result. The authors describe the thresholds as local comparisons at matched states; actual clearing leaves the pools with different inventories. They acknowledge the reversal: "sufficiently noisy or stale oracles can reverse these gains." They therefore tune λ to oracle quality, treating sensitivity as "a design choice rather than a limit to approach." Separately, they argue that tokenized securities face lower manipulation risk because their reference prices come from deep, surveilled NBBO markets where moving the quote is costly.

A sandwich around the oracle update

The authors' example gives the attacker about 25.6% of the pool through a sandwich, compared with 2.7% from plain arbitrage. The attacker trades against a stale curve, waits for the oracle update, then reverses the trade. Start with a CPMM base, a pool at (1,1), S = 1, a GA with λ = 3/5, and an oracle refresh from 0 to 1/2. The optimal front-run buys the entire risky reserve for 2.175 units of numéraire and extracts about 0.512. Plain arbitrage after the update takes about 0.054.

A finite trade can empty the GA because the curve fails the authors' boundary-divergence property, as they point out. Fees prevent a profitable front-run for small updates: it adds nothing when λ|Δπ| ≤ Γ, where Γ = −log(1−γ). Heartbeat or delayed updates can breach that band, the paper warns. In its example, λΔπ = 0.3, about 60 times a 50 bps Γ.

What happens with three feeds?

The backtest runs on one-second SPY NBBO for 2023, with 250 trading days simulated independently from each open. Arbitrageurs supply all volume. The external market is assumed infinitely deep at the NBBO. The oracle takes the log mid-price, lags it by δ, and updates on a heartbeat h or deviation threshold ε:

The authors scan λ from 0% to 99% and fees from 0 to 50 bps across 5,100 configurations. In Pull, about 7.5 bps of average daily tracking error comes with annualized LVR around 0.001 bps. At λ ≈ 0.84, that is about $0.10 a year on a $1,000,000 position after collected fees. Realized depth misses the 1/(1−λ) multiplier by at most 0.012% under L2 and Pull, and at most 0.22% under L1. The multiplier at λ ≈ 0.84 is about 6.25x, close to what the pool delivers.

Pull is the best case here. Its oracle error consists solely of a one-second lag in the NBBO mid from the same quote stream used by the arbitrageurs. The simulation includes no aggregation noise or outages. Each tracking-error level on the frontier takes the best grid point from that same 2023 sample, making the frontier an in-sample envelope. Daily resets leave overnight and closed-market oracle risk unmeasured, as the authors state. They reset to avoid what they call "the overnight oracle problem," when the oracle would jump severely at the open.

L1 tells more about a slower feed. With its 60-second delay, 25 bps deviation trigger and hourly heartbeat, the CPMM remains optimal on the LVR-at-a-given-tracking-error frontier until tracking error exceeds 11 bps. L1 still adds depth on the depth-at-a-given-LVR frontier. The paper says its oracle "can lead to higher LVR than the benchmark CPMM if improperly tuned," while a well-tuned pool can match the CPMM's risk profile with significantly greater capital efficiency.

Fees at the edge of the grid

For λ > 0 on the L1 frontier, the chosen fee is almost always 50 bps. It is 50 bps throughout the depth-versus-LVR frontier in every regime. The authors explain: "as the simulation contains no liquidity-motivated demand, increasing the fee carries no penalty in trading volume." They caution against reading that grid value as an equilibrium fee recommendation.

The fee also matters to the loss claim. At 50 bps, Γ ≈ 50 bps, blocking a front-run when an update moves the quote by less than about 50 bps. As far as we can see, the backtest itself does not simulate sandwiches. The paper does not report the fee at the Pull 7.5 bps point, although every depth-versus-LVR frontier point uses 50 bps. The authors raise the trade-off themselves: the 50 bps fee "also widens the bid-ask spread quoted by the OP-AMM and can harm the same liquidity-sensitive traders" meant to benefit from concentrated depth. They call for an equilibrium model. Their headline LP-loss figures come from precisely the fee regime they say could harm those traders.

We could not rerun the simulation. It requires one-second SPY NBBO quotes for 2023, which we do not have; trading SPY shares on minute bars would leave the pricing rule untested.

We would take the low-LVR claim at face value if a rerun included fee-sensitive liquidity flow and an oracle whose error was independent of the arbitrageurs' price, with the Pull frontier still anywhere near 0.001 bps. The authors list an equilibrium order-flow model as their first extension.