RADIX WikiRADIX Wiki

Overview

Cerberus is the Byzantine fault-tolerant consensus protocol specified for Radix in two papers published in 2020. 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. Each shard runs its own BFT instance, a local Cerberus; a commit spanning several of them is carried by an emergent Cerberus built from those instances. The two papers, and the terms each one uses, are set out in The Two Cerberus Papers.

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 formal safety proofs are in the academic paper rather than the Radix whitepaper, and it is the academic paper that was peer-reviewed in the Journal of Systems Research in 2023.

The Two Cerberus Papers

Cerberus is specified by two documents published in 2020. They share two authors and a name, and almost none of their vocabulary, which is why public accounts of the protocol describe it in incompatible terms.

The Radix whitepaper, 3 March 2020

Cerberus: A Parallelized BFT Consensus Protocol for Radix, version 1.01, by Florian Cäsar, Dan Hughes, Josh Primero and Stephen J. Thornton, is where the braiding language comes from. Its abstract states the departure from classical consensus: "While classical SMR protocols ensure global ordering of commands, Cerberus introduces a partial ordering regime that enables a novel state sharding approach." Ordering is imposed only between commands touching the same state; commands over disjoint state carry no ordering relationship at all, which is what leaves them free to run in parallel.

On that base it builds two levels. Each shard runs its own BFT instance, a local Cerberus, and a commit spanning several shards is carried by an emergent Cerberus assembled from the local instances of the shards a command touches. The paper defines the emergent level by mapping each part of a single-shard BFT onto its multi-shard counterpart: a leader becomes a leader set, a proposal a merged proposal, a quorum certificate a QC set, and a 3-chain a 3-braid. The braid is that last row – the emergent-level analogue of the three-round commit rule a single HotStuff chain uses – and it is what "braiding" refers to wherever the term appears in Radix’s materials.

The academic paper, 10 August 2020

Cerberus: Minimalistic Multi-shard Byzantine-resilient Transaction Processing, by Jelle Hellings and Mohammad Sadoghi of the Exploratory Systems Lab at the University of California, Davis with Josh Primero and Dan Hughes of Radix DLT, was posted to arXiv as 2008.04450 and published in the Journal of Systems Research, volume 3 issue 1, on 6 June 2023, under the journal’s Problem category. This is the peer-reviewed one.

It specifies three protocols over UTXO-like transactions rather than one. Core-Cerberus "uses strict environmental requirements to enable simple yet powerful multi-shard transaction processing", and operates correctly for transactions proposed and approved by well-behaved clients while giving no guarantees for any others. Optimistic-Cerberus needs no additional coordination phase while nothing goes wrong, at the cost of "intricate coordination when recovering from attacks". Pessimistic-Cerberus pays for that coordination in the normal case instead, so that recovery from an attack costs little.

Neither document uses the other’s terms. Local Cerberus, emergent Cerberus and braid appear nowhere in the academic paper; Core-Cerberus, Optimistic-Cerberus and Pessimistic-Cerberus appear nowhere in the Radix whitepaper. Because the peer review attaches to the academic paper, a description that calls the braided local-and-emergent architecture peer-reviewed has joined the two documents together. What was reviewed is the three-protocol family above, and what it was reviewed as is a statement of a problem and a set of primitives, not a running system – see Cerberus Whitepaper & Academic Validation.

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.

HydrateLast updated Sep 21, 2026v6.2.046 revisionsVerified Sep 21, 2026