Once enabled, your validator participates in each consensus round:

Each Consensus Round (~4 seconds):

1. Proposal Phase

1. Voting Phase

1. Validation Phase

1. Repeat

Your validation messages are public:

- Your public key (identity)
- Which ledgers you validated
- Timing of your validations
- Whether you agree with consensus

- Your uptime (% of expected validations)
- Agreement rate (% matching consensus)
- Historical performance
- Any anomalies

This is why preparation matters—
everyone can see your performance.

# Verify token is in configuration
sudo grep -A2 "validator_token" /opt/ripple/etc/rippled.cfg
# Should show your token

Verify file permissions

ls -la /opt/ripple/etc/rippled.cfg

Should show: -rw------- (600)

Check current server state

/opt/ripple/bin/rippled server_info | grep server_state

Should show: "full"

Check peer count

/opt/ripple/bin/rippled peers | grep -c '"address"'

Should be 10+

# Restart rippled service
sudo systemctl restart rippled

The server will:

1. Stop current operation

2. Load new configuration (with token)

3. Reconnect to network

4. Synchronize

5. Begin validating (once synced)

# Watch logs during startup
sudo journalctl -u rippled -f

You should see:

- Server starting

- Peer connections established

- Ledger synchronization

- Eventually: Validation messages

Or watch server state

watch -n 5 '/opt/ripple/bin/rippled server_info | grep -E "(server_state|pubkey_validator)"'
```

State progression after restart:

1. connected (immediate)

1. syncing (seconds to minutes)

1. tracking (brief)

1. full (minutes)

1. proposing (goal state)

---

Key fields to check:

Verification checklist:

Required confirmations:

□ server_state: "proposing"
  - NOT "full" (that's stock server)
  - "proposing" means actively validating

□ pubkey_validator: matches your public key
  - Verify against your validator-keys.json
  - Confirms correct token loaded

□ validation_quorum: present
  - Shows consensus parameters
  - Confirms network awareness

# Check logs for validation activity
sudo grep -i "validation" /var/log/rippled/debug.log | tail -20

Look for messages like:

"Validation: ..."

"Published validation for ..."

Check for any errors

sudo grep -i "error|warning" /var/log/rippled/debug.log | tail -20
```

# Check if validations are being sent
# Watch logs for validation messages
sudo tail -f /var/log/rippled/debug.log | grep -i "valid"

You should see validation messages every ~4 seconds

(matching ledger close time)

Your validator's activity should be visible to the network:

External verification methods:

1. XRPL Validator Registry

1. XRPScan Validators

1. Direct peer queries

# Check validation status directly
/opt/ripple/bin/rippled validation_info

Returns information about validation state

Useful for diagnosing issues

# Get your latest validated ledger
/opt/ripple/bin/rippled server_info | grep -A5 "validated_ledger"

Compare to public server

curl -s https://s1.ripple.com:51234" 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://s1.ripple.com:51234">https://s1.ripple.com:51234 -X POST
-H "Content-Type: application/json"
-d '{"method":"server_info"}' |
python3 -c "import sys,json; d=json.load(sys.stdin); print('Network ledger:', d['result']['info']['validated_ledger']['seq'])"

Your ledger should be within a few ledgers of network

Critical metrics to monitor:

1. Server State Stability

1. Validation Frequency

1. Agreement Percentage

1. Peer Connectivity

#!/bin/bash
#===============================================================================
# Validator Monitoring Script
# Run periodically to track validator performance
#===============================================================================

echo "=============================================="
echo "Validator Monitor - $(date)"
echo "=============================================="

Get server info

INFO=$(/opt/ripple/bin/rippled server_info 2>/dev/null)

if [ $? -ne 0 ]; then
echo "ERROR: Cannot connect to rippled"
exit 1
fi

Extract validator-specific metrics

