Why Rust
Why build an independent XRP Ledger server in Rust?
Quaxar gives the XRP Ledger another implementation path and gives Rust developers a direct route into node-level infrastructure. It is not a wrapper around rippled and not a file-by-file translation. Protocol serialization, ledger construction, transaction execution, peer behavior, storage, and consensus all have to be understood, reproduced, and tested independently.
A remark that became a protocol project
The project began after a University Blockchain Research Initiative session in which David Schwartz mentioned that a Rust implementation of the XRP Ledger server would be interesting. I had spent years building applications and integrations above XRPL, but had never worked through the node itself.
That changed the question from whether someone should build another implementation to what I would learn by trying. Opening the rippled source meant learning how fields are serialized, how ledgers close, how state is represented, how peers exchange data, and where years of production behavior live beyond the API surface.
A second codebase makes assumptions visible
An independent implementation cannot inherit behavior by accident. Every field order, ledger hash, state transition, offer-crossing rule, and consensus boundary must be understood and reproduced. When Quaxar and rippled disagree, that difference creates a concrete test case.
This does not make Quaxar a replacement for rippled, and it does not make diversity automatic network resilience. Today the immediate value is engineering and review: another way to inspect existing rules, expose implicit assumptions, and build tests that compare two implementations of the same protocol.
A new contributor path below the API layer
Rust opens XRPL infrastructure to an additional community of developers. Contributors familiar with Cargo, Tokio, Serde, tracing, ownership, and typed errors can work directly on protocol, networking, storage, transaction execution, and operator tooling through a Rust-native codebase.
Long-lived ledger state, temporary acquisition work, cache retention, and persistence handoffs have explicit owners and release boundaries.
Typed messages and bounded workers make network, storage, consensus, and application responsibilities easier to inspect.
Cargo, Tokio, Serde, tracing, and established test tooling reduce the amount of infrastructure a protocol contributor must build first.
A different language and architecture reveal different failure modes while targeting the same XRPL behavior.
Reference intent, implement, compare, correct
Quaxar was developed with extensive AI-assisted iteration, but compilation was never treated as evidence of protocol correctness. The working loop was to inspect the reference behavior, design the Rust equivalent, write focused tests, connect to real peers, compare outputs and state, and correct every observed divergence.
That process surfaced serialization mismatches, storage and lifecycle defects, moving-ledger recovery failures, transaction differences, and metadata gaps. Some corrections were architectural. Others required matching a small but important reference behavior exactly. The recent OfferCreate work is an example: a disagreement at Testnet ledger 20660471 became a bounded replay, regression tests, and a deployed correction.
See the source on main.
Memory safety is not protocol correctness
Safe Rust eliminates many classes of memory and concurrency errors, but it cannot prove that a transaction result, metadata object, ledger hash, recovery decision, or RPC response matches XRPL behavior. Those claims still require tests, reference comparisons, and live-network evidence.
Quaxar also uses carefully reviewed unsafe code where compact layout, intrusive ownership, pinned traversal, and synchronization require it. The benefit is not automatic correctness. It is a different implementation discipline with explicit invariants and a compiler that can enforce many of them.
More contributors, reviewers, and test cases
XRPL application developers often know the JSON-RPC surface without having an approachable route into node internals. Quaxar creates another route: Rust developers can review a transaction path, storage boundary, peer message, or acquisition invariant without first becoming C++ specialists.
The project needs protocol reviewers, operators, Rust contributors, test authors, documentation improvements, and reproducible mismatch reports. Contributions should start with the contributing guide, architecture, and open issues.
What public-Testnet runs have shown
Quaxar has operated on public Testnet as both a non-validator and a proposing validator, published signed validations, advanced with the validated chain, and exercised selected XRP, issued-token, NFT, AMM, account-query, and expected-rejection paths.
Those runs show that the architecture works across real peers and real ledger traffic. They do not prove complete behavioral parity or production readiness. Current work continues to compare transaction results, metadata, ledger state, recovery behavior, and RPC responses against rippled.
Beta, with explicit boundaries
- Complete transaction, metadata, ledger-state, consensus, and RPC response parity is not claimed.
- Registered RPC handlers are not proof that every response and edge case matches
rippled. - Full-history configuration exists, but a complete public historical deployment is not claimed.
- Production validator operation is not recommended.
- Interfaces and runtime configuration may still change during beta.
- One
fullorproposingsample is not readiness proof; sustained canonical advancement must be observed.