06 — Matching to settlement
Matching, custody, market surveillance and settlement built to pass an audit rather than a demo.
An exchange is three systems that must never disagree: the matching engine, the ledger and custody. Most incidents are not exotic — they are a withdrawal processed against a balance the ledger had not yet reconciled, or a matching engine that accepted an order the risk system would have rejected.
We build the engine deterministic and replayable, the ledger authoritative, and custody separated by policy that is enforced before signing rather than reviewed afterwards. Surveillance runs on the same event stream the engine produces, so what compliance sees is what actually happened.
Common questions
What does proof of reserves actually demonstrate?
That an exchange controlled certain on-chain balances at a point in time, and — with a Merkle tree of liabilities — that a given customer's balance was included. It does not prove the absence of off-chain liabilities, borrowed assets staged for the snapshot, or solvency between snapshots. It is a useful control, not a substitute for audit.
How should hot wallet exposure be limited?
By policy enforced before signing, not by convention. Caps per address, per asset and per time window, with automatic escalation to warm or cold approval above threshold. The limit that matters is the one the signing service refuses to exceed, not the one written in a runbook.
Why must a matching engine be replayable?
Because disputes, incidents and regulatory enquiries all ask the same question: what did the system do, and why. An engine that can replay an ordered event log to reproduce any historical state answers that in minutes. One that cannot answers it with an apology.
Next capability
Digital asset platforms
Bring us the hard part.
Forty-five minutes with the people who would actually run the build.