XRPL Networks:

- Production network
- Real value at stake
- Your primary validator location
- Network ID: 0
- Standard peer port: 51235

- Public test network
- Free test XRP from faucet
- Generally stable
- Mirror of mainnet (mostly)
- Network ID: 1
- Standard peer port: 51235

- Development network
- More experimental
- May reset periodically
- New features first
- Network ID: 2
- May use different ports

- Specialized test networks
- For sidechain development
- Various configurations

Mainnet:
├── Value: Real XRP
├── Stability: Production-grade
├── Reset: Never
├── Amendments: Activated by validator vote
├── Use: Real transactions only
└── Your role: Careful operation

Testnet:
├── Value: Free test XRP
├── Stability: High (generally)
├── Reset: Rare (announced in advance)
├── Amendments: Often ahead of mainnet
├── Use: Testing, development
└── Your role: Experimentation safe

Devnet:
├── Value: Free test XRP
├── Stability: Variable
├── Reset: More frequent
├── Amendments: Most experimental features
├── Use: Cutting-edge testing
└── Your role: Bleeding edge only
```

The cleanest approach—dedicated test infrastructure:

# On a SEPARATE server from mainnet:

# Install rippled (same as mainnet)
sudo apt install rippled

# Configuration will specify testnet
sudo nano /opt/ripple/etc/rippled.cfg

# /opt/ripple/etc/rippled.cfg for TESTNET

[server]
port_rpc_admin_local
port_peer
port_ws_admin_local

[port_rpc_admin_local]
port = 5005
ip = 127.0.0.1
admin = 127.0.0.1
protocol = http

[port_peer]
port = 51235
ip = 0.0.0.0
protocol = peer

[port_ws_admin_local]
port = 6006
ip = 127.0.0.1
admin = 127.0.0.1
protocol = ws

[node_size]
medium

[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
online_delete=256
advisory_delete=0

[database_path]
/var/lib/rippled/db

[debug_logfile]
/var/log/rippled/debug.log

[sntp_servers]
time.google.com
time.cloudflare.com

TESTNET-SPECIFIC: Point to testnet infrastructure

[ips_fixed]
s.altnet.rippletest.net 51235

TESTNET-SPECIFIC: Testnet validator list

[validators_file]
validators.txt

[ssl_verify]
1

Optional: Testnet validator token (different from mainnet!)

[validator_token]

# /opt/ripple/etc/validators.txt for TESTNET

[validator_list_sites]
https://vl.altnet.rippletest.net" 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://vl.altnet.rippletest.net">https://vl.altnet.rippletest.net

[validator_list_keys]
ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
```

For devnet, configuration differs slightly:

# Key differences for DEVNET:

[ips_fixed]
s.devnet.rippletest.net 51235

# Devnet validator list
[validator_list_sites]
https://vl.devnet.rippletest.net 

[validator_list_keys]
# Devnet-specific key (check current documentation)
EDDF2F53DFEC79037E3BD0971B264D8513E6E0C5D6BD84BE5B8F8BD6E96E78E7E

Critical: Never mix mainnet and testnet:

Isolation Requirements:

- Mainnet validator: server-main
- Testnet validator: server-test
- Complete separation

- Different directories
- Different ports
- Different data paths
- VERY careful management

Never share:
✗ validator-keys.json (different keys per network!)
✗ Configuration files
✗ Database directories
✗ Token files

# On your testnet server:

# Start rippled
sudo systemctl start rippled

# Check synchronization
/opt/ripple/bin/rippled server_info

# Should show:
# - Connection to testnet peers
# - Synchronization with testnet ledger
# - Lower ledger numbers than mainnet

# Testnet XRP is free from faucets

Generate a testnet wallet

/opt/ripple/bin/rippled wallet_propose

Note the account address and secret

NEVER use these on mainnet

Get test XRP from faucet:

https://xrpl.org/xrp-testnet-faucet.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/xrp-testnet-faucet.html">https://xrpl.org/xrp-testnet-faucet.html

