DeepBook, CLOB Liquidity, and Why a Native On-Chain Order Book Changes Prediction Markets

A central limit order book is one ordered list, per instrument, of every unfilled buy and sell order anyone has posted, matched by a fixed rule: the best price wins, and among orders at the same price the one that arrived first fills first. There is no curve, no reserve ratio and no operator discretion in that sentence — the whole mechanism is a sorted data structure plus a matching rule. DeepBook is that data structure implemented as a Move package on Sui, which means the list itself lives in on-chain state and matching happens inside transaction execution, not inside a server that publishes results afterwards.

That distinction is the subject of this post. An AMM replaces the book with a pricing function over pooled reserves. A hybrid exchange keeps a real book but runs it off-chain and posts only settled trades to a contract. A native on-chain CLOB keeps the book itself in consensus state, so depth, queue position, cancellation and fill order are all things the chain enforces rather than things an operator reports. For prediction markets — where the tradeable object is a probability between zero and one, fragmented across every strike and every expiry — that architectural difference is not academic. DeepBook Predict is the binary-options protocol built alongside that book, and the way it sources liquidity is a direct consequence of the design below.

What a central limit order book actually is

Strip it to state and rules. The state is two sorted collections — bids descending by price, asks ascending — where each entry records a price, a remaining quantity, an owner and a sequence number. The rules cover three operations: insert an order, cancel an order, and match an incoming order against the opposite side while the prices cross. Everything traders talk about is derived from that state. The spread is the gap between the best bid and the best ask. Depth is the cumulative quantity resting within some distance of the mid. Slippage is what you pay for consuming more than one price level.

An incoming order either rests or crosses. If you post a bid below the best ask, it joins the book and waits — you have added depth. If you post a bid at or above the best ask, the engine walks the ask side, filling the best price first, then the next, until your quantity is exhausted or your limit price is exceeded. Any unfilled remainder rests at your limit. That single behaviour is why a book with real depth is self-correcting: consuming liquidity moves the price, which widens the incentive for someone to replace it.

DeepBook exposes the order restrictions that professional venues use, and they matter more on-chain than off, because a transaction that partially fills is a transaction whose outcome you must handle:

• No restriction — fill what crosses now, rest the remainder. The default limit order.
• Immediate or cancel — fill what crosses now, cancel the remainder rather than resting it. Use when you want price certainty but not queue exposure.
• Fill or kill — fill the entire quantity at your limit or do nothing. Use when a partial fill leaves you with an unhedged position.
• Post only — never cross; abort if the order would take. This is the maker's safety catch, and it is how a quoting strategy guarantees it never pays taker fees by accident.

Makers, takers, and why the fee is asymmetric

A maker posts an order that rests and waits. A taker posts an order that crosses and removes resting size. The maker supplies the option — anyone may trade against that price until it is cancelled — and is compensated with a lower fee than the taker pays; some venues go further and pay makers an outright rebate, though whether any given venue does is a parameter of its own fee schedule, not something the CLOB design guarantees. The asymmetry is not a courtesy either way. It is the only lever a venue has to pay for the thing it cannot manufacture itself: a book with no makers is an empty list, and an empty list has no price.

The maker's real cost is adverse selection. A resting quote is a free option granted to everyone who can see it: when new information arrives, informed traders hit the stale side of your quote before you can cancel. Everything a market maker does — widening the spread, skewing quotes against inventory, cancelling on volatility — is an attempt to price that option correctly. Understanding this explains most of what a book looks like in practice, including why spreads widen violently right before a short-dated expiry.

Price-time priority, and what it guarantees

Price-time priority — FIFO — says an incoming order fills against the best price available, and within a price level, against the oldest resting order first. Two consequences follow. First, improving the price by one tick jumps the entire queue at the level below, which is why tick size is an economically loaded parameter rather than a display setting. Second, being early at a price level is worth something real, so makers are rewarded for committing capital before the information arrives rather than after.

The property that matters for an on-chain venue is that FIFO is checkable. On an off-chain book, queue position is asserted by the operator; you take it on trust that your order was not reordered relative to someone else's. When the book is a shared on-chain object, ordering is decided by validator consensus and the resulting state transition is public. You do not need to trust a claim about matching fairness, because the matching is the transaction. That is a narrower guarantee than "no MEV" — validators still order transactions, and latency still matters — but it is a materially different trust assumption from a private sequencer.

AMM, off-chain book, native CLOB

The three designs are usually compared on user-visible outcomes — spread, slippage, fees. The more useful comparison is where the state lives and who is trusted to advance it, because everything else falls out of that.

