Maker settlement and taker execution
Takers execute against the on-chain curve. The merged book is also public through the read API. Spire merges every maker’s accepted quotes, compresses the merged book into a piecewise-linear curve, and posts that curve on-chain. Takers swap against the curve. When a swap lands, the platform replays it against the exact merged book snapshot that curve was built from and pays each maker at the price that maker streamed. Two consequences:- Each constituent leg settles at its streamed price, with its quote amount floored to the quote token’s smallest unit. The curve’s price never appears in your leg.
- The difference between what the taker paid on the curve and the sum of maker legs is the residual, and it is Spire’s in both directions. It is not shared with you, and it is not charged to you.
Equal prices split pro-rata, not by time
A fill walks the snapshot best price first, and at equal price it is split pro-rata by posted size, with largest-remainder rounding and a deterministic tie-break by maker address. Being first to a price buys you nothing; posting more size at it does.Books are the platform’s liquidity model
BaiBai records one book per maker and pair. An adapter translates the maker’s quote or order messages into that book. The Hyperliquid-compatible interface accepts individual orders, modifications, and cancellations. The gateway builds the per-maker book from their remaining sizes. Attribution tracks consumption across consecutive fills against each published snapshot, so later fills cannot reuse depth already consumed. The publisher also limits offered liquidity by current unreserved inventory.Staleness is yours
Quotes pass through several steps: the gateway accepts your update, the publisher compresses the merged book and posts it about once per block, and the taker executes against the curve available on-chain. Maker legs are priced from the recorded snapshot behind that curve. A market move in between is your risk. Quote expiry and liveness controls bound exposure. Your adapter’s protocol guide explains how to use them. There is no last look: an acknowledged update or cancellation changes the gateway book first, and an earlier on-chain curve may remain executable until replaced or expired. Do not treat a sent-but-unacknowledged update as live.Fill timing
On-chain execution and attribution happen before notification delivery. Plan for the delay when managing inventory and hedging. Read Settlement and fill latency for the timing, confirmation, and reconciliation model; each adapter documents its own notification format.What is public
The read API needs no authentication. It exposes accepted quotes and ledger data as well as information derived from on-chain events:GET /v0/book/{pair}: the merged book of every maker’s accepted quotes, aggregated by price. It does not name makers.GET /v0/fills?pair=…: every on-chain fill with its whole amounts, the taker’s direction, and itsfill_seq.GET /v0/fills/{fill_seq}/decomposition?pair=…: every leg of a fill, each with the maker’s address, streamed price, size, and amounts, plus the residual.GET /v0/checkpoints/latest: every maker’s ledger balance per token, by address.GET /v0/makers/{maker}/limits: any maker’s quotable inventory and funding counters, by address.
openOrders queries by master address.
Funds move on-chain, with a delay
There is no instant withdrawal. The watcher reserves a requested withdrawal out of quoting inventory after observing its mined event, the platform settles a claim on-chain after a fresh checkpoint, and you execute the claim after the custodian’swithdrawDelay() (600 s on Base; read the contract value before withdrawing). Deposits are credited when the platform’s watcher sees the Deposited event, not when the transaction mines. Details in Deposits & withdrawals.