rippled: the XRP Ledger daemon that gave up reporting mode

xrpld starts in one of several modes, and the mode list lives on xrpl.org

The daemon in this repository is `xrpld`, the server software that powers the XRP Ledger, written primarily in C++ and shipped under the ISC open source license. It does not run one way. Which behaviour you get depends on configuration, and the enumeration of those modes is not kept here: the README sends you to https://xrpl.org/rippled-server-modes.html. That page, not the source tree, is where mode definitions live, which means it is also where you find out what a given mode answers and what it keeps on disk.

Hold two claims apart while you read the rest of the documentation. The ledger has no central operator, and no single party decides which transactions succeed or fail. Software maintenance is described differently: a team of full-time developers at Ripple and other organizations maintain and improve it, with Ripple acting as steward for the technology. Validating transactions and shipping the code are separate jobs in that description, and only the first one is distributed.

Reporting mode was removed, and the replacement lives in another repository

The README removes a whole use case in one line: `xrpld` Reporting Mode has been replaced by Clio. Anyone who wanted an API Server, including a Full History Server, is pointed at the Clio repository instead. The consequence for planning is that participating in the ledger and serving data are now two programs in two repositories, and the one you install from this tree participates in consensus.

A design that assumed a single process would absorb network traffic and answer historical queries has to be reworked, and installing rippled expecting a query endpoint leaves you holding a node. Read the requirement before the hardware: if your job is reading old ledger state rather than agreeing on new state, this is the wrong repository to start from.

Four to five seconds to settle, conditional on the participants staying healthy

The README states that the consensus algorithm settles transactions in 4 to 5 seconds, processing at a throughput of up to 1500 transactions per second. Read the condition that arrives with the figure instead of the figure alone: the same document says transactions settle in seconds as long as those who choose to participate in the network keep it healthy. Liveness is a property of the participant set, not a promise compiled into the binary, and a thin or degraded validator set is where latency assumptions break first.

The same section claims XRP sits at least an order of magnitude ahead of other top digital assets. No benchmark data ships here to check that against; the top-level tree holds `tests/` and `sanitizers/` rather than anything recording throughput. Supply is the one figure that is fixed: 100 billion XRP were created in 2012, no more will ever be created, and the available supply decreases slowly as small amounts are destroyed to pay transaction fees.

main constructs an ApplicationImp that every other component holds by reference

The source layout gives a contributor an actual starting point. `main` constructs an `ApplicationImp` object, which implements the `Application` virtual interface, and almost every component in the application takes an `Application&` parameter in its constructor, typically named `app` and stored as the member `app_`. That single reference is what lets most components depend on any other component.

Two consequences follow. An edit to the `Application` interface reaches code that never names it, so reading a diff means reading that interface first. And because dependency direction travels through one shared handle rather than through constructor types, the internal graph is worth understanding before any refactor: the levelization document at `.github/scripts/levelization` exists for exactly that, and the markdown files under `src/xrpld/**/*.md` carry the local explanations.

Building starts in BUILD.md, and the tree mixes four toolchain declarations

The build section of the README is two instructions: read `BUILD.md`, and open an issue if something breaks. Everything a first build needs is therefore in the repository rather than in this article. These are the files a new contributor opens, and the order the tree implies:

BUILD.md
./Builds
./cfg
./CMakeLists.txt
./conanfile.py
./conan.lock
./rust-toolchain.toml

Platform-specific guides for building `xrpld` sit under `./Builds`, and example configuration files sit in `./cfg`. Four toolchain declarations in that listing are the part that surprises people: a CMake build, dependencies resolved through Conan and pinned in `conan.lock`, a Nix environment in `flake.nix` with a `nix/` directory, and a Rust toolchain file sitting beside Rust sources in `./crates`. The code also documents itself in two places worth opening early:

src/xrpld/**/*.md
.github/scripts/levelization

Installation guidance that is not in the repository is published at https://xrpl.org/install-rippled.html, and `package/` covers how builds turn into packaged artifacts.

C++ core, vendored git-subtree code, and a Rust directory beside it

The repository contents table gives six directories separate jobs: `./bin` holds scripts and data files for XRPL developers, `./Builds` holds platform-specific guides for building `xrpld`, `./docs` holds source documentation files and the doxygen config, `./cfg` holds example configuration files, `./src` holds the source code, and `./crates` holds Rust source code.

Some directories under `src` are external repositories included using git-subtree, and each one carries its own README file. Review a diff inside those with that in mind, since part of what you are reading arrived by subtree merge and moves on someone else's schedule. Upgrade reading starts at the top level too, where `API-VERSION-2.md`, `API-VERSION-3.md` and `API-CHANGELOG.md` sit beside `RELEASING.md`. If your tooling calls the WebSocket API, those files are where you find out whether a call still behaves the way your code expects. Licensing is ISC in `LICENSE.md`, with `CODEOWNERS` and `SECURITY.md` naming ownership and reporting routes inside the repository.

The tree names no supported platforms, no hardware, and no rollback

Several things an operator needs are simply absent here. The README says `xrpld` runs on a variety of platforms and stops there: no list of supported operating systems, no memory or disk figures, no database prerequisites. Mode-specific configuration keys are not in the tree either, since `./cfg` holds examples and the mode reference sits on xrpl.org. A rollback procedure between releases is not documented, which is the gap that bites when an upgrade goes wrong on a node that cannot be taken offline.

Recent history is easier to judge. Releases 3.4.1 (2026-10-10), 3.4.0 (2026-09-17) and 3.3.0 (2026-08-06) landed within weeks of each other, and the last push was on 2026-10-30, so this tree is moving quickly. The default branch is `develop`, which means a fresh clone tracks the development line rather than a released version. Pin a tag before running anything you depend on.

Editorial conclusion

Run rippled if you intend to operate a validating XRP Ledger node or work on the protocol in C++, and leave it out of any plan that needs historical queries or a reporting front end, because reporting mode has been replaced by Clio. Before committing hardware, read BUILD.md and pin a release tag, since the default branch is develop and the README gives no platform or sizing table.

Frequently asked questions

Official sources

1. License: ISC
2. Project website
3. README
4. Releases
5. XRPLF/rippled on GitHub