Or use API: https://faucet.altnet.rippletest.net/accounts" 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://faucet.altnet.rippletest.net/accounts">https://faucet.altnet.rippletest.net/accounts

If running as a testnet validator (not just a stock server):

# Generate SEPARATE keys for testnet
# On secure machine:
./validator-keys create_keys

# This creates NEW keys
# NOT your mainnet keys
# Store separately, labeled "TESTNET ONLY"

# Generate testnet token
./validator-keys create_token --keyfile testnet-validator-keys.json

# Same commands as mainnet
/opt/ripple/bin/rippled server_info
/opt/ripple/bin/rippled peers
/opt/ripple/bin/rippled feature

Note different:

- Ledger numbers (testnet has its own sequence)

- Peer addresses (testnet infrastructure)

- Amendment status (may differ from mainnet)

Software Update Test Process:

1. ANNOUNCE

1. TEST ENVIRONMENT

1. VERIFY

1. OBSERVE

1. MAINNET

1. DOCUMENT

#!/bin/bash
#===============================================================================
# rippled Update Test Script
# Run on TESTNET server before mainnet updates
#===============================================================================

echo "=============================================="
echo "rippled Update Test - $(date)"
echo "=============================================="

Record pre-update state

echo "=== Pre-Update State ==="
/opt/ripple/bin/rippled --version
/opt/ripple/bin/rippled server_info | grep -E "server_state|build_version"

Stop service

echo ""
echo "=== Stopping rippled ==="
sudo systemctl stop rippled

Backup configuration

echo ""
echo "=== Backing up configuration ==="
sudo cp /opt/ripple/etc/rippled.cfg /opt/ripple/etc/rippled.cfg.backup.$(date +%Y%m%d)

Update package

echo ""
echo "=== Updating rippled ==="
sudo apt update
sudo apt install --only-upgrade rippled -y

Start service

echo ""
echo "=== Starting rippled ==="
sudo systemctl start rippled

Wait for startup

echo ""
echo "=== Waiting for startup (60 seconds) ==="
sleep 60

Check post-update state

echo ""
echo "=== Post-Update State ==="
/opt/ripple/bin/rippled --version
/opt/ripple/bin/rippled server_info | grep -E "server_state|build_version"

Check for errors

echo ""
echo "=== Recent Errors ==="
sudo grep -i "error" /var/log/rippled/debug.log | tail -10

