Skip to main content
This page reports what the scalability harness measured on the reference node. Every figure comes from the whitepaper’s benchmark runs.

Method

The harness drives the node through POST /submit with a replayable set of one-to-one transfer transactions, at a fixed target rate for a fixed duration, then watches a recovery window. The harness distinguishes three counts:
  • Enqueued: accepted onto the ingress queue.
  • Durably accepted: inserted into the mempool.
  • Committed: included in a committed block.

Throughput

The node sustained 1,000 transactions per second for 30 minutes and committed more than 1.5 million transactions, with zero commitment failures and zero merge failures. Runs made on 27 to 29 May 2026:
  • The sustained 800 TPS run committed 1,292,478 transactions. The sustained 1,000 TPS run committed 1,571,744.
  • Both had zero commitment failures and zero merge failures.
  • Every run ended with an empty mempool and queue after its recovery window.
A run passes when the node stays available, the mempool and queue recover within the recovery window, and commitment and merge failures stay below the configured thresholds.

L1 cost per block

Each L1 commitment transaction costs a fixed fee, whatever the number of L2 transactions in the block. In these runs that was 229,155 lovelace. So the L1 cost per L2 transaction falls as blocks fill:

Batching

The node can defer a block to fill it. In a paired run at 100 TPS on the same host, batching cut the number of blocks from 508 to 91 for the same transactions. Total L1 commitment fees fell by 82%, at unchanged throughput.

Where the time goes

A transaction passes through five hops from submission to confirmation: The first three hops come before a transaction is in a committed block. Confirmation takes the full maturity period. See Protocol parameters.

Reproducing the runs

The harness and the reports of every run are in the monorepo.