Mirror has no load numbers for the hosted operator, and this page does not invent any. It states what was measured, on one machine, with the tool that measured it, and then says what has not been measured and how a pilot would measure it.
What was measured#
node server/load-test.js starts one operator on the loopback interface, sends signed reconciliations over HTTP, and reports throughput and latency. Run on 9 October 2026:
| Setting | Result |
|---|---|
| Machine | Intel Core i5-8265U (1.6 GHz base), 8 threads, 8 GB RAM, Windows 11, Node 24.16.0 |
| Requests | 2,000 reconciliations of 3 committed legs each, 16 in flight |
| Verdicts signed | 2,000 of 2,000 (no failures) |
| Throughput | about 497 signed verdicts per second, one Node process |
| Latency | p50 29 ms, p95 40 ms, p99 58 ms, max 228 ms |
| Registry fold | one full fold of 40,000 governance events (20,000 corridors): 130 ms |
These numbers describe one process on one laptop with an in-memory store, over loopback. They do not include the network, the database, the Cloudflare Worker or the EU Durable Object.
The bottleneck the fold number exposes#
The hosted operator runs in "fresh reads" mode. Every state-dependent route re-reads the governance log from its store and folds it into the registry before answering, so that a fresh isolate never acts on stale governance. The cost of that fold grows with every corridor, member and witness ever ratified. At 40,000 events it is 130 ms of CPU per request, before the read from the store, and the store read returns up to 100,000 rows per call.
This is the first thing to fix, and it is a reason to measure before anything else. The design below starts there.
The design#
1. Incremental fold (first, and small). Keep the folded registry in memory, keyed by the highest event sequence number it has applied. A request reads only the events after that sequence and folds those into the existing state. The fold is already deterministic and append-only, so a fold of the new events onto the old state gives the same registry as a full fold; the test for that is a property the registry can state, and this change makes it load-bearing. Cost per request becomes proportional to new governance, not to all of it.
2. Shard the verdict ledger by corridor. A verdict belongs to one corridor. Each corridor's ledger (the signed verdicts, the idempotency keys, the counts) can live on its own Durable Object, so two corridors never contend for one writer. The registry stays global and read-mostly: a corridor's governance is the only state a verdict needs from it, and that is what the incremental fold delivers.
3. Governance stays single-writer. Governance events are rare, quorum-gated, and must be totally ordered. They keep one writer per federation (see federation), and that writer publishes a signed snapshot per registry version. Everything else reads snapshots.
4. Snapshots instead of re-reads. A snapshot is the signed registry at a version. A host verifies a snapshot against the operator key it already holds and serves reads from it, so a read costs a verification, not a log scan. A stale snapshot is detectable, because it names its version.
5. Measure each step against the previous one. The load tool runs against a pilot's own staging operator. A change ships only with before-and-after numbers on the same machine, and the page is updated with them.
What is not measured, and what would measure it#
- The Cloudflare Worker and its Durable Object, in the EU jurisdiction: the request path, the object's own limits and the store read. These need a load run against a staging deployment, never the live rail, because a load run creates governance-visible activity.
- The store: the PostgREST read of the governance log at realistic sizes.
- Multi-operator federation: k operators reconciling the same legs. Each reconciles independently, so the cost is roughly k times one operator, plus the bank's fan-out. It is not measured.
- Verdict volume over a real corridor, at a real bank's rate. No bank has run a pilot. Any throughput figure that claims a customer's volume would be invented.
What a pilot does#
- Stand up a staging operator (
node server/app.jswith a staging key and a store). - Run
node server/load-test.js --requests 10000 --concurrency 32 --legs 3 --fold <the governance size you expect>and keep the output. - Repeat against the deployed staging Worker with the same parameters, and report both.
- Ask for the governance size the first corridor will reach in a year, and measure the fold at that size.
The numbers that matter are the ones a bank can reproduce on its own machine.