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. So we load-tested for both speed and correctness, held correctness to a zero-tolerance bar, and published every number. Here is what happened, and here is where you can check it.
Correct
0
violations across 1,550,594 transactions. An independent audit recomputed every balance from raw records. Every check returned zero.
Fast
1,600tx/s
payments delivered end to end, at 100% completion, through the top of the ramp. A payment here is a full authorize and capture, the heavy path.
Headroom
~26% used
of the single database writer's processor at the top rate. The ceiling is well above what we drove. That gap is the point.
The part that matters most
It stayed correct, and we did not trust ourselves to say so.
After the load, an audit recomputed every account balance directly from the raw transaction records, without trusting the software's own bookkeeping, and asked whether the books still hold. Four checks, each of which must be exactly zero.
- 0
Conservation
The signed sum of every entry, per currency, is zero. Money is neither created nor destroyed.
- 0
Every transaction balances
No single transaction leaves the books uneven.
- 0
Stored equals recomputed
Every account's balance matches the sum of its own history. Nothing drifted.
- 0
No overdraft past the floor
No account holds a balance its rules do not permit.
Independently, the load generator watched the same invariants live during the run and recorded 0 violations and 0 double-spends across 623,564 money operations. Two methods, no shared code, same answer.
Fast, with room to grow
As the load climbed, the writer barely woke up.
We raised offered load from 400 to 1,600 payments per second. Below, both the database's scaling capacity and its processor are drawn as a share of what the single writer could give. The empty space above the lines is the headroom.
Nothing dropped
Every payment offered was delivered, at every step.
The honest part
We found a wall, and moved it.
An earlier run of this test hit a ceiling far lower than this, at a point where the database's processor sat mostly idle. A resource that is half-asleep while throughput refuses to climb is not a capacity limit. It is a contention limit: something was serialising the work and starving the rest.
We traced it to a locking bottleneck deep in the database write path, removed it, and re-ran exactly the same test. Throughput more than tripled, and the correctness bar did not move a hair. That is the result on this page.
We are not going to walk you through how the fix works, because that is our engineering. What we will tell you is the habit behind it: we went looking for the true number instead of the flattering one, and we hold the ledger to the same zero-tolerance correctness bar at 1,600 payments per second as at rest.
See for yourself
The numbers are public. So is how we got them.
Everything above lives in one open repository: the raw load-generator report, the aggregated data as plain CSV and JSON, the charts, and a SHA-256 manifest so you can prove nothing was altered after publication.
Open evidence that the WalletD ledger stays correct under load, and moves money fast with room to spare. Raw data, charts, and a hash manifest. No code, no claims you cannot check.
Early access
Become a design partner.
We are working with a small number of teams building wallet and money products on WalletD. If that is you, let's talk. You will get direct access to the people who built it.