The Stellar Consensus Protocol (SCP) Explained

Stellar consensus by the numbers (October 2026)

On 9 October 2026, Obsrvr Radar counted 317 nodes on the Stellar network, 106 of them validators and 93 active. The top tier was 30 validators run by 10 organisations, three each. The network was on Protocol 29 with Stellar Core 29.0.0, and Radar reported that quorum intersection held.

• Top tier: SDF, LOBSTR, Blockdaemon, Franklin Templeton, MoneyGram, OBSRVR, Range, Creit Technologies, Public Node and Figure Certificate Company.
• Thresholds: SDF's validators require 7 of those 10 organisations to agree, and within each organisation 2 of its 3 validators.
• Fragility: Radar's minimum blocking set was 4 organisations: if four top-tier organisations went offline together, the network could not close ledgers. Its minimum splitting set was also 4.
• Close time: "about 5 seconds", per stellar.org. Measured in SDF's 2019 SOSP paper, nomination averaged 83ms and balloting 96ms.
• Protocol 29 activated on mainnet on 1 October 2026, per Stellar's software-versions page; see Stellar's 2026 upgrades.

How to read this, depending on why you are here

• You hold XLM and want yield: SCP is why there is no staking. Read XLM staking before buying any product with that name, and Stellar yield farming for where returns do come from.
• You are comparing chains: the relevant facts are deterministic finality, halt-not-fork behaviour, and a top tier you can name. See Stellar vs Solana.
• You are building payments or settlement: a closed ledger is final, so you can credit a payment once it is in a ledger.
• You want to run a validator: the sections on quorum sets and Tier 1 cover what the docs require.

Federated Byzantine agreement — trust you choose

Classic Byzantine agreement needs a fixed, agreed list of participants. Federated Byzantine agreement drops that: each node declares its own "quorum slices", sets of nodes whose agreement would convince it. A quorum is a set of nodes that contains a slice for every one of its members. Anyone can join.

David Mazières' whitepaper puts it as "individual trust decisions made by each node that together determine system-level quorums", and calls the result open membership, the property that separates SCP from earlier Byzantine protocols. Proof-of-work and proof-of-stake get open membership by making participation expensive, through electricity or locked capital. SCP gets it by letting each operator decide who to listen to, which the whitepaper says gives it "modest computing and financial requirements".

Safety rests on one condition: quorum intersection, meaning any two quorums share at least one node (in practice, at least one honest node). The paper is blunt that "no protocol can guarantee safety in the absence of quorum intersection". If two groups of validators trusted only each other, they could agree on different ledgers. Stellar's job as a network is to keep trust overlapping, which is why monitoring tools such as Radar check intersection continuously.

Federated voting — vote, accept, confirm

SCP agrees on statements through federated voting. A node votes for a statement, accepts it once a quorum around it has voted for it (or a set blocking all its slices has accepted it), and confirms it once a quorum has accepted. Only confirmed statements are acted on.

Two thresholds do the work. A quorum threshold is met when every member of some quorum containing the node has issued the message. A blocking threshold is met when at least one member of each of the node's slices has, a set the paper calls "v-blocking", because those nodes could stop the node from progressing on their own. The blocking rule lets a node catch up with a decision the rest of the network has reached even if it voted the other way. The IETF draft is explicit that "accepting 'a' is not sufficient to act on it": a node waits for confirmation.

The four phases — nomination and ballots

Each ledger goes through four phases, per the IETF specification: NOMINATE and PREPARE run concurrently, then COMMIT and EXTERNALIZE. Nomination settles on candidate transaction sets; the ballot protocol makes the network commit to exactly one of them; externalize means the value is final and applied to the ledger.

1. Nominate. Validators propose transaction sets and vote to nominate others' proposals. Once a node confirms its first candidate, Stellar's docs say, it stops voting for new ones, so the candidate list converges and is combined into one value.
2. Prepare. Nodes vote on a ballot carrying that value, checking that no conflicting ballot can already have been committed.
3. Commit. Nodes vote to commit the prepared ballot. Once the commit is confirmed, the decision cannot be reversed.
4. Externalize. The node applies the agreed transaction set and closes the ledger.

If a ballot gets stuck, for example because messages are slow, nodes move to a higher-numbered ballot after a timeout and try again. That is the liveness side of the design: only termination, not safety, depends on timing.

Finality — and why Stellar halts instead of forking

Because a ledger is only externalised once a quorum has confirmed it, a closed Stellar ledger is final. There are no competing chains and no reorganisations. The trade-off, which Stellar's docs state directly, is that SCP "prioritizes fault tolerance and safety over liveness": if validators cannot agree, ledgers stop.

