When people hear "XRP," they often think of Ripple. It makes sense -- Ripple Labs created the XRP Ledger, employs many of its core developers, and remains the most visible entity in the ecosystem. But here is a question worth asking: who actually keeps the XRP Ledger running?

The answer is more distributed than you might expect. While Ripple plays an important role, the XRPL depends on a broad network of community-run infrastructure -- validators, full-history nodes, API providers, and indexing services -- operated by independent organizations and individuals around the world.

Understanding the distinction between Ripple and community infrastructure is essential for any developer building on the XRP Ledger. It shapes how you think about trust, reliability, and the long-term resilience of your application stack.

Ripple Labs is a private technology company focused on cross-border payments and digital asset solutions. Its relationship with the XRP Ledger includes:

• •
  Core development: Ripple employs engineers who contribute to rippled, the reference server implementation for the XRPL.
• •
  Validator operation: Ripple operates a set of validators that participate in the consensus process.
• •
  Ecosystem funding: Through grants and partnerships, Ripple supports projects building on the ledger.
• •
  Enterprise adoption: Ripple's On-Demand Liquidity (ODL) product uses XRP for cross-border settlement.

What Ripple does not do is control the network. It cannot unilaterally freeze accounts, reverse transactions, or dictate protocol changes. The XRP Ledger's consensus mechanism is designed so that no single entity -- including Ripple -- has that power.

Decentralization is not just a philosophical ideal -- it has practical implications for developers:

• •
  No single point of failure: If one organization goes offline, the network continues operating.
• •
  Censorship resistance: No entity can block specific transactions or accounts.
• •
  Protocol integrity: Changes to the ledger require supermajority consensus among independent validators, not approval from a single company.
• •
  Infrastructure resilience: Applications that rely on multiple independent providers are inherently more robust than those dependent on a single source.

For the XRP Ledger specifically, decentralization means that your application does not depend on Ripple's uptime, Ripple's business decisions, or Ripple's continued involvement. The ledger has a life of its own, sustained by its community.

The XRP Ledger uses a consensus protocol called the XRP Ledger Consensus Protocol, which relies on a concept called the Unique Node List (UNL). Understanding the UNL is key to understanding how trust works on XRPL.

Each node operator configures a list of validators they trust to participate in consensus. This is the node's UNL. For a transaction to be confirmed, at least 80% of trusted validators must agree on the outcome.

There are two commonly referenced default UNLs:

The important detail here is that you choose your own UNL. Node operators are not forced to trust Ripple's list. Many operators curate their own lists or use the Foundation's list, further distributing trust away from any single entity.

The default UNLs include validators operated by universities, exchanges, infrastructure providers, and independent community members -- not just Ripple. This diversity is what gives the network its resilience.

Community infrastructure on the XRP Ledger extends well beyond validators. Here is a breakdown of the key categories:

Validators participate in the consensus process, confirming transactions and closing ledgers. Running a validator is a direct contribution to the network's security and liveness.

• •
  Requirements: Reliable uptime, fast networking, and proper key management
• •
  Impact: Validators determine what transactions get confirmed
• •
  Who runs them: Exchanges, universities, infrastructure companies, independent operators

A full-history node stores every ledger since the genesis ledger (ledger #32570). This is a substantial dataset -- multiple terabytes -- and it enables historical lookups that most stock nodes cannot serve.

• •
  Use case: Historical analytics, auditing, compliance, and research
• •
  Challenge: Storage and bandwidth costs grow continuously
• •
  Why it matters: Without full-history providers, older transaction data becomes inaccessible

These are the services developers interact with most directly. API providers run clusters of rippled and Clio nodes behind load balancers, exposing public WebSocket and HTTP endpoints.

Bash
# Example: Querying account info via a public API endpoint
curl -X POST https://xrpl.ws/ -H "Content-Type: application/json" -d '{
  "method": "account_info",
  "params": [{
    "account": "rN7n3473SaZBCG4dFL83w7p1W9cgZw6itp",
    "ledger_index": "validated"
  }]
}'

• •
  Use case: Application backends, wallets, DEX interfaces, payment services
• •
  What to look for: Low latency, high uptime, full-history support, rate limit policies
• •
  Who runs them: Honeycluster, XRPL Foundation, and other community providers

Some providers go beyond raw RPC access and offer enriched data -- token metadata, NFT indexing, DEX aggregation, and account activity streams. These services process raw ledger data into formats that are immediately useful for applications.

Honeycluster is community-run public infrastructure for the XRP Ledger. We operate a distributed network of rippled and Clio nodes that provide:

• •
  Full-history access: Every ledger, every transaction, since the beginning of the XRPL
• •
  High-performance API endpoints: Sub-50ms response times across WebSocket and HTTP
• •
  Global distribution: Nodes deployed across 15+ regions for low-latency access worldwide
• •
  Enterprise-grade reliability: 99.9% uptime backed by real-time monitoring with Prometheus and Grafana

We are not Ripple. We are not affiliated with Ripple. We are an independent infrastructure provider contributing to the decentralization and resilience of the XRP Ledger.

As a developer, the infrastructure choices you make have a direct impact on the decentralization of the network. Here are practical steps you can take:

1. •
   Use multiple providers: Do not rely on a single RPC endpoint. Configure fallback providers so your application stays online even if one goes down.
2. •
   Prefer community infrastructure: By routing traffic through independent providers, you distribute load and reduce centralization risk.
3. •
   Run your own node: If your application has high throughput requirements, consider operating your own rippled or Clio node alongside public endpoints.
4. •
   Monitor your dependencies: Track the uptime and latency of every endpoint your application depends on. Know your supply chain.

If you are building on the XRP Ledger and want reliable, community-operated infrastructure, Honeycluster is ready to support your application. Our public endpoints provide full-history data access with the performance characteristics production applications demand.

Connect via WebSocket or HTTP and start building with confidence that your infrastructure layer is decentralized, resilient, and community-driven.

Visit honeycluster.io to explore our endpoints, review documentation, and get started. If you have questions or want to discuss infrastructure needs, reach out to our team at support@honeycluster.io.