XRP Ledger Batch Amendment: Why September 29, 2026 Is a Hard Deadline for Node Operators

On September 29, 2026 at 14:06:41 UTC, a protocol upgrade on the XRP Ledger arms itself: the batch amendment carrying the internal name BatchV1_1. If you hold XRP on an exchange or in a custodial wallet, there is nothing for you to do. If you run a node of your own, or run a service against a node of your own, this date is a hard deadline, after which your server drops out of the network.

This article explains what the amendment changes, where the date comes from, how to check the status yourself and which caveats are attached to the date. Every figure in this article comes from the validated ledger and from the protocol documentation, not from announcements.

What an amendment on the XRP Ledger is and why it needs no shutdown date

An amendment is a change to the rules of the XRP Ledger protocol that the network's trusted validators vote on, rather than a company scheduling it. That is what separates the process from a classic hard fork with an announced block height: there is no calendar entry that somebody sets, only a condition that the network either meets or does not.

The rule behind it is written into the protocol documentation and it is short. An amendment needs the approval of more than 80 percent of the trusted validators, and it has to hold that approval continuously for two weeks. Only then is it activated. Should approval slip below the threshold at any point during those two weeks, even briefly, the count starts again from the beginning.

For you as a reader that means two things. First, a date of this kind can be verified, because it sits in the ledger and not in a press release. Second, it is not immovable while the two weeks are still running. Both points are the heart of the matter for the date at issue here.

What the BatchV1_1 batch amendment changes technically

Batch is a new transaction type that bundles several individual transactions into one package processed together. According to the protocol reference, a package holds at least two and at most eight inner transactions, which may also come from different accounts. Until now the XRP Ledger required you to submit every step on its own and to hope, with each one, that it went through.

The practical gain lies in the certainty. Anyone submitting two steps one after the other today, say an approval and then a swap, carries the risk that the first step succeeds and the second fails. A package closes that gap, because the network knows the processing rule and enforces it.

Do I have to do anything if my XRP sits on an exchange?

No. That is the most common situation, and the least dramatic one. If your XRP sits with a trading platform or in a custodial wallet, the provider runs the infrastructure and the duty to upgrade is theirs. You do not have to move holdings, sell, or change an address. Shuffling balances in a hurry because of a protocol date mainly produces fees and, in case of doubt, a taxable event that was never needed.

The occasion is still worth a calm inventory that has nothing to do with the date. Do you know which provider holds which part of your balance, how high the withdrawal fee is there, and whether the provider is supervised in the EU? Regardless of the protocol date, those are the more important questions.

What to check if you hold your XRP in self-custody

Even in self-custody the case is usually a simple one. A hardware wallet stores your private key and signs transactions with it; as a rule it reaches the network through the servers of the wallet provider. The keys themselves are never affected by an amendment, because an amendment changes the rules of the chain, not your address and not your access.

What you can do is keep the software you use to reach the wallet up to date, and check once before the date that your recovery words are where you believe them to be. That is basic hygiene and it is right independently of September 29. If you are still undecided about which device to pick, our hardware wallet comparison helps.

Amendment-blocked: what happens to an outdated xrpld node on September 29

Amendment-blocked is the state a server falls into when it does not know an activated protocol rule. The protocol documentation describes the consequences unambiguously: a blocked server can no longer validate ledgers, can no longer submit or process transactions, can no longer take part in consensus and can no longer vote on future amendments.

The decisive sentence stands right beside it: a server's voting configuration has no bearing on this. Anyone who has set their xrpld to vote against the amendment is just as blocked after activation as someone who voted in favour. What gets a server blocked is the missing code that understands the new rule. There is no carrying on against an activated majority decision.

The server does not crash while this happens, and it throws no conspicuous error message on the wall. It keeps answering, only no longer with valid data from the running chain. That is exactly what makes the state dangerous for services that query a node of their own in the background: the application looks healthy and serves a data state that has stopped moving.

Where the September 29, 2026 date comes from and how it is arrived at

The date is calculated, neither derived nor estimated. The validated ledger holds an object that tracks the state of every amendment. It contains a field called Majorities, and for every amendment that has reached the threshold, that field records the point in time from which the two-week period runs.

This editorial team queried the object on September 18, 2026 at around 00:35 UTC through a public XRP Ledger node (ledger index 107058182, response HTTP 200). The Majorities field held exactly one entry: the amendment with the identifier 9F287AED3CDB50A7BD1ACEC24296A30C9B5230CCD136219317AC790E3B884377 and the CloseTime value 842796401.

The XRP Ledger counts time from January 1, 2000. Converting that value gives September 15, 2026, 14:06:41 UTC as the start of the period. Two weeks later falls September 29, 2026, 14:06:41 UTC. The cross-check through the feature query on the same node returned the name BatchV1_1 for the same identifier, along with the values enabled: false and supported: true. The amendment is therefore known to the network and supported, but not yet active.

How to check the status of the amendment yourself