echo ""
echo "=============================================="
echo "Update test complete. Monitor for 24-48 hours before mainnet."
echo "=============================================="
```

Post-Update Verification:

Immediate (within 5 minutes):
□ Service started successfully
□ No crash on startup
□ Version shows expected update
□ Basic commands respond

Short-term (within 1 hour):
□ Achieves "full" or "proposing" state
□ Peer connectivity normal
□ No error storms in logs
□ Resource usage normal

Medium-term (24-48 hours):
□ State remains stable
□ No unexpected restarts
□ Performance comparable to before
□ No regression in functionality

Only after all checks pass:
□ Proceed with mainnet update

Use testnet to practice:

Operational Procedures to Test:

- Service restart
- Configuration changes
- Log rotation
- Backup verification

- Software updates
- Database cleanup
- Certificate renewal
- Key rotation

- Service recovery
- Data restoration
- Failover procedures
- Incident response

# Test backup restoration on testnet

Create backup (simulating production backup)

sudo systemctl stop rippled
sudo tar -czvf /tmp/rippled-backup-test.tar.gz /var/lib/rippled/db

Simulate data loss

sudo rm -rf /var/lib/rippled/db/*

Restore from backup

sudo tar -xzvf /tmp/rippled-backup-test.tar.gz -C /

Verify restoration

sudo systemctl start rippled
/opt/ripple/bin/rippled server_info

Document results

Did it work? How long did it take?

Update your procedures based on findings

# Testnet is safe for failure testing

Simulate network partition

sudo ufw deny 51235/tcp

Wait, observe behavior

sudo ufw allow 51235/tcp

Simulate resource exhaustion

(Careful - don't crash your test server permanently)

stress --vm 1 --vm-bytes 50G --timeout 60s

Simulate process crash

sudo kill -9 $(pgrep rippled)

Verify service restart behavior

sudo systemctl status rippled

Document:

- How did the system respond?

- Did monitoring catch the issue?

- How long to recover?

Training Curriculum Using Testnet:

- Install rippled on testnet
- Understand configuration
- Monitor synchronization
- Use basic commands

- Perform software update
- Configure monitoring
- Review logs
- Troubleshoot issues

- Generate testnet keys
- Enable validation
- Monitor validator status
- Understand amendment voting

- Security hardening
- Incident response practice
- Backup/restore
- Performance tuning

- Risk-free learning
- Realistic environment
- Full feature access
- No production impact

# Test your documentation on testnet

Follow your own procedures exactly

On testnet server with fresh install

Questions to answer:

- Can a new operator follow these docs?

- Are any steps missing?

- Are there errors in commands?

- Does the expected output match?

Update documentation based on findings

# Test incident response runbooks

Scenario: Simulated compromise

On testnet, follow your incident response:

1. Detect (simulate alert)
2. Contain (stop rippled)
3. Investigate (check logs)
4. Eradicate (rotate token)
5. Recover (restart)
6. Document (lessons learned)

Did the runbook work?

How long did each step take?

What was unclear?

---

Testnet Server Maintenance:

- Keep reasonably current with mainnet
- Monitor for testnet resets (announced)
- Maintain configuration parity

- Perfect uptime (it's test)
- Agreement percentage
- Peer count optimization

- Usefulness for testing
- Practicing procedures
- Learning opportunities

Testnet Infrastructure Costs:

Options:

1. Minimal VPS ($5-20/month)

2. Home server

3. Cloud free tier

• Production-grade hardware
• 24/7 high availability
• High-speed storage
• Geographic optimization

Budget accordingly
```

For larger operations:

- Local or minimal server
- Rapid testing
- May run devnet

- Mirrors production
- Pre-deployment testing
- Full testnet

- Full testnet validator
- Final validation
- Procedure testing

- Solo operator: One testnet server sufficient
- Team: May want multiple environments

---

Mainnet Update Process (with testnet):

- New rippled version announced
- Review release notes
- Plan testing

- Apply to testnet
- Verify functionality
- Run test scenarios

- Monitor testnet behavior
- Check community reports
- Identify any issues

- After successful testnet period
- Apply during maintenance window
- Monitor closely

Document findings at each stage

Ongoing Test Activities:

- Test backup restoration
- Verify monitoring scripts
- Practice incident response

- Full testnet deployment
- Feature testing
- Regression testing

- Test new procedures
- Verify fixes work
- Update runbooks

# Software Update Test Report

