Skip to content
DeFi Reference

On-chain order books

1. TL;DR

Section titled “1. TL;DR”

An on-chain central limit order book (CLOB) stores resting limit orders in contract state and matches incoming orders by price-time priority, so makers quote exact prices instead of a curve. The hard part is engineering: every quote, cancel and fill costs gas or compute units, and a naive book that loops over orders or price levels runs out of both. Solana’s cheap, fast blocks made Phoenix and OpenBook viable for spot trading; on the EVM, Clober’s segment-tree and Fenwick-plus-bitmap engines work by making every operation touch a constant or logarithmic number of storage slots.

2. Explain it simply

Section titled “2. Explain it simply”

Analogy

Section titled “Analogy”

A fish-market auctioneer keeps two chalkboard lists: buyers with the price they will pay and sellers with the price they want, best prices on top. When a seller shouts “15 crates, best price now”, the auctioneer walks down the buyers’ list, crossing off buyers in arrival order until 15 crates are gone. An on-chain book is that chalkboard inside a smart contract, with the rule that every chalk mark costs money, so the board must need as few marks as possible.

ELI5

Section titled “ELI5”

An order book is a list of people who have said “I’ll buy this many at this price” or “I’ll sell this many at this price”, sorted so the best offers are on top. When you trade, you take the best offers first, and among people at the same price the earliest gets served first. Keeping this list inside a blockchain program is expensive because every update to it costs fees, so designers invent clever ways to record who is owed what without going through the whole list every time. On fast, cheap chains this works well enough that professional traders quote on it; on slower chains it is still hard to make cheap.

Step-by-step walkthrough

Section titled “Step-by-step walkthrough”

Scenario: an ETH/USDC on-chain book with a single bid price level at 3,000 USDC, modelled on Clober’s claim-range example.

  1. Alice posts a bid: buy 10 ETH at 3,000. Before: Alice holds 30,000 USDC; level 3,000 is empty. After: 30,000 USDC escrowed; level depth 10 ETH; Alice is order #1 with claim range [0,10][0, 10].
  2. Bob posts the same bid. After: Bob escrows 30,000 USDC; depth 20 ETH; Bob is #2 with range [10,20][10, 20].
  3. Carol posts the same bid. After: depth 30 ETH; Carol is #3 with range [20,30][20, 30].
  4. Dave market-sells 15 ETH. The engine finds the best bid (3,000) and matches 15 ETH at that level. Dave’s 15 ETH become 45,000 USDC atomically in his transaction. Level depth falls to 15 ETH; the level’s “total claimable amount” TT rises from 0 to 15.
  5. Makers claim. Alice: range [0,10][0,10], fully below T=15T = 15, claims 10 ETH. Bob: range [10,20][10,20] straddles TT, claims 15−10=515 - 10 = 5 ETH. Carol: range starts at 20 > 15, claims nothing. Balances: Alice +10 ETH, Bob +5 ETH (15,000 USDC still escrowed), Carol 30,000 USDC still escrowed.
  6. Bob cancels his remaining 5 ETH. 15,000 USDC is refunded; Carol’s claim range shifts to [15,25][15, 25] without anyone touching her order; level depth is now 10 ETH.

Common misconceptions

Section titled “Common misconceptions”
  • Myth: An order book on-chain is just an AMM with more code. Reality: It is a different liquidity model: makers post directional, one-sided quotes that do not “convert back” when price reverses, whereas pool liquidity is bidirectional (0xrahul, 2023).
  • Myth: Solana books beat AMMs because they are faster. Reality: Solana books lost share to proprietary AMMs, which Ellipsis (Phoenix’s builders) called the “natural evolution of Phoenix’s orderbook markets”, since a book quote update costs 100,000–300,000 compute units (as of 2025-08, Helius).
  • Myth: Takers pay gas proportional to makers hit. Reality: In Clober’s engine a taker never touches maker slots; cost scales with price levels crossed (2025).
  • Myth: Drift’s DLOB is a book stored in one on-chain structure. Reality: Orders live in user accounts; off-chain keepers assemble the book and submit matches, and market orders first pass through a per-order just-in-time auction (Drift docs, 2026).

If you only remember one thing

Section titled “If you only remember one thing”

An on-chain book is a matching engine whose every operation must cost a bounded number of storage writes — get that right and makers quote exact prices; get it wrong and the book is a gas trap.

