The Amendment System - Protocol Evolution

An amendment is a proposed change to XRPL protocol rules:

AMENDMENT EXAMPLES:

- Escrow (time-locked funds)
- Payment Channels (off-ledger payments)
- Checks (deferred payments)
- NFTokens (NFT support)
- AMM (Automated Market Maker)

- fixQualityUpperBound
- fixPayChanRecipientOwnerDir
- fixMasterKeyAsRegularKey

- RequireFullyCanonicalSig
- DisallowIncoming

Each amendment goes through states:

AMENDMENT LIFECYCLE:

┌─────────────┐
│  PROPOSED   │ ← Amendment code merged into rippled
└──────┬──────┘
       ↓
┌─────────────┐
│  VOTING     │ ← Validators signal support
└──────┬──────┘
       ↓
   80% support sustained for 2 weeks?
       ↓
   ┌───┴───┐
   YES     NO
   ↓       ↓
┌─────────────┐  ┌─────────────┐
│  ENABLED    │  │  VETOED     │
└─────────────┘  │  (can retry) │
                 └─────────────┘

Validators vote through their ledger proposals:

VOTING MECHANISM:

In each ledger proposal, validator includes:
{
  "supported_amendments": [
    "amendment_id_1",
    "amendment_id_2",
    ...
  ]
}

- How many UNL validators support each amendment
- Percentage calculated per ledger

- Support must hit 80% threshold
- And stay above 80% for 2 weeks (~215,000 ledgers)

Why two weeks?

TWO-WEEK REQUIREMENT RATIONALE:

- Time to detect issues with proposal
- Time for community discussion
- Operators can prepare for changes

- Amendment must maintain consistent support
- Prevents oscillating majorities
- Demonstrates genuine consensus

- 2 weeks ≈ 14 days × 24 hours × 60 min × ~15 ledgers/min
- ≈ 215,000 ledgers of sustained support

- Clock resets
- Must achieve 80% again for full 2 weeks

---

How amendments are proposed:

PROPOSAL PROCESS:

1. Development

1. Release

1. Signaling Begins

During voting:

VOTING DYNAMICS:

- Amendment proposed
- Early adopter validators upgrade and support
- Support grows as more validators upgrade
- Hits 80% threshold
- Two-week countdown begins
- Support maintained → Activation

- Support stalls below 80% (insufficient adoption)
- Support oscillates around 80% (resets clock)
- Validators explicitly oppose (vote against)

When an amendment activates:

ACTIVATION PROCESS:

1. Amendment status changes to "enabled"
2. New protocol rules take effect immediately
3. All validators must follow new rules
4. Old rules no longer valid

