Hyperscale: 500K TPS Public Test

Overview

In January 2026, the Radix Foundation completed the final public Hyperscale test, demonstrating that its Hyperscale reference implementation could sustain over 500,000 transactions per second and peak above 700,000 TPS – on commodity hardware using Amazon Web Services m6i.xlarge instances (4 CPU cores, 16 GB RAM per validator node).

The test was documented in a February 20, 2026 blog post titled "Interim Hyperscale: Closing the Chapter." The word "interim" signals that these results represent a milestone rather than a ceiling.

The results are frequently attributed to Cerberus. That attribution is disputed by the lead developer of the Xi'an production candidate, who states that "Hyperscale never really used Cerberus". The throughput figures are a property of the implementation that was tested, not of the protocol specified in the Cerberus whitepaper – whose braiding mechanism has never run in production.

Linear Scaling Confirmed

The defining result of the Hyperscale test series is the confirmation of linear scaling. Private tests compared 64-shard and 128-shard configurations directly:

• 64 shards: ~250,000 TPS
• 128 shards: ~500,000 TPS

Doubling the shard count doubled the throughput, holding per-shard throughput constant – the property a sharded design exists to deliver. The public test confirmed it in practice with real cross-shard atomic swap transactions rather than simplified transfer workloads.

The bottleneck during testing was transaction generation, not consensus. At peak load, the six m6i.12xlarge spam nodes (48 CPU cores, 192 GB RAM each) reached their generation limits before the validator network reached its processing limit, suggesting actual protocol capacity exceeds the measured results.

The Committee-Size Caveat

One qualification is important for reading these numbers forward. According to the lead developer of hyperscale-rs, the reference implementation could only sustain its headline throughput with very small per-shard committees, where the cost of inter-shard messaging stays hidden. At the committee sizes the Xi'an candidate targets – around 100 validators per shard, for meaningful Byzantine fault tolerance – he assesses that the older design would saturate the bandwidth of a single data centre at a fraction of the throughput. The published test materials do not state the per-shard committee size used.

Test Infrastructure

The public test involved 384 bootstrap nodes, 40 validator nodes, and 6 load-generation nodes, all provisioned on AWS using Terraform and Ansible automation. More than 590 community nodes also participated in the public phase, running hardware ranging from datacenter servers to laptops.

Cross-shard atomic integrity was maintained throughout. Every swap transaction that crossed shard boundaries either fully succeeded or fully reverted – no partial state was ever committed.

Open Sourcing Plans

The Radix Foundation stated that code, tooling, and test logs are prepared for publication to enable independent reproduction of the results. Open sourcing requires agreement with parties outside the Foundation and did not have a confirmed timeline at the time of the blog post.

The community implementation hyperscale-rs predates this announcement. Its lead developer has stated it "throws out almost all designs" from both the original Cerberus and the Foundation's Hyperscale reference implementation; its per-shard consensus is HotStuff-2–derived rather than Cerberus.

What the Test Establishes for Xi'an

The tests demonstrate that a sharded Radix network can scale linearly on commodity hardware with real cross-shard transactions, and that cross-shard atomicity holds under load. That is a meaningful result about the approach.

What the test does not establish is the performance of Xi'an as it is now being built. The software measured here is not the software heading for mainnet: the hyperscale-rs candidate replaced the consensus design, targets committees roughly an order of magnitude larger, and deliberately trades peak throughput for validator hardware that home users can run – roughly 1,000 TPS per shard at about five-second finality, scaling by adding shards rather than by driving individual shards harder. Its execution layer is also changing: a purpose-built VM is underway to replace the Radix Engine. Comparisons between the 2026 test figures and future Xi'an benchmarks are therefore not like for like.

External Links

• Interim Hyperscale: Closing the Chapter – Radix Blog (Feb 20, 2026)
• Hyperscale Update: 500k+ Public Test Done – Radix Blog
• Cerberus Whitepaper – arXiv 2020
• hyperscale-rs – Community Rust Implementation
• Cerberus Consensus Protocol