The XRP Ledger Consensus Protocol - Overview

The XRPL network consists of different node types:

XRPL NODE TYPES:

┌─────────────────────────────────────────────────────┐
│                    STOCK SERVERS                     │
│  - Run rippled software                              │
│  - Maintain local copy of ledger                     │
│  - Relay transactions and validations                │
│  - Can submit transactions                           │
│  - Do NOT participate in consensus                   │
└─────────────────────────────────────────────────────┘
                         ↓
┌─────────────────────────────────────────────────────┐
│                    VALIDATORS                        │
│  - All capabilities of stock servers                 │
│  - PLUS: Publish validation messages                 │
│  - Participate in consensus process                  │
│  - Sign validations with validator keys              │
│  - May or may not be in others' UNLs                 │
└─────────────────────────────────────────────────────┘
                         ↓
┌─────────────────────────────────────────────────────┐
│                 UNL VALIDATORS                       │
│  - Validators that appear in others' UNLs            │
│  - Their votes actually count for consensus          │
│  - Typically: ~35 in default UNL                     │
│  - ~150+ total validators on network                 │
└─────────────────────────────────────────────────────┘

XRPL operates as a peer-to-peer network:

• Servers discover and connect to peers

• Messages propagate through gossip protocol

• No central coordinator or message broker

• Redundant paths ensure message delivery

• Transactions: User-submitted operations

• Proposals: Validator-suggested transaction sets

• Validations: Validator confirmations of ledger state

• Ledger data: Actual ledger contents

This "intrinsic motivation" model is sometimes criticized (no economic skin in the game) but has proven sustainable for 12+ years.

The consensus cycle repeats every 3-5 seconds:

CONSENSUS CYCLE:

┌─────────────────────────────────────────────────────┐
│  PHASE 1: COLLECTION (~1 second)                    │
│  - Servers receive transactions from users           │
│  - Transactions validated locally (syntax, sigs)     │
│  - Valid transactions enter "candidate set"          │
└─────────────────────────────────────────────────────┘
                         ↓
┌─────────────────────────────────────────────────────┐
│  PHASE 2: CONSENSUS (~2-3 seconds)                  │
│  - Validators propose their candidate sets           │
│  - Multiple voting rounds with increasing thresholds │
│  - Converge on agreed transaction set                │
└─────────────────────────────────────────────────────┘
                         ↓
┌─────────────────────────────────────────────────────┐
│  PHASE 3: VALIDATION (~1 second)                    │
│  - Validators apply agreed transactions to ledger    │
│  - Compute new ledger hash                           │
│  - Publish validation messages                       │
│  - Confirm agreement on result                       │
└─────────────────────────────────────────────────────┘
                         ↓
┌─────────────────────────────────────────────────────┐
│  LEDGER VALIDATED                                   │
│  - 80%+ validators confirm same hash                 │
│  - Ledger N is final                                 │
│  - Begin cycle for Ledger N+1                        │
└─────────────────────────────────────────────────────┘

When a user submits a transaction:

Transaction Flow:

User → Transaction → Local Server → Validation
                                        ↓
                            ┌───────────────────┐
                            │ Valid?            │
                            │ - Correct syntax  │
                            │ - Valid signature │
                            │ - Sender exists   │
                            │ - Sufficient XRP  │
                            └───────────────────┘
                                 ↓        ↓
                               YES        NO
                                ↓         ↓
                         Candidate Set  Reject
                                ↓
                         Relay to peers
                                ↓
                         Other servers add to
                         their candidate sets

• Local validation is syntax/signature only
• Actual execution depends on current ledger state
• Multiple transactions might conflict (same funds)
• Resolution happens in consensus phase

The consensus phase determines which transactions to include:

Consensus Round Structure:

- Each validator proposes their candidate set
- Transactions proposed by 50%+ of trusted validators are included
- Transactions proposed by <50% are "disputed"

- Include if 60%+ now propose
- Exclude if <40% now propose
- Otherwise, continue deliberating

- Same logic with 70%/30% thresholds

- Final threshold: 80% agreement required
- If achieved, round ends
- Remaining disputed transactions deferred to next ledger

Why Increasing Thresholds?

• Low initial threshold: Be inclusive
• Rising threshold: Force decisions
• Final 80%: Ensure strong agreement

After consensus on transaction set:

Validation Flow:

Agreed Transaction Set
         ↓
Apply to Previous Ledger (N-1)
         ↓
Compute New Ledger State (N)
         ↓
Hash the New Ledger
         ↓
Validators Sign: "I computed hash H for ledger N"
         ↓
Broadcast Validation Messages
         ↓
Each Server Collects Validations
         ↓
If 80%+ of UNL validators signed same hash:
         ↓
    LEDGER N IS VALIDATED (FINAL)

Critical Insight:
Consensus is on transaction set; validation confirms everyone computed the same result. Both must succeed for finality.

XRPL explicitly prioritizes properties:

• Never process invalid transactions

• Never violate protocol rules

• This is non-negotiable

• All validators who validate should validate the same ledger

• No conflicting "valid" ledgers

• Sacrifice progress before sacrificing agreement

• Process transactions in timely manner

• Close ledgers regularly

• But not at the cost of correctness or agreement

Practical Implication:
If the network can't achieve agreement, it stalls rather than producing conflicting ledgers. A paused network is recoverable; conflicting histories are catastrophic.

Unlike many consensus protocols, XRPL has:

• No single validator proposes "the" block

• All validators propose simultaneously

• Proposals are combined through voting

• XRPL produces "ledgers" not "blocks"

• Each ledger contains complete state (not just transactions)

• No chain of blocks to traverse for current state

• No leader failure mode (no view changes needed)

