We changed how we talk about performance.

A load generator rate is no longer enough. The live benchmark now keeps every signed transaction envelope, checks admission, waits for the exact committed hash, and records finality from broadcast start to the committed query. At the same time it samples every validator’s process metrics and binds each metrics endpoint to the node identity reported by RPC.

That makes the result harder to earn and much easier to audit.

The four-validator result

On July 12, a fresh four-validator, 20-worker, 20-second live run committed 1,580 of 1,580 zero-fee native transfers at 5ms query cadence. Admission P95 was 0.866ms. Finality measured 241.875ms at P50, 330.774ms at P95, and 396.590ms at P99.

The closed-loop workflow rate was 78.42 committed transactions per second. That is not a saturation-capacity result: each worker waits for commitment before sending its next transfer.

Aggregate validator CPU averaged 1.8325 cores. Peak process RSS across the set was 1,687,814,144 bytes, or 1,609.625 MiB. Individual peaks were 436,371,456, 421,429,248, 411,500,544, and 418,512,896 bytes.

After stopping and restarting the same persisted validator homes, a second 10-second run committed 765 of 765 transfers at the same 5ms query cadence. It recorded 360.896ms P95 finality and a lower aggregate RSS peak of 1,232,338,944 bytes.

Both runs passed the 500ms P95 finality target and stayed below the 2 GiB aggregate validator-set memory boundary. Both used zero native transfer fees.

What the numbers do not prove

They do not reproduce the stressnet’s multi-in-flight workload, and they do not establish maximum transaction-envelope capacity. The benchmark is closed-loop by design. A separate saturation workload is still required before making that claim.

Source record