How does price impact differ between an order book (Phoenix) and an AMM (Raydium) on Solana, and why?

A market maker routing size into SOL/USDC needs to know which venue absorbs a given trade without moving the price against it. If an order book holds tighter impact at small size but degrades sharply past its resting depth, while an AMM degrades smoothly but predictably, that shapes how a router should split an order across venues — and at what notional it should stop treating "best quoted price" as a reliable guide to "best executed price."

• Pair: SOL/USDC (So111...112 / EPjFW...Dt1v)
• Venues: Phoenix (central limit order book) vs. Raydium (constant-product AMM), isolated via Jupiter's /quote endpoint with the dexes parameter restricted to one venue at a time
• API: https://api.jup.ag/swap/v1/quote (and /program-id-to-label to confirm current venue label strings before querying)
• Sizes: $100 / $1,000 / $10,000 / $50,000 / $100,000 notional, quoted as USDC → SOL (ExactIn, 50 bps slippage tolerance)
• Held constant: direction (buying SOL), slippage tolerance, single snapshot in time, single RPC/quote provider
• Snapshot timestamp: 2026-07-31 09:25 UTC
• Script: src/fetchQuotes.ts → data/results.csv; chart generated by src/charts.ts

Venue resolution came back clean on the first pass — both Phoenix and Raydium are present in the current /program-id-to-label list, so no fallback to OpenBook or a two-AMM comparison was needed.

(Baseline unrestricted 1 SOL quote: $73.45.)

Raydium's impact grows slowly and near-linearly across two orders of magnitude of size. Phoenix's impact is already higher than Raydium's at the smallest size tested and accelerates sharply past $10,000 — by $100,000 it is roughly 12x Raydium's impact. There is no crossover in this range: Raydium quotes tighter execution at every size tested, not just at the top end.

• Quoted ≠ executed. These are point-in-time quote responses, not filled trades. Real execution would face latency between quote and landed transaction, competing order flow, and (on Phoenix) the possibility that resting orders at the top of book are pulled before the trade lands.
• Single snapshot, not a time series. All ten quotes were pulled within about two minutes of each other on 2026-07-31. Order book depth in particular can vary a lot over the course of a day; this is one instant, not a distribution.
• No MEV or slippage-tolerance modeling. The 50 bps slippage parameter affects routing/threshold behavior, not the impact numbers reported here, but real-world execution would additionally be exposed to sandwich risk that this method doesn't capture.
• One pair. SOL/USDC is Solana's deepest market on both venue types. These dynamics need not hold for a thinner pair, where an order book could plausibly have no liquidity at all past the top few levels.
• Routing may understate true venue depth. Restricting dexes to a single label forces Jupiter to quote against whatever that venue's on-chain state looks like at query time; it does not guarantee that is the venue's full available depth, only what Jupiter's route-finder found routable through it.
• The $100 result is the one to be most careful with. Phoenix already shows higher impact than Raydium at the smallest size tested, which is not the naive expectation (order books are usually assumed to have near-zero impact for small trades relative to top-of-book size). This could reflect thin resting size at the top of Phoenix's book at snapshot time, a wide effective spread being counted as "impact," or Jupiter's impact calculation benchmarking against a reference price rather than Phoenix's own mid. It is reported as observed, not smoothed over.

The mechanical difference is the shape of the two curves, and it comes from how each venue prices size.

An order book's impact is stepwise: a market order walks through discrete resting orders at successive price levels, and impact stays flat as long as size fits within the liquidity resting near the top of book, then rises in steps as it consumes deeper, worse-priced levels. That is consistent with Phoenix's curve here — flat-ish from $100 to $1,000, then a visible bend upward once size passes whatever was resting near the top of the book, with the steepest step between $10,000 and $100,000.

An AMM's impact is continuous, set by the constant-product curve itself (x·y=k): every trade moves the price along the curve, so impact grows smoothly with size, with no discrete steps. Raydium's near-linear-looking growth across the tested range is that curve behaving as designed — predictable, but never zero, even at $100.

In this snapshot, Raydium's deeper pool dominates Phoenix's order book at every size tested, so there is no crossover point to report — the honest finding is that Phoenix would need meaningfully more resting depth near the top of its book to be competitive with Raydium's pool at these notional sizes, at least at this moment in time.

VERIFIBET's pool design sidesteps this entire question: because all bets on an outcome settle at a single pool-implied price determined at resolution, there is no per-trade price impact curve to walk, no order book to have depth in, and no AMM curve to slide along — the tradeoff analyzed above simply doesn't apply to that market structure.

Time series of impact over a trading day (not a snapshot), a second pair with thinner liquidity, and a note on oracle latency / MEV / LP returns are natural follow-ups — none are in scope here.

The SHA-256 of this README (3e0c029b007f53055417df0425cc502d414d6db40b3d7dc73abc791418e7a745, computed over the file content prior to this section being added) plus the repo URL were sent as a memo transaction on Solana devnet — not mainnet, so this is a free proof-of-timestamp exercise with no real value transferred, and it should be verified with that in mind.

• Signature: 3rdhDFFq3W9siG73vV9QhXF4jj2iiA6o6Piw5KakHcZo1kcjVf7wiz2KAHbZuwFMrCRTEc79b2h4cw1JcGHyUJjk
• Explorer: https://explorer.solana.com/tx/3rdhDFFq3W9siG73vV9QhXF4jj2iiA6o6Piw5KakHcZo1kcjVf7wiz2KAHbZuwFMrCRTEc79b2h4cw1JcGHyUJjk?cluster=devnet
• To verify: check out the commit before this section was added, hash that version of README.md, and confirm it matches the hash above and the memo logged in the transaction.