STATE=$(echo "$INFO" | grep -o '"server_state" : "[^"]"' | cut -d'"' -f4)
PUBKEY=$(echo "$INFO" | grep -o '"pubkey_validator" : "[^"]"' | cut -d'"' -f4)
PEERS=$(echo "$INFO" | grep -o '"peers" : [0-9]' | awk '{print $3}')
LEDGER_SEQ=$(echo "$INFO" | grep -o '"seq" : [0-9]' | head -1 | awk '{print $3}')

echo ""
echo "Validator Public Key: ${PUBKEY:0:20}..."
echo "Server State: $STATE"
echo "Peers: $PEERS"
echo "Current Ledger: $LEDGER_SEQ"

echo ""
echo "--- Validation Status ---"

Check if proposing

if [ "$STATE" = "proposing" ]; then
echo "✓ Validation: ACTIVE"
else
echo "✗ Validation: INACTIVE (state: $STATE)"
echo " Expected: proposing"
fi

Check validator public key

if [ -n "$PUBKEY" ]; then
echo "✓ Validator identity: CONFIGURED"
else
echo "✗ Validator identity: NOT FOUND"
fi

Check peer count

if [ "$PEERS" -ge 10 ]; then
echo "✓ Peer connectivity: GOOD ($PEERS peers)"
elif [ "$PEERS" -ge 5 ]; then
echo "! Peer connectivity: MARGINAL ($PEERS peers)"
else
echo "✗ Peer connectivity: POOR ($PEERS peers)"
fi

echo ""
echo "--- Recent Validations ---"

Count recent validation log entries (last 60 seconds)

RECENT_VALS=$(sudo grep -c "$(date -d '1 minute ago' '+%Y-%m-%d %H:%M')|$(date '+%Y-%m-%d %H:%M')" /var/log/rippled/debug.log 2>/dev/null | head -1)
echo "Log entries (last minute): $RECENT_VALS"

echo ""
echo "=============================================="
```

# Make executable
sudo chmod +x /opt/ripple/bin/validator-monitor.sh

Run monitor

sudo /opt/ripple/bin/validator-monitor.sh
```

First Hour Checklist:

0 minutes:
□ Restart completed
□ Logs show startup

5 minutes:
□ Server reaches "proposing" state
□ pubkey_validator matches expected

15 minutes:
□ Stable in "proposing" state
□ No state drops
□ Peer count stable

30 minutes:
□ Still "proposing"
□ Validation messages in logs
□ No error messages

60 minutes:
□ Continuous "proposing" state
□ Consistent validation activity
□ Ready for ongoing monitoring

Symptom: Server stays in "full" instead of "proposing"

# Check if token is loaded
/opt/ripple/bin/rippled server_info | grep pubkey_validator

If no pubkey_validator field:

Token not loaded correctly

Verify token in config

sudo grep -A2 "validator_token" /opt/ripple/etc/rippled.cfg

Check for configuration errors

sudo journalctl -u rippled | grep -i "error|invalid"

Common issues:

- Token not properly copied (truncated)

- Section header missing [validator_token]

- Extra whitespace or characters

- Configuration file syntax error

Resolution:

# Re-copy token carefully
# Ensure complete token on single line after [validator_token]
sudo nano /opt/ripple/etc/rippled.cfg

# Restart after fixing
sudo systemctl restart rippled

Symptom: Server drops from "proposing" to "syncing" or "tracking"

# Check resource usage
ps aux | grep rippled
free -h
df -h /var/lib/rippled/db

Check for memory pressure (swap usage)

swapon --show

Check logs for issues

sudo grep -i "error|warning|disconnect" /var/log/rippled/debug.log | tail -30

Common causes:

- Insufficient memory (swap usage)

- Network connectivity issues

- Storage performance problems

- Too few peers

Symptom: "proposing" state but no external visibility

# Verify peer count (need good connectivity)
/opt/ripple/bin/rippled peers | grep -c '"address"'

Check if validations are being sent

sudo grep -i "validation|publishing" /var/log/rippled/debug.log | tail -20

