Consensus Evolution at Radix

Overview

Radix's consensus mechanism has evolved through multiple generations, each building on lessons learned:

eMunie (2013–2017)

Dan Hughes' earliest experiments with distributed ledger design. Explored various approaches to achieving consensus without a single chain.

Tempo (2017–2019)

Tempo was a DAG-based consensus mechanism that used logical clocks and gossip protocols. While innovative, Tempo had limitations in providing the strong finality guarantees needed for DeFi.

Cerberus (2020–present)

Cerberus replaced Tempo with a formal BFT protocol using braided cross-shard consensus. The whitepaper was published in 2020. The later Hyperscale tests measured the Radix Foundation's Hyperscale implementation, which did not braid, so they are not a test of braided Cerberus (see below). In practice, the live Babylon mainnet runs Cerberus in a simplified unsharded form (a single shard group), a variant of the original HotStuff BFT; the fully sharded, multi-shard Cerberus design has not yet shipped.

Xi'an (no release date)

Xi'an is Radix's sharded mainnet upgrade, intended to deliver the full Radix Engine sharding and linear scalability that has been Radix's goal since inception. Its original consensus design was the fully sharded Cerberus protocol, but the current production candidate (the community hyperscale-rs implementation, proposed for funding in the April 2026 Xi'an RFC; its lead developer withdrew from that funding on 3 September 2026 and has kept working on it) does not implement Cerberus, using a HotStuff-2–derived per-shard consensus instead – the later two-chain commit variant, distinct from the original HotStuff that Babylon runs today. The last dated schedule Radix published, in November 2024, put launch in the second half of 2027 on the assumption of a sharded Radix Engine; that approach was dropped in August 2026 and no date has replaced it (release timeline).

Two clarifications on the lineage. First, 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.

Second, Xi'an's execution layer is changing along with its consensus. On 1 August 2026 the lead developer confirmed that a purpose-built virtual machine, hyperscale-vm, is underway to replace the Radix Engine, on the reasoning that the sharding adjustments required "would require touching everything" and that a VM able to resolve a transaction's data dependencies deterministically in advance is a precondition for the cross-shard commit protocol. Existing dApps are expected to need a recompile at best and a source-level transpiler at worst.