XRP Ledger Amendments Explained: How Changes Get Approved

• An amendment normally needs more than 80% support from trusted validators for two weeks before it goes live.
• Validators can withdraw support during the waiting period, delaying activation while a problem is addressed.
• Servers need compatible software when new rules activate. Outdated servers can stop keeping up with the network.
• A published feature, a feature receiving votes, and a live feature are three different stages.

XRP Ledger amendments are changes to the rules the network uses to process transactions. They can add a feature, improve an existing one, or fix a bug. A change normally goes live after more than 80% of trusted validators support it for two weeks.

For newcommers, a validator is a server that helps the network agree on its transaction history. Validators also signal whether they support proposed rule changes, which lets the network add features while keeping every server on the same rules. XRPL explains the process in its amendment documentation.

Two episodes from 2026 show the process under pressure. A feature for grouping transactions was held back twice after security problems surfaced before launch. A separate payment bug was judged critical enough that developers fixed it outside the usual vote.

Buy bitcoin and stocks. Signup to Coinbase today

What is an XRP Ledger amendment?

An XRP Ledger amendment works like an update to a shared rulebook. The rulebook tells servers which transactions are allowed and how those transactions change account balances or other records.

Every participating server needs to reach the same result. If one server accepts a payment under new rules while another rejects it under old rules, they can disagree about the ledger. Coordinating the change keeps the network working from one agreed transaction history.

Developers therefore build a proposed change into the server software before the network activates it. Installing that software gives a server the ability to understand the feature, and the amendment vote determines when the network starts using it. Ripple describes this separation between developing a change and coordinating its activation in its overview of XRPL governance.

As a result, a release can contain working code for a service that users still cannot access on the live network. Before treating an announcement as a launch, check whether the amendment has actually been enabled.

In protocol terms, amendments govern changes to transaction processing, including bug fixes that alter transaction outcomes. Once an amendment is enabled, its rules apply to subsequent ledgers, and reversing the change requires another amendment. Software maintenance that leaves transaction processing unchanged can be released without an amendment.

How does XRPL amendment voting work?

Only validators vote on amendments, and each server counts the votes of the validators it trusts. Server operators usually begin with recommended validator lists, although they can choose their own trusted set. Holding more XRP does not give a wallet more amendment votes. XRPL’s validator FAQ explains how these trust lists work.

The approval rule has two parts: support must exceed 80%, and it must last for two weeks. If 35 validators are counted, an amendment needs 29 yes votes, because 28 out of 35 equals exactly 80% and falls short of the requirement.

Under the official amendment process, a change moves through four stages.

If support drops below the required level before the waiting period ends, the countdown restarts once support recovers. An expected launch date can therefore move even after an amendment appears close to approval.

The future of finance is here. Trade crypto and more

At the protocol level, votes are checked around every 256th ledger, known as a flag ledger, typically about 15 minutes apart. The network records when an amendment gains or loses the required support. Operators can configure their votes and change them; otherwise, the software uses its default vote, which can differ between releases. The trusted validator list is called a Unique Node List, or UNL.

What happens if a server misses an upgrade?

A server that lacks the code for an activated amendment becomes amendment blocked, meaning it can no longer reliably follow the network’s current rules. According to XRPL’s explanation of amendment blocking, the affected server cannot validate ledgers, submit or process transactions, participate in consensus (the process servers use to agree on the ledger), or vote on future amendments.

For an exchange or wallet provider, that can become a customer service problem. A business relying on the blocked server may lose its normal way of detecting deposits or submitting withdrawals. The impact depends on its infrastructure, including whether another compatible server is available.

Ordinary XRP holders generally leave server upgrades to their wallet, exchange, or infrastructure provider, so the practical question is whether that provider supports the network’s current rules. Businesses running their own servers need to follow release notices and upgrade before relevant amendments activate.

Operators should note that blocking depends only on whether a server’s software supports an enabled amendment. A validator that voted against a change still follows it after activation if its software supports it. The core server software is now called xrpld; older documentation calls it rippled. XRPL’s June 2026 release notes document that rename.

What happens to rejected and older amendments?

A release containing a proposal gives validators something to assess, and approval still depends on their support. A validator can oppose an amendment by voting against it. If enough validators withhold support, the change stays below the approval threshold. A single opposing validator has no automatic power to block every proposal, although one changed vote can matter when support is close to the threshold.