Verify firewall allows peer port

sudo ufw status | grep 51235

Test external connectivity to your peer port

(From another machine)

nc -zv YOUR_SERVER_IP 51235

Common causes:

- Firewall blocking outbound

- NAT issues

- Peer port not reachable

- Very low peer count

Symptom: pubkey_validator doesn't match expected

# Get current pubkey from server
/opt/ripple/bin/rippled server_info | grep pubkey_validator

Compare to your validator-keys.json

cat /path/to/secure/validator-keys.json | grep public_key

If mismatch:

Wrong token in configuration

Regenerate token from correct master key

Update configuration and restart

First 24 hours after enablement:

□ Monitor every few hours
□ Verify continuous "proposing" state
□ Check logs for any errors
□ Confirm peer connectivity stable
□ Watch for external visibility

□ Document:
  - Exact enablement time
  - Initial metrics
  - Any issues observed

Week 1 priorities:

□ Establish baseline performance
□ Configure automated monitoring
□ Set up alerting (if not already)
□ Document normal behavior patterns
□ Join validator community channels

□ Track:
  - Uptime percentage
  - State stability
  - Peer count trends
  - Resource usage patterns

Ongoing requirements:

- Check monitoring dashboard
- Review any alerts
- Verify "proposing" state

- Full health check
- Log review
- Resource trend analysis
- Software update check

- Comprehensive metrics review
- Security update assessment
- Backup verification
- Documentation updates

---

Reputation Development:

- Establish basic track record
- Demonstrate stability
- Build uptime history
- Network takes note of new validator

- Track record lengthening
- Performance patterns emerge
- Community awareness grows
- May begin discussions with UNL operators

- Substantial track record
- Domain verification recommended
- UNL consideration possible (if metrics good)
- Established community member

- Long-term track record
- Trusted operator status
- Potential UNL inclusion
- Community leadership opportunities

Recommended community engagement:

- XRPL Developer Discord
- Validator operator discussions
- Amendment discussion channels

- Share experiences (appropriately)
- Help newer operators
- Contribute to documentation
- Provide feedback on proposals

- Connect with other operators
- Establish communication channels
- Network within community

---

✅ "proposing" state confirms active validation - This is the definitive indicator that your validator is participating in consensus

✅ Public key visibility enables verification - Your pubkey_validator can be checked against your known key to confirm correct configuration

✅ Network visibility takes time - New validators may not immediately appear on monitoring sites; allow time for propagation

✅ Stable "proposing" state indicates healthy operation - Consistent state without drops suggests proper configuration and resources

⚠️ Time to external visibility - Varies based on network conditions and monitoring tool update frequencies

⚠️ Optimal peer count for your location - 10+ is guidance; actual optimal number depends on geography and network topology

⚠️ When you'll be noticed by UNL operators - Depends on your engagement, performance, and their monitoring practices

📌 Enabling before stability verification - Rushing past stock server validation leads to public poor performance

📌 Ignoring initial monitoring - First hours/days reveal configuration issues; attention now prevents reputation damage

📌 No alerting for state drops - "proposing" → "syncing" transitions should trigger investigation; automated alerts essential

📌 Assuming success without verification - "It restarted successfully" isn't enough; verify all indicators

Enabling validation is straightforward technically—restart the service. The challenge is everything that comes after: maintaining stable operation, monitoring continuously, responding to issues promptly. Your reputation starts building from this moment, and it's measured by consistent, reliable operation over months and years.

The validators that earn UNL consideration aren't necessarily the most technically sophisticated—they're the ones that demonstrate reliable operation over extended periods. Consistency matters more than complexity.

Assignment: Document successful validation enablement and initial monitoring.

Requirements:

• Screenshot of server_info showing "proposing" state

• Screenshot showing pubkey_validator field

• Confirmation that pubkey matches your generated key

• Timestamp of enablement

• Run validator-monitor.sh at 0, 30, and 60 minutes

• Document all checks passing

