A mandatory rippled upgrade is a release that introduces one or more new protocol amendments and marks the end of support for a previous version. Unlike optional releases, failing to upgrade before the network's AmendmentBlocked flag becomes set will cause a node to lose consensus with the XRP Ledger, effectively taking it offline. For exchange infrastructure teams, custody providers, and validator operators, this is not a routine maintenance window—it is a hard deadline with direct operational and financial consequences.
Protocols
Preparing for a Mandatory rippled Upgrade
A pre-upgrade operational guide for XRPL node operators, exchange infrastructure teams, and custody providers. Covers identifying amendment-introducing releases, safe upgrade procedures, stability verification, and monitoring for consensus divergence during voting periods.
introduction
MANDATORY UPGRADE PREPARATION
Introduction
A practical checklist for XRPL node operators to safely navigate a mandatory rippled upgrade that introduces new protocol amendments.
The core risk during a mandatory upgrade is consensus divergence. A node running an outdated version will not understand the new transaction types, ledger objects, or validation rules introduced by an activated amendment. This leads to a fork in the node's internal state, transaction processing failures, and potential double-spend exposure if the node's APIs continue to serve stale data. The upgrade process must therefore include not just the software installation, but also a verification phase where operators confirm their node is tracking the network's validated_ledger sequence and hash after the amendment's activation window.
Operators should treat the upgrade as a multi-stage process: identifying the amendment-introducing release, reviewing its configuration changes and API deprecations, staging the upgrade in a non-production environment, executing the upgrade with a rollback plan, and then actively monitoring for stability. Key monitoring signals include the server_state, amendment_blocked status, and the validated_ledger sequence. Chainscore Labs can assist teams with upgrade readiness reviews, configuration audits, and the design of monitoring and alerting systems to detect divergence before it impacts downstream services.
UPGRADE READINESS
Quick Facts: Mandatory rippled Upgrades
Key operational facts for node operators, validators, and infrastructure teams preparing for a mandatory rippled upgrade that introduces new protocol behavior.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Release Identification | A new rippled version is published that introduces one or more amendments and is declared mandatory for all node operators. | Node operators, validators, exchange infrastructure teams, custody providers. | Identify the specific rippled version, its release notes, and the amendment IDs it introduces. Verify against the canonical XRPL Foundation repository. |
Upgrade Window | A mandatory upgrade must be completed before an amendment achieves the 80% supermajority and activates on the network. | All rippled node operators. | Monitor the amendment voting status via the |
Consensus Risk | Nodes running an old version after an amendment activates will become amendment blocked and diverge from the main network ledger. | Exchanges, custodians, and any service submitting or processing transactions. | Schedule the upgrade during a maintenance window. Validate that the new version is running and in sync with the network before the activation threshold is met. |
Configuration Changes | The new rippled version may deprecate or add configuration stanzas in | Validator operators and infrastructure teams managing node configuration. | Review the release notes and sample config files for the new version. Audit your existing |
API and Integration Impact | New features may introduce new transaction types, ledger objects, or modified RPC responses that client applications must handle. | Wallet developers, exchange integration engineers, DeFi protocol builders. | Test all transaction submission, balance tracking, and history retrieval workflows against a devnet or testnet running the new version before mainnet activation. |
Rollback Planning | If a critical issue is discovered post-upgrade, a rollback to the previous version is only safe if the new amendments have not yet activated. | High-availability infrastructure teams and security incident responders. | Prepare a documented rollback procedure. Ensure the team knows the exact activation status of new amendments before attempting any downgrade. |
Post-Upgrade Monitoring | After the upgrade, the node's | Node operators, monitoring and alerting teams. | Configure alerts for |
technical-context
WHEN A RELEASE IS NOT OPTIONAL
The Anatomy of a Mandatory Upgrade
A technical breakdown of the XRP Ledger amendment lifecycle stage that forces every node operator to upgrade rippled or fall out of consensus.
A mandatory upgrade on the XRP Ledger is not a governance vote or a new feature proposal—it is the final, non-negotiable stage of an amendment's lifecycle. After an amendment has been enabled on the network for a sufficient period, typically two years or more, a new rippled release will hard-code its functionality as a permanent, always-on part of the protocol. The amendment's unique ID is removed from the voting ledger object, and the feature can no longer be vetoed or configured. For node operators, this means the new rippled version is the only software that can correctly process the post-amendment transaction set.
The operational risk is immediate and binary: any node that fails to upgrade to the mandatory release before the hard-coded logic activates will diverge from the canonical chain. The node will not simply miss new features; it will calculate a different ledger state, leading to server_state errors, transaction rejections, and a complete loss of sync with the network. This is not a theoretical edge case. The transition from an enabled amendment to a default, hard-coded rule changes the transaction processing engine itself, and older rippled versions have no fallback path. Operators must treat the release announcement as a hard deadline, not a recommendation.
Preparing for a mandatory upgrade requires more than installing a new binary. Infrastructure teams must validate the release in a staging or devnet environment, confirm that all internal transaction signing and submission logic is compatible with the new default behavior, and monitor the network for any unexpected consensus divergence during the transition window. For exchanges, custody providers, and validators, the checklist includes verifying that all dependent systems—wallets, explorers, compliance tools—are also aligned with the post-amendment transaction model. A mandatory upgrade is the protocol's final assertion that a feature is now part of the XRPL's permanent foundation, and every operator must treat it as such.
WHO MUST ACT ON A MANDATORY RIPPED UPGRADE
Affected Actors and Systems
Validator Operators
Validator operators are the most directly affected group. Running an outdated rippled version after an amendment activates can cause a fork from the consensus ledger, leading to a loss of voting power and potential double-signing risks.
Action Steps:
- Monitor the
featuremethod to track amendment voting and activation windows. - Upgrade
rippledto the mandatory release during the two-week activation window, not after. - Verify your UNL publisher is also signaling support for the new version to avoid network splits.
- After upgrading, confirm your validator is back in the
proposingstate usingserver_info.
Chainscore can provide upgrade readiness reviews and configuration audits to ensure your voting infrastructure remains consistent with the network's canonical chain.
implementation-impact
MANDATORY UPGRADE PREPARATION
Implementation Impact Areas
A mandatory rippled upgrade introduces new amendment code that, once activated by validator vote, becomes a permanent protocol rule. Operators must prepare for the upgrade itself and the subsequent activation of new features.
05
Rollback and Recovery Planning
Prepare a rollback plan in case the new version introduces instability. This includes taking a full ledger snapshot before upgrading, documenting a downgrade path, and ensuring you can rebuild your node database from a trusted source. Test the recovery procedure in a devnet environment that mirrors your production topology.
06
Post-Activation Validation
After the amendment gains a supermajority and activates, validate that your node is processing the new transaction types correctly. Submit test transactions on the mainnet to confirm end-to-end functionality. Monitor for unexpected fee escalation, reserve changes, or new error codes that could indicate a misalignment between your integration layer and the new protocol rules.
MANDATORY RIPPLED UPGRADE
Upgrade Risk Matrix
Operational risk areas for node operators, validators, exchanges, and custody providers preparing for a mandatory rippled upgrade that introduces new amendment logic or deprecates legacy behavior.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Consensus engine | New amendment logic may alter transaction processing rules before activation | Validators, node operators | Run new version in parallel on a passive node to compare ledgers before switching production |
Amendment voting | New version may change default vote for pending amendments | Validators | Audit rippled.cfg amendment_majority and veto_amendments stanzas against governance policy |
API behavior | Deprecated fields or methods may be removed; new fields may appear in responses | Exchanges, wallets, data teams | Diff JSON-RPC responses between old and new versions for all used commands |
Ledger history | New version may require a different history shard format or pruning behavior | Node operators, custody providers | Verify history availability and replay time against operational SLAs |
Peer protocol | Network message versioning may change, risking eclipse from upgraded peers | All node operators | Monitor peer count and consensus participation immediately after upgrade |
Configuration | New required or deprecated rippled.cfg stanzas may cause startup failure | Infrastructure teams | Test startup with production config in staging before deploying to live nodes |
Sidechain bridge | Cross-chain proof verification or federated signing logic may change | Bridge operators, exchanges supporting sidechains | Validate bridge transaction submission and proof generation on testnet |
AMM and DeFi | AMM amendment fixes may alter swap pricing or liquidity behavior | DeFi protocols, market makers, liquidity providers | Simulate swap and deposit flows against new version on devnet |
MANDATORY RIPPLED UPGRADE
Operator Upgrade Checklist
A step-by-step operational checklist for XRPL node operators preparing for a mandatory `rippled` upgrade that introduces new protocol amendments. This process ensures a safe transition, prevents consensus divergence, and verifies operational stability before, during, and after the upgrade.
Review the release notes for the new rippled version to confirm it introduces a mandatory amendment. Identify the specific Amendment ID and its corresponding short name.
- What to check: The canonical release notes on the XRPL GitHub repository and the official XRPL blog. Verify the minimum supported version and any new configuration stanzas.
- Why it matters: Failing to upgrade by the activation deadline will cause your node to become amendment blocked and diverge from the main network, leading to service outages and potential financial discrepancies.
- Readiness signal: You have documented the new version number, the Amendment ID, and any critical configuration changes required for your node's role (validator, hub, API server).
resource-links
XRPL UPGRADE REFERENCES
Canonical Resources
Use these primary sources to confirm whether a rippled release is mandatory, which amendments it introduces, and how your node is behaving during upgrade and voting windows.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
MANDATORY UPGRADE PREPARATION
Frequently Asked Questions
Operational questions for node operators, validators, and infrastructure teams preparing for a mandatory rippled upgrade that introduces new protocol amendments.
A release is mandatory when it introduces new amendment IDs that are expected to activate on Mainnet. Check the release notes for the specific version. Look for:
- New amendment IDs listed in the release notes or the
libxrplsource code. - Statements from RippleX or the XRPL Foundation indicating that the release is required for Mainnet validators and node operators.
- The
server_infomethod on your node, which will show new amendments in the"amendments"object with their status.
If you do not upgrade before an amendment activates, your node will become amendment blocked and will not be able to process new ledgers. This is a hard consensus divergence, not a soft warning.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.