Domain Verification Establishes:

1. Organizational Identity

1. Accountability

1. Contact Path

1. Verification of Control

Domain Verification Mechanism:

Step 1: Generate validator keys
→ Public key identifies your validator

Step 2: Create domain attestation
→ Sign message linking validator key to domain

Step 3: Publish attestation
→ Host at https://domain.com/.well-known/xrp-ledger.toml 

Step 4: Configure rippled
→ Tell rippled your domain

Step 5: Network verifies
→ Anyone can verify the link:
   - Fetch .well-known/xrp-ledger.toml
   - Check validator public key listed
   - Confirm validator claims same domain
   - Cryptographic proof of link

Domain Verification Requirements:

- Domain you control
- HTTPS on domain (valid SSL certificate)
- Ability to host files at .well-known/
- rippled configuration access

- Real organization (business, nonprofit, etc.)
- Legitimate online presence
- Contact information available
- Ideally: Established reputation

- Specific domain age
- Specific traffic level
- Specific business type
- Formal corporate structure

---

Example xrp-ledger.toml:

# XRP Ledger Domain Verification
# Organization: Example Company
# Last Updated: 2024-XX-XX

# Metadata
[[METADATA]]
modified = 2024-01-15T00:00:00Z

# Organization Information
[[ORGANIZATION]]
name = "Example Company"
description = "Provider of XRP infrastructure services"
domain = "example.com"
email = "[email protected]"
twitter = "ExampleCompany"

# Validator Information
[[VALIDATORS]]
public_key = "nHBtBkHGfL4NpB54H1AwBaaSJkSJLUSPvnUNAcuNpuffYB51VjH6"
attestation = "example.com"
network = "main"
owner_country = "US"
server_country = "US"
unl = "https://vl.ripple.com" 

If you operate multiple validators:

[[VALIDATORS]]
public_key = "nHBtBkHGfL4NpB54H1AwBaaSJkSJLUSPvnUNAcuNpuffYB51VjH6"
attestation = "example.com"
network = "main"

[[VALIDATORS]]
public_key = "nHUXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
attestation = "example.com"
network = "main"

For Apache:

# Add to Apache configuration
<Directory "/var/www/html/.well-known">
    Options -Indexes
    AllowOverride None
    Require all granted
</Directory>

# Ensure CORS headers (optional but recommended)
<IfModule mod_headers.c>
    <LocationMatch "/.well-known/xrp-ledger.toml">
        Header set Access-Control-Allow-Origin "*"
    </LocationMatch>
</IfModule>

For Nginx:

# Create directory if needed
sudo mkdir -p /var/www/html/.well-known/

Create the file

sudo nano /var/www/html/.well-known/xrp-ledger.toml

Paste your content

Set permissions

sudo chmod 644 /var/www/html/.well-known/xrp-ledger.toml
```

# Verify file is accessible
curl -s https://yourdomain.com/.well-known/xrp-ledger.toml 

Check SSL is working

curl -sI https://yourdomain.com/.well-known/xrp-ledger.toml" 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://yourdomain.com/.well-known/xrp-ledger.toml">https://yourdomain.com/.well-known/xrp-ledger.toml | head -5

Should see:

HTTP/2 200

content-type: text/plain (or similar)

# Add to rippled.cfg

[server_info]

This section may already exist

Add domain claim

[validator_domain]
yourdomain.com
```

# Restart rippled
sudo systemctl restart rippled

Wait for sync

sleep 120

Check server_info for domain