• Note any issues observed and resolutions

• Confirm continuous "proposing" state

• Monitoring results at 24 hours post-enablement

• Confirm no unplanned state changes

• Document peer count stability

• Note any log warnings/errors and resolutions

• Document your monitoring approach

• Configure automated alerting (describe setup)

• Establish check schedule

• Identify escalation procedures

• PDF or Markdown document

• Screenshots with timestamps

• Monitoring output

• Verified "proposing" state with correct pubkey (30%)

• Initial monitoring documentation (30%)

• 24-hour stability confirmation (25%)

• Monitoring plan (15%)

Time investment: 1 hour active + 24 hours observation
Value: Confirmed, operational validator with monitoring

1. State Verification (Tests Technical Knowledge):

After restarting rippled with a validator token configured, what server_state indicates successful validation enablement?

A) "full" - indicates full synchronization
B) "proposing" - indicates active consensus participation
C) "validating" - indicates validation messages being sent
D) "connected" - indicates network connectivity

Correct Answer: B
Explanation: "proposing" is the state that indicates active validation. A stock server reaches "full" but doesn't participate in consensus. "proposing" means the server is fully synchronized AND actively proposing transaction sets and sending validation messages. There is no "validating" state in rippled.

2. Verification Process (Tests Operational Knowledge):

What should you verify FIRST after restarting rippled to enable validation?

A) Check external validator registries for your public key
B) Verify pubkey_validator in server_info matches your expected key and state is "proposing"
C) Post to community forums announcing your validator
D) Begin voting on amendments

Correct Answer: B
Explanation: First verify the basics: correct public key loaded (pubkey_validator) and correct state ("proposing"). External visibility takes time and isn't immediate confirmation. Community announcements should wait until operation is confirmed. Amendment voting comes later after establishing stable operation.

3. Troubleshooting (Tests Diagnostic Skills):

Your server shows server_state "full" after restart, with no pubkey_validator field in server_info. What's most likely wrong?

A) The server hasn't finished synchronizing yet
B) The validator token was not properly loaded from configuration
C) Your validator has been banned from the network
D) The peer count is too low

Correct Answer: B
Explanation: "full" state without pubkey_validator indicates the server is operating as a stock server, not a validator. This means the token wasn't loaded—check that [validator_token] section exists in configuration, the token is complete and properly formatted, and there are no configuration syntax errors. Restart after fixing.

4. Monitoring Priority (Tests Operational Judgment):

During the first 24 hours after enabling validation, what should you monitor MOST closely?

A) External validator registry rankings
B) Server_state stability (consistent "proposing") and log errors
C) XRP price movements
D) Amendment voting deadlines

Correct Answer: B
Explanation: The first 24 hours are critical for identifying configuration issues, resource problems, or connectivity issues that cause state instability. Watch for drops from "proposing" to lower states and any error messages in logs. External rankings update slowly and aren't relevant yet; price and amendments aren't operational concerns.

5. Reputation Building (Tests Understanding):

Your validator has been running in "proposing" state for 3 months with 99.5% uptime. What is your current status regarding UNL inclusion?

A) Automatically added to default UNLs after 3 months
B) Building track record; 12+ months typically required for UNL consideration
C) Can apply immediately for UNL inclusion
D) Will never be considered since you weren't invited

Correct Answer: B
Explanation: UNL inclusion typically requires 12+ months of demonstrated reliable operation, plus domain verification and being a recognizable separate entity. Three months is good progress but insufficient for consideration. Continue building track record, complete domain verification (covered in later lessons), and engage with the community.

For Next Lesson:
With validation enabled and confirmed, Lesson 9 will cover network connectivity options—different approaches for connecting your validator to the network including discovered peers, proxy configurations, and public hub connections. We'll optimize your validator's network presence.

End of Lesson 8

Congratulations! Your validator is now live on the XRP Ledger network.

Total words: ~5,400
Estimated completion time: 55 minutes reading + 24 hours monitoring