That last row is the honest cost of the native design, and it is why on-chain CLOBs were impractical until block space got cheap and fast enough. Market making is a high-cancel activity: a strategy may replace its quotes many times over for every fill it gets. A venue that charges for every message has to be cheap enough that quoting remains profitable, which is the constraint any native on-chain book has to be designed against — and the reason a book like DeepBook is built as a package on a chain with cheap, parallelisable execution rather than as a contract on a general-purpose settlement layer.

Why native-on-Sui is architecturally different

Three properties of the Sui stack do the work here. The first is the object model. State is addressed as typed objects, and transactions touching only objects you own can be finalised without full consensus ordering, while operations on shared objects — a book everyone writes to — go through consensus. A CLOB pool is necessarily shared, so orders against it are consensus-ordered; but the accounts, balances and positions hanging off it need not be, and the work of the chain scales because unrelated pools and unrelated users do not contend for the same lock.

The second is Move itself. Assets are linear resources: a value of a resource type exists in exactly one place at a time and cannot be silently copied or discarded, because the type system withholds the abilities that would allow it. For a book, that eliminates an entire class of accounting bug — a fill cannot credit a position it did not debit, because a balance cannot appear from nowhere. Order matching written in Move is closer to a proof about balances than to a database transaction.

The third is that a public book is a public good. Because DeepBook's matching is a package call rather than an API, any other Move package can route through it inside the same atomic transaction — a router, a liquidation engine, a structured-product vault, or an options protocol pricing off the same underlying. Liquidity posted once is addressable by every application on the chain rather than by one venue's front end. That property is why an options protocol can sit alongside the book rather than having to bootstrap a parallel one, and it is the backbone of the wider Sui prediction market stack.

Two smaller Sui features change the user side of the same picture. Transactions can be sponsored — a third party pays gas — so a trader does not need to hold the native token to place an order. And zkLogin lets an account be derived from an ordinary OAuth login, using a zero-knowledge proof that the login was valid without putting the identity on chain, which removes the seed phrase from onboarding entirely; we cover the mechanism in prediction markets without a seed phrase. Neither changes the book's microstructure, but together they remove the two frictions that usually stop a retail trader from ever reaching it.

Tick size, lot size, and the admission grid

Every book quantises two axes: price into ticks and quantity into lots, with a minimum size below which an order is refused. Ticks that are too fine let a competitor jump your queue position for an economically meaningless improvement, which drives makers away; ticks that are too coarse pin the spread wider than it needs to be. Lot size and minimum size exist to stop the book filling with dust that costs more to match than it is worth.

Binary options add a third quantised axis: the strike. A prediction market is not one instrument but a grid of them, one per (strike, expiry) pair, and a grid that is too fine shatters liquidity into cells nobody quotes. That is why the DeepBook Predict testnet deployment we integrate against enforces a coarse admission grid for strikes that is deliberately wider than the price tick — a mint whose strike does not land on a whole multiple of the admission step is rejected on-chain with a dedicated abort code, not silently rounded into something you did not ask for. Concretely, the check is that (strike / tick_size) % (admission_tick_size / tick_size) == 0. There is one deliberate exception, and it matters: a market's own on-chain reference strike — the round baseline described in the lifecycle below — is admitted even when it does not sit on the coarse grid, which is what lets an hourly round anchor to a real observed price instead of to the nearest round number.

Fixed-point scaling

1e9 for probabilities, prices and leverage

Strike encoding

A price tick; strike price = tick × tick_size

One-sided contracts

Sentinel ticks — 0 for −∞, (1 << 30) − 1 for +∞

Range contract

A bounded (lower, upper) tick pair

Strike admission

Coarse admission grid, wider than tick size, with a reference-strike exception

Position lot size

Quantity must be a whole multiple of the lot

Premium floor

Net premium must clear a per-market minimum

Settlement asset

dUSDC on the Sui testnet deployment

The sentinel encoding is worth pausing on, because it is how one data structure expresses both product shapes. A range contract is a bounded pair of ticks. An "above X" contract is the pair (X, +∞); a "below X" contract is (0, X). There is no separate one-sided instrument type — the unbounded side is just a reserved tick value, so pricing, admission and settlement all take the same code path. That is also why a single pricing call over a (lower, upper) range answers both an up quote and a down quote, and why the two probabilities sum to one rather than being quoted independently and reconciled afterwards. The payoff mechanics themselves are covered in binary options vs prediction markets.