Developers can also replace a proposal after finding a problem, and the earlier version may then be listed as obsolete. The known amendments register includes proposals removed or replaced before activation, among them the original version of the transaction-grouping feature discussed below.

Successful amendments follow a different path. After an amendment has been active on the live network for two years, developers can retire it into the core protocol. Its behaviour continues, while the software can discard the older logic that applied before the change, reducing the historical code developers need to maintain.

The mechanics of retirement are defined in the XRPL standard for retiring amendments. Retirement removes the switch between old and amended behaviour, so current software may be unsuitable for accurately replaying ledgers from before a retired change. Historical analysis can require a server version from the period being examined.

Buy bitcoin and stocks. Signup to Coinbase today

Why did batched transactions take months to go live?

Batched transactions let users group up to eight transactions into one submission, with different options for how the group is processed. One option makes the group all or nothing. A user could, for example, create a digital collectible and offer it for sale together; if creating the sale offer fails, creating the collectible can be reversed within the same batch. The Batch documentation describes the available execution modes.

In February, researchers found a serious problem in how the original proposal checked permission to move funds. If activated, the flaw could have allowed transactions from a victim’s account without their approval. Validators were advised to vote against it, and an emergency software release prevented the original proposal from activating. The February disclosure says no funds were at risk because the feature had never gone live on the main network.

The replacement ran into another problem in September, when developers found that servers running different software versions could disagree over specially constructed batches. Validators withdrew support to stop the activation countdown while a correction was prepared.

On 9 October 2026, the correction activated ahead of the replacement feature, so batched transactions launched with the second problem already addressed. XRPL records the sequence in its October security disclosure. Withdrawn votes gave developers time to fix the feature before users depended on it.

Release notes and explorers list the replacement as BatchV1.1 and the September correction as fixBatchV1.2. The correction tightened checks on how transactions inside a batch are packaged.

Why did one critical fix bypass the vote?

Developers judged a separate payment bug too dangerous for the normal waiting period. Their October disclosure says specially constructed transactions could have created spendable XRP beyond the intended supply. Investigators believed the flaw dated to 2015.

The problem involved a calculation that could roll over when a total became too large, producing an incorrect smaller number. The fix took effect as servers upgraded, and the team reported finding no evidence of exploitation on a public network.

According to the official disclosure, this was the first deliberate bypass of the amendment process for a transaction-processing change since that system began. Developers judged the exposure from waiting to be greater than the risk of an immediate upgrade.

Operators tracking versions will find the overflow fix in xrpld 3.4.1, released on 25 September 2026. It affected exploit transactions while leaving ordinary transaction results unchanged. During the upgrade, patched and unpatched servers could still have disagreed over an attempted exploit, and rapid validator upgrades reduced that exposure.

The future of finance is here. Trade crypto and more

Which XRP Ledger changes are still waiting?

At the 31 October 2026, 23:45 UTC roll call displayed by xrpldashboard, a maintenance bundle had enough support for a countdown, while proposed vault and lending features remained below the threshold.

These figures come from xrpldashboard’s own node observations at that roll call and can change. A projected date also depends on the required support lasting through the waiting period and the network completing its activation checks.

The lending proposal would allow pooled assets to fund loans with agreed repayment periods. Its design supports loans without collateral, with borrower assessment and risk management carried out outside the ledger. Recording a loan on a blockchain still leaves the lender exposed to a borrower failing to repay. XRPL’s institutional credit documentation explains the intended structure.

In release notes, the maintenance bundle appears as fixCleanup3.4.0. The lending design combines a single-asset vault with a lending protocol. An extension adds closed-ended vaults with separate deposit, investment, and redemption phases, and recognises interest when payments arrive. The September release notes explain those changes.

How can readers track XRP Ledger amendments?

The official amendment register explains each proposal, and xrpldashboard shows votes and countdowns. Three questions, answered in order, separate a development announcement from a service people can use.

1. Has the code been released?
2. Has the proposal gained enough support to start its waiting period?
3. Has it actually activated on the live network?

Businesses should also read the relevant release notice and check whether their infrastructure supports upcoming changes. A feature affecting payments or account permissions is a reason to review how the business’s own service handles those operations.

An amendment approval tells you what the network can do. It gives no reliable forecast of XRP’s future price.

Operators can query the same information through the server’s feature method, which reports the amendments a server knows about, including whether each is enabled and supported. Its administrative version also lets validator operators configure votes. Check these fields separately, since a server can support a proposal’s code before the network enables it.