We ran 42 million orders through one contended order book on a single core

Most throughput benchmarks are set up so transactions never collide: shard it, parallelize it, quote a huge TPS number. A number you get by spreading the load describes the benchmark rather than the engine. Real usage concentrates on a handful of applications carrying most of the traffic, and that hotspot is exactly where execution engines fail.

So we ran the opposite test. Everything goes through one contended order book on a single CPU core, no sharding, nowhere for the load to hide.

Results:

This is the execution engine and global state tree of a blockchain we're building. Consensus, proving, and networking are not part of this measurement; scope details below.

Why maximum contention is the honest unit

A single order book with one shared state is the worst case for any parallel execution scheme. Every order conflicts with every other order, so there is nothing to parallelize. No sharding layout or optimistic scheduler gets around that. A contended book serializes.

That makes single-thread throughput on one book the hardest number to game. Aggregate TPS is roughly this number times the count of independent lanes in the workload, and quoting the aggregate assumes traffic spreads evenly across them. Real traffic doesn't spread evenly.

We're not aware of an on-chain market that sustains this rate on a single contended pair. If you know of one measured under comparable conditions, we want to see it.

The workload

We used a central limit order book because it's the harshest contention case we know: one trading pair, every order competing for the same book and the same state.

Order flow is an evenly split two-sided book (50.0% bids / 50.0% asks) around a mid-price that random-walks ±0.05% per block from 100. Each side's limit price is Gaussian around mid ± half of the 0.5% spread, with σ = 3× that spread, so prices span 96.60–103.41 (p1–p99, σ 1.44) and the median bid (100.23) sits 0.46 above the median ask (99.77).

The book is deliberately crossed, which is what leaves the matcher something to clear and explains the ~56% fully-executed rate. That's the anti-gaming choice, not fill-rate rigging: matches are the expensive path — they mutate the book and the state tree — while resting inserts are cheap, so a crossed book maximizes real work per order.

Sizes are log-normal (μ=3, σ=1.5), strongly heavy-tailed: median 20.1, mean 61.9, p99 658, max 46,670, with the largest 1% of orders carrying 20.5% of total volume. Block lengths are Gamma-distributed with shape 1.009, near-exponential, so per-block counts swing from 8.7k up to hundreds of thousands rather than sitting at the mean.

• 56.6% of orders filled fully, 0.1% partially, 43.3% cancelled. The book was doing real matching work, not just absorbing inserts.

• Price-time priority matching.

Scope

Execution ran sequentially inside our VM on 1 thread, and each of the 200 blocks committed a state root inside the 231.02 s.

State roots are computed with Blake2b over our global state tree. We're not describing the tree layout before mainnet.

Orders were generated for each block in advance with deterministic seeded randomness. Blocks executed sequentially: as soon as one block's orders finish executing, we merklize and move straight to the next block. That's also where the block count comes from — 200 pre-generated blocks of Gamma-distributed length. Block length here is a workload parameter, not the chain's target block time.

Not measured:

• Consensus, networking, proving. This is the execution layer only.
• Privacy. The engine is privacy-default by design, but privacy was off in this run. We won't claim privacy-on performance until we've measured it.
• Sustained load. This run is about four minutes; a soak run is on the list.
• Multi-market scaling. A transaction only queues behind the state it touches, so a hot market shouldn't slow unrelated traffic. That's a design property we're asserting here, not something this run shows. It's the next benchmark.

Objections we expect

"Closed source, so this is marketing." The engine is closed until mainnet. What you can check today: the full order trace, which you can verify is contention-shaped and internally consistent, plus the workload spec — generation is deterministically seeded, so the spec plus the seed regenerates the exact trace. The per-block roots also work as a commitment. Once the engine is public at mainnet, anyone can replay this trace and check every root, so if we fabricated the run we eventually get caught. And if you have an engine of comparable scope, state commitment included, beating this on like hardware, post it.

"LMAX did millions of ops/s on one thread fifteen years ago." True, and match-only our number would be higher too. The comparison leaves out the state tree: a chain commits a verifiable global state root every block while it matches, and that's where the budget goes.

"Only 231 seconds?" Yes. A soak run is on the backlog.

"Why 1 core of 8?" One contended book leaves nothing for the other cores to do. That's the point of the test. Independent markets scale across cores; that run comes separately.

Why we're building this

On-chain markets have always given up throughput for a book you can verify. This run says that choice is going away. And desks that trade at this scale won't broadcast their flow, which is why privacy went into the engine itself.

We're taking five design partners pre-testnet. CONTACT-EMAIL-HERE if what you're building lives in the hotspot. Methodology questions: we'll be in the comments.