Notes
The thinking behind the ledger.
Two streams: what instant-payment rails demand of a participant's ledger, for the people deciding — and the engineering notes on where financial correctness lives, for the people building.
Real-time payments
For institutions joining instant rails: posting in front of the core, one balance across rails, and intraday liquidity.
Instant rails meet batch cores
Real-time rails settle in seconds, around the clock. Most cores post in batches. The posting layer in between is where it breaks.
Read noteOne balance across every rail
A customer has one balance. Most systems give each payment rail its own copy of it — and that gap is where money gets spent twice.
Read noteIntraday liquidity you can enforce, not just report
Treasury usually learns the intraday position from a report. On an instant rail, the position has to be a limit the ledger enforces on every payment.
Read noteEngineering notes
Where financial correctness lives in the engine.
A balanced ledger can still be wrong
Conservation checks are necessary and nowhere near sufficient. Here are the faults a perfectly balanced ledger can hide — and how we test for them.
Read noteReplication that checks its own homework
Before a follower's acknowledgement counts toward quorum, the leader verifies a hash of the follower's entire log. Here's why, and what happens on a mismatch.
Read noteOne hot account is a serialization point
A single account's throughput is bounded by the replicated write path, cluster-wide — and we learned the hard way what it takes to measure that number honestly.
Read noteWhy our installer refuses curl | sh
Piping a script from the network into a shell skips every chance to verify it. Our installer detects the pipe and aborts — here's the design behind that.
Read noteDesign partners
Preparing for an instant rail?
Prove a real-time posting layer in shadow mode before anything depends on it. We reply within one business day.