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.
Adoption Outside Radix
Cerberus is a specification, and one project outside Radix has built on it. In September 2022 the core developers of Tari – the proof-of-work chain started by Monero maintainer Riccardo "fluffypony" Spagni and Naveen Jain, merge-mined with Monero and built on Mimblewimble – abandoned the independent side-chain design for their digital assets layer and pivoted to Cerberus. Their development update credits the paper to Dan Hughes, notes that "to my knowledge, only Radix is developing Cerberus", and concludes: "To be blunt, it's just better than what we're building."
Tari documents its version in RFC-0330, which describes "the Cerberus variant known as Optimistic Cerberus, for the most part, with Hotstuff BFT replacing pBFT as described in the Cerberus paper". The state space is divided into contiguous shards of substate addresses, each covered by a validator node committee of 25 to 100 nodes, and a cross-shard instruction brings the affected shards together into a temporary HotStuff group – the braided step. Substates follow the same up and down lifecycle Radix uses. The code lives in the Ootle, Tari's smart contract layer, whose consensus crate is a HotStuff implementation carrying cross-shard foreign proposals; its developer guide targets a testnet, so the sharded design has not run in production there either.
The borrowing extends past consensus. The Ootle's template library is built from the same asset vocabulary as the Radix Engine – buckets, vaults, proofs and non-fungibles, with transactions submitted as manifests – and adds one construct Radix has no equivalent of: a stealth resource, whose balances are commitments rather than numbers and which can carry an optional view key that lets the issuer read them.
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 orders transactions with Proof of History under Tower BFT and executes non-conflicting ones in parallel across cores through Sealevel, its parallel runtime — over one global state machine, with no sharding, on high-end validator hardware. Cerberus parallelises by partitioning state instead, targeting commodity hardware with throughput scaling via shard count (see Radix vs Solana).
vs. Cosmos Tendermint: Cosmos chains are sovereign with IBC for asynchronous cross-chain communication. Cerberus specifies synchronous atomic composability across shards.