What this means for prediction-market liquidity

Prediction-market liquidity has a structural problem that spot trading does not: fragmentation. One BTC spot pair concentrates every participant into a single book. The same underlying, expressed as hourly binaries across a range of strikes, is a separate book per cell — most of them thin, most of the time, with all of the attention in the two or three cells nearest the money. A book alone does not solve this, and pretending otherwise is how venues end up displaying a beautiful order-entry screen over an empty ladder.

Two properties make it tractable. First, a binary contract's payoff is bounded — you can lose the premium and no more, and the maximum liability per contract is known at mint. Bounded liability means the worst case for whoever is on the other side is computable in closed form rather than being an open-ended tail, which is what allows exposure to be sized by a rule the chain can check instead of by a risk desk's discretion. Second, quoting happens in probability space: a price is a number between zero and one, and it is mechanically related to spot, time to expiry and implied volatility. A protocol that can read those inputs on-chain can produce a quote for a cell that has no resting orders at all.

That is the design DeepBook Predict uses on the deployment we integrate against, and it is the part most write-ups get wrong. Binary positions are not crossed against a queue of resting limit orders. They are minted against an on-chain pricer that reads spot, forward and volatility-surface feeds published on Sui alongside Pyth price feeds for the underlying, with sizing constrained by lot size and a premium floor. The CLOB and the pricer are complements: the order book is where the underlying's liquidity and price discovery live, and the surface derived from that market is what makes a quote on an illiquid strike meaningful. How the resulting position resolves is covered in oracle resolution and on-chain settlement.

The fee schedule follows the same probability-space logic, and it has a consequence worth spelling out because it is easy to misread. The per-contract fee rate on that deployment scales with √(p(1−p)), subject to a per-market floor: in absolute terms it is largest near a coin flip, where the pricer is warehousing the most uncertainty, and smallest at the extremes. But a fixed stake buys roughly stake / p contracts, so the fee measured as a fraction of your stake moves the other way — it grows as the probability falls, which makes long shots proportionally the most expensive thing on the board. That is why a correctly built front end sizes quantity and quotes the payout multiple as 1/(p + fee_rate) rather than 1/p: the multiple you are shown should already have the fee in it, not surprise you at settlement.

The lifecycle of one position

1. Read the baseline

   The round's strike is anchored to an on-chain reference tick — a price frozen for that round and snapped to the tick grid — so it is the same number for every participant and nobody gets a private strike. It is published by a keeper rather than existing from the first second of the round, so a market can legitimately read as "baseline pending" before it lands; minting is gated until it does.

2. Quote the range

   Ask the on-chain pricer for the price of a tick range. Above is (strike, +∞); below is (0, strike). The two probabilities sum to one, and the payout multiple is the reciprocal of the probability once the fee rate is folded in.

3. Size to the grid

   Round quantity to a whole lot, check the premium clears the market's floor, and confirm premium plus fee stays inside the maximum cost you authorised. Any one of these wrong and the transaction aborts rather than executing something you did not intend.

4. Mint

   Submit the transaction. The position is created on-chain and held in your account — not as a claim on an operator's ledger.

5. Settle at expiry

   At expiry the protocol settles against its on-chain oracle price. The outcome is a function of published feed data, not of a decision made by a front end.

6. Redeem

   A winning position is redeemed on-chain for the fixed payout in the settlement asset — dUSDC on the testnet deployment. A losing one expires worth nothing.

What is actually live on Predict Bay

Every market page carries a mode switch, and with EVM withdrawn it renders two options rather than three: Practice for free and Sui for DeepBook Predict. What you can trade right now are short-duration price markets on BTC, ETH, SOL, SUI, DOGE and XRP, in hourly and daily rounds. A strike is set at the open, you pick whether the asset finishes above or below it, and the market resolves against an on-chain price feed. Practice mode runs the identical market data, the identical strike and the identical resolution — the only thing that changes is whose money is at stake, which makes it a genuine rehearsal for the microstructure described above rather than a toy. Start on the BTC market or the SUI market, or read how it works end to end.

Sign-in is Google via zkLogin, so there is no seed phrase to record, and transactions can be sponsored so you do not need to hold SUI for gas. Connecting a Sui wallet directly works too. If you want the protocol-level introduction before the microstructure, start with what DeepBook Predict is; if you want the venue-design comparison, Predict Bay vs Polymarket covers the off-chain-book model in more detail, and the token page states what $PBAY is and is not.

Prediction markets carry risk and you can lose what you commit to a position. Nothing here is financial advice.