- Nodes running old software: Fork off (can't validate)
- Nodes running new software: Continue normally
- Critical that validators upgrade before activation

The AMM (Automated Market Maker) amendment:

AMM AMENDMENT TIMELINE:

- XLS-30 specification developed
- Extensive testing on devnet/testnet
- Code merged into rippled

- Validators began signaling support
- Support grew over several weeks
- Hit 80% threshold

- AMM functionality enabled
- XRPL native AMM pools available
- No network disruption

Result: Major feature addition without fork

The amendment system concentrates power with validators:

GOVERNANCE POWER DISTRIBUTION:

- Vote on amendments
- 80% threshold gives minority veto power
- UNL validators have effective power

- Determine which validators count
- Don't vote directly, but influence who does

- Propose amendments
- Write code that validators choose to run
- Don't vote directly

- Can choose which validators to trust
- Can advocate for/against amendments
- Don't vote directly

80% threshold has specific implications:

THRESHOLD ANALYSIS:

- Need 80% of UNL validators
- With 35 validators: 28 must support
- 8 validators (23%) can block any amendment

- Need 21% opposition (8 of 35)
- Small minority has veto power
- Protects against rushed changes

- Conservative bias (hard to pass)
- Consensus required, not just majority
- Controversial amendments unlikely to pass

How XRPL compares:

Critics argue:

CENTRALIZATION CRITIQUE:

- Small validator set (35) makes 80% = 28 validators
- UNL publishers influence who votes
- Same entities influence both UNL and amendments
- Effectively semi-permissioned governance

DEFENSE:

• 80% is a high bar (requires near-consensus)
• Any 8 validators can block (minority protection)
• Validators are diverse organizations
• Process is transparent and predictable
• Community can pressure validators

Add new capabilities:

FEATURE AMENDMENT EXAMPLES:

- Enables time-locked and conditional payments
- Used for escrow agreements

- High-throughput off-ledger payments
- Enables streaming payments

- Deferred payments (like paper checks)
- Recipient can claim when ready

- Native NFT support
- Minting, trading, burning NFTs

- Automated Market Maker pools
- Native DeFi functionality

Correct bugs or edge cases:

FIX AMENDMENT EXAMPLES:

- Corrected order book quality calculation
- Edge case in pathfinding

- Fixed ownership directory for payment channels
- Bookkeeping correction

- Corrected check transaction threading
- Consistency fix

Change how existing features work:

BEHAVIORAL AMENDMENT EXAMPLES:

- Changed signature validation rules
- Security improvement

- Allows accounts to block incoming payments
- Privacy/control feature

- Allows account deletion
- Recover reserve XRP

As of late 2024 (check current status):

AMENDMENTS IN VOTING:

- xrpl.org/known-amendments.html
- XRPL explorers

- XChainBridge (sidechain connectivity)
- PriceOracle (native oracle support)
- Various fixes and improvements

---

What could go wrong:

POTENTIAL RISKS:

- Activated amendment has critical bug
- Could affect all transactions
- Hard to roll back once activated

- Insufficient testing
- Edge cases not discovered
- Production issues

- Coordinated validators push self-serving changes
- Users have limited recourse

- Validators don't upgrade in time
- Network fragments

XRPL has safeguards:

SAFEGUARDS:

- Time to find issues
- Time for operators to prepare
- Resets if support wavers

- Requires broad consensus
- Minority can block questionable changes

- Amendment code is open source
- Community can review before voting
- Issues can be identified early

- Amendments tested on testnet first
- Real-world testing before mainnet

- Different operators have different incentives
- Unlikely to all support bad amendment

Emergency procedures:

EMERGENCY SCENARIOS:

- Deploy fix as new amendment
- If critical: coordinate validator downgrade
- Social consensus for emergency response

- Community pressure on validators
- Validators can withdraw support
- If support drops <80%, doesn't activate

- Operators coordinate to ensure compatibility
- Clear communication channels
- Historical precedent: hasn't happened

---

STRENGTHS:

- Vote counts are public
- Anyone can track amendment status
- No backroom deals (voting is on-chain)

- Clear rules for activation
- Known thresholds and timelines
- No surprise changes

- High threshold prevents hasty changes
- Two-week window provides buffer
- Minority can protect against risky changes

- Dozens of amendments activated
- No network splits
- Features added smoothly

WEAKNESSES:

- 35 validators is small for governance
- UNL publishers have indirect influence
- Not fully permissionless

- Two-week minimum even for critical fixes
- No fast path for emergencies
- Could be problematic for urgent bugs

- Users don't vote directly
- Must influence through validators
- Validator incentives may not align with users

- How validators decide is not transparent
- Who influences validators is unclear
- Informal discussions not visible

Questions to assess amendment governance:

EVALUATION FRAMEWORK:

- Do validators represent diverse interests?
- Are user interests adequately considered?
- Is there path for new voices?

- Can validators be held accountable?
- Is there recourse for bad decisions?
- Who watches the watchers?

- Can necessary changes be made?
- Is the process too slow?
- Too fast?

- Is the process accepted by stakeholders?
- Is it perceived as fair?
- Would major changes be adopted?

---

XRPL's amendment system is a well-designed governance mechanism that has proven effective for protocol evolution. The high threshold and two-week window provide meaningful safeguards. However, governance power is concentrated in a small validator set whose selection is influenced by UNL publishers. This is more decentralized than a single company making decisions, but less decentralized than truly open governance. For institutional users, the predictability and stability may be features; for decentralization maximalists, it's insufficient.

Assignment: Research and analyze three recent or upcoming XRPL amendments.

Requirements:

• Amendment name and ID

• What the amendment does (technical description)

• Why it was proposed (motivation)

• Current status (enabled, voting, proposed)

• Voting history (if available)

• How long did voting take (for enabled amendments)?

• Was there any controversy?

• Who seemed to support/oppose (if known)?

• Did the process work as designed?

• Is the amendment process working well?

• What would you change about the process?

• Is this governance model appropriate for institutional settlement infrastructure?

• xrpl.org/known-amendments.html

• XRPL explorers (voting data)

• GitHub (amendment proposals)

• XRPL Foundation communications

• Quality of amendment research (35%)

• Depth of governance analysis (35%)

• Thoughtfulness of assessment (20%)

• Proper sourcing (10%)

Time investment: 2-3 hours
Value: Understanding governance is essential for evaluating any blockchain as long-term infrastructure.

For Next Lesson:
Lesson 12 examines the Negative UNL—how XRPL automatically adjusts for offline validators to maintain liveness without sacrificing safety. This completes Phase 2 on XRPL mechanics.

End of Lesson 11

Total words: ~4,900
Estimated completion time: 50 minutes reading + 2-3 hours for deliverable

Teaching Philosophy:
Governance is often overlooked in technical courses. This lesson treats it as a fundamental aspect of protocol design. Students should understand that XRPL's governance is neither perfect nor terrible—it's a specific design with trade-offs.

Deliverable Purpose:
Researching actual amendments grounds the governance discussion in reality. Students see how the process actually works and can form informed opinions.

Lesson 12 Setup:
The Negative UNL is an elegant mechanism for maintaining liveness when validators go offline. It's the last piece of the XRPL mechanics puzzle before Phase 3 (security and comparison).