Amendment States:

1. DEVELOPMENT

1. PROPOSED

1. APPROACHING (got majority)

1. ENABLED

1. NEVER ENABLED

Timeline:
Development → Proposal → Voting Period (variable) → 
80% threshold → 2-week countdown → Enabled

How Voting Works:

- Validators include amendment votes in validations
- Votes are either YES (support) or NO (oppose)
- Default: YES for known amendments, NO for unknown

- Based on each validator's trusted validators (UNL)
- When 80% of trusted validators support = majority
- Majority must hold for 14+ days (256 flag ledgers)

- Your vote contributes to 80% threshold on other UNLs
- If you're on UNLs, your vote directly affects threshold
- Even non-UNL validators: vote is visible, shows position

Why Your Vote Matters:

1. Protocol Integrity

1. Community Signal

1. Operational Requirement

1. Trust Relationship

---

# rippled.cfg - Amendment voting configuration

[voting]

List amendments to vote AGAINST (NO)

By default, rippled votes YES on all known amendments

Add amendment IDs here to vote NO

Example: Vote against a specific amendment

4D9D0A7C93DA6D27E4BC89A32B3A6C1E8D000000 = NO

Leave section empty to accept all amendments (default YES)

rippled Default Voting:

- Default: YES
- Override: Add to [voting] section

- Default: NO
- Cannot override without upgrade

- Running current software = YES to included amendments
- Running old software = automatic NO to new amendments
- To oppose an amendment, must explicitly configure

Accept All (Default):

Oppose Specific Amendment:

Multiple Votes:

# After modifying [voting] section:
sudo systemctl restart rippled

Verify vote configuration took effect

/opt/ripple/bin/rippled feature

Note: Vote changes take effect immediately after restart

Other validators will see your changed vote within minutes

# List all amendments and their status
/opt/ripple/bin/rippled feature

Output shows:

- Amendment name

- Amendment ID (hex)

- Status: enabled, vetoed, or voting status

- Support percentage

Example Output:

Amendment Status Fields:

- Amendment is active on the network
- All transactions follow these rules
- Cannot be disabled

- Your software supports this amendment
- Amendment not yet activated
- Voting is active

- Your software doesn't support this
- Need to upgrade to participate
- Automatic NO vote

- You've configured to vote NO
- Listed in your [voting] section

# Check specific amendment voting status
/opt/ripple/bin/rippled feature AMENDMENT_NAME

Check via public tools:

https://livenet.xrpl.org/network/validators" target="_blank" rel="noopener noreferrer" class="text-cyan-400 hover:text-cyan-300 underline hover:no-underline transition-colors inline-flex items-center gap-1">https://livenet.xrpl.org/network/validators">https://livenet.xrpl.org/network/validators

Shows amendment voting status

XRPL.org amendments page:

https://xrpl.org/known-amendments.html" target="_blank" rel="noopener noreferrer" class="text-cyan-400 hover:text-cyan-300 underline hover:no-underline transition-colors inline-flex items-center gap-1">https://xrpl.org/known-amendments.html">https://xrpl.org/known-amendments.html

Documents all amendments

Where to Learn About Amendments:

1. XRPL.org Documentation

1. XRP Ledger Standards (XLS)

1. Developer Community

1. rippled Release Notes

Questions for Amendment Evaluation:

- Does this solve a real problem?
- Is the implementation sound?
- Are there security implications?
- Has it been adequately tested?

- How does this affect consensus?
- What are the performance implications?
- Does it change transaction costs?
- Are there centralization concerns?

- Are exchanges and wallets prepared?
- Have developers had time to adapt?
- Is there broad community support?
- What's the rollback plan if problems?

- Do I understand this amendment?
- Have I read the technical specification?
- What do trusted community members think?
- Am I comfortable supporting this?

Amendment Types:

- Add new transaction types
- Enable new capabilities
- Example: AMM, NFTokens

- Enhance existing functionality
- Fix limitations
- Example: ExpandedSignerList

