We pushed our ledger until something broke. It wasn't the ledger.

Past the comfortable rate, we kept going

Our earlier study showed that the ledger stayed correct and fast at a published rate, with headroom to spare. This time the goal was different: not to find a number we liked, but to find the point where the system stopped keeping up and learn what that point actually was.

We ramped the full payment path—the complete authorize-and-capture, the heavy path—well beyond where latency began to climb and watched for the first component to buckle.

The wall was our own database contention

Throughput stopped climbing even though the database processor was nowhere near busy. That is the signature of contention: work is being serialised somewhere instead of a resource running out.

We traced the limit to a contention point in our own database write path, removed it, and drove the same ramp again.

The result was direct: every offered payment committed, at 100%, all the way to 2,600 per second, with zero hard failures. At that load, the managed ledger database was using only about half of its maximum capacity and under half of its processor.

The published 1,600 payments per second sits comfortably inside that measured envelope. It was a conservative number, and the later run shows why.

The next limit is the easy part

Once the database contention was gone, the ceiling moved to ordinary stateless compute in front of the ledger—the part of a system that scales horizontally by adding more instances. That is a good place for a limit to live.

The hard part of a payments platform is not accepting requests. It is keeping a ledger perfectly correct while money moves under load. That part was never the bottleneck.

An independent audit recomputed every balance from raw records across 1.3 million transactions:

Every invariant returned zero.

The limit moved to ordinary compute. The correctness boundary did not move at all.

The evidence is public