xLedgRS - Rust Infrastructure for the XRP Ledger

Why xLedgRS

Built for the next decade of XRPL infrastructure

xLedgRS combines protocol fidelity, predictable operations, and a modern Rust codebase for teams that need dependable XRPL infrastructure.

🛡

Compile-Time Memory Safety

Written entirely in Rust. Buffer overflows, use-after-free, data races, and null pointer dereferences are eliminated by the compiler — not by hope. No garbage collector overhead. No manual memory management mistakes.

⚡

Async-Native Architecture

Built on Tokio from the ground up. Every peer connection, RPC request, WebSocket subscription, and consensus timer runs on an async executor. No thread-per-connection. No blocking I/O on the critical path.

🔗

Full Network Compatibility

Implements the XRPL peer protocol, integrates with existing network participants, synchronizes the account-state tree through SHAMap download, and follows live ledgers on the public network.

💾

Dual-Layer Persistence

NuDB for content-addressed Merkle tree nodes (SHAMap) with 256MB cache. SQLite in WAL mode for relational data (ledger headers, transaction index, metadata). Crash-safe, delta-based writes between ledger closes.

🌐

Full Consensus Implementation

Implements the XRP Ledger Consensus Protocol: proposal rounds with convergence thresholds (50% → 65% → 70% → 80%), UNL quorum validation, manifest-based ephemeral key delegation, and amendment tracking.

📊

rippled-Compatible APIs

Provides operator-facing JSON-RPC and WebSocket surfaces for ledger data, account state, order books, transaction submission, and live event streams in formats teams already recognize.

Architecture

Modular design, proven patterns

Draws on proven XRPL architecture patterns while using Rust’s safety model and modern async execution to support maintainable, operator-friendly deployments.

View Stack (Transaction Application)

ClosedLedger
ReadView

→

OpenView
TxsRawView

→

ApplyViewImpl
ApplyView

→

New Ledger
Validated

Consensus Phases

Open
Collect TXs

→

Establish
Exchange proposals

→

Accept
Apply TX set

→

Validate
80% UNL quorum

Source Modules

crypto/

secp256k1 & Ed25519 keys, base58check encoding, SHA-512-Half, RIPEMD160, account ID derivation, family seed encode/decode

transaction/

STObject canonical binary serialization, field catalog with type/field codes, binary parser for all field types, fluent transaction builder with multi-algorithm signing

ledger/

Radix-16 Merkle tree (SHAMap), view stack, state tables, transaction application, order book management, directory management, and metadata generation

consensus/

Proposal & validation rounds, manifest delegation (master → ephemeral key), convergence thresholds with UNL quorum, amendment tracking

network/

RTXP framing (6-byte uncompressed / 10-byte LZ4 compressed), HTTP upgrade handshake with session-hash signing, peer state machine (connecting → connected → active)

rpc/

JSON-RPC dispatcher with 15+ rippled-compatible methods, WebSocket server with subscribe/unsubscribe, live ledger/transaction/validation event streams

sync/

Peer-based SHAMap state download with multi-peer fan-out, progressive tree sync with missing-node detection, and NuDB-backed content-addressed persistence

node/

Central event loop orchestrating all subsystems: peer accept/dial, RTXP message dispatch, RPC serving, consensus timer, sync coordination, follower replay engine

Protocol

Wire-compatible with every rippled node

xLedgRS is designed to operate comfortably in existing XRPL environments, with peer messaging, handshake behavior, consensus signaling, and state sync aligned to network expectations.

Peer Handshake

TLS 1.2 with self-signed certificates (OpenSSL)
HTTP upgrade with session-signature verification
Headers: Network-ID, Network-Time, Public-Key, Session-Signature, Instance-Cookie, Closed-Ledger, Previous-Ledger, X-Protocol-Ctl
Bidirectional RTXP message stream post-upgrade

Message Framing (RTXP)

6-byte header for uncompressed messages
10-byte header for LZ4-compressed messages
Protobuf-encoded payloads (prost, proto2 schema)
Generated from rippled's official xrpl.proto

