---
title: "Cerberus (Consensus Protocol)"
url: "https://radix.wiki/contents/tech/core-protocols/cerberus-consensus-protocol"
updated: 2026-08-24
last_verified: 2026-08-21
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
version: "6.1.0"
---

# 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** | 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)) |

## 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](/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 [whitepaper](/contents/tech/research/cerberus-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](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 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](/community/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](/community/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 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, 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](https://ethereum.org) PoS**: Ethereum processes all transactions sequentially through a single execution layer. Cerberus parallelises across shards while maintaining 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, 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)
- [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)