Honeycluster is a distributed layer in front of the XRP Ledger's public node software. It exists so application developers don't have to run their own rippled or Clio instances to serve production traffic — you hit a single set of endpoints and we route to a healthy node near you.
| Component | Purpose |
|---|---|
rippled | Reference XRP Ledger server. Serves the P2P protocol, validates ledgers, and exposes a WebSocket/HTTP API. We run rippled for consensus-sensitive paths. |
Clio | Read-optimized XRP Ledger indexer. Stores full ledger history in Cassandra/ScyllaDB and answers history queries orders of magnitude faster than rippled. Most reads in Honeycluster hit Clio. |
Edge proxy | The Honeycluster API server. Accepts HTTPS and WebSocket connections, applies shared-tier fair-use limits (or per-project credit accounting on private plans), then forwards to the closest healthy upstream. |
Control plane | Prisma-backed service that stores projects, keys, credit allocations, and billing for private / enterprise plans. The edge proxy reads this synchronously via Redis. |
https://honeycluster.io — for
example {"method":"ledger","params":[{"ledger_index":85123456}]}.WebSocket connections to wss://honeycluster.io follow the same flow
minus the per-request body — the proxy holds the socket open and pipes
frames in both directions for the lifetime of the connection.
Same shape, plus:
X-API-Key: <key> on the HTTP upgrade / request.X-Credits-*) report the new balance.See Authentication for the full details on when keys come into play.
Why Clio first?
Clio indexes the full ledger into a column store, so queries like "all transactions affecting account X between ledgers A and B" return in tens of milliseconds instead of seconds. rippled is still used for recent state and submit paths.
Honeycluster runs in 15+ regions. Each region has at least one rippled and one Clio replica behind a local edge proxy. DNS-based GeoIP routing picks the nearest region for the caller; health checks drain a region in seconds if the upstream becomes unhealthy, and the client is transparently failed over to the next-closest region.
Because ledgers are globally consistent, regional replicas are interchangeable for reads — there's no "stale region" concern. Writes (transaction submission) always flow to a rippled that's validated against the live network.