• No leader centralization concerns

• Simpler failure model

• More complex convergence (everyone proposes)

• Higher message complexity than leader-based

XRPL achieves BFT with specific guarantees:

• If <20% of UNL validators are Byzantine, no conflicting ledgers can be validated

• Quorum intersection ensures any two validating sets share honest validators

• If <20% of UNL validators are Byzantine/offline, consensus continues

• Negative UNL mechanism helps maintain liveness under partial failures

• Stronger than theoretical minimum (67%)

• Tolerates fewer failures for liveness

• But stronger safety guarantees

Let's trace a transaction from submission to finality:

• Alice sends 100 XRP to Bob

• Transaction submitted to Alice's server

• Server checks: valid syntax, valid signature, Alice exists

• Server adds to candidate set

• Server relays to peers

• Transaction propagates through peer network

• Multiple servers add to their candidate sets

• Validators receive the transaction

• Validators propose their candidate sets

• Alice's transaction included in proposals

• Proposals propagate through network

• Validators see 70% of UNL proposed Alice's transaction

• Transaction "approved" at 50% threshold

• Continues to next round

• 75% now support Alice's transaction

• Passes 60% threshold

• Transaction included in agreed set

• 80% support achieved

• Transaction set finalized

• All validators apply transactions to previous ledger

• Alice: -100 XRP, Bob: +100 XRP

• New ledger state computed

• Validators sign ledger hash

• "Ledger 85,000,000 has hash 0xABC123..."

• Validations propagate

• Alice's server sees 80%+ UNL validations for hash 0xABC123

• Ledger 85,000,000 is VALIDATED

• Alice's transaction is FINAL

• Cannot be reversed

• Start collecting for ledger 85,000,001

Not all transactions succeed:

Insufficient Balance:

Alice has 50 XRP, tries to send 100 XRP
→ Local validation passes (she exists, signature valid)
→ During ledger computation: FAIL
→ Transaction marked "tesunsufficient_funds"
→ Transaction fee still charged (prevents spam)

Conflicting Transactions:

Alice sends 100 XRP to Bob AND 100 XRP to Carol
She only has 100 XRP total
→ Both pass local validation
→ Both may be in candidate sets
→ During consensus: One or both may be proposed
→ During execution: First one succeeds, second fails
→ Transaction ordering determines winner

Expired Transactions:

Transaction has LastLedgerSequence = 85,000,000
Current ledger = 85,000,001
→ Transaction rejected (too old)
→ Prevents stale transactions from executing

For applications, finality confirmation:

API Response After Submission:
{
  "result": "tesSUCCESS",
  "validated": false,
  "ledger_index": null
}

↓ (wait for validation)

After Ledger Validation:
{
  "result": "tesSUCCESS", 
  "validated": true,
  "ledger_index": 85000000,
  "ledger_hash": "0xABC123...",
  "TransactionIndex": 15
}

validated: true means the transaction is final.

XRPL's design choices optimize for:

• Fast finality (4 sec vs 10 min or more)

• Deterministic outcome (no confirmation counting)

• Low resource requirements (no mining hardware)

• Institutional use prefers identified validators

• Regulatory compliance is easier

• Accountability is clear

• No leader election complexity

• No staking/slashing complexity

• No mining economics

• Not maximally decentralized (smaller validator set)

• Not permissionless at consensus layer (UNL gatekeeping)

• No native smart contracts (simpler transaction types)

XRPL's consensus protocol is a well-designed federated BFT system optimized for payment settlement. It achieves fast deterministic finality without mining or staking through validator voting with UNL-based trust. The design is neither perfect nor universally best—it makes specific trade-offs (less decentralized, no economic stakes) that are appropriate for its intended use case. Understanding how it works is the foundation for evaluating whether those trade-offs fit your needs.

Assignment: Create a comprehensive visual diagram of the XRPL consensus cycle.

Requirements:

• All three phases of consensus (Collection, Consensus, Validation)

• Key decision points and thresholds

• Message flows between participants

• Timing estimates for each phase

• What happens when consensus fails

• Different node types (stock servers, validators, UNL validators)

• What messages each type sends/receives

• How UNL membership affects participation

• What happens when a transaction fails validation

• What happens when consensus rounds time out

• What happens when validators disagree on result

• Hand-drawn scan (clear and legible)

• Digital drawing tool (Lucidchart, draw.io, etc.)

• Presentation slides

• Structured markdown with ASCII diagrams

• Completeness of consensus cycle (35%)

• Accuracy of technical details (30%)

• Clarity and visual effectiveness (20%)

• Edge case documentation (15%)

Time investment: 2-3 hours
Value: This diagram becomes your reference for understanding XRPL consensus and explaining it to others.

For Next Lesson:
Lesson 8 dives deep into Unique Node Lists (UNLs)—the trust infrastructure that defines who participates in consensus. You'll learn how UNLs work, why overlap matters, and the honest assessment of centralization concerns.

End of Lesson 7

Beginning of Phase 2: XRPL Mechanics

Total words: ~5,600
Estimated completion time: 55 minutes reading + 2-3 hours for deliverable

Teaching Philosophy:
This is a "forest before trees" lesson. Students need the complete picture of how XRPL consensus works before diving into UNLs, consensus rounds, etc. The transaction walkthrough makes the abstract concrete.

Deliverable Purpose:
The diagram exercise forces students to visualize and articulate the consensus cycle. Creating a diagram reveals understanding gaps and produces a reference artifact.

Lesson 8 Setup:
This lesson mentions UNLs multiple times without full explanation. Lesson 8 provides the deep dive—how UNLs work, why overlap requirements exist, and the honest centralization assessment.