[Any observations, issues, or recommendations]
```

✅ Testnet catches many issues - Problems discovered on testnet prevent mainnet incidents

✅ Practice improves incident response - Rehearsed procedures execute better under pressure

✅ Documentation gaps emerge in testing - Following your own docs reveals missing steps

✅ Lower cost than mainnet mistakes - Testnet infrastructure costs far less than reputation damage

⚠️ Testnet behavior may differ - Some issues only appear on mainnet due to scale or load

⚠️ Optimal testing duration - Longer isn't always better; balance thoroughness with timeliness

⚠️ Testnet stability - Testnet occasionally has its own issues unrelated to your testing

📌 Skipping testnet testing - Direct mainnet updates risk production incidents

📌 Over-relying on testnet - Testnet success doesn't guarantee mainnet success

📌 Mixing testnet/mainnet credentials - Using mainnet keys on testnet is poor practice

📌 Ignoring testnet as "not real" - Sloppy testnet practices often transfer to mainnet

Testnet operation isn't glamorous, but it's professional. Every hour spent testing on testnet potentially saves many hours of mainnet incident response.

A simple testnet setup (even a cheap VPS) that you actually use beats an elaborate test environment you ignore. Start simple, use it consistently, and expand as needed.

Assignment: Establish testnet infrastructure and integrate it into your operational workflow.

Requirements:

• Deploy rippled on testnet (separate server or environment)

• Verify synchronization with testnet

• Document configuration differences from mainnet

• Obtain test XRP from faucet

• Create software update test script

• Define test checklist for updates

• Document testnet validation steps

• Establish approval criteria for mainnet deployment

• Perform simulated incident response on testnet

• Test backup and restoration procedure

• Document timing and results

• Identify procedure improvements

• Document when testnet will be used

• Define testing requirements for different change types

• Create test results template

• Schedule regular testnet activities

• PDF or Markdown document

• Configuration files (testnet-specific)

• Test scripts

• Procedure documentation

• Working testnet setup (30%)

• Complete test procedures (30%)

• Documented practice exercise (25%)

• Clear workflow integration (15%)

Time investment: 4-6 hours
Value: Professional testing infrastructure and procedures

1. Network Differences (Tests Understanding):

What is the primary purpose of XRPL Testnet?

A) Backup network if mainnet fails
B) Safe environment for testing without risking real value
C) Faster network for high-volume transactions
D) Network for validators only

Correct Answer: B
Explanation: Testnet provides a safe environment for testing software updates, practicing procedures, and developing applications without risking real XRP or mainnet validator reputation. It mirrors mainnet functionality but uses free test XRP and has no real value at stake.

2. Key Management (Tests Security Knowledge):

Should you use your mainnet validator keys on testnet?

A) Yes—it simplifies management
B) No—use separate keys for each network
C) Only for testing key rotation
D) Only if running both on the same server

Correct Answer: B
Explanation: Never use mainnet keys on testnet. Generate separate testnet-only keys. This prevents accidental mainnet key exposure, maintains clean key management, and follows proper operational security practices. Testnet keys can be treated with lower security since only test value is at stake.

3. Update Testing (Tests Process Understanding):

How long should you observe a rippled update on testnet before deploying to mainnet?

A) Testing isn't necessary if release notes look fine
B) A few minutes to verify it starts
C) 24-48 hours of stable operation
D) At least one month

Correct Answer: C
Explanation: 24-48 hours allows observation of stability, memory usage patterns, and any delayed issues that don't appear immediately. A few minutes catches only obvious startup failures. One month is excessive for routine updates. The appropriate duration balances thoroughness with timely deployment.

4. Testnet Infrastructure (Tests Practical Knowledge):

What hardware is appropriate for a testnet validator?

A) Must match mainnet specifications exactly
B) A modest VPS or home server is sufficient for testing
C) Requires dedicated enterprise hardware
D) Cloud free tier is never adequate

Correct Answer: B
Explanation: Testnet doesn't need production-grade hardware. A modest VPS ($5-20/month) or home server is sufficient because testnet doesn't require the same performance, uptime, or reliability as mainnet. The goal is functional testing, not production operation.

5. Practice Value (Tests Strategic Understanding):

Why should incident response procedures be practiced on testnet?

A) Testnet incidents count toward mainnet metrics
B) Rehearsed procedures execute better under real incident pressure
C) Testnet failures are reported to UNL operators
D) It's required for validator certification

Correct Answer: B
Explanation: Practicing incident response on testnet reveals gaps in procedures, builds muscle memory for executing steps, and identifies timing for each phase—all without mainnet risk. When a real incident occurs, rehearsed procedures help operators respond calmly and effectively.

For Next Lesson:
With test infrastructure established, Phase 2 is complete! You have a secure, properly configured, network-connected validator with governance participation and test infrastructure. Lesson 13 begins Phase 3: Operations & Excellence, covering comprehensive monitoring and alerting systems.

End of Lesson 12

Congratulations on completing Phase 2: Validator Configuration & Security!

• Secure key management
• Active validation
• Optimized network connectivity
• Advanced security hardening
• Governance participation
• Test infrastructure

Phase 3 will focus on operational excellence—the practices that distinguish reliable validators from the rest.

Total words: ~5,200
Estimated completion time: 50 minutes reading + 4-6 hours testnet setup