Pairs with real liquidity get an order book, because that is what it takes to give a trader limit orders and a tight spread. Everything else gets a pool, which will quote a price at any size and charge more the bigger the order gets.
Both, rather than one, because neither covers the other's ground. A book has nothing to say about an asset nobody is making a market in yet, and a pool has nothing to offer a trader who wants to sit on a limit order at a price of their own choosing.
How the two halves fit
A pair is not assigned to a book or a pool by us deciding it deserves one. It is assigned by whether there is enough liquidity for a book to function, and that can change.
Limit orders, visible depth, price-time priority matching, and a maker and taker fee. It runs in the native engine because this is the kind of thing that engine was built for, and it is the one component that genuinely benefits from a fast block rate. A pool barely notices block time. A book meant to feel like an exchange notices nothing else.
Anyone can create a pool for any pair without asking us, and pools run on both execution engines, so a developer already working in one of them does not have to move to the other. Constant product to begin with. Concentrated liquidity is a sensible later upgrade and we are not going to describe it as a launch feature.
A pair that starts in a pool and grows past a volume and liquidity threshold can be listed on the book instead. Where that threshold sits is a governance parameter rather than a number we are fixing on this page, because the right level depends on how much liquidity the network actually has and nobody knows that yet.
Slippage protection on both the book and the pools reads from the oracle service the Compute Mesh already provides, which is the same machinery being audited for everything else. Reusing it adds no new assumption about who has to be trusted. A second price source would have added one.
What launches, and what waits
The version of this worth being excited about is the one where a token on the EVM side and a token on the native side trade directly against each other, out of a single pool of liquidity rather than two separate ones. That is what the router between the two engines exists to make possible.
It is also not what launches. The router starts with a narrow allowlist of the call patterns it will permit, and widening that list is a security decision taken on evidence rather than a feature we can schedule. So at mainnet each side trades with itself: the native side runs the book and its own pools, the EVM side runs pools for EVM tokens, and both are complete. They are simply not joined yet.
Saying that now costs us the more impressive version of the sentence. Shipping cross-engine pairs early and then finding out why the allowlist was narrow would cost considerably more, and it would be somebody else's money rather than our credibility.
at mainnet
native side order book + pools, native assets
evm side pools, evm assets
between them nothing yet
once the router's allowlist widens
between them cross-engine pairs, liquidity joined
its own audit, on top of the router's
not at launch, and not on a date
leverage no
perpetuals no
synthetics no
fair ordering research. a stretch goal for the book,
not something to plan aroundSpot only is not caution for its own sake. The rules for centralised derivatives venues have become a good deal clearer recently, and that clarity has not extended to decentralised ones, where enforcement action from a few years ago still stands and the question is being argued among regulators themselves. Spot avoids the argument entirely. What would change it is a dedicated legal review finding the picture settled, not a date we picked in advance.