Determinism
Every accepted command is processed in a single gap-free sequence. The same ordered input produces identical trades and book states — on any server, on any replay. No randomness, no hidden timing dependence.
Every venue platform claims low latency. Fewer can tell you what happens when a server loses power mid-auction, or show a regulator exactly why a particular trade printed at a particular price eighteen months ago. Those two questions have the same answer here, and it is the reason the system is built the way it is.
Every accepted command is processed in a single gap-free sequence. The same ordered input produces identical trades and book states — on any server, on any replay. No randomness, no hidden timing dependence.
Commands are journaled before they execute; no trade exists whose command is not written. Recovery is a replay — sessions, resting orders, hidden iceberg remainders and sequence numbers restored exactly. Fail-stop, never fail-wrong.
Operator actions travel the same sequenced path as orders, so the journal is a complete timestamped record of what happened and who caused it — the maker and the approver of every administrative action included.
The matching path is entirely in memory, with no I/O and no locks on the critical path. Sub-millisecond to low-millisecond round-trips on commodity server hardware — no exotic network cards, no kernel tuning.
Every accepted command — a member’s order and an operator’s halt alike — is written to an append-only journal before it executes. Nothing else about the system is as consequential as the ordering of those two words: before it executes.
After any failure, including abrupt power loss, the engine restores its latest snapshot and re-executes the journal tail. Sessions, resting orders, hidden iceberg remainders, reference prices and sequence numbers come back exactly.
A production incident is replayed on a test machine and produces the same trades and the same book states. There is no “we could not reproduce it”.
The journal is an ordered, timestamped record of everything that happened to the market and who caused it — including the maker and the approver of every administrative action.
A candidate release is run against a recorded trading day and its output compared to the original, so a behavioural change is visible before it reaches production.
On any detected internal inconsistency, the affected market segment halts rather than emit a trade it cannot stand behind. A halt is embarrassing, recoverable and explainable. An incorrect trade in a regulated venue is none of those things — it has to be broken, which means unwinding settlement, notifying counterparties, and explaining to a regulator why the book cannot be trusted.
Matching contains no randomness and no hidden timing dependence, so there is no class of bug that produces a different result on a different server or a busier day. Given the same ordered input the engine produces identical trades and book states, which is what makes the previous paragraph enforceable rather than aspirational.
No trade exists whose command is not journaled. The write happens first, so a crash between the two can only lose an order — never invent a fill.
Independent instruments never contend with each other, so a halt is scoped to the affected segment rather than the venue.
Because operator commands travel the same sequenced path, a halt and the decision to lift it are themselves auditable events.
<1 ms
Typical order round-trip on commodity hardware
1 → 5,000
Instruments, order books distributed as you grow
In memory
The matching path carries no I/O and no locks
100%
Of accepted commands journaled before they execute
The matching path is entirely in memory, with no I/O and no locks on the critical path. That is the whole trick: there is no clever scheduling to tune and no lock contention to reason about, because neither exists where it would matter.
A live demonstration runs about an hour: the order book, the Control Panel, an auction uncrossing, and a replay of the journal that produced it.