---
title: "Cerberus vs Other BFT Protocols"
url: "https://radix.wiki/contents/tech/comparisons/cerberus-vs-other-bft-protocols"
version: "2.0.1"
updated: 2026-08-02
last_verified: 2026-08-02
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Cerberus vs Other BFT Protocols

|  |  |
| --- | --- |
| **[Cerberus](/contents/tech/core-protocols/cerberus-consensus-protocol)** | Braided cross-shard BFT (specification) |
| **vs PBFT/HotStuff** | Single-shard BFT protocols |
| **vs [Tendermint](https://tendermint.com)** | Per-chain BFT ([Cosmos](https://cosmos.network)) |
| **Claimed property** | Atomic consensus across arbitrary shard sets |

## Overview

This page compares a specification against deployed protocols, which is the first thing to hold in mind: [Cerberus](/contents/tech/core-protocols/cerberus-consensus-protocol)'s distinguishing feature – **atomic consensus across arbitrary sets of shards** – is specified in a peer-reviewed paper but has never run in production.

### Traditional BFT (PBFT, HotStuff, [Tendermint](https://tendermint.com))

These protocols achieve consensus within a single group of validators. They do not natively support cross-shard atomicity – any sharded system using them requires additional coordination layers that compromise either composability or performance.

### Cerberus Braiding, as Specified

Cerberus forms dynamic consensus groups per transaction, braiding across exactly the shards each transaction touches, with a 3-phase commit protocol (pre-prepare, prepare, commit) ensuring atomicity. The [whitepaper](/contents/tech/research/cerberus-whitepaper) provides formal safety proofs for this design.

### What the Xi'an Candidate Does Instead

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.

The [hyperscale-rs](/contents/tech/research/hyperscale-rs) candidate reaches cross-shard atomicity differently: one HotStuff-2–derived two-chain commit per shard, a leaderless beacon chain as the control plane, and settlement by exchanged proofs of execution rather than by any vote between shards. A transaction commits only if every participating shard reports success; one abort anywhere is terminal. On its own account this is closer to the deterministic-database tradition than to either braiding or two-phase commit.

The [500k TPS test](/contents/tech/research/hyperscale-500k-tps) is often cited as validating braiding in practice. It measured the Radix Foundation's Hyperscale implementation, which per the Xi'an candidate's lead developer "never really used Cerberus".