Orderbook DEXs vs AMMs
The previous page showed how a fungible token lives on Solana: a balance sitting in a token account, moved between accounts by the SPL Token program. That gives you the nouns of DeFi — the tokens. This page gives you the first and most important verb: the swap. How do two people who hold different tokens agree on a price and trade, on-chain, with no trusted middleman?
There are two fundamentally different machines for this, and the whole rest of Solana DeFi is built on top of one or both of them. An orderbook DEX matches buyers against sellers the way a stock exchange does. An automated market maker (AMM) replaces the sellers with a pool of pooled money and a pricing formula. They solve the same problem — turn token A into token B at a fair price — with opposite architectures, opposite cost profiles, and opposite failure modes. And the reason Solana can run the first kind on-chain at all is the throughline of this entire book: it runs at hardware speed without falling apart.
Two machines for one job
Section titled “Two machines for one job”Strip an exchange down to its job: someone wants to sell token A for token B, someone else wants the reverse, and the exchange has to (a) discover a price both accept and (b) settle the trade. The two designs answer (a) completely differently.
ORDERBOOK DEX AUTOMATED MARKET MAKER (AMM) ───────────── ──────────────────────────── makers POST resting orders LPs DEPOSIT a token pair into a pool bids (buy A@price) reserves: x of A, y of B asks (sell A@price) price is a FORMULA of the reserves a matching engine CROSSES them e.g. x * y = k price = where a bid meets an ask a swap MOVES ALONG the curve needs active market makers needs only passive deposits many small transactions, low latency one transaction per swap, always-onKeep that split in mind — everything below is a consequence of it. An orderbook is a queue of human intentions that a computer crosses. An AMM is a vending machine whose price is set by how full it is.
The orderbook DEX
Section titled “The orderbook DEX”An orderbook is the design you already know from every stock or crypto exchange, moved on-chain. Two roles:
- A maker posts a resting order — “I will buy 100 SOL at 140 USDC each” (a bid) or “I will sell 100 SOL at 141 USDC each” (an ask). The order sits in the book, providing liquidity, until it is filled or cancelled.
- A taker arrives wanting to trade now and hits an existing resting order, crossing the book.
The book is just two sorted lists — bids high-to-low, asks low-to-high — and the gap between the best bid and best ask is the spread:
ASKS (sellers) price BIDS (buyers) ───────────── ───── ───────────── 141.20 ← someone will sell here 141.00 best ask → 141.00 ──┐ │ ← the SPREAD (0.02) best bid → 140.98 ──┘ 140.98 ← someone will buy here ← best bid 140.50A matching engine does one thing: when a new order can cross an existing one on the opposite side (a bid priced at or above the best ask, or vice versa), it matches them, settles the trade, and removes the filled quantity. Tight spreads and deep books mean you can trade a large size close to the quoted price — the classic sign of a good market.
Why this needs Solana
Section titled “Why this needs Solana”Here is the part that ties an orderbook to the book’s throughline. A healthy orderbook is not quiet. Professional market makers post fresh quotes and cancel stale ones many times per second as the reference price moves — most orders in a real book are cancelled, not filled. Every one of those posts and cancels is a transaction.
On Ethereum L1, where a transaction costs dollars in gas and blocks land every ~12 seconds, that pattern is economically impossible: a market maker would spend more on gas cancelling quotes than they earn on spread, and the ~12-second block time means their quotes are stale before they even confirm. So Ethereum DeFi went almost entirely to AMMs — a design that needs one transaction per trade and no cancels at all. The orderbook wasn’t chosen against; it was priced out.
Solana changes the inputs. Sub-second slots, thousands of transactions per second of capacity, and fees measured in tiny fractions of a cent make the post/cancel/repost loop affordable. That is why on-chain central-limit orderbooks became practical on Solana — projects like Serum and, after it, its community fork OpenBook put the entire book and matching engine on-chain as Solana programs. (Treat the specific projects as point-in-time: Serum’s history is tangled, OpenBook is the community continuation, and the DEX landscape shifts — the architecture is the durable lesson, not any one program’s name.)
The automated market maker (AMM)
Section titled “The automated market maker (AMM)”The AMM throws out the matching engine entirely. There are no makers, no takers, no resting orders — just a pool and a formula.
Liquidity providers (LPs) deposit a pair of tokens into the pool in equal value —
say x units of SOL and y units of USDC. Traders don’t trade against each other; they
trade against the pool. The price is not quoted by anyone — it is computed from how
much of each token the pool currently holds, via a constant-product formula:
x * y = k (k is held constant across every swap)
pool holds: x = 1,000 SOL, y = 140,000 USDC k = x * y = 140,000,000
A trader sells 10 SOL into the pool: new x = 1,010 SOL new y = k / new x = 140,000,000 / 1,010 ≈ 138,613.86 USDC USDC paid out ≈ 140,000 − 138,613.86 ≈ 1,386.14 USDC effective price ≈ 138.6 USDC/SOL (below the 140 you'd hope for)Because k must stay constant, adding SOL to the pool forces the USDC reserve down,
and the ratio y/x — the price — moves against the trader as they buy. The pool
automatically re-prices with every trade. No human quotes anything; the curve does it.
Slippage, LP tokens, and impermanent loss
Section titled “Slippage, LP tokens, and impermanent loss”Three concepts fall straight out of the formula, and you must have all three:
- Slippage. Notice the effective price above (138.6) was worse than the spot price
(140). The bigger your trade relative to the pool, the further you push along the curve,
and the worse your average price. That gap is slippage — the price impact of your
own trade. A deep pool (big
x, bigy) has low slippage; a shallow one is brutal. - LP tokens. When you deposit into the pool, you get back LP tokens — themselves SPL tokens — representing your share of the pool. They are your claim check: burn them later to withdraw your proportional slice of the (now larger, from fees) reserves. LPs earn a cut of every swap’s trading fee, which is the incentive to supply liquidity.
- Impermanent loss. This is the subtle one, and the reason “passive liquidity” is not free money. If the price of SOL moves sharply after you deposit, the pool’s constant rebalancing leaves you holding more of the token that fell and less of the one that rose than if you’d simply held the two tokens in your wallet. That shortfall versus just-holding is impermanent loss — “impermanent” because it reverses if the price returns, but very permanent the moment you withdraw at the new ratio. LP fees are meant to compensate for it; sometimes they don’t.
Impermanent loss, intuitively: you deposit 1 SOL + 140 USDC (SOL = 140) SOL doubles to 280 elsewhere arbitrageurs buy the pool's cheap SOL until its price = 280, which DRAINS SOL from your share and adds USDC you now hold less SOL (the winner) and more USDC (the loser) → worth LESS than if you'd just held 1 SOL + 140 USDC in a walletComparing the trade-offs
Section titled “Comparing the trade-offs”Neither design dominates. They trade the same quantities in opposite directions:
Orderbook DEX AMM ──────────── ───────────── ─── liquidity active (makers must quote) passive (deposit and walk away) price control precise (limit orders) take-it-or-leave-it curve price spreads/impact tight, if book is deep slippage grows with trade size compute cost high (post/cancel churn) low (one tx per swap) who bears risk market makers (inventory) LPs (impermanent loss) availability only as good as the book always-on, even at 3 a.m. best chain fit fast, cheap chains works even on slow, dear chainsThe honest summary: an orderbook gives tight spreads, precise limit-order control, and professional-grade price discovery — if you can afford the compute and attract active market makers. An AMM gives always-on, permissionless, passive liquidity that a weekend LP can supply — at the cost of slippage on large trades and impermanent-loss risk. Ethereum’s fees pushed it to AMMs. Solana’s speed lets it have both, and much of Solana DeFi is aggregators that route a single swap across whichever venues — orderbook or AMM — give the best net price.
Under the hood — a swap is just SPL transfers under Sealevel
Section titled “Under the hood — a swap is just SPL transfers under Sealevel”Zoom in on what a swap actually does to on-chain state, and it connects straight back to the token page. A swap is not magic; it is the exchange program invoking the SPL Token program to move balances between token accounts:
trader swaps SOL → USDC against an AMM pool: 1. token program: debit trader's SOL token account, credit pool's SOL vault 2. token program: debit pool's USDC vault, credit trader's USDC account all inside one atomic transaction — both legs commit, or neither doesBecause Solana transactions declare every account they touch up front (the accounts part’s account model), the runtime knows exactly which token accounts and pool vaults a swap will read and write before it runs. Two swaps against different pools share no writable accounts, so Sealevel runs them in parallel on different cores — the exact conflict rule from the runtime part, now doing real work: disjoint swaps fly, while two swaps hitting the same pool’s vaults must serialize because they both write the same reserves. The hot-account ceiling you met earlier is precisely why a single wildly-popular pool can become a throughput bottleneck even on a chain built for parallelism.
That is the whole book in one transaction: tokens are accounts, swaps are declared-footprint transactions over those accounts, and Sealevel runs the non-overlapping ones at hardware speed.
The architect’s lens
Section titled “The architect’s lens”- Why does it exist? Two people holding different tokens need to trade at a fair price with no trusted intermediary. An exchange — orderbook or AMM — is the on-chain machine that discovers that price and settles the swap trustlessly.
- What problem does it solve? It solves price discovery and settlement without a custodian. The orderbook solves it by crossing real human bids and asks; the AMM solves it by pricing algorithmically from a pool so liquidity is always present, even when no counterparty is online.
- What are the trade-offs? Orderbooks give tight spreads and precise limit-order control but demand active market makers and heavy transaction throughput; AMMs give always-on passive liquidity anyone can supply but impose slippage on large trades and impermanent-loss risk on LPs. You are trading price precision and compute cost against simplicity and always-on availability.
- When should I avoid it? Avoid an on-chain orderbook on a slow or expensive chain — the post/cancel churn makes it uneconomical, which is exactly why Ethereum L1 went to AMMs. Avoid an AMM (or size down) for large trades in a shallow pool, where slippage eats you, and avoid trusting any single venue’s spot price as an oracle when its book or pool is thin.
- What breaks if I remove it? Remove the exchange layer and tokens become islands: you can hold and transfer an SPL token but never price or swap it. Every layer above — lending (which needs prices), aggregators, yield strategies — has no ground to stand on. The DEX is where a token stops being a static balance and becomes a market.
Check your understanding
Section titled “Check your understanding”- In an orderbook DEX, what is the difference between a maker and a taker, and what does the matching engine actually do? What is the spread?
- Explain, using the arithmetic of
x * y = k, why an AMM’s price moves against a trader as they buy — and why a deeper pool causes less slippage. - Ethereum L1 DeFi is dominated by AMMs while Solana can run on-chain orderbooks. Name the two properties of Solana that make the difference, and explain why an orderbook needs them where an AMM does not.
- Define impermanent loss. Why does an LP end up holding more of the token that fell and less of the token that rose, and why is it “impermanent” yet real at withdrawal?
- Trace what a single AMM swap does to on-chain state in terms of the SPL Token program and token accounts, and explain why two swaps against different pools can run in parallel under Sealevel while two swaps against the same pool cannot.
Show answers
- A maker posts a resting limit order (a bid to buy or an ask to sell) that provides liquidity and waits in the book; a taker trades immediately by hitting an existing resting order. The matching engine crosses opposite-side orders whenever a bid is priced at or above the best ask (or vice versa), settling the trade and removing the filled quantity. The spread is the gap between the best bid and the best ask — small spreads and deep books mean you can trade size near the quoted price.
kmust stay constant, so buying token A (adding it to the pool) forces reservexup, which forces reserveydown to keepx*y = k; the pricey/xtherefore falls as you buy A, so each additional unit costs more — that worsening average price is slippage. A deeper pool has largerxandy, so a given trade is a smaller fraction of reserves and moves the ratio less, giving lower slippage.- Sub-second slots (low latency) and cheap transactions (thousands/sec at fractions of a cent). An orderbook needs them because a healthy book requires market makers to post and cancel quotes many times per second — most orders are cancelled, not filled — so both dollar-cost-per-tx and block latency must be tiny. An AMM needs only one transaction per swap and no cancels, so it tolerates slow, expensive chains, which is why Ethereum L1 DeFi went to AMMs.
- Impermanent loss is the shortfall an LP suffers versus simply holding the two tokens, caused by the pool’s automatic rebalancing when the price moves. As one token’s price rises, arbitrageurs buy that (now-cheap-in-pool) token until the pool’s ratio matches the market, draining the winning token from the LP’s share and adding the losing one — so the LP ends up with less of the winner and more of the loser. It is “impermanent” because it reverses if the price returns to the entry ratio, but it becomes a realized, permanent loss the moment the LP withdraws at the new ratio.
- A swap invokes the SPL Token program to debit the trader’s input token account / credit the pool’s input vault, then debit the pool’s output vault / credit the trader’s output token account — all atomically in one transaction. Because the transaction declares every account it touches up front, two swaps against different pools share no writable accounts, so Sealevel’s conflict rule lets them run in parallel on different cores; two swaps against the same pool both write that pool’s vault accounts, so they conflict and must be serialized.