- Fix vulnerabilities
- Improve safety
- Usually urgent support

- Modify voting rules
- Change reserve requirements
- High-impact decisions

- Internal improvements
- Performance optimizations
- Usually low controversy

---

Governance Best Practices:

DO:
✓ Stay informed about proposed amendments
✓ Participate in community discussions
✓ Ask questions if you don't understand
✓ Share your perspective respectfully
✓ Consider diverse viewpoints
✓ Vote based on informed opinion

DON'T:
✗ Vote without understanding
✗ Follow others blindly
✗ Ignore amendment discussions
✗ Make uninformed public statements
✗ Vote based on personal benefit only
✗ Refuse to engage with community

Ways to Signal Your Vote:

1. Configuration

1. Public Statement

1. Community Discussion

1. Direct Communication

When Amendments Are Controversial:

1. Gather Information

1. Form Independent Opinion

1. Communicate Position

1. Accept Outcome

---

XRPL Reserve System:

- Minimum XRP to activate account
- Currently 10 XRP (after amendment)
- Protects against spam accounts

- Additional XRP per owned object
- Trust lines, offers, etc.
- Currently 2 XRP per object

- Set by amendment (NegativeUNL)
- Changed via amendments
- Affect all network participants

Transaction Fees:

- Base cost for standard transaction
- Currently 10 drops (0.00001 XRP)
- Scales with load

- Increases during network congestion
- Prioritizes transactions
- Returns to base when load decreases

- Fees determined by protocol
- Changed via amendments
- Your software version matters

Reserve Evolution:

- Very expensive to create accounts
- Limited adoption

- More accessible
- Still significant barrier

- Most accessible yet
- Balance spam protection vs. adoption

- Some want further reduction
- Others concerned about spam
- Amendments determine changes

---

Voting Philosophies:

- Vote NO on new amendments initially
- Wait for broader testing
- Support only proven changes
- Prioritize stability

- Support new features quickly
- Help advance protocol
- Accept some risk
- Prioritize innovation

- Evaluate each amendment individually
- Support well-tested features
- Caution on risky changes
- Flexibility based on evidence

When to Change Your Vote:

- New information reveals issues
- Testing shows problems
- Community raises valid concerns
- Better alternative proposed

- Issues have been addressed
- Additional testing successful
- Community reaches consensus
- You better understand benefits

- Shows you're paying attention
- Demonstrates informed participation
- Explain changes if asked

Emergency Amendment Scenarios:

- May need rapid YES votes
- Coordinate with community
- Balance speed vs. caution

- Fix may require amendment
- Community coordinates response
- Validators enable solution

- Monitor community channels
- Be prepared to update quickly
- Coordinate vote changes
- Document decisions

---

# Amendment Tracking Document

# Governance Participation Log

✅ 80% threshold provides stability - Prevents premature activation of controversial changes

✅ Two-week countdown enables preparation - Gives ecosystem time to prepare once threshold reached

✅ Amendment system avoids hard forks - Network upgrades without chain splits

✅ Validator votes are public - Transparent governance enables accountability

⚠️ Optimal voting strategy - Balance between caution and progress varies by perspective

⚠️ Weight of non-UNL votes - Non-UNL validators can vote but impact on threshold is indirect

⚠️ Community coordination mechanisms - No formal governance structure; relies on informal consensus

📌 Voting without understanding - Uninformed votes may support harmful changes

📌 Following others blindly - Abdicates your governance responsibility

📌 Ignoring amendment discussions - Miss important context for voting decisions

📌 Running outdated software - Automatic NO votes may oppose beneficial amendments

Amendment voting is a significant responsibility, but don't overthink it. Most amendments are non-controversial improvements. The community discusses proposals thoroughly before they reach voting stage.

Your practical approach: Stay subscribed to XRPL development channels, keep your software current, and vote NO only when you have specific, informed concerns. Default YES behavior plus engaged monitoring is reasonable for most validators.

