The XRP Ledger is preparing for version 3.2.0, an infrastructure-level release whose most visible change is the renaming of the network’s core server software from rippled to xrpld. XRPL Operations has confirmed that the release is coming soon, while validator Vet has pointed to June 15 as the target date, making the upgrade a near-term operational milestone rather than a fully finalized activation schedule.
The change is not aimed at regular XRP holders or application users. Instead, it focuses on validators, node operators, exchanges, explorers, wallet backends and infrastructure teams that depend on the reference server software. The main work is at the backend layer, where scripts, service files, monitoring checks and deployment pipelines may need to reflect the new xrpld naming.
XRP Ledger 3.2.0 is coming soon!
The core software powering the XRPL is changing its name from rippled to xrpld.
This transition will require some updates for infrastructure operators. We're preparing a detailed playbook to help guide you through the upgrade process. pic.twitter.com/296TNhUGkC
— XRP Ledger Operations (@XRPLOperations) June 4, 2026
Operators Prepare for the xrpld Transition
XRPL Operations said the transition from rippled to xrpld will require updates from infrastructure operators and that a detailed migration playbook is being prepared. Once the release is live, command-line checks are expected to identify the server as xrpld version 3.2.0, turning the naming change into a practical compatibility issue for automated systems.
The rename also carries symbolic weight. rippled has long been the name of the reference server implementation, but xrpld more directly identifies the software with the XRP Ledger itself rather than Ripple’s commercial brand. That helps separate open-source ledger infrastructure from company-specific products and services.
Version 3.2.0 is being discussed as a maintenance and optimization release, with public reporting pointing to server refactoring, code cleanup, number-handling improvements and possible memory-efficiency gains. However, final release notes and public benchmarks have not yet been published, so claims such as 30% to 40% lower memory use should remain provisional until the technical release confirms them.
Mainnet Timing Still Needs Final Confirmation
The June 15 date should be treated as a target, not a confirmed final activation date from XRPL Operations. The public message from XRPL Operations says the upgrade is coming soon, while external reporting attributes the June 15 timing to validator Vet. That distinction matters because infrastructure teams can prepare around the target without presenting it as an official locked mainnet schedule.
The release follows XRP Ledger version 3.1.3, which introduced the fixCleanup3_1_3 amendment. That earlier upgrade bundled fixes across NFTs, Permissioned Domains, Vaults, the Lending Protocol and Multi-Purpose Tokens, and was designed to improve long-term reliability after several operational issues were identified. Version 3.2.0 continues that infrastructure-hardening pattern rather than introducing a new user-facing feature set.
Security work around XRPL development has also expanded through AI-assisted testing, red-team processes and bug bounty intake, but those efforts should be framed as part of the broader development environment unless final 3.2.0 notes tie specific security changes to the release. The safer framing is that 3.2.0 arrives during a wider security-hardening push, not that every security initiative is part of the upgrade itself.
For validators and infrastructure providers, the practical risk is falling behind the supported server path once the new release becomes active. Operators will need to follow the migration playbook, update automation around the renamed binary and confirm that their nodes remain compatible with network operations. The release is therefore less about visible product changes and more about continuity of service.
For now, the clean takeaway is that XRPL 3.2.0 is approaching with a core server rename from rippled to xrpld, pending final documentation and official release confirmation. The next items to watch are the migration playbook, final release notes, confirmed activation timing and whether the reported memory-efficiency gains are validated in production.