Cerberus Whitepaper & Academic Validation

Overview

The Cerberus whitepaper presents the formal specification of the Cerberus consensus protocol. Originally published as a preprint in 2020, it was peer-reviewed and published in the Journal of Systems Research (JSys) in June 2023.

Key Contributions

• Minimal coordination between shards – the paper asks how little coordination a multi-shard commit needs, and answers with three steps per transaction: local inputs, cross-shard exchange and decide outcome, set out under How does Cerberus commit a transaction across shards?
• Three variants – Core-Cerberus, correct for well-behaved clients; Optimistic-Cerberus, which runs the exchange inside a PBFT-style round spanning every affected shard; and Pessimistic-Cerberus, which pays for coordination up front so that recovery from an attack is cheap. The Radix announcement calls the last one Resilient.
• UTXO-like objects – each object is created once and consumed once, so transactions compete for an input only when its owner signed both, and a shard processes unrelated transactions concurrently
• Safety proofs – each variant is proved to meet the paper's requirements, including cross-shard consistency: if one shard commits or aborts a transaction, every shard it touches eventually does the same

What Has and Has Not Been Demonstrated

The paper's contribution is a formal specification with safety proofs, and that contribution stands on peer review. What has not happened is an implementation of its multi-shard protocols in a production system.

The Hyperscale public test of January 2026 – 500,000+ sustained TPS with peaks above 700,000 across 128 shards, on real cross-shard swap transactions rather than simple transfers, with linear scaling confirmed as shard count doubled from 64 to 128 – did not validate the paper's protocols. It measured the Radix Foundation's Hyperscale implementation, which the lead developer of the Xi'an production candidate states "never really used Cerberus". The live Babylon mainnet runs Cerberus unsharded, a configuration in which braiding is inactive, and the Xi'an candidate hyperscale-rs does not implement Cerberus at all.

Criticism

The paper's terminology has drawn criticism from the Xi'an candidate's lead developer, who argues it uses "shards" for what are really keys – encouraging the mistaken idea that ledger state is "pre-sharded" rather than mapped to shards by a topology that changes as shards split and merge.

External Links

• Full Paper (arXiv PDF)
• Cerberus Consensus Peer Reviewed (Blog)
• Consensus Evolution at Radix
• hyperscale-rs – the Xi'an production candidate