3. How it works

Section titled “3. How it works”

Matching and priority

Section titled “Matching and priority”

A limit order specifies side, price tick and size; a market order only side and size. The engine matches against the opposite side from the best price, and within a level in arrival order (price-time priority). The taker settles atomically; makers are paid in the same transaction (a “crank”) or via a deferred claim. Serum-era Solana books required an external crank to process the event queue; Phoenix Legacy “is an on-chain orderbook that operates without a crank” (Ellipsis Labs README), settling trades atomically.

Why naive books fail on-chain

Section titled “Why naive books fail on-chain”

Clober identified two unbounded loops: iterating over makers to settle, and iterating over empty ticks to fill a large market order — a book with asks only at 1,000 and 2,000 USDC and a 1 USDC tick would need “1000 storage reads” to walk the gap (Clober, 2022). Capping queues at 32 orders per level, as some EVM books did, was judged “too strong of a constraint”.

Deferred claims via prefix sums

Section titled “Deferred claims via prefix sums”

Let f(n)f(n) be the unclaimed size of the nn-th order at a price level. Its claim range is [αn,βn][\alpha_n, \beta_n] with αn=∑x=0n−1f(x),βn=αn+f(n).\alpha_n = \sum_{x=0}^{n-1} f(x), \qquad \beta_n = \alpha_n + f(n). If TT is the total amount taken from the level and not yet claimed, the claimable amount is c(T,[α,β])=min⁡(max⁡(0,T−α), β−α).c(T, [\alpha, \beta]) = \min\big(\max(0, T - \alpha),\ \beta - \alpha\big). Computing αn\alpha_n needs a prefix sum over a queue that changes on every claim and cancel. A plain array is O(n)O(n) to update; a segment tree makes query and update O(log⁡n)O(\log n). Clober’s segmented segment tree packs four 64-bit nodes per 256-bit slot so a 32,768-order queue needs only four SSTOREs per update (Clober, 2023); a Fenwick tree achieves the same O(log⁡m)O(\log m) bound with simpler maintenance (Clober, 2025).

Finding the next price level

Section titled “Finding the next price level”

Gaps between ticks are skipped with an index over occupied levels: Clober’s 2022 design used a max-heap for bids and min-heap for asks (the “Octopus heap”); the 2025 design uses a three-tier bitmap — one bit per tick at level 0, one bit per 256 level-0 bits at level 1, one bit per 256 level-1 bits at level 2 — so locating the best price is three reads plus a count-trailing-zeros, i.e. O(1)O(1).

OperationTarget complexityFenwick + bitmap cost (as of 2025-05)
Locate best priceO(1)O(1)3 reads, “a few thousand” gas
Place / cancel at a levelO(log⁡m)O(\log m), mm = quotes at level~40k / ~50k gas
Market order crossing tt levelsO(t)O(t)~20k gas per level swept

Hybrid book-plus-AMM

Section titled “Hybrid book-plus-AMM”

Long’s 2020 proposal keeps a constant-product pool alongside limit orders: a swap consumes resting sell orders at the current pool price p=xl/ylp = x_l / y_l, then pool liquidity until the price reaches the next order, and so on. With yo(p)y_o(p) the limit-sell depth at price pp, the input Δx\Delta x satisfies Δx=∫pspep yo(p) dp+Δxl,\Delta x = \int_{p_s}^{p_e} p\, y_o(p)\, dp + \Delta x_l, where Δxl\Delta x_l is the part absorbed by the pool and ps,pep_s, p_e are start and end prices; the end state is found by binary search on Δyl\Delta y_l (Long, 2020). Buterin’s reply suggested fixing order ticks 0.5–1% apart for gas predictability. Concentrated-liquidity AMMs later absorbed this idea directly: a limit order is “liquidity concentrated on a single tick” that is uni-directional (0xrahul, 2023); Meteora’s DLMM advertises “native onchain limit orders” as bins, and Uniswap v4 hooks can implement limit orders that fill at tick prices (see /exchange/concentrated-liquidity/ and /exchange/v4-hooks-and-am-amm/).

Drift’s DLOB and JIT auctions

Section titled “Drift’s DLOB and JIT auctions”

