Stellar's Thruput benchmark hit 7.02 million payments a second

The Stellar Development Foundation published Project Thruput on 28 October, a technology preview of an execution model that grows by adding machines. Its headline number is 7.02 million payments a second, measured inside a single validator running on eight AWS hosts, up from 1.18 million on one host. The foundation states in the same post that these are not end-to-end network throughput figures, and the benchmark repository is blunter.

“no consensus or mempool in the path yet”

— Stellar Development Foundation, in the README of Whitney, the benchmark that produced the 7.02 million figure, https://github.com/thruputchain/whitney

The design drops the sequential order inside a block. Every transaction reads the same snapshot of state from the previous block and runs beside the others without seeing what they do. Contracts record relative changes rather than final values, and the runtime merges compatible changes when the block closes. That is what lets two payments from the same account run at the same time instead of queueing, and the work spreads across machines without splitting the state between them.

What the benchmark measured

• eight r8a.16xlarge hosts, 64 AMD Zen 5 cores each, in one availability zone
• ERC-20 style transfers between 100 accounts, median of three runs
• state on tmpfs, 4 million transactions per block, no consensus layer in the path

Run the arithmetic on the scaling. Eight times the hardware returned 5.95 times the throughput, so each machine added about three quarters of a machine. Those eight hosts carry 512 cores between them, which puts the result at 13,711 payments per core per second. The repository also publishes a second curve, with 10,000 sender accounts instead of 100, and that one finishes at 6.33 million. The foundation quoted the faster of its two numbers, and the slower one is the more realistic account distribution.

No fee per transaction, a balance instead

Thruput charges nothing per transaction, and the foundation says there is no gas charge for a micropayment or a complex calculation. Gas still measures and caps what a single transaction may execute. When demand runs past capacity, an account's share of scheduling capacity comes from its unlocked native-token balance, with no priority fees and no tokens spent on scheduling. Storing data locks part of that balance until the data goes away. You stop paying per transaction and start holding tokens for the right to send them, so the cost moves from the sender's fee to the sender's balance. Tearsheet reported from Meridian that the balance in question is XLM; the foundation's own post says native token.

The preview runs on FutureNet with open code, white papers and a benchmark anyone with an AWS account can rerun for about 20 minutes of 11 large instances. The foundation has not said how Thruput relates to the Stellar network that exists, or on what timeline, and Tearsheet noted from Meridian that nobody outside the foundation has reproduced the number. Solana spent this month on the same gap: its block time dropped to 200 milliseconds and throughput stayed flat, and Alpenglow cut finality from 12.8 seconds to 150 milliseconds.

Wait for the figure that includes consensus, a mempool, storage that survives a restart and accounts spread the way real ones are. Until then 7.02 million describes an engine on a bench, measured without the parts that slow a network down.

Informational material. Benchmark conditions and results come from the Stellar Development Foundation's announcement and the Whitney repository, the XLM detail from Tearsheet's report from Meridian. The scaling efficiency, the per-core figure and the comparison of the two account curves are ours.