Monad's only fully on-chain central limit order book — a market structure that's normally too gas- and latency-expensive for the EVM, made viable by Monad's 400ms blocks.
Kuru is a fully on-chain central limit order book (CLOB) built specifically for Monad — market makers post real limit orders at specific prices, exactly like a traditional exchange order book, rather than trading against a bonding-curve formula the way an AMM does. Matching happens entirely in contract state: a taker order "cranks" through resting maker orders and credits the outputs directly, with no off-chain matching engine translating intent into on-chain settlement. It's paired with "Kuru Flow", a smart-order-routing layer that sources liquidity across Kuru's own markets and other venues.
Order books are normally impractical on general-purpose EVM chains: a market maker refreshing quotes needs to place and cancel orders constantly as prices move, and on a slow, expensive chain that's either too costly to do often enough to stay competitive, or too slow to avoid getting picked off by faster traders before a stale quote can be cancelled. This isn't a new problem — Solana's Serum had to cap how many orders a single transaction could match, and dYdX abandoned Ethereum-adjacent infrastructure entirely for a sovereign Cosmos chain in its v4 specifically to control block time and throughput. Monad's own blog uses Kuru as its worked example for this exact tradeoff: halving tick size doubles the resting orders a vault has to manage, and Monad's parallel execution processes independent price-tick updates concurrently rather than serially, backed by sub-second finality. Monad's sub-second block times and low gas costs are close to a precondition for a CLOB to work economically on-chain at all — it's not a coincidence that Kuru was built for Monad specifically rather than ported from elsewhere.
Four contracts do the work: a Router deploys new markets and exposes the multi-hop swap function NullTerminal's own integration calls; an OrderBook per market holds the price-point tree and can be ACTIVE, SOFT_PAUSED or HARD_PAUSED; a MarginAccount is the central balance ledger; and a KuruAMMVault is the constant-product backstop, with its spread sized per market. Beyond standard limit, post-only and market (with optional fill-or-kill) orders, Kuru supports a "Flip Order" that automatically re-posts on the opposite side after each fill — letting a passive LP act like a self-managing micro-market-maker in tight-range pairs (LST/native, stable/stable) without building custom bot infrastructure.
Kuru pairs the order book with a vault-based backstop AMM, so a market isn't simply empty when no market maker happens to be actively quoting it. Vault depositors act as passive liquidity providers behind the active book and earn a share of trading fees for taking on that role, similar in spirit to how an AMM LP earns fees — except here it's a liquidity floor underneath a real order book rather than the entire pricing mechanism. LPs choose a liquidity shape — "Curve" (concentrated near mid-price, for correlated pairs, modeled on the same intuition as Curve's StableSwap), "Spot" (uniform) or "BidAsk" (edge-weighted, for volatile pairs).
A CLOB's core tradeoff against any AMM is that market-making on a real order book demands active capital, tooling and strategy — it's inherently less passive than dropping funds into a pool, which is precisely the gap Kuru's Flip Orders and shaped vaults try to close. Against Uniswap V4, the two solve overlapping problems differently: V4's hooks can bolt on limit-order-like behavior to a pool, but Kuru matches real resting orders natively rather than approximating one through pool logic. Against Curve's StableSwap invariant, Kuru's own "Curve" liquidity shape borrows the same near-peg concentration intuition, just implemented as discrete order placement instead of a continuous integral — useful context for LPs who understand Curve and are evaluating Kuru's shaped vaults. Against plain constant-product AMMs generally, a CLOB can offer materially tighter execution at size when real market makers are active, but degrades to something closer to the AMM backstop's own pricing the moment they aren't.
Kuru doesn't let external contracts call its order book directly — swaps have to route through its router contract, which is a deliberate design choice to keep order matching consistent. Its set of tradable markets also isn't fixed; new markets get added as the exchange grows, so anything routing through Kuru needs to discover markets dynamically rather than hardcoding a list, which is the approach NullTerminal's own integration takes.
A CLOB is only as good as the market makers actively quoting it — outside the one or two pairs with real market-maker attention, spreads can be wide or the book can be thin near the touch price, even with the AMM backstop underneath. Kuru's own audit disclosure notes one accepted design tradeoff: because the backstop vault doesn't reinvest fees the way a standard constant-product pool does, it can drift imbalanced, and an arbitrageur can extract a zero-slippage swap via a deposit-then-withdraw cycle — Kuru's team classifies this as by-design rather than a bug, but it's worth knowing as a user of the vault side specifically. Kuru's exact taker fee schedule isn't published in flat-percentage terms the way an AMM fee tier is — LP economics are effectively the bid/ask spread the vault sets (roughly 0.05% for tight/stable pairs, 0.30% for wider/volatile ones, per its own docs), which makes it harder to compare cost-to-trade at a glance against a transparent AMM fee tier.
Note: NullTerminal routes through Kuru automatically when its book offers the best price, and caps trade size against Kuru specifically to keep quotes honest on thinner markets rather than reporting a price the book can't actually fill.
It's genuinely hybrid: order matching is fully on-chain and real limit orders from market makers do get matched directly against takers, but every market also has a constant-product AMM vault underneath as a backstop, so a quote can blend real limit-order liquidity with AMM liquidity depending on the market's depth at that moment.
Market makers need to constantly cancel and replace resting orders as prices move — on a slow, expensive chain that's either too costly to do often enough to stay competitive, or slow enough that a stale quote gets picked off by faster traders before it can be cancelled. Historically this pushed order-book exchanges like Serum and dYdX off general-purpose L1s entirely; Monad's throughput and sub-second blocks are close to a precondition for doing it economically on-chain.
Kuru states its core contracts have been through audits by Spearbit and Cantina (each with an initial and post-fix review), plus a separate audit of the Kuru Flow router, plus a public Cantina security competition (August–September 2025, a $100K prize pool, 1,147 submitted findings). No public reports of Kuru itself being hacked were found.
Standard limit, post-only and market orders (with optional fill-or-kill) are all supported, plus a Kuru-specific "Flip Order" that automatically reposts on the opposite side after each fill — useful for passively market-making a tight-range pair without running your own bot.
Sources: Kuru Docs, Guide to Kuru Finance — Backpack Learn, Kuru x Monad — Medium, Kuru contract architecture — Docs, Next-gen CLOB — Monad Blog, Kuru audits — Docs, Paradigm leads $11.6M round for Kuru Labs — CoinDesk
Last reviewed 2026-07-08. More Monad research.
Monad DeFi board · Markets · Swap on NullTerminal