Stellar validators choose for themselves which nodes to trust

A different kind of consensus

Most blockchains secure agreement through brute force: proof of work uses computing power, proof of stake uses locked capital. @StellarOrg takes a different route entirely.

Stellar runs on the Stellar Consensus Protocol (SCP), a system built around what academics call Federated Byzantine Agreement (FBA). FBA is a model for consensus that achieves robustness through quorum slices, individual trust decisions made by each node that together determine system-level quorums. In plain terms, each validator publishes a list of other nodes it trusts. Those lists are called quorum slices, and the overlap between them is what allows the entire network to reach agreement.

Unlike prior Byzantine agreement models, which rely on a unanimously accepted membership list, SCP features open membership. Compared to proof-of-work and proof-of-stake schemes, SCP has modest computing and financial requirements, lowering the barrier to entry. Anyone can run a node without buying hardware at scale or locking up tokens as collateral.

How quorums form, and what can go wrong

A quorum is a set of nodes that contains at least one quorum slice for each of its members. The design was formalised in the SCP whitepaper published in 2015. Professor David Mazieres, head of Stanford's Secure Computer Systems Group and Chief Scientist at the Stellar Development Foundation, introduced the protocol as a decentralised alternative to earlier consensus methods.

The freedom this model grants validators comes with a practical responsibility. The math only guarantees a single shared ledger when operators choose sensible, well-overlapping slices. Misconfigured or poorly chosen slices can erode the quorum intersection the whole system depends on.

That vulnerability surfaced in May 2019. The Stellar Development Foundation concluded that the network stalled because new nodes took on too much consensus responsibility too soon. Several nodes were repeatedly misconfigured in the weeks before the incident, and one additional node going offline for maintenance pushed the network past the threshold needed to maintain consensus. The network froze abruptly, and transactions could not be validated for roughly two hours. Aside from that episode, $XLM's network has maintained a continuous, unbroken ledger throughout its history.

The episode remains a useful illustration of how FBA-based systems differ from their counterparts. There is no mining pool to attack and no staking pool to dominate, but the trust graph itself must be designed carefully. Get the slice configuration right, and the network is resilient and open. Get it wrong, and even a handful of nodes going dark can stall the chain.

Sources
Stellar Docs: Overview of the Stellar Consensus Protocol
SCP Whitepaper: The Stellar Consensus Protocol (Mazieres, 2015)
CoinTelegraph: Stellar's Blockchain Briefly Goes Offline (2019)