Overview
Cerberus is the Byzantine fault-tolerant consensus protocol specified in Radix's 2020 whitepaper. Its central idea is braided parallelism: rather than a single chain or fixed shards, Cerberus braids consensus across only the shards relevant to each transaction.
How the Specification Works
Each transaction identifies the substates it needs to read or write. Cerberus forms a temporary consensus group from the validators responsible for those substates' shards, and uses a 3-phase commit (pre-prepare, prepare, commit) to achieve atomic consensus across all involved shards. Transactions touching disjoint substates execute in parallel with no coordination overhead; only transactions with overlapping substates need ordering relative to each other. Adding shards and validators therefore raises total throughput proportionally – linear scalability, with no theoretical ceiling.
The whitepaper provides formal safety proofs for this design and was peer-reviewed in the Journal of Systems Research in 2023.
What Actually Runs
The specification and the deployed protocol have diverged, and the distinction matters when reading throughput claims.
On Babylon mainnet, Cerberus runs as a single, unsharded instance – one shard group covering the whole ledger. In that configuration it is equivalent to the original HotStuff BFT protocol, and the braiding machinery is inactive because there is nothing to braid.
Braiding has never run in production. Babylon runs Cerberus unsharded, where there is nothing to braid; the Radix Foundation's Hyperscale implementation, according to the lead developer of the Xi'an candidate, "never really used Cerberus"; and on 2 August 2026 he added that the original Java Hyperscale did not braid either – Dan Hughes having replaced it with an execution process asynchronous to consensus, which hyperscale-rs continues. The stated objection is liveness contagion: braiding makes shards co-dependent for liveness, so a single stalled shard can impede others, whereas asynchronous execution lets a down counterparty shard time out only the transactions that touch it.
In Xi'an, the leading production candidate is the community hyperscale-rs implementation, which does not implement Cerberus. Its per-shard consensus is a HotStuff-2–derived two-chain commit – a later variant than the original HotStuff that Babylon runs – and its control plane is a leaderless prefix-consensus beacon chain. Cross-shard atomicity is reached without any voting between shards: each shard executes independently and exchanges proofs of execution, and a transaction commits only if every participating shard reports success. Its lead developer has characterised Cerberus as "never a fully thought through design... more like a vague beginnings of an idea", and community members have argued that Radix's public materials should stop framing the network's scalability around it.
Throughput figures attributed to Cerberus should be read with this in mind. The January 2026 public test sustained over 500,000 TPS with peaks above 700,000, but it measured the Foundation's Hyperscale implementation rather than the protocol specified here.
Comparison with Other Consensus
As specified, Cerberus differs from mainstream BFT protocols in the following ways.
vs. Ethereum PoS: Ethereum processes all transactions sequentially through a single execution layer. Cerberus parallelises across shards while maintaining atomic composability.
vs. Solana Tower BFT: Solana uses a single-threaded PoH + Tower BFT design requiring high-end hardware. Cerberus targets commodity hardware with throughput scaling via shard count.
vs. Cosmos Tendermint: Cosmos chains are sovereign with IBC for asynchronous cross-chain communication. Cerberus specifies synchronous atomic composability across shards.