Order Book
Pod has an enshrined central limit order book (CLOB) built into the protocol as a precompile.
Orderbook precompile address: 0x50d0000000000000000000000000000000000002 (same on every Pod network). All submitOrder / cancel / update / deposit / withdraw calls target this address — see the Orderbook precompile reference for the full ABI.
Orders are immediately added to the order book as soon as they are finalized through the standard attestation flow - they do not wait for the current batch to conclude. This means cancellations and modifications are also applied responsively, before the next matching round. This is better than systems that execute cancels and modifications at the top of a block, because in Pod the liquidity from cancels and updates can already be reflected in the book before waiting for batch confirmation.
Order Types
The order book supports limit orders and market orders. The direction of a trade is determined by the sign of the volume parameter - positive for buy/bid, negative for sell/ask.
All markets use 1e18 tick sizes, matching the token decimal standard.
Market Data
The full node includes a built-in indexer for both live and historical market data. This provides order book snapshots, OHLCV candles, account-level order history, and position data without requiring users to run their own indexer. See the ob_ endpoints in the JSON-RPC reference.
Matching
Pod uses frequent batch auctions to match orders. Instead of processing orders one at a time as they arrive (continuous trading), orders are collected over a short interval and matched together at a single uniform clearing price. This removes timing-based ordering advantages - competition is on price alone.
Each market has a fixed batch interval that defines how often matching rounds run. At the end of every interval the solver settles a batch covering all orders whose deadline lands at or before that interval. See Market Configurations for the per-market interval on live markets.
Clearing
At the end of each batch interval, the matching engine runs a double auction using the average mechanism (for simplification, we describe a case where all orders have unit size):
Buy orders are sorted by price in descending order: b1 >= b2 >= ... >= bn.
Sell orders are sorted by price in ascending order: s1 <= s2 <= ... <= sn.
The breakeven index k is the largest index where bk >= sk.
The clearing price is set to the average of the kth values: p = (bk + sk) / 2.
The first k buyers and sellers trade at price p.
All matched orders execute at the same uniform price. No participant gets a better or worse price based on when their order arrived within the batch.
Market orders do not influence the clearing price — only limit orders at the margin determine it. If the marginal matched order on one side is a market order, the clearing price equals the limit price from the other side alone. If no limit orders were matched at all, the previous batch's clearing price carries over.
Batch Deadline
The deadline parameter in submitOrder specifies the latest batch the user wants their order included in. The order can be included in any batch up to and including the deadline batch — so pushing deadline further into the future widens the window of batches the order can land in, it does not delay execution.
deadline must be aligned to the market's auction_interval (a multiple of it); intents whose deadline is not aligned are rejected by the validator with "CLOB validation failed: Deadline is not aligned to auction interval". Compute it as:
LAG is the headroom you give for network and attestation propagation, capped at 10 minutes in the future from now_us. Most integrators should aim for at least 1 minute; experts who want to target a specific upcoming batch can push it lower at the risk of missing the batch if the transaction doesn't reach enough validators in time. This 10-minute ceiling is the maximum last look duration and is expected to shorten as the network matures.
The protocol guarantees (via past perfection) that if an order receives n - f attestations within the deadline - which it will if it was sent sufficiently early - it will be part of a batch up to and including the latest batch specified by the deadline.
Transactions that do not receive a finality certificate may still be used for matching, but they do not get to settle - the user cannot withdraw funds even if their order is matched. This is by design, to prevent last look attacks.
Traders can set the deadline to be small to ensure they are matched quickly, but they open up the risk of not being able to claim funds if they do not receive sufficient attestations in time. Traders setting recent deadlines should estimate their network latency to honest validators.
Solver
The solver is the service responsible for settling a batch. It can be a rotating set of solvers or a single entity, configurable per market. The solver waits for the auction deadline and then settles the batch.
The solver does not get any additional advantage. It cannot censor transactions or include transactions that were not submitted in time. It has some flexibility on whether to include out-of-time transactions - orders submitted after the batch timestamp, or orders that received some attestations but fewer than the required n − f. These orders always lose, because they cannot claim funds even if they get matched.
References
E. Budish, P. Cramton, J. Shim. The High-Frequency Trading Arms Race: Frequent Batch Auctions as a Market Design Response. Quarterly Journal of Economics, 2015.
AMM Order Book
Coming soon.
Pod's order book allows traders to attach custom EVM contracts that define pricing curves for their orders. This enables AMMs and limit orders to coexist natively on the same book. Markets can be bootstrapped using passive AMM curves and progressively transition to professional market maker liquidity for tighter spreads and better price discovery. Market makers can update orders across the entire pricing curve with minimal state changes.
Last updated