/opt/ripple/bin/rippled server_info | grep -A2 domain
```

How Others Verify:

1. See your validator on network
2. Note your public_key and claimed domain
3. Fetch https://yourdomain.com/.well-known/xrp-ledger.toml 
4. Check if public_key appears in file
5. If yes: Domain verified
6. If no: Verification fails

- xrpscan.com/validators
- livenet.xrpl.org
- Various community tools

---

Credibility Factors:

Verifiable Identity:
□ Domain verification complete
□ Organization information public
□ Contact information working
□ Social media presence

Track Record:
□ Operating history (months/years)
□ Uptime statistics
□ Agreement percentage
□ No security incidents

Transparency:
□ Public statement of commitment
□ Operating policies published
□ Contact responsiveness
□ Community engagement

Independence:
□ Separate entity from existing validators
□ Different infrastructure
□ Different geographic location
□ Organizational diversity

Example Validator Announcement:

# Example Company XRPL Validator

Example Company provides infrastructure services for digital finance.
We have operated in the space since 20XX.

Consider Maintaining:

- StatusPage.io
- UptimeRobot status pages
- Self-hosted (Cachet, etc.)
- Simple web page

- Current operational status
- Recent incidents (if any)
- Planned maintenance
- Historical uptime
- Contact information

---

Community Engagement:

- XRPL Discord #validators channel
- Validator-specific discussion groups
- Amendment discussion forums

- Introduce yourself and your validator
- Participate in technical discussions
- Share your experiences (appropriately)
- Help newer operators
- Provide feedback on proposals

- Promote yourself excessively
- Claim expertise you don't have
- Ignore community norms
- Be absent then only appear to ask for help

Relationship Building:

- Network at events (virtual or in-person)
- Collaborate on testing
- Share operational insights
- Build mutual respect

- Be visible in community
- Demonstrate competence
- Provide value to discussions
- Be patient (trust takes time)

- Report bugs constructively
- Test new features
- Provide feedback on proposals
- Contribute if you can

Communicate Your Position:

- Study the amendment
- Form informed opinion
- Consider sharing your reasoning
- Be open to changing views

- Demonstrates engagement
- Helps community understand landscape
- Builds reputation for thoughtfulness
- Creates accountability

Example Communication:
"After reviewing XLS-30d and testing on testnet,
Example Company's validator will vote YES on AMM.
We believe the benefits outweigh risks for [reasons].
We welcome discussion of concerns."

UNL Reality Check:

- Ripple (vl.ripple.com)
- XRPLF (vl.xrplf.org)

- 12+ months of reliable operation
- Verified domain
- Recognizable separate entity
- Organizational diversity from existing UNL
- Geographic diversity value
- No operational concerns
- Community engagement

What You Can Control:
✓ Reliable operation
✓ Domain verification
✓ Organizational credibility
✓ Community engagement
✓ Transparency

What You Cannot Control:
✗ When/if UNL operators add you
✗ Network need for additional validators
✗ Competition from other candidates
✗ UNL operators' priorities

Typical Path to UNL Consideration:

Month 0: Validator operational
Month 1-3: Stabilization, monitoring, learning
Month 4-6: Domain verification, public presence
Month 6-12: Track record building, community engagement
Month 12+: Potential UNL consideration begins

- Most validators NEVER make UNLs
- Currently ~150 validators, ~35 UNL slots
- Selection is competitive
- Run a validator for other reasons too
- UNL inclusion is bonus, not expectation

Behaviors That Hurt Your Chances:

- "I've been running for 6 months, add me!"
- UNL operators owe you nothing
- Entitlement is unattractive

- Claiming credentials you don't have
- Exaggerating your track record
- Hiding incidents or issues

- Constantly asking when you'll be added
- Lobbying operators directly
- Creating pressure campaigns

- Running validator but no community presence
- Unresponsive to outreach
- No transparency about operations

Focus on being excellent, not on getting noticed.

Maintaining Trust:

Operational:
□ Sustain high uptime (99%+)
□ Keep software updated
□ Respond to incidents promptly
□ Maintain monitoring

Communication:
□ Keep domain verification current
□ Update contact information
□ Respond to inquiries
□ Announce planned maintenance

Community:
□ Stay engaged in discussions
□ Vote informedly on amendments
□ Help community when able
□ Maintain professional presence

If Trust Is Damaged:

- Don't hide or minimize issues
- Be transparent about what happened
- Accept responsibility appropriately

- Root cause analysis
- What you've learned
- What's being changed

- Implement improvements
- Show consistent operation
- Rebuild track record

- Trust recovery takes longer than building
- Some damage may be permanent
- Actions matter more than words

Trust Is Built Over Years:

- Prove basic competence
- Establish presence
- Build initial track record

- Demonstrate consistency
- Deepen community relationships
- Build reputation for excellence

- Established community member
- Trusted operator
- Potential leadership role

Think in years, not months.

✅ Domain verification is required for UNL consideration - No anonymous validators on default UNLs

✅ Track record matters - UNL operators look at operational history

✅ Community engagement helps - Visible, engaged operators are more likely to be trusted

✅ Transparency builds trust - Open communication about operations builds confidence

⚠️ Exact UNL selection criteria - No published formula; varies by UNL operator

⚠️ Timeline to consideration - Depends on many factors; 12+ months is guidance not guarantee

⚠️ Future UNL landscape - May evolve as network grows

📌 Running validator solely for UNL inclusion - May never happen; need other motivations

📌 Overpromising uptime or performance - Better to underpromise and overdeliver

📌 Neglecting verification updates - Expired or broken verification hurts credibility

📌 Expecting fast inclusion - Patience is required; pushing hurts more than helps

Domain verification is necessary but not sufficient for UNL inclusion. It proves you're real and accountable—baseline requirements. What differentiates candidates is sustained excellence, genuine community contribution, and the patience to let trust develop naturally.

Most validators will never make default UNLs. If UNL inclusion is your only motivation, reconsider running a validator. Run it because you believe in contributing to the network, and let UNL consideration be a potential outcome of excellence.

Assignment: Complete domain verification and establish trust foundation.

Requirements:

• Create xrp-ledger.toml with correct content

• Host at proper location with HTTPS

• Configure rippled with domain

• Verify accessibility

• Create public validator information page

• Establish contact mechanisms

• Document your operational commitment

• Consider status page

• Introduce yourself in appropriate channels

• Document your engagement plan

• Make initial contributions

• Build initial relationships

• Document your credibility factors

• Create transparency plan

• Define ongoing communication strategy

• Set realistic timeline expectations

• PDF or Markdown document

• URL to xrp-ledger.toml

• Links to public information

• Community introduction evidence

• Working domain verification (40%)

• Professional organizational presence (25%)

• Genuine community engagement (20%)

• Realistic trust documentation (15%)

Time investment: 4-8 hours
Value: Foundation for validator trust and potential UNL consideration

1. Domain Verification Purpose (Tests Understanding):

What does domain verification prove about a validator?

A) That the validator has high uptime
B) That a verifiable organization controls the validator
C) That the validator is on a UNL
D) That the validator has been audited

Correct Answer: B
Explanation: Domain verification cryptographically proves that the organization controlling a domain also controls the validator. This establishes accountability—misbehavior would affect the organization's reputation. It doesn't prove uptime, UNL status, or audit status.

2. File Location (Tests Technical Knowledge):

Where must the xrp-ledger.toml file be hosted for domain verification?

A) On the validator server at port 51235
B) At https://domain.com/.well-known/xrp-ledger.toml" 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://domain.com/.well-known/xrp-ledger.toml">https://domain.com/.well-known/xrp-ledger.toml
C) At any URL listed in rippled.cfg
D) In the rippled database directory

Correct Answer: B
Explanation: The attestation file must be at the standardized .well-known/ path on your domain, accessible via HTTPS. This is the location verification tools check. It's hosted on your web server, not on the validator itself.

3. UNL Consideration (Tests Realistic Understanding):

After completing domain verification and operating reliably for 3 months, what should you expect regarding UNL inclusion?

A) Automatic addition to default UNLs
B) Invitation from UNL operators
C) Continued operation to build longer track record; UNL consideration typically requires 12+ months
D) Need to apply through formal process

Correct Answer: C
Explanation: Three months is early in the track record building phase. UNL consideration typically requires 12+ months of reliable operation, plus domain verification, community engagement, and organizational credibility. Continue building your track record with patience.

4. Trust Building (Tests Strategic Understanding):

What is MORE important for building trust as a validator operator?

A) Frequently asking UNL operators when you'll be added
B) Consistent excellence in operations and genuine community contribution
C) Having the longest uptime of any validator
D) Operating the most validators

Correct Answer: B
Explanation: Trust is built through sustained excellence and genuine contribution, not through campaigning or metrics alone. Pushing for inclusion hurts your chances. Operating multiple validators doesn't inherently build more trust. Focus on being excellent and the trust (and potential recognition) will follow.

5. Verification Maintenance (Tests Operational Knowledge):

How should you handle updates to your domain verification?

A) Once set, never change it
B) Update xrp-ledger.toml when information changes, and keep it current
C) Remove it after UNL inclusion
D) Rotate domains monthly

Correct Answer: B
Explanation: Domain verification should be maintained—update the file when information changes (new contact info, additional validators, etc.) and keep it accessible. Broken or outdated verification hurts credibility. It's an ongoing commitment, not a one-time task.

For Next Lesson:
With domain verification complete and trust foundation established, Lesson 17 will cover UNL strategy and deeper community engagement—how to maximize your contribution to the network regardless of UNL status.

End of Lesson 16

Total words: ~5,200
Estimated completion time: 50 minutes reading + 4-8 hours implementation