---
title: "Byzantine Fault Tolerance"
path: "/contents/tech/core-concepts/byzantine-fault-tolerance"
version: "1.3.0"
author: "Hydrate"
createdAt: "2026-02-18T22:38:09.775Z"
updatedAt: "2026-07-22T07:08:36.689Z"
---

# Byzantine Fault Tolerance

<Infobox>
| **Concept** | Consensus in adversarial environments |
| **Threshold** | Tolerates up to ⅓ faulty nodes |
| **Radix Implementation** | [Cerberus](/contents/tech/core-protocols/cerberus-consensus-protocol) |
</Infobox>

## Overview

**Byzantine Fault Tolerance ([BFT](https://en.wikipedia.org/wiki/Byzantine_fault))** is the property of a distributed system that enables it to reach consensus even when up to one-third of participating nodes are malicious, unresponsive, or sending conflicting information. The name comes from the Byzantine Generals Problem — a thought experiment about coordinating military strategy when some generals may be traitors.

All secure blockchain consensus protocols must be BFT. Radix's [Cerberus](/contents/tech/core-protocols/cerberus-consensus-protocol) is a BFT protocol that uniquely braids consensus across shards, achieving both fault tolerance and [atomic composability](/contents/tech/core-concepts/atomic-composability) in a sharded environment.

## The Byzantine Generals Problem

The concept was formalised in the 1982 paper *[The Byzantine Generals Problem](https://lamport.azurewebsites.net/pubs/byz.pdf)* by Leslie Lamport, Robert Shostak, and Marshall Pease. It frames distributed agreement as a group of generals besieging a city who can coordinate only by messenger: they must agree on a single plan of attack, yet some generals — or their messengers — may be traitors sending contradictory orders. A protocol is **Byzantine fault tolerant** if the loyal generals still reach the same decision despite this arbitrary, adversarial behaviour.

In a blockchain the "generals" are [validator nodes](/contents/tech/core-concepts/validator-nodes) and the "plan" is the ordering of transactions. A Byzantine fault is the strongest failure model: it covers not just crashed or slow nodes but nodes that actively lie, equivocate, or collude.

## The One-Third Threshold

Classical BFT protocols tolerate faults among strictly fewer than one-third of participants — a system of `3f + 1` nodes stays safe and live with up to `f` Byzantine nodes. Below that bound the honest supermajority can always outvote any malicious faction and any two [quorums](https://en.wikipedia.org/wiki/Quorum_(distributed_computing)) are guaranteed to overlap in at least one honest node, which prevents two conflicting decisions from both being finalised.

This is why validator decentralisation matters: security rests on no single entity controlling a third of the effective voting weight. On Radix that weight is [stake-weighted](/contents/tech/core-concepts/staking), so it tracks staked [XRD](/contents/tech/core-protocols/xrd-token) rather than a raw node count.

## Byzantine Fault Tolerance in Radix

Radix's [Cerberus](/contents/tech/core-protocols/cerberus-consensus-protocol) is a BFT protocol in the [HotStuff](https://arxiv.org/abs/1803.05069) family — a leader-based, partially-synchronous design that reaches finality in a linear message pattern. In its [unsharded form](/contents/tech/research/cerberus-whitepaper) Cerberus behaves like standard HotStuff; its innovation is *braiding* many parallel consensus instances so that a single transaction touching multiple shards is agreed atomically. This lets Radix keep the classic one-third fault tolerance while preserving [atomic composability](/contents/tech/core-concepts/atomic-composability) across a sharded state space — the property most sharded designs give up.