---
title: "Consensus Evolution at Radix"
path: "/contents/tech/research/consensus-evolution"
version: "1.5.0"
author: "Hydrate"
createdAt: "2026-02-19T06:03:53.174Z"
updatedAt: "2026-07-13T14:11:32.992Z"
---

# 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.