Supported Message Types

TMProposeSet — validator proposals
TMValidation — ledger validations
TMManifests — ephemeral key delegation
TMTransaction — transaction relay
TMGetLedger / TMLedgerData — state sync
TMEndpoints — peer discovery (v2 with IPv6)
TMStatusChange — node status broadcasts
TMPing / TMPong — latency measurement
TMSquelch — validator suppression

Cryptographic Primitives

secp256k1 ECDSA — signing & verification
Ed25519 — signing & verification
SHA-512-Half — primary hash (first 256 bits of SHA-512)
SHA-256 + RIPEMD-160 — account ID derivation
HMAC-SHA-512 — key derivation from family seeds
Base58Check — XRPL custom alphabet encoding

SHAMap — The Merkle State Tree

The XRP Ledger stores all account state in a radix-16 Merkle tree called the SHAMap. Each leaf node contains a serialized ledger entry (AccountRoot, Offer, RippleState, etc.) keyed by its SHA-512-Half hash. Inner nodes aggregate 16 child hashes into a single parent hash, enabling efficient proof-of-inclusion and incremental state sync.

xLedgRS implements the SHAMap with NuDB-backed content-addressed storage, a 256MB LRU cache for hot inner nodes, and a sparse overlay mode for follower nodes that only materializes branches that change between ledgers.

Transaction Engine

Core XRPL transaction coverage for live network operation

Transaction handling includes preflight validation, preclaim checks, state application, metadata generation, and ledger replay for the core surfaces operators depend on.

Payment ✓

OfferCreate ✓

OfferCancel ✓

TrustSet ✓

AccountSet ✓

AccountDelete ✓

SetRegularKey ✓

EscrowCreate ✓

EscrowFinish ✓

EscrowCancel ✓

PayChanCreate ✓

PayChanFund ✓

PayChanClaim ✓

CheckCreate ✓

CheckCash ✓

CheckCancel ✓

NFTokenMint ✓

NFTokenBurn ✓

NFTCreateOffer ✓

NFTAcceptOffer ✓

NFTCancelOffer ✓

TicketCreate ✓

DepositPreauth ✓

DEX engine

The DEX layer supports XRPL order-book behavior including quality-sorted crossing, partial fills, ticket-aware sequencing, reserve checks, and funding validation aligned with live network expectations.

RPC Methods

Method	Description
`server_info`	Node status, peer count, memory, uptime, validated ledger
`account_info`	Account balance, sequence, owner count, flags
`account_lines`	Trust lines with balances and limits
`account_offers`	Open DEX orders for an account
`account_tx`	Transaction history per account
`tx`	Look up transaction by hash
`ledger`	Ledger header by sequence or "validated"
`ledger_data`	All ledger objects (paginated)
`book_offers`	Order book for a currency pair
`submit`	Submit a signed transaction
`sign`	Server-side transaction signing (all 22 types)
`fee`	Current transaction fee (escalation-aware)
`feature`	Amendment status
`ripple_path_find`	Cross-currency pathfinding
`ping`	Connectivity check

Quick Start

Build and deploy with standard tooling

xLedgRS uses a straightforward Cargo-based workflow for operators who want a clear path from source checkout to a running node.

Terminal

# Clone and build (release mode, ~2 min)
git clone https://github.com/realJDP/xLedgRS.git
cd xLedgRS
cargo build --release

# Run on mainnet as a follower node
./target/release/xledgrs --config cfg/xledgrs.cfg

# Run on testnet
./target/release/xledgrs --config cfg/testnet.cfg

# Query your node
curl -s http://127.0.0.1:5005 \
  -d '{"method":"server_info"}' | jq .result.info

# Check account balance
curl -s http://127.0.0.1:5005 \
  -d '{"method":"account_info","params":[{"account":"rN7n3473SaZBCG4dFL83w7p1W9cgZw6iTP"}]}' | jq .

cfg/xledgrs.cfg

# rippled-compatible configuration format

[server]
port_rpc
port_peer

[port_rpc]
port = 5005
ip = 0.0.0.0
protocol = http

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

