Three guarantees the running service proves on this request — not marketing, not a CI badge.
Reload to re-run them live against the deployed binary.
Clearing matches the research oracleVERIFIED
247 / 247
oracle vectors reproduced exactly — same clearing price, cleared quantity, and per-order
fill allocation — by re-running the pure Go clear over fixtures embedded from
sim/fba.py::clear_uniform_price, in-process, just now.
random permutations of a 444-order batch cleared to a byte-identical result.
Order of arrival cannot change the outcome — the batch cut is an absolute marker, not a clock
(invariant 0).
cleared price44.48cleared quantity1778 shfills244
Settlement nets to zeroBALANCED
Latest crossed batch #26784: every fill executes at one
uniform price with equal buy and sell volume, so the cash and share legs cancel exactly —
no value is created or destroyed.
Every cleared fill is posted to a real double-entry ledger as a balanced four-leg
delivery-vs-payment transfer, asynchronously — off the matching hot path. A dedicated
settlement worker drains a bounded queue, so matching never blocks on the ledger; the queue
depth and in-flight count below are the live backpressure. The trial balance is computed
across every account, live, right now.
ledger backendin-memory — fast, wiped on restarttransfers posted22209323fills settled22209323 (+1761962 half-unit, not truncated)settlementasync ✓ · 0 in flight · queue 0ledger accounts1456Σ debits = Σ credits29,425,098,212.69 = 29,425,098,212.69cash net / share net0 / 0 (both 0 ⇒ balanced)
Transparency log — tamper-evident, signedVERIFIED
Every cleared trade batch is appended as a leaf to an append-only Merkle log (RFC 6962-style
hashing). The tree head is Ed25519-signed, so altering any past entry changes the
root and breaks the signature — the tamper-evidence a regulated register needs. Both checks
below run live, right now, against the deployed binary.
Don’t take our word for it — your browser fetches the entry, its audit path, and the signed
root, then recomputes the Merkle root locally (SHA-256) and checks it matches. We never tell
your browser the answer; it computes it.
How the line is held
Every change to the core/ledger passes mechanical gates before it can merge:
determinism-lint — no clock, randomness, network, or global sequence inside the clearing core
property suite — uniform-price axioms (single price, no order crosses it, price-time priority, quantity conservation) on fuzzed batches
golden-master — the conformance you see above, also run in CI against the sim oracle
ledger-lint — double-entry balanced, idempotency keys on every transfer, never a float
Proven here, live, from the deployed binary: deterministic permutation-invariant
clearing · conformance to the research oracle · per-batch settlement balance · a real
double-entry ledger settling every fill (trial balance above) · and an Ed25519-signed Merkle
transparency log every trade is appended to. How durability works here: settlement runs asynchronously off the matching hot
path, and the durable system of record is the Postgres event log — the ledger is a
deterministic projection of it, reconstructible by replay, so no settled state is invented or
lost. The balance-ledger above runs behind a single interface with two real backends: a fast
in-memory one, and a durable Postgres one (the “ledger backend” line says which is live).
The durable backend posts every fill and dividend as an ACID transfer that survives a restart and
is queryable — bounded by a TRUNCATE on each start so it cannot outgrow the disk. Disclosed demo simplifications: the durable Postgres backend is opt-in (the in-memory one
is the default, to keep the matching throughput this demo showcases and to keep on-disk growth
flat). Both backends permit overdrafts: accounts are zero-seeded with no genesis equity, so the
clearing/CCP account mirrors traders negative and the unconstrained bots overdraw freely — each
transfer still balances, so the trial balance is exact regardless. The strict, overdraft-refusing
mode is kept for the Phase-2 escrow path, which gates on pre-trade risk. The transparency log is
in-memory. Half-unit notionals are not truncated, so a few fills stay unsettled and are counted,
not hidden. Roadmap, honestly not yet built: pre-trade risk controls on the live trading path, a
persisted transparency log with HSM-held signing keys, real cash-rail (EMT/bank) integration.
This is a demo of the hard core, not a production venue.