Introduction
Interim Hyperscale was the Radix Foundation's three-month programme, from November 2025 to February 2026, to get Hyperscale running again after its author died and to test it in public. Hyperscale is a research prototype of a sharded Radix network, one that splits its validators into groups called shards so that they process transactions in parallel; Radix founder Dan Hughes wrote it in Java. The programme ended with a public test on 31 January 2026, in which the Foundation reported 500,000 transactions per second (TPS) sustained across 128 shards. Radix mainnet does not run this software, no outside party validated the result, and the code needed to repeat the test is not public.
Was the Hyperscale test real or a theoretical calculation?
The test was real. On 31 January 2026 a network of several hundred computers processed swaps, trades of one token for another through a liquidity pool, which six load-generating machines sent to it. The Foundation rented some of those computers from Amazon Web Services and community members ran the rest, having followed public installation guides to join; anyone else could watch live dashboards.
The 500,000 figure describes that prototype on a temporary test network. It does not measure Radix mainnet, which runs unsharded, and the Foundation called the event a public, non-validated performance test. What the test did not show sets out the open questions.
The interim phase
Hughes led Hyperscale testing until he died in July 2025. He had published part of the code in March 2025, and its README says that several mechanisms a mainnet would need were left out to protect intellectual property: the algorithm that reconfigures shards as load changes, the shuffling of validators between shards, and a weighting function for block proposals. He had been preparing a test aimed at 1m TPS, in which third parties as well as the community were invited to run validators.
On 10 November 2025 the Foundation appointed Timan Rebel, the founder of Astrolescent, who had taken part in Hyperscale testing since 2023, as Interim Hyperscale Lead. "Interim" names the role: someone to keep the work going after Hughes, on a three-month contract. The Foundation gave him the private repositories and a backup of Hughes's work folders, since the public code was enough to understand the architecture but not to run a full network.
On 15 January 2026, the week after it announced a strategy of handing its work to the community, the Foundation set the end of the phase: a public test by the end of January with a target of 500,000 TPS, Rebel's role ending on 4 February, and the code and documentation handed over. The closing post followed on 20 February.
How the tests were run
A Hyperscale network is defined by a configuration called a universe, which sets the shards, the bootstrap nodes and the round and epoch timings; bootstrap nodes start the network and are the first that a joining node contacts. Load comes from separate machines, which the project called spam nodes. A script creates wallets and liquidity pools when the network starts, and the spam nodes then sign and send swaps against those pools. Nodes were provisioned with Terraform and Ansible, tools that create and configure servers from scripts, and Rebel logged each run on an experiment card with its nodes, shards, configuration, goal and peak TPS.
He tested at three levels: an internal cluster of identical rented servers with 3 to 5 nodes per shard; a private testing group, whose members ran mostly data-centre machines spread around the world; and public tests open to anyone. A target was reached internally first and then confirmed with the private group. Because the design scales by adding shards, the number he tracked was throughput per shard.
| When | Swaps per second | Setup |
|---|---|---|
| By 18 November 2025 | 100,000 | 36 nodes on 12 shards |
| Week of 28 November 2025 | 250,000 | 32 shards |
| Late December 2025 | 381,000 | Private testing group; more than 60 outside nodes joined |
| Week of 26 January 2026 | About 250,000, then 500,000 | Private runs on 64 and then 128 shards |
| 31 January 2026 | 500,000 sustained | Public test on 128 shards |
Two changes took the tests past 250,000. In early December the work moved to Amazon Web Services, where the Foundation already ran its infrastructure, after creating and destroying hundreds of servers a day went beyond what the first hosting provider expected. Then Rebel found that the script generating the load used one processor core however large the machine: he rewrote it to use every core, and replaced dozens of small spam nodes with a few machines of 48 cores each.
The public test of 31 January 2026
The Foundation announced the test on 26 January: onboarding from 13:00 UTC on Saturday 31 January, the test at 15:00 UTC, and a rehearsal the day before for participants to download the software and sync. A participant needed 4 processor cores, 16 GB of memory, about 30 GB of disk and an open network port, the same size as the Foundation's own nodes. The Foundation posted the result a little over an hour after the start.
The network had 128 shards. On Amazon Web Services the Foundation ran 384 bootstrap nodes and 40 validator nodes, each with 4 cores and 16 GB of memory, and 6 spam nodes with 48 cores and 192 GB, each able to send about 100,000 swaps per second. Community machines joined the same network. The Foundation counted 598 nodes in its announcement and more than 590 in its blog post, "ranging from datacenter-grade nodes to desktops and even laptops"; neither says whether the count includes its own 430 machines.
The report on the day gave peaks of over 700,000 swaps per second; the closing post three weeks later, and Radix's post on X, gave peaks above 800,000. In private runs earlier that week the same software had reached about 250,000 on 64 shards and 500,000 on 128, which is about 3,900 swaps per second for each shard in both cases: doubling the shards doubled the throughput. The Foundation said the swaps included cross-shard atomic transactions, which change state held by more than one shard and complete in all of them or in none. Its posts do not say what share of the swaps crossed shards.
What the test did not show
No independent validation
No auditor or benchmarking firm checked the result. Rebel said a week before the test that there was no realistic way to engage one, with a few weeks left and the Foundation taking on no new contractual obligations. On 4 February the Foundation said it was in touch with Amazon Web Services and the University of California, Davis about promoting the test and giving input on it; its blog has carried nothing on Hyperscale since the closing post.
How the total was counted
The Foundation's posts do not describe how the network-wide figure was measured. A post on RadixTalk, the community forum, set out the day after the test what one observer saw: each node's dashboard showed a different network total, and each total was about 126 times that node's own shard throughput, roughly the number of shards. The busiest shard the author saw, in a participant's stream, peaked at 6,372 swaps per second. The post asks whether a swap that touches three shards was counted three times, how many shards each swap touched, and for the load generator's code. It has had no reply.
Three or four nodes per shard
The 384 bootstrap nodes come to 3 for each of the 128 shards; the Foundation's posts do not say how the 40 validator nodes and the community's machines were spread. flightofthefox, the lead developer of hyperscale-rs, wrote in April 2026 that "a test with 4 nodes in a shard is not a real test", and that at 100 nodes per shard the Foundation's Hyperscale would need every node in one data centre, on 10-gigabit network links. In March he had said that the Java code was never tested with more than a handful of validators per shard.
No Radix Engine, and not Cerberus
The swaps did not run on the Radix Engine, the software that executes transactions on mainnet. The prototype's README lists signature verification, Merkle proofs, validator voting, cross-shard message verification and state transition validation, and says the code "should not be used in production without substantial additional security hardening". In the same March message flightofthefox described it as having no real execution engine and no state commitments, the cryptographic summaries that let anyone check a ledger's state.
The result is often credited to Cerberus, the consensus protocol of Radix's 2020 whitepaper. The README names the consensus as Cassandra, a hybrid of Byzantine fault-tolerant and Nakamoto consensus, and says its cross-shard commit is built "on Cerberus principles". flightofthefox's reading is that "Hyperscale is not Cerberus": the Java code did not braid, which is Cerberus's way of joining the consensus of every shard a transaction touches into one process, and ran execution separately from consensus instead.
Was the Hyperscale code open-sourced?
Only in part. Hughes's public repository has held part of the code since March 2025 and was last changed on 27 July 2025; the rest of the code, and the configuration, tooling and logs of the January test, had not been published by 15 November 2026.
The closing post said the Foundation was "keen to open source the remaining code" and to publish the setup, network configuration and tooling, so that anyone with Terraform, Ansible and a cloud account could run the same test. It gave no date, because agreement was needed from parties outside the Foundation. The Foundation's update of 4 February names one: it was waiting for an answer from RDX Works, the company that developed the Radix protocol, whose position was that it owned the Hyperscale work Hughes had been doing.
Nothing has followed. The Foundation's GitHub organization has no Hyperscale repository, the test's guide site, radixlabs.net, has lapsed (archived copy), and the test's Telegram group was made a read-only archive on 30 April 2026. The closing post called reproducibility the phase's most important deliverable, and the test cannot be rerun without the private code. The lead developer of hyperscale-rs wrote in January 2026 that the core cross-shard transaction protocol was already public and that he expected the rest to add little.
What the test means for Xi'an
Xi'an is the planned Radix release that would bring sharding to mainnet, and it has no release date. The software being written for it is not the software tested here. hyperscale-rs is a separate Rust project, which community members had started while the interim phase was still running, and whose lead developer says it "throws out almost all designs from both Cerberus and the original Hyperscale repo". The table sets the two side by side.
| Hyperscale, as tested | hyperscale-rs | |
|---|---|---|
| Written | In Java, by Dan Hughes | In Rust, by flightofthefox, from 7 December 2025 |
| Consensus | Cassandra, a hybrid of Byzantine fault-tolerant and Nakamoto consensus | A two-chain commit derived from HotStuff-2 on each shard, and a beacon chain that assigns validators to shards; the developer is redesigning the two as one |
| Execution | The prototype's own state transitions, not the Radix Engine | hyperscale-vm, a WebAssembly virtual machine written for it |
| Shards | 128, set in the network's configuration | Split under load and merge when it falls, while the network runs |
| Validators per shard | 3 Foundation bootstrap nodes; the spread of the other machines is unstated | 128 seats in the project's security analysis, of which 42 may be faulty |
| Throughput per shard | About 3,900 swaps per second, measured | About 1,000 TPS, a target |
| Public test | One, on 31 January 2026 | None yet |
| Code | Partly public, under the Radix License | Public, under the MIT or Apache-2.0 licence |
| Warning in its README | Not for production without further security hardening | "Work in progress. Do not use." |
A January 2026 figure and a future Xi'an benchmark would therefore measure different software under different conditions.
The first hyperscale-rs testnets are still being prepared: on 8 November 2026 its lead developer listed a desktop validator client for them among his three current pieces of work.
External Links
- Continuing the Vision: Timan Appointed Interim Hyperscale Lead (Radix blog, 10 November 2025)
- Hyperscale Rebirth: Update 1 (18 November 2025)
- Hyperscale Rebirth Update 2 (28 November 2025)
- Hyperscale Rebirth Part 3 (2 January 2026)
- Hyperscale: Completing the Interim Phase (15 January 2026)
- Hyperscale Update: 500k+ Public Test Done (31 January 2026)
- Interim Hyperscale: Closing the Chapter (20 February 2026)
- Hyperscale, Dan Hughes's public repository on GitHub
- Hyperscale Public Test, Feedback and Open Questions (RadixTalk)