That trade-off was tested on 15 May 2019, when the network halted at 1:14pm Pacific time for 67 minutes. SDF's post-mortem said "some new nodes took on too much consensus responsibility too soon" and that Keybase took its validator down for maintenance while other validators were already "shaky or down". No balances were affected: "a temporary halt is preferable to the permanent confusion of a fork". SDF's later SOSP paper added an irony: operators had widened their slices to reduce reliance on SDF, which "only increased the risk to liveness".

For DeFi this is mostly good news: a liquidation, swap or deposit in a closed ledger will not be undone. The bad news is that during a halt nothing settles, including transactions that would protect a position.

Validators, quorum sets and Tier 1

Most validators no longer write quorum sets by hand. Stellar Core builds one automatically from a list of organisations and a quality rating of CRITICAL, HIGH, MEDIUM or LOW. Tier 1 organisations run three full validators each, each with its own history archive, targeting 99.9% uptime.

Stellar's validator configuration guide says HIGH and CRITICAL organisations must publish a history archive and have at least three validators on one home domain. Inside one organisation, Core requires a simple majority of its validators; across organisations it sets thresholds that tolerate Byzantine failures on the classic 3f+1 basis. All LOW-quality organisations together count as one MEDIUM one. The effect is a layered trust graph in which a small, named group of organisations carries most of the weight.

That top tier is the honest answer to "how decentralised is Stellar?". It is more spread out than in 2019, when SDF's SOSP paper said liveness "depended on us", and its members are identifiable businesses with reputations at stake: a wallet, an infrastructure provider, an asset manager, a money transmitter. But it is ten organisations, and four of them acting or failing together could halt the network, per Radar's blocking-set figure. Proof-of-stake networks have their own concentration, in stake rather than trust; neither model makes it disappear.

Why there is no staking

SCP does not need an economic bond, so Stellar has none. Validators are not chosen by stake, are not paid block rewards, and cannot be slashed. Transaction fees go into a locked account "not given to or used by anyone", and new issuance ended when validators voted to disable inflation on 28 October 2019.

Stellar did once issue new lumens: 1% a year, distributed to accounts by vote, which created about 5.4B XLM in total. SDF's proposal to end it, made with Protocol 12 and CAP-0026, noted that "the majority of users join pools in order to claim that inflation for themselves". A week later, on 4 November 2019, SDF burned 55B XLM, leaving 50B in existence.

Why run a validator, then? Stellar's docs list asset security, network health and a say in governance, including votes on protocol upgrades and network limits. Several Tier 1 organisations, such as MoneyGram, Franklin Templeton and LOBSTR, run products on the network. That incentive is real but informal, and it is the main philosophical difference from proof-of-stake. It is also why "XLM staking" products are lending or marketing, not consensus; see XLM staking and, for the general model Stellar does not use, what is crypto staking.

Proofs and limits

SCP has formal proofs. In 2019 Giuliano Losa and Mike Dodds modelled it in the Ivy and Isabelle/HOL tools, and their 2020 paper describes "the first mechanized proof of both safety and liveness" for a deployed Byzantine fault-tolerant protocol. The proofs cover a model of SCP, not Stellar Core's code.

The proof repository says so itself: its results are "about a model of SCP written in the Ivy language, and not about SCP's implementation". A proof that the algorithm is safe if quorums intersect says nothing about whether real operators configure them to intersect, or whether the C++ is bug-free. Those depend on monitoring, review and upgrades; see what audits do and do not cover for the same distinction applied to contracts.

How these fit together

SCP's choices hang together. Choosing trust instead of buying it removes the need for stake, which removes the need for rewards, which removes inflation. Insisting on quorum intersection buys deterministic finality, which suits payments and the anchors and tokenised funds that use Stellar. The price is liveness: when trust thins out, the network waits. A named, small top tier makes the system legible and also makes its failure points countable.

The takeaway

SCP is consensus by overlapping trust: no mining, no staking, final ledgers every five seconds, and a halt rather than a fork when agreement fails. If you hold XLM, it explains why there is no native yield. If you build on Stellar, it means a closed ledger is the end of the story, provided the ten organisations at the top keep their validators running.

Sources: Mazières, "The Stellar Consensus Protocol" (whitepaper, February 2016 draft); IETF draft-mazieres-dinrg-scp-05; developers.stellar.org (SCP, validators, Tier 1 organisations, validator configuration, lumens, fees and resource limits, software versions); stellar.org/learn; stellar.org blog ("May 15th network halt", "Our proposal to disable inflation", "SDF's next steps"); Lokhava et al., "Fast and Secure Global Payments with Stellar", SOSP 2019; Losa and Dodds, FMBC 2020, and github.com/stellar/scp-proofs; Obsrvr Radar API, 9 Oct 2026.