[ips]
s1.ripple.com 51235
s2.ripple.com 51235
r.ripple.com 51235

[peers_max]
21

[node_db]
path=./data

[xrpl_rs]
enable_consensus_close_loop = 1

System Requirements

Build

Rust 1.75+ (stable)
OpenSSL dev headers
protoc (prost-build)
~2 min build time

Runtime

Linux x86_64 (primary)
macOS ARM64 (dev)
512 MB RAM (follower)
~10 GB disk (state)

Network

Port 51235 (peer)
Port 5005 (JSON-RPC)
Port 6006 (WebSocket)
Outbound TCP required

Comparison

How xLedgRS compares to rippled

A high-level view of where xLedgRS aligns with the reference implementation across protocol, runtime, and operator-facing surfaces.

Capability	rippled (C++)	xLedgRS (Rust)
Language	C++17	Rust (memory-safe)
Async Model	Boost.Asio	Tokio (async/await)
Peer Protocol (RTXP)	Full	Full
TLS + Session Signatures	Full	Full
Consensus Protocol	Full	Full
State Sync (Peer)	Full	Full (7-9K obj/sec)
Ledger Following	Full	Full
Transaction Engine	Broad coverage	Core ledger + market flows
JSON-RPC API	Operator-grade	Operator + ledger methods
WebSocket API	Event subscriptions	Live event subscriptions
DEX Order Book	Full	Quality-sorted matching
NFToken Support	Full	Mint, burn, offers, accept
Escrow & PayChan	Full	Full
Checks	Full	Full
Config Format	rippled .cfg	rippled .cfg + TOML
Build System	CMake + Conan	Cargo (single command)

Dependencies

Minimal, audited, production-grade

A focused dependency set chosen for networking, cryptography, storage, and observability without unnecessary framework weight.

tokioAsync runtime

prostProtobuf codec

opensslTLS + session sigs

rustlsTLS (ring backend)

secp256k1ECDSA signing

ed25519-dalekEd25519 signing

sha2 / sha3Hash functions

ripemdAccount ID hash

lz4_flexMessage compression

nudbContent-addressed store

rusqliteSQLite (bundled)

serde_jsonJSON serialization

tokio-tungsteniteWebSocket server

clapCLI argument parsing

tracingStructured logging

arc-swapLock-free atomics

num-bigintArbitrary precision

rcgenCertificate generation

The XRP Ledger,
reimplemented in Rust

Built for the next decade of XRPL infrastructure

Compile-Time Memory Safety

Async-Native Architecture

Full Network Compatibility

Dual-Layer Persistence

Full Consensus Implementation

rippled-Compatible APIs

Modular design, proven patterns

View Stack (Transaction Application)

Consensus Phases

Source Modules

Wire-compatible with every rippled node

Peer Handshake

Message Framing (RTXP)

Supported Message Types

Cryptographic Primitives

SHAMap — The Merkle State Tree

Core XRPL transaction coverage for live network operation

DEX engine

RPC Methods

Build and deploy with standard tooling

System Requirements

Build

Runtime

Network

How xLedgRS compares to rippled

Minimal, audited, production-grade

Open source infrastructure for serious XRPL operations.

The XRP Ledger,reimplemented in Rust

Built for the next decade of XRPL infrastructure

Compile-Time Memory Safety

Async-Native Architecture

Full Network Compatibility

Dual-Layer Persistence

Full Consensus Implementation

rippled-Compatible APIs

Modular design, proven patterns

View Stack (Transaction Application)

Consensus Phases

Source Modules

Wire-compatible with every rippled node

Peer Handshake

Message Framing (RTXP)

Supported Message Types

Cryptographic Primitives

SHAMap — The Merkle State Tree

Core XRPL transaction coverage for live network operation

DEX engine

RPC Methods

Build and deploy with standard tooling

System Requirements

Build

Runtime

Network

How xLedgRS compares to rippled

Minimal, audited, production-grade

Open source infrastructure for serious XRPL operations.

The XRP Ledger,
reimplemented in Rust