Introduction
Radix runs one network today, Babylon, and its public materials describe two others that do not run: Cerberus as the 2020 papers specify it, and Xi'an, the sharded network the hyperscale-rs project is building. The three share a name, authors and some vocabulary, and they differ in the parts that decide how a network scales: how many shards it has, which consensus orders transactions inside a shard, how a transaction that touches several shards commits, and which engine executes it.
This page sets the three side by side. Every cell links the paper, repository or message it comes from, and the pages linked in each column carry the detail.
What runs on Radix today, and what is still research?
Babylon is the only one of the three that runs: it has carried Radix mainnet since September 2023 as a single shard, ordered by a variant of the original HotStuff consensus and executed by the Radix Engine. Sharded Cerberus has never run on any Radix network, and the Xi'an candidate is in development, on a different consensus and a different execution engine from both.
| Babylon mainnet | Cerberus, as the papers specify it | Xi'an candidate (hyperscale-rs) | |
|---|---|---|---|
| Status | Live since 28 September 2023 | Specified in 2020; its multi-shard commit has never run, not even in the Foundation's Java Hyperscale | In development; the first testnets are in preparation, and Xi'an has no release date |
| Shards | One. Radix describes Babylon as unsharded: one set of 100 validators orders every transaction | Many. Each shard runs its own consensus, and transactions over unrelated state need no ordering against each other (Radix whitepaper) | Many. A beacon chain assigns each shard its committee, and shards split and merge while the network runs (design docs) |
| Consensus inside a shard | A variant of the original HotStuff, according to the node repository; a block commits after a chain of three certified blocks | Local Cerberus, a BFT instance patterned on HotStuff (Radix whitepaper) | HotStuff-2, a two-chain commit (consensus docs) |
| Transactions that touch several shards | Do not arise: there is one shard | The whitepaper's emergent Cerberus joins the shards' local instances into a "3-braid", which Radix calls braiding. The academic paper, peer-reviewed in the Journal of Systems Research in 2023, defines three protocols instead, Core-, Optimistic- and Pessimistic-Cerberus, and proves them safe | No vote between shards: each shard executes the transaction over its own state and state the others prove to it, and the transaction commits only if every shard's certificate records success (atomic commitment docs) |
| Execution engine | The Radix Engine, running blueprints that Scrypto, Radix's Rust SDK, compiles to WebAssembly (source) | The Radix whitepaper pairs Cerberus with an earlier Radix Engine as its application layer; the academic paper models objects that are each created once and consumed once | hyperscale-vm, a purpose-built virtual machine in place of the Radix Engine; the workspace has no Radix Engine dependency |
Babylon runs the original HotStuff, published in 2018, and not HotStuff-2, published in 2023, which commits a block one round sooner and is what hyperscale-rs runs inside each shard. The objection to the braid, as the hyperscale-rs lead developer puts it, is that braided shards depend on each other to stay live, so one stalled shard can hold up the rest. Dan Hughes replaced it in the Java Hyperscale with execution that runs asynchronously to consensus, and hyperscale-rs continues that design: a shard that goes down times out only the transactions that touch it.
Which software produced the 500,000 TPS figures?
The Radix Foundation's Hyperscale implementation produced them, a fourth codebase that is none of the three columns above. Its public test in January 2026 sustained over 500,000 transactions per second, with peaks above 700,000, and the Foundation closed that phase in February 2026.
The figures measure that implementation. They are not a measurement of Cerberus, whose multi-shard commit the Java Hyperscale did not use, nor of hyperscale-rs, which was written separately and replaces both its consensus and its engine. Hyperscale: 500K TPS Public Test covers the test in full.
What happens next
The Xi'an column is still moving. On 8 November 2026 the hyperscale-rs lead developer said three streams of work are under way, none of them public yet: a formal specification of the whole system, verified in Lean 4, a language for machine-checked proofs; a consensus redesign that replaces the HotStuff-2 shard chains and the beacon chain's prefix consensus with one model, prefix consensus running on a DAG (directed acyclic graph); and a first desktop validator client. If the redesign lands, the consensus row above changes with it.
Moving mainnet from Babylon to Xi'an would not be an in-place upgrade. Xi'an is a different protocol, so the old chain would end and its state would be exported at a set epoch, transformed and loaded into a new genesis, as when Olympia moved to Babylon. Contracts would move too: the expected cost for developers ranges from a recompile to an automatic source transpiler.
External Links
- Cerberus Whitepaper v1.01 (PDF) – the Radix paper, where local and emergent Cerberus and the braid are defined
- Cerberus: Minimalistic Multi-shard Byzantine-resilient Transaction Processing (arXiv) – the peer-reviewed paper
- babylon-node – the Babylon node software
- hyperscale-rs – the Xi'an production candidate
- HotStuff: BFT Consensus in the Lens of Blockchain (arXiv)
- HotStuff-2: Optimal Two-Phase Responsive BFT (IACR ePrint)