Assignment: Document your approach to amendment voting and network governance.

Requirements:

• Run feature command and document results

• List all enabled amendments

• Identify any amendments currently in voting

• Note your current vote configuration

• Select one amendment (enabled or voting)

• Research using XRPL.org and community sources

• Document your evaluation using the framework

• Explain your voting position

• Identify community channels you'll monitor

• Set up notifications for XRPL development

• Document your information sources

• Create amendment tracking template

• Document your voting philosophy

• Define criteria for YES vs. NO votes

• Describe your vote change process

• Note how you'll handle emergencies

• PDF or Markdown document

• Feature command output

• Completed evaluation

• Policy documentation

• Accurate amendment status (25%)

• Thoughtful evaluation (25%)

• Practical governance setup (25%)

• Clear voting policy (25%)

Time investment: 2-3 hours
Value: Framework for ongoing governance participation

1. Amendment Activation (Tests Process Understanding):

What conditions must be met for an XRPL amendment to activate?

A) 51% validator support for 1 week
B) 80% trusted validator support sustained for 2 weeks
C) Unanimous validator support
D) Approval by Ripple Labs

Correct Answer: B
Explanation: Amendments require 80% support from trusted validators (as measured by each validator's UNL) sustained over approximately two weeks (256 flag ledgers). This threshold ensures broad consensus and gives the ecosystem time to prepare once threshold is reached.

2. Default Voting (Tests Configuration Knowledge):

If you don't configure the [voting] section in rippled.cfg, how does your validator vote?

A) Abstains from all votes
B) Votes NO on all amendments
C) Votes YES on known amendments, NO on unknown
D) Follows Ripple's recommended votes

Correct Answer: C
Explanation: rippled defaults to YES for amendments known to the current software version (included in the release), and NO for unknown amendments (not in the current version). To oppose a known amendment, you must explicitly add it to the [voting] section with = NO.

3. Voting Responsibility (Tests Governance Understanding):

Why should validators stay informed about proposed amendments?

A) Ripple requires it for validator registration
B) Uninformed voting may support harmful changes, and voting is a governance responsibility
C) It's required for UNL inclusion
D) Validators are paid based on informed voting

Correct Answer: B
Explanation: Validators are protocol guardians. Voting YES without understanding an amendment may support harmful changes. Voting NO without understanding may block beneficial improvements. Informed participation is a responsibility that comes with operating a validator.

4. Vote Configuration (Tests Technical Knowledge):

You want to vote NO on amendment ID "89308AF3B8B10B7192C4E613E1D2E4D4B000000". What do you add to rippled.cfg?

A) [amendments]\n89308AF3B8B10B7192C4E613E1D2E4D4B000000 = false
B) [voting]\n89308AF3B8B10B7192C4E613E1D2E4D4B000000 = NO
C) [features]\n89308AF3B8B10B7192C4E613E1D2E4D4B000000 = disabled
D) [validator]\nvote_no = 89308AF3B8B10B7192C4E613E1D2E4D4B000000

Correct Answer: B
Explanation: Amendment voting is configured in the [voting] section of rippled.cfg. Add the amendment ID followed by = NO to vote against it. After adding, restart rippled for the change to take effect.

5. Amendment Impact (Tests Understanding):

Once an amendment is enabled on the XRPL, what happens?

A) It can be disabled by a future vote
B) It becomes permanent; the network cannot revert to previous rules
C) It requires annual renewal votes
D) Individual validators can opt out

Correct Answer: B
Explanation: Enabled amendments are permanent protocol changes. The network cannot revert to previous rules—there's no mechanism to disable amendments. This is why careful evaluation before voting YES is important; once activated, changes cannot be undone.

For Next Lesson:
With governance participation established, Lesson 12 will cover testnet and devnet operations—using test networks for experimentation, testing software updates, and practicing operations without mainnet risk.

End of Lesson 11

Total words: ~5,300
Estimated completion time: 55 minutes reading + 2-3 hours documentation