Drift stores orders in each trader’s on-chain account; keepers reconstruct the decentralised order book (DLOB) off-chain and submit matches for fees. Every market order first runs a just-in-time auction whose price interpolates linearly from the taker’s best price to their limit over a set number of slots: P(s)=Pstart+(Pend−Pstart)⋅min⁡ ⁣(1,s−s0D),P(s) = P_{\text{start}} + (P_{\text{end}} - P_{\text{start}}) \cdot \min\!\Big(1, \frac{s - s_0}{D}\Big), with makers filling first-come-first-served; unfilled size then falls through to resting DLOB orders and the AMM (Drift docs, 2026). See /derivatives/perpetual-futures/.

Why books struggle against active AMMs on Solana

Section titled “Why books struggle against active AMMs on Solana”

Every quote update is a transaction that must win priority, and quotes are public, so “latency-sensitive actors … can snipe stale orders during volatile price moves” (Helius, 2025). Proprietary AMMs replace discrete quotes with a curve that a 143-compute-unit oracle update re-centres (HumidiFi, as of 2025-08). See /exchange/lp-toxicity-and-jit/.

4. Worked numeric example

Section titled “4. Worked numeric example”

Same book as §2. Level 3,000 USDC holds three 10-ETH bids from Alice (#1), Bob (#2), Carol (#3).

Claim ranges before any fill: [α1,β1]=[0,10][\alpha_1,\beta_1] = [0,10], [α2,β2]=[10,20][\alpha_2,\beta_2] = [10,20], [α3,β3]=[20,30][\alpha_3,\beta_3] = [20,30]; total claimable T=0T = 0.

Dave sells 15 ETH. The engine reads the best bid via the bitmap (three reads), matches 15 ETH at 3,000, and credits Dave 15×3,000=45,00015 \times 3{,}000 = 45{,}000 USDC. It updates only the level’s filled cursor: T=15T = 15. No maker slot is touched.

Claims:

  • Alice: c=min⁡(max⁡(0,15−0),10)=10c = \min(\max(0, 15 - 0), 10) = 10 ETH, costing her 30,00030{,}000 USDC of escrow.
  • Bob: c=min⁡(max⁡(0,15−10),10)=5c = \min(\max(0, 15 - 10), 10) = 5 ETH for 15,00015{,}000 USDC; 15,00015{,}000 USDC remains escrowed.
  • Carol: c=min⁡(max⁡(0,15−20),10)=0c = \min(\max(0, 15 - 20), 10) = 0.

Bob cancels: the engine reads his prefix sum (10), sees 5 filled, removes the remaining 5 from the Fenwick tree (updating log⁡2m\log_2 m cells; with m=3m = 3, two cells) and refunds 15,000 USDC. Carol’s range is now [15,25][15, 25] because the tree’s partial sums changed, not because her order was rewritten. If a second seller now sells 8 ETH, TT becomes 23 and Carol can claim min⁡(max⁡(0,23−15),10)=8\min(\max(0, 23 - 15), 10) = 8 ETH.

Gas for Dave’s one-level sweep: about 20k under Clober’s estimates (as of 2025-05). A Phoenix quote update on Solana consumes 100k–300k compute units (as of 2025-08, Helius).

5. Where it’s used

Section titled “5. Where it’s used”

Ethereum

Section titled “Ethereum”
  • Clober — fully on-chain EVM book (LOBSTER): segmented segment tree + Octopus heap (2022–23), then Fenwick + three-tier bitmap (2025); the authors argue falling L2 gas will let books displace AMMs. ethresear.ch/t/22313
  • Dfyn v2 “superimposed liquidity” — limit-order liquidity layered on a concentrated-liquidity curve so orders add to, rather than take from, pool depth. ethresear.ch/t/15489
  • Uniswap v4 limit-order hooks — “Onchain limit orders that fill at tick prices” is a listed hook use case (Uniswap v4 whitepaper, 2024). See /exchange/v4-hooks-and-am-amm/.

Solana

Section titled “Solana”
  • Phoenix (Ellipsis Labs) — crankless on-chain spot book with atomic settlement; program PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY, MIT-licensed, OtterSec-audited; over $75B cumulative notional by mid-2025 (secondary: Solana Compass, as of 2025-06). docs.phoenix.trade now describes a perpetuals product (as of 2026-08). github.com/Ellipsis-Labs/phoenix-v1
  • OpenBook — community fork of Serum v3 deployed 14 November 2022 after FTX’s collapse left Serum’s upgrade key with FTX; upgrade authority moved to a multisig. OpenBook v2 remains a spot book venue alongside Phoenix (Helius, 2025). github.com/openbook-dex/program
  • Drift DLOB + JIT auctions — perps book in user accounts, keepers match, market orders auctioned per-order in slots; spot DLOB trading disabled in the current docs (as of 2026-08). docs.drift.trade
  • Meteora DLMM — bin liquidity with “native onchain limit orders” and volatility-aware fees. docs.meteora.ag

6. Risks, attacks, and incidents

Section titled “6. Risks, attacks, and incidents”
  • Upgrade-key risk: Serum, November 2022. After FTX filed for bankruptcy on 11 November 2022, Serum’s upgrade key turned out to be held by FTX rather than the DAO; Raydium, Jupiter and Mango warned against it and OpenBook was deployed on 14 November 2022 with multisig control (The Block, 2022-11). Root cause: a shared book whose upgrade authority was one private company.
  • Adverse selection from public, slow quotes. Each update is a transaction that must win priority (100k–300k CU on Solana), so makers get “sniped” on stale orders in volatile moments (Helius, as of 2025-08); on Ethereum L1 with 12-second blocks the problem is worse.
  • Stale-quote arbitrage across venues. Helius documents a searcher buying 2.11513 SOL for 45 USDC on an Orca pool and selling 2.115 SOL for 45.0045 USDC on Phoenix, profiting about $0.026 after a Phoenix maker had already moved quotes (as of 2025-01) — books are where the fresh price is, AMMs are where it is stale.
  • Gas griefing and unbounded loops. Levels with unbounded queues or tick gaps can push a taker transaction over the block gas limit; designs cap depth (32 or 32,768 per level) or index levels (Clober, 2022–25).
  • Re-entrancy in settlement. Clober finishes matching before any external transfer and uses monotone depth counters to block double refunds (2025).
  • JIT calibration. Drift’s FAQ notes auctions “too passive or slow can be frustrating for users” and that makers need “sniping” capabilities and RPC infrastructure to land fills (Drift docs, 2026).

7. Open problems

Section titled “7. Open problems”
  • Cancel priority. Whether the protocol should guarantee that a maker’s cancel/update lands before a taker’s fill (“application-controlled execution”) is an open design question on both chains (Neuder & Bahrani, 2026, citing ethresear.ch 23977).
  • Books vs active AMMs. Ellipsis, who built Phoenix, moved to a proprietary AMM (SolFi) because curve updates are cheaper than discrete quotes; whether books regain share is unresolved (Helius, 2025).
  • Data-structure trade-offs. No engine dominates: segment-tree-plus-heap wins in sparse books, radix trees on branch deletions, Fenwick + bitmap on predictability (Clober, 2025).
  • Latency arbitrage and proposer power. Solana’s proposed multiple concurrent proposers aim to give makers same-slot censorship resistance (Neuder & Bahrani, 2026); Ethereum’s FOCIL guarantees inclusion but not ordering.

8. Ethereum vs Solana

Section titled “8. Ethereum vs Solana”
AspectEthereumSolana
Live spot CLOBsClober on L2s; L1 spot books negligiblePhoenix, OpenBook v2; Drift for perps
Cost of a quote updateTens of thousands of gas (~40–50k on Clober) at L1 gas prices100k–300k CU, fractions of a cent, but must win priority
Settlement modelDeferred maker claims (prefix sums)Atomic, crankless (Phoenix) or keeper-matched (Drift)
Main competitorConcentrated-liquidity AMMs, intents/RFQProprietary AMMs (>60% of SOL/USDC volume as of 2025-08)
Key incident—Serum upgrade key held by FTX (2022-11)

Ethereum’s block time and gas made resting quotes uneconomic, so EVM books live on L2s with careful storage layouts or defer to intent-based fills. Solana’s cheap blocks let books set the fresh price that AMMs lag — yet even there makers migrated to curve-based proprietary AMMs whose updates cost a thousandth of a book quote. See /exchange/routing-and-aggregation/.

9. Reference doc

Section titled “9. Reference doc”

The reference

Section titled “The reference”

Fenwick + Bitmap: constant-time matching for on-chain order books — dev-clober (Clober), 12 May 2025. ethresear.ch/t/22313

Summary of the reference

Section titled “Summary of the reference”

The post is organised in eight numbered sections. §1 argues why DeFi needs an on-chain limit-order book: in traditional markets liquidity emerges from limit orders placed by market makers managing exposure and by directional traders expressing views; AMMs were a gas-efficient minimum viable mechanism that “cannot handle explicit limit orders” and restrict LPs to “simple, passive two-sided quoting”.

§2 sets complexity targets: locating the best executable price in O(1)O(1) regardless of how many ticks are empty; placing or cancelling at one level in O(log⁡m)O(\log m) where mm is the number of quotes at that level; executing a market order in O(t)O(t) where tt is the number of levels touched. With a cap of thirty thousand quotes per level, log⁡m\log m stays below fifteen.

§3 introduces the two structures. The price directory is a three-tier bitmap: L0 has one bit per tick, L1 one bit per 256 L0 bits, L2 one bit per 256 L1 bits; setting or clearing a level touches at most three bits and finding the best price reads one word per tier and counts trailing zeros — exactly three storage reads. Inside a level, a Fenwick tree stores live sizes as overlapping partial sums; quotes get increasing sequence numbers, and adding, cancelling, or computing the volume ahead of a sequence number reads or updates log⁡m\log m cells (at most fifteen reads and two writes under the cap).

§4 describes the engine operations. Placing a limit order assigns a sequence number, adds size to the level’s tree, raises the depth counter, and sets the bitmap bits if the tick was empty. Cancelling reads a prefix sum to see how much has filled, removes the remainder from tree and counter, refunds, and clears bits if depth hits zero. A market order loops three constant-cost steps — read best price, advance the filled cursor, continue if volume remains — so gas depends on ticks crossed. Claiming compares the filled cursor with the prefix sum before the order’s sequence.

§5 gives a gas outline: best-price lookup a few thousand gas (3 reads); place ~40k (up to 18 reads, 1–4 writes); cancel ~50k; sweeping one level ~20k. §6 lists safety properties: matching completes before external transfers (no re-entrancy reordering), monotone depth counters block over-claims, and claimed tree entries reset so sequence numbers can wrap. §7 compares the design with the segmented-segment-tree-plus-heap engine (best in sparse books, 32,768 depth cap) and radix-tree heaps (near-constant branch deletion but gas spikes under deep cancellations); Fenwick + bitmap trades a fixed tick grid for predictable gas. §8 concludes that the design reproduces price-time priority on-chain “without external helpers”.

Key quotes

Section titled “Key quotes”

“Because the loop runs once per price level gas depends on ticks crossed, not maker count.” (§4, Submitting a market order)

“With a practical cap of thirty thousand quotes per price level log m stays below fifteen, so maker actions behave like a constant.” (§2)

“Matching logic finishes before any external transfer, preventing re-entrancy from reordering fills.” (§6)

“The three-tier bitmap locates the next price level in constant time, and the per-level Fenwick tree keeps maker edits within tiny logarithmic cost” (§8)

How to read the original

Section titled “How to read the original”

Background needed: what a prefix sum is, why SSTORE dominates EVM cost, and the price-time priority rule. Skip §7’s engine comparison on a first pass. The hardest part is §3’s Fenwick description: “stores live sizes as overlapping partial sums” means each tree cell holds the sum of a power-of-two-sized block of orders, so any prefix sum is assembled from at most log⁡m\log m cells and any single-order change touches at most log⁡m\log m cells — read it alongside Clober’s 2022 claim-range example (Alice/Bob/Carol) to see why prefix sums are the only quantity the engine needs.

What changed since

Section titled “What changed since”
  • The 2022 LOBSTER post used a segmented segment tree (4 SSTOREs for 32,768 orders) and Octopus heap; the 2025 post replaces both with Fenwick + bitmap, trading the depth cap for a fixed tick grid.
  • On Solana, Ellipsis (Phoenix) shifted its market-making to proprietary AMMs in November 2024, and by mid-2025 such AMMs took over 60% of SOL/USDC volume (Helius, as of 2025-08) — the competitive backdrop for any book design.
  • Uniswap v4 (whitepaper August 2024) lists on-chain limit orders at tick prices as a hook use case, so limit-order liquidity on the EVM increasingly lives inside AMMs rather than standalone books.

Secondary references

Section titled “Secondary references”
  1. Clober, “Enabling on-chain order matching for order book DEXs” (2022) and its 2023 “Revisited” — read if you want the claim-range math and the segmented segment tree in detail.
  2. Drift docs, “JIT Auctions” — read if you want the per-order auction formulas and maker workflow that sit in front of a keeper-matched book.
  3. Ellipsis Labs, phoenix-v1 README — read if you want the program ID, licence and audit pointers for a crankless Solana book.
  4. Long, “Hybrid of order-book and AMM” (2020) — read if you want the integral formulation of book-plus-pool swaps.

The reference

Section titled “The reference”

JIT Auctions — Drift Protocol developer docs (docs.drift.trade, published under the Velocity Protocol brand at fetch), last updated 27 August 2026. docs.drift.trade/developers/market-makers/jit-auctions

Summary of the reference

Section titled “Summary of the reference”

The page defines JIT (just-in-time) auctions as the venue’s price-discovery mechanism: when a taker order arrives — a market order or an aggressive limit crossing the spread — it enters an auction in which market makers compete to fill it at better prices before it reaches the DLOB or AMM. The stated rationale is fourfold: better execution for takers, reduced adverse selection because makers can react to toxic flow, more maker competition per fill, and off-chain quoting without resting orders.

Each auctioned order carries three parameters: auctionDuration in slots (a requested value can be raised by order sanitisation to a market- or tier-derived floor; unfilled size falls through afterwards), auctionStartPrice (the taker’s best price at slot 0) and auctionEndPrice (the taker’s limit at slot N). For a long, start must be at or below end, otherwise the program rejects the order. The price ramps from best to worst, so early fills require makers to offer prices close to the taker’s best.

The pricing formula is linear interpolation: Auction Price(slot) = start + (end − start) × progress, with progress = min(1, (current − start slot)/duration). The worked example uses an oracle at $100, start $100.00, end $100.10 and ten slots: at slot 3 the price is $100.03, at slot 7 it is $100.07; a maker offering $100.05 becomes eligible from slot 5, one offering $100.02 from slot 2.

The lifecycle: the taker places the order via the SDK; the auction runs; makers observe via an event-driven AuctionSubscriber (a websocket program-account subscription filtered to users with orders in auction) and submit placeAndMakePerpOrder fills; best makers fill, partial fills continue through the auction, and unfilled remainder can match resting DLOB orders and the AMM by price at each level. Maker participation is described as subscribe, filter and price auctions (using getAuctionPrice with the market’s tick size so rounding matches the program), then apply risk management: reject stale oracles and respect position limits. The companion FAQ adds that auctions are parallel per order (up to 32 order slots per taker), partially fillable, cancellable, first-come-first-served for makers, and that makers cannot withdraw once partially filled.

Key quotes

Section titled “Key quotes”

“When a taker order arrives (market order or aggressive limit crossing the spread), it enters an auction where market makers compete to fill it at better prices before it hits the DLOB or AMM.” (Introduction)

“Makers who fill closer to slot 0 are giving the taker a better price (and taking more risk). Makers who wait until later slots get easier fills but at less favorable prices.” (Auction timeline)

“Auction prices interpolate linearly from start to end over the auction duration” (Auction pricing formula)

How to read the original

Section titled “How to read the original”

Background needed: Solana slots (about 400 ms, but the docs stress durations are counted in slots, not seconds) and the difference between a maker and a filler. Skip the TypeScript listings on first pass. The hardest paragraph is the “key insight” on start/end price ordering: for a long the start price is the lowest the taker would pay and the auction moves up toward the limit, which is the reverse of a classic descending Dutch auction from the maker’s viewpoint — think of it as the taker’s bid rising until a maker accepts.

What changed since

Section titled “What changed since”
  • The docs site now carries the Velocity Protocol brand and states spot DLOB trading is disabled, with perps remaining (as of 2026-08-27).
  • Paradigm’s “Priority is all you need” (2024-06) proposes replacing Dutch auctions with MEV taxes on chains with competitive priority ordering, arguing on-chain Dutch auctions “leak some value to MEV due to price movements between blocks”.

Secondary references

Section titled “Secondary references”
  1. Drift “Just-in-Time (JIT) FAQ” — read if you want the maker/taker Q&A on parallel auctions, cancellation and fill rules.
  2. Drift “Market Maker Participation” — read if you want the difference between JIT making and post-only resting orders.
  3. Helius, “Solana MEV Report” — read if you want the stale-quote arbitrage example between an AMM and Phoenix.

10. Sources

Section titled “10. Sources”