Quaxar improvements and parity work

A direct route for Rust contributors

Developers familiar with Cargo, Tokio, Serde, tracing, ownership, and typed errors can work on XRPL server infrastructure in a native Rust codebase. Differences between Quaxar and rippled also expose assumptions that can be turned into tests.

This broadens access to the codebase. It does not show that Rust makes protocol work inherently correct or faster.

Process memory while fully synced

On 11 September, a node_size=huge build remained full during a 60-second recheck. The process had no restarts, maintained 21 peers, kept validated-ledger age at two to three seconds, and advanced by 18 validated ledgers. Process RSS was 7.28 to 7.41 GiB.

These figures come from limited Testnet windows on one host. They are observations, not memory limits, hardware requirements, or long-term averages.

In the recorded same-host windows, Quaxar's medium full average was 3.83 GiB, compared with 12.60 GiB for rippled 3.3.0 in a medium late-full window. This is a lower observed RSS, not proof of equivalent profiles or a prediction of future runs.

Source review identifies three relevant differences: immediate allocator decay across supported platforms, a size-capped single-flight cache that stores no misses, and explicit acquisition limits. Determining how much each contributes requires a single controlled same-workload A/B allocation experiment.

What differs from rippled

Quaxar shares established patterns with rippled, including intrusive SHAMap ownership, hash canonicalization, cache-first NodeStore reads, rotating-store copy-forward, and per-hash ledger acquisition. These are not presented as Quaxar advantages.

Three areas do differ. First, Quaxar uses jemalloc on non-MSVC targets and compiles in immediate dirty- and muzzy-page decay. In rippled, jemalloc is an opt-in build flag that defaults off; the standard build relies on malloc_trim(0), which is limited to Linux with glibc. Outside that environment, this mechanism does nothing.

Second, Quaxar rejects encoded cache objects above 1 MiB, stores no negative entries, and coalesces simultaneous same-hash loads into one backend read rather than one per caller. The reference TaggedCache has no per-entry size limit, caches negative entries as a sentinel object, and lets concurrent callers reconcile at insertion. Quaxar performs each cold load once.

Third, Quaxar applies explicit limits to acquisition work: 128 packets and 4 MiB by default, 512 pending reads, a 768-entry retained frontier, four packets per engine turn, and twelve timeout reprobes. These limits are checked at shared ingress and again in each session mailbox. The reference subsystem does not apply equivalent count or byte limits to its per-request inbound-ledger vector.

Explicit limits on retained work

Acquisition limits cover retained packets and bytes, pending reads, the network frontier, outbound credits, ingress queues, and read-broker subscriptions. Per-profile write backpressure ranges from 64 to 1024 MiB. Named constants enforce these limits at ingress and in each session mailbox.

The NodeStore cache rejects objects above 1 MiB, coalesces same-hash loads, and prevents stale loaders from repopulating the cache after database rotation. It also keeps a cache that spends none of its capacity remembering absences.

On non-MSVC builds, jemalloc returns freed pages promptly through immediate decay settings. These limits and policies are implemented in the source. Their individual effect on RSS has not yet been measured in isolation.

Quaxar does not promise a fixed RSS ceiling. Memory use depends on the cache profile, active work, retained history, storage mode, and allocator behavior.

Reusable work for each ledger hash

Requests for the same ledger hash share one acquisition session. Different hashes can progress independently, while workers, brokers, mailboxes, packet lanes, peer credits, and retained bytes remain bounded.

Verified immutable nodes remain available through NodeFamily, fetch-pack state, and NodeStore. A stable recovery anchor can remain in place while the preferred ledger follows the network tip, so valid work is not discarded whenever that preference changes.

Quaxar confirms durable storage before publishing FullBelow state. See the acquisition architecture and syncing guide.

Rotating NuDB and verified snapshots

Rotating NuDB keeps active and archive generations, with generation fences and copy-forward handling for immutable objects. This allows bounded online deletion without discarding valid stored nodes.

Operators can export a snapshot while the node is running. Offline import streams records into NuDB, verifies SHA-256 integrity, and supports LZ4 compression. Snapshots simplify recovery, but operators must still decide which ledger state to trust.

Operator CLI, structured logs, and diagnostics

The CLI provides direct RPC access, configuration checks, doctor, ledger and acquisition inspection, NodeStore counters, snapshot commands, validator-key tools, and graceful shutdown. Structured logs include subsystem and severity context.

Installers are available for Linux and macOS. The Windows installer verifies the binary, and Docker Compose provides a packaged deployment option. Migration guidance covers existing volumes and configuration. Selected metrics exist internally, but packaged deployments do not expose a Prometheus /metrics endpoint.

See the CLI reference, configuration reference, and running guide.

Corrections, not protocol features

Recent work addressed OfferCreate Direct IOU semantics, BookDirectory quality, Fill-or-Kill regressions, Payment and AMM flow, metadata, ledger application, MPT behavior, consensus, and recovery.

An OfferCreate mismatch was reproduced at public-Testnet ledger 20660471. A seven-SLE replay isolated it, focused tests captured it, and the corrected binary returned to sustained full. The correction is available in the source on main.

The XRPL protocol remains unchanged

Quaxar does not intentionally change transaction rules, amendments, serialization formats, ledger hashes, or consensus rules. Its runtime, storage, diagnostics, and operator interfaces may differ, but the protocol target remains established XRPL behavior.

Parity corrections are bug fixes. Likewise, a Quaxar capability is not a measured advantage over rippled unless evidence supports that claim.

Current limits

• Production validator operation is not recommended.
• Complete transaction, metadata, state, recovery, consensus, and RPC parity is not claimed.
• Full-history configuration exists, but a complete public historical deployment is not claimed.
• Initial sync time and hardware use depend on profile, storage, network conditions, retained history, and current network state.
• One deployment window cannot establish a universal performance ranking.