Engineering, in the open
We proved our ledger stays correct at 1,600 payments a second.
A ledger has one job it can never get wrong: the books must balance, always, no matter how much money is moving. We load-tested for speed and correctness, then published every number.
0
correctness violations
Across 1,550,594 audited transactions.
1,600payments/s
delivered end to end
100% completion through the top of the measured ramp.
~26% used
writer processor
At the highest published payment rate.
Correctness was the gate, not a footnote
Performance only matters after correctness. We treated every ledger invariant as a zero-tolerance gate, then checked the result without trusting the application’s own bookkeeping.
After the run, an independent audit recomputed every account balance directly from raw transaction records and asked whether the books still held. Four checks had to return exactly zero:
Conservation
The signed sum of every entry, per currency, is zero. Money is neither created nor destroyed.
Every transaction balances
No individual transaction leaves the books uneven.
Stored equals recomputed
Every stored account balance matches the sum of its own history.
No overdraft past the floor
No account holds a balance its rules do not permit.
Independently, the load generator watched the same invariants during the run and recorded 0 violations and 0 double-spends across 623,564 money operations. Two methods, no shared code, same answer.
A ledger that is fast but cannot prove it stayed balanced is not a fast ledger. It is an unmeasured risk.
The writer had room to spare
We raised offered load from 400 to 1,600 full authorize-and-capture payments per second. At the top rate, the single database writer used about 32% of its scaling capacity and 26% of its processor.
Those figures share one axis below. The empty space above the lines is the useful part: measured headroom, not an extrapolated throughput claim.
Resource headroom
The writer stayed far below its ceiling.
End-to-end delivery
Every offered payment completed.
100% at every plateau
The source series is published as resource-usage.csv. Delivery figures come from throughput-ladder.csv.
We found a wall, and moved it
An earlier run hit a ceiling far below this point while the database processor sat mostly idle. A resource that is half-asleep while throughput refuses to climb is not at capacity. Something is serialising the work.
We traced that behaviour to a locking bottleneck deep in the database write path, removed it, and ran the same test again. Throughput more than tripled while the correctness bar did not move.
We are not publishing the implementation of the fix. We are publishing the engineering habit behind it: look for the true number instead of the flattering one, and hold the ledger to the same zero-tolerance correctness standard under load as at rest.
The evidence is public
Early access
Become a design partner.
Bring us your collection-to-payout workflow. We are working with design partners building merchant wallet and payment products. Talk directly with the engineers building the platform.