rippled Renamed to xrpld: What XRPL v3.2.0 Means for Builders

rippled Renamed to xrpld: What XRPL v3.2.0 Means for Builders

Part of our guide: XRP Explained.

Quick answer: XRP Ledger v3.2.0, released June 15, 2026, renames the reference server from rippled to xrpld under standard XLS-0095, ships a single bundled bug-fix amendment (fixCleanup3_2_0), and retires 28 long-activated amendments. For builders it also adds practical tooling: TLS/mTLS on the gRPC server, a configurable NuDB block size, a typed code generator, and a --definitions flag. Node operators are told to upgrade promptly and follow a migration guide because default config and database paths change.

Updated 07/17/2026. By Jake Claver. Educational content, not investment advice.

This is a maintenance release, not a feature blockbuster. The headline is organizational: the software long known as Ripple‘s rippled daemon is now xrpld. The substance for builders sits underneath that: cleanup of the amendment list, a few developer-experience improvements, and a migration that touches how nodes are packaged and configured.

Every claim below traces to a primary source: the XRPL.org release notes, the GitHub release tag, and the XLS-0095 specification.

What actually shipped in v3.2.0

Version 3.2.0 carries one new amendment, fixCleanup3_2_0, which bundles corrections rather than a new capability: precision and rounding fixes for Single Asset Vaults and the Lending Protocol, a fix for the ValidPermissionedDEX invariant firing incorrectly, validation of non-canonical Multi-Purpose Token amounts, and a zero DomainID check for permissioned domains. The Lending Protocol itself is defined in XLS-66, an XRPL-native design for fixed-term, pooled loans; v3.2.0 refines its math rather than introducing it.

The rippled to xrpld rename (XLS-0095)

XLS-0095 formalizes renaming “ripple(d)” references to “xrpl(d)” across the project: the GitHub repository, the binary, config files, C++ namespaces, and packages. The stated motivation is to reflect the decentralized, community-driven nature of the ledger rather than a single company’s brand. Concretely, the binary is now xrpld, the config file moves from rippled.cfg to xrpld.cfg, the C++ namespace changes from ripple to xrpl, and the internal “Ripple epoch” timestamp becomes the “XRPL epoch.”

The rollout is deliberately staged. Low-risk cosmetic changes (include guards, comments, CMake files) land first; functional changes (config file, binary) are staged next; and high-impact community changes (repository, namespace) roll out slowly. Backward compatibility is preserved through overlapping support: a rippled symlink and the old config filename are accepted, with legacy artifacts maintained for roughly six months before removal. Flags tied to the ledger’s “rippling” mechanic, such as tfNoRippleDirect and ltRIPPLE_STATE, are left unchanged because they describe protocol behavior, not branding.

Protocol tooling builders get

The developer-facing additions in this release are incremental but useful:

• TLS and mTLS for the gRPC server, so infrastructure can secure gRPC connections between services.
• Configurable nudb_block_size (4K to 32K), giving operators a knob for NuDB storage tuning.
• A code generator producing typed wrapper classes for transactions and ledger entries.
• A --definitions CLI flag that outputs server definitions as JSON, handy for tooling and client libraries.
• Official DEB and RPM package builds added to the release pipeline, plus updated ledger_entry RPC options.

Operators should also note environment defaults called out in the notes: base reserve of 1 XRP, owner reserve of 0.2 XRP, and a peering port set to 2459. These are documented in the XRP Ledger developer docs.

28 amendments retired

v3.2.0 moves 28 amendments to a retired state, meaning they no longer need on-ledger activation because they have been live for years. The list includes foundational ones such as Flow, Checks, DepositAuth, NegativeUNL, MultiSignReserve, and a long set of fix* amendments activated over two years ago. Retiring them trims the active amendment surface without changing behavior, which reduces long-term maintenance load for the codebase.

How node operators migrate

Because default config and database paths change, an in-place upgrade is not automatic. The official migration guide walks through backing up configuration, validator keys, and ledger data; removing the old package (which preserves existing data); installing xrpld; restoring the config to /etc/xrpld/xrpld.cfg; and either re-syncing small nodes from the network or transferring ownership of existing data at /var/lib/rippled for full-history nodes. A separate detail worth flagging: a new GPG signing key took effect February 18, 2026, and automatic upgrades will not work until operators trust the new key.

Why this matters

Renames rarely change what an application can do, but they do change what breaks. Automation, monitoring scripts, package references, and any code importing the ripple namespace all touch the old names. The six-month compatibility window is the practical safety net: teams can migrate without a hard cutover. The more durable value in v3.2.0 is the cleanup and the small tooling wins (typed code generation, JSON definitions, secured gRPC) that make client integrations and node operations more predictable.

Common questions

What is the difference between rippled and xrpld?

They are the same reference server software for the XRP Ledger. XLS-0095 renamed the binary, config file, repository, and C++ namespace from “rippled” and “ripple” to “xrpld” and “xrpl” to reflect the ledger’s community-driven governance. The rename does not change what the server does.

Do I have to migrate to xrpld immediately?

The release notes recommend upgrading to v3.2.0 promptly for service continuity, but XLS-0095 keeps legacy names working during a roughly six-month transition. A rippled symlink and the old config filename are accepted temporarily, so operators can migrate scripts and configs gradually rather than all at once.

What new amendment does v3.2.0 add?

One: fixCleanup3_2_0. It bundles bug fixes, including precision and rounding corrections for Single Asset Vaults and the Lending Protocol, a fix for the ValidPermissionedDEX invariant, validation of non-canonical Multi-Purpose Token amounts, and a zero DomainID check for permissioned domains. It is a maintenance amendment, not a new feature.

What do builders get in this release?

Practical tooling: TLS and mTLS on the gRPC server, a configurable NuDB block size (4K to 32K), a code generator that emits typed wrapper classes for transactions and ledger entries, a –definitions flag that outputs server definitions as JSON, and official DEB and RPM package builds.

Why were 28 amendments retired?

They had been active on the ledger for years, so they no longer need on-ledger activation. Retiring long-live amendments such as Flow, Checks, and DepositAuth trims the active amendment surface and reduces maintenance overhead without changing ledger behavior.

This content is educational only. It is not tax, legal, or investment advice. Check primary sources and speak with a qualified professional before making financial decisions.