---
title: "Cerberus (Consensus Protocol)"
url: "https://radix-wiki.miow.me/contents/tech/core-protocols/cerberus-consensus-protocol"
updated: 2026-10-03
description: "Cerberus is the Byzantine fault-tolerant consensus protocol specified for Radix in two papers published in 2020. Its central idea is braided parallelism…"
---

# Cerberus (Consensus Protocol)

|  |  |
| --- | --- |
| **Type** | [BFT](https://en.wikipedia.org/wiki/Byzantine_fault) Consensus Protocol (specification) |
| **Whitepaper** | [2020, peer-reviewed 2023](/contents/tech/research/cerberus-whitepaper) |
| **Key idea** | Braided cross-shard consensus – specified, never implemented in production |
| **Running today** | Unsharded Cerberus secures [Babylon](/contents/tech/releases/radix-mainnet-babylon) mainnet, equivalent to the original [HotStuff](https://arxiv.org/abs/1803.05069) |
| **In [Xi'an](/contents/tech/releases/radix-mainnet-xian)** | Not implemented – the [production candidate](/contents/tech/research/hyperscale-rs) uses a HotStuff-2 two-chain commit per shard |
| **Outside Radix** | Tari's Ootle implements Optimistic Cerberus with HotStuff ([RFC-0330](https://rfc.tari.com/RFC-0330_Cerberus)) |

# Cerberus (Consensus Protocol)

## 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](#two-papers).

### How the Specification Works

Each transaction identifies the [substates](/contents/tech/core-concepts/substate-model) 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](/contents/tech/research/cerberus-whitepaper) 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_](https://assets.website-files.com/6053f7fca5bf627283b582c2/608811e3f5d21f235392fee1_Cerberus-Whitepaper-v1.01.pdf), version 1.01, by Florian Cäsar, [Dan Hughes](/contents/history/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](https://arxiv.org/abs/1803.05069) 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_](https://arxiv.org/abs/2008.04450), 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](https://www.jsys.org/read), 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](/contents/tech/research/cerberus-whitepaper).

## What Actually Runs

The specification and the deployed protocol have diverged, and the distinction matters when reading throughput claims.

**On [Babylon](/contents/tech/releases/radix-mainnet-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](https://arxiv.org/abs/1803.05069) 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](/contents/tech/releases/radix-mainnet-xian) candidate, ["never really used Cerberus"](https://t.me/hyperscale_rs); and on 2 August 2026 he added that [the original Java Hyperscale did not braid either](https://t.me/hyperscale_rs/10351) – [Dan Hughes](/contents/history/dan-hughes) having replaced it with an execution process asynchronous to consensus, which [hyperscale-rs](/contents/tech/research/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](/contents/tech/research/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](/contents/tech/research/hyperscale-500k-tps) 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](https://www.tari.com) – 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](https://www.tari.com/updates/2022-09-22-update-89). Their development update credits the paper to [Dan Hughes](/contents/history/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](https://rfc.tari.com/RFC-0330_Cerberus), 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](/contents/tech/core-concepts/substate-model) addresses, each covered by a [validator node](/contents/tech/core-concepts/validator-nodes) 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](https://github.com/tari-project/tari-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](/contents/tech/core-protocols/radix-engine) – [buckets](/contents/tech/core-concepts/buckets-proofs-and-vaults), vaults, proofs and non-fungibles, with transactions submitted as [manifests](/contents/tech/core-protocols/transaction-manifests) – and adds one construct Radix has no equivalent of: a stealth [resource](/contents/tech/core-concepts/resources), 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](https://ethereum.org) PoS**: Ethereum processes all transactions sequentially through a single execution layer. Cerberus parallelises across shards while maintaining [atomic composability](/contents/tech/core-concepts/atomic-composability).

**vs. [Solana](https://solana.com) Tower BFT**: Solana orders transactions with Proof of History under Tower BFT and executes non-conflicting ones in parallel across cores through [Sealevel](https://solana.com/docs/references/terminology), its parallel runtime — over one global state machine, with no [sharding](/contents/tech/core-concepts/sharding), on [high-end validator hardware](https://docs.anza.xyz/operations/requirements). Cerberus parallelises by partitioning state instead, targeting commodity hardware with throughput scaling via shard count (see [Radix vs Solana](/contents/tech/comparisons/radix-vs-solana)).

**vs. [Cosmos](https://cosmos.network) [Tendermint](https://tendermint.com)**: Cosmos chains are sovereign with [IBC](https://ibcprotocol.dev) for asynchronous cross-chain communication. Cerberus specifies synchronous atomic composability across shards.

## External Links

- [Cerberus Whitepaper](/contents/tech/research/cerberus-whitepaper)
- [Cerberus Whitepaper v1.01 (PDF)](https://assets.website-files.com/6053f7fca5bf627283b582c2/608811e3f5d21f235392fee1_Cerberus-Whitepaper-v1.01.pdf) – the Radix paper, where local and emergent Cerberus are defined
- [Academic Paper (arXiv)](https://arxiv.org/pdf/2008.04450)
- [hyperscale-rs – the Xi'an production candidate](/contents/tech/research/hyperscale-rs)
- [Hyperscale 500k TPS Test](/contents/tech/research/hyperscale-500k-tps)
- [Tari RFC-0330 – Cerberus as implemented in Tari](https://rfc.tari.com/RFC-0330_Cerberus)