You do not need a node of your own for this. A public XRP Ledger endpoint answers the question with a single request. Anyone comfortable with the command line sends a feature request carrying the identifier above to a public node and reads three fields out of the answer:

• enabled: if this reads false, the amendment is not yet active. Once the value flips to true, activation has taken place.
• supported: if this reads true, the software of the node you asked already knows the rule. If it reads false, that very node will be blocked at activation.
• majority: the timestamp from which the two-week period runs. Should this field disappear again, the majority has slipped and the countdown has been reset.

That third point is precisely why you should look at the status once more shortly before the date, instead of writing the date down and ticking it off. The same route applies to a node of your own, with one important difference: send the feature query to your server, not to somebody else's. Only the answer of your own node tells you anything about your own node.

Which software version brings the new rule with it

The server software of the XRP Ledger is called xrpld and is published as open software. The current release is 3.4.0, published on September 17, 2026; before that came 3.3.0 of August 6, 2026 (both dates taken from the release dates of the official source code archive, retrieved on September 18, 2026).

Copying a version number out of an article is still the weaker route. The reliable answer comes from your own server through the supported field: it answers the question of whether the running software actually knows the rule. Which version you believe you are running plays no part in it. If false stands there, only an update helps, and it has to happen before September 29.

Why the date carries a caveat

The two-week period runs for as long as approval stays above 80 percent. Should it fall below, the counter is reset and September 29 lapses. That clause is no theoretical footnote; it is the safety mechanism built into the procedure. It leaves the validators the option, right up to the last moment, of stopping a change if a problem surfaces in the meantime.

For your planning, one simple stance follows from this. Treat September 29 as the deadline you prepare for, and treat its arrival as unsettled. Anyone who updates a node loses nothing if the countdown is reset. Anyone who postpones the update because the date might still fall through ends up, in the opposite case, with a system cut off from the chain.

The four modes of a batch package and what they mean in daily use

A package is given a mode when it is submitted, and that mode determines how the network deals with failures. The protocol reference names four:

• AllOrNothing: every single transaction in the package has to succeed. If one fails, the whole package fails. This is the mode for sequences that only make sense in full.
• OnlyOne: as soon as the first transaction has succeeded, the remaining ones are skipped. It allows alternatives to be submitted of which exactly one should take effect.
• UntilFailure: the transactions run in order until one fails; everything after that is dropped. This suits sequences that build on one another.
• Independent: all transactions are processed independently of one another, regardless of whether individual ones fail. This is pure bundling without chaining.

As a holder you will rarely set these modes yourself. The difference becomes visible where applications make use of it: in wallet interfaces that gather several steps into one confirmation, and in trading applications, where a half-executed sequence has so far been the most awkward case of all.

What services, wallet providers and payment processors should clarify now

Anyone who reaches the XRP Ledger through infrastructure of their own rather than through an outside provider is affected. That includes payment services, trading applications, accounting tools with their own data feed and every wallet whose provider runs a node. For this group, three questions need answering before the date.

1. Does the feed run against a node of your own or against an outside endpoint? With an outside endpoint the duty lies with its operator, and you should ask there instead of acting yourself.
2. Does your own node report the value supported: true for BatchV1_1? If not, an update is due, with the usual lead time for testing and a maintenance window.
3. Would a data state that has stopped moving show up in your monitoring at all? A blocked node keeps answering. Monitoring that only checks reachability notices nothing of it. Whoever monitors the gap between the last validated ledger and the current time notices it immediately.

Experience says the third question is the one on which everything hangs. An outage that disguises itself as normal operation is discovered late, and in the meantime bookings and displays carry on working with old data.

How this date fits into the run of amendments so far

The procedure is routine on the XRP Ledger and runs several times a year. Most recently, on September 9, 2026, we described the activation of the previous amendment; anyone who wants to read the sequence through from the start again will find it in our article on which points to check on wallet, node and position. The mechanics are the same, only this time a concrete date and an open condition hang on it.

For placing the network as a whole, a look at what is being built on it remains more telling than any single protocol step. One example from February 2026 is the euro stablecoin of Société Générale, which is issued on the XRP Ledger. Applications of that kind are the reason binding transaction packages are in demand at all: anyone automating payment sequences wants no half-executed chains.

XRP Ledger batch amendment: what you take away from it

1. If your XRP sits with a provider, you do nothing. Use the date at most for a calm check on whether the provider still suits you: the overview of the best crypto exchanges puts fees and withdrawal routes side by side.
2. If you hold your own coins, check access and recovery, not the protocol. Your keys are not affected by an amendment. Which device is up to the job is shown by the hardware wallet comparison.
3. If you run a node of your own, send the feature query before September 29. If supported: false stands there, update the software. Anyone who also needs an overview of their holdings and how they are recorded for tax will find the tools for it under crypto tax software and portfolio trackers.

The primary sources for this article: the description of the amendment procedure and the protocol reference for the batch transaction, both in the official documentation of the XRP Ledger.

(As of September 18, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)