---
title: "Consensus Evolution at Radix"
path: "/contents/tech/research/consensus-evolution"
version: "1.6.0"
author: "Hydrate"
createdAt: "2026-02-19T06:03:53.174Z"
updatedAt: "2026-08-02T14:33:55.306Z"
---

# Consensus Evolution at Radix

<Infobox>
| **Category** | Research History |
| **Timeline** | 2013–2027 |
| **Stages** | eMunie → Tempo → [Cerberus](/contents/tech/core-protocols/cerberus-consensus-protocol) → [Xi'an](/contents/tech/releases/radix-mainnet-xian) |
</Infobox>

## Overview

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

### eMunie (2013–2017)

[Dan Hughes](/community/dan-hughes)' earliest experiments with distributed ledger design. Explored various approaches to achieving consensus without a single chain.

### Tempo (2017–2019)

[Tempo](/contents/tech/research/tempo-consensus-mechanism) 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](https://en.wikipedia.org/wiki/Decentralized_finance).

### [Cerberus](/contents/tech/core-protocols/cerberus-consensus-protocol) (2020–present)

[Cerberus](/contents/tech/core-protocols/cerberus-consensus-protocol) replaced Tempo with a formal [BFT](https://en.wikipedia.org/wiki/Byzantine_fault) protocol using braided cross-shard consensus. The [whitepaper](/contents/tech/research/cerberus-whitepaper) was published in 2020 and validated through the [Hyperscale tests](/contents/tech/research/hyperscale-500k-tps). In practice, the live [Babylon](/contents/tech/releases/radix-mainnet-babylon) mainnet runs Cerberus in a simplified **unsharded** form (a single shard group), a variant of the **original** [HotStuff](https://arxiv.org/abs/1803.05069) BFT; the fully sharded, multi-shard Cerberus design has not yet shipped.

### Xi'an (2027 target)

[Xi'an](/contents/tech/releases/radix-mainnet-xian) is Radix's sharded mainnet upgrade, intended to deliver the full [Radix Engine](/contents/tech/core-protocols/radix-engine) sharding and linear scalability that has been Radix's goal since inception. Its original consensus design was the fully sharded [Cerberus](/contents/tech/core-protocols/cerberus-consensus-protocol) protocol, but the current production candidate (the community [hyperscale-rs](/contents/tech/research/hyperscale-rs) implementation, subject of the April 2026 [Xi'an RFC](https://radixtalk.com/t/rfc-xian-delivering-hyperscale-for-radix/2280)) 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.

**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"](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.

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 is [underway](https://t.me/hyperscale_rs/10334) to replace the [Radix Engine](/contents/tech/core-protocols/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](https://t.me/hyperscale_rs/10346).