The XRP Ledger's BatchV1_1 amendment has 30 of 35 validator votes: what the ledger's own amendment table shows, what activation on 29 September would change, and what it does not

A blockchain amendment is a rule change with a countdown. On the XRP Ledger the countdown is public: every validator on the trusted list publishes its vote, the ledger records the moment a proposal first passes the threshold, and two weeks later, if the support has held, the rule switches on. This article reads one row of that table as it stood on the morning of 20 September 2026, for an amendment called BatchV1_1, and sets out what the row states, what the specification behind it describes, and what neither of them can tell you about the days that follow.

We read the amendment table through the XRPScan API on 20 September 2026 at 09:1x Central European Summer Time. The API lists 145 amendments in total. Exactly one of them is not yet enabled and carries a recorded majority. That row reads as follows: name BatchV1_1; enabled false; supported true; count 30; threshold 28; validations 35; introduced 3.3.0; majority 842796401.

Each field has a plain meaning. Count is the number of validators on the default trusted list that are voting for the amendment; validations is the size of that list; threshold is the number of votes required. Thirty is above twenty-eight. The majority field is a timestamp in the ledger's own epoch, which counts seconds from the first of January 2000; converted to the common epoch it corresponds to 15 September 2026 at 14:06:41 UTC. That is the moment the ledger first recorded the proposal as having passed the threshold.

The XRP Ledger's rule for activation is that an amendment which holds a majority continuously for two weeks becomes enabled. Fourteen days from 15 September at 14:06 UTC is 29 September at 14:06 UTC. The row does not state that date; we derive it from the timestamp and the rule, and the derivation holds only if the vote count stays at or above twenty-eight for the whole of that period. If it drops below the threshold at any point, the majority is lost and the clock restarts from whenever a majority is next recorded.

The xrpl.org list of known amendments describes BatchV1_1 in one sentence: it "Allows multiple transactions to be bundled into a batch that's processed all together." The page identifies it with the standard XLS-56 and gives its identifier as 9F287AED3CDB50A7BD1ACEC24296A30C9B5230CCD136219317AC790E3B884377. The mechanism described in the specification is a wrapper transaction that carries several inner transactions and processes them under one of a small set of modes, of which the most discussed is the all-or-nothing mode: either every inner transaction succeeds and the batch is applied, or the batch is discarded as a whole. The practical use most often cited for this is a delivery-versus-payment exchange, where one leg delivers an asset and the other leg pays for it, and neither party wants to be exposed to the other leg failing.

We record the description rather than evaluate it. Whether a given application on the ledger will use batching, and how, is a matter for the application, not for the amendment table.

BatchV1_1 carries a version suffix because it is a replacement. The same xrpl.org page lists an earlier amendment named simply Batch, identifier 894646DD5284E97DECFE6674A6D6152686791C4A95F8C132CCA9BAF9E5812FB6, introduced in server version 2.5.0, with a note that it was disabled in version 3.1.1 due to a bug and replaced by BatchV1_1. A second related amendment, fixBatchInnerSigs, introduced in 3.1.0 and described as fixing an issue where inner transactions of a batch would be flagged as having valid signatures, is likewise marked as disabled in 3.1.1 with its fix folded into BatchV1_1.

The XRPScan table is consistent with this history. Both Batch and fixBatchInnerSigs appear in the API with the flag deprecated true and with vote counts of 12 and 10 respectively, well under the threshold, and with no majority recorded. The table therefore shows three amendments with the word Batch in their names, of which only one is live as a proposal. A reader who counts the votes on the wrong row would be counting votes for a withdrawn proposal.

Three boundaries follow from the material. First, the count of thirty is a snapshot; validators change their votes, operators upgrade or fail to upgrade their servers, and the trusted list itself can change. The number we read at 09:1x on 20 September is not a number for 29 September. Second, the activation date is an inference from a rule, not a statement in the table; the table will show enabled true, and a transaction hash for the enabling ledger, only after the fact. Third, the amendment table records votes, not consequences. Whether any asset manager, exchange or application changes its behaviour when batching becomes available is not recorded anywhere in the ledger's amendment data, and this article makes no claim about it.

We also note what we did not read. We did not read the source code of the amendment, the security reviews that others have cited for it, or any validator operator's public statement about its vote. The article is bounded by two documents: the amendment table as served by XRPScan, and the known-amendments page on xrpl.org.

The XRP Ledger's amendment process is one of the mechanisms we describe in RIPPLE, the book, which covers the ledger's governance in its own chapter and is available as a PDF and audiobook. The live XRP price and volume series we display under Market Observation are sourced from exchange data and have no connection to the amendment table; a rule change on the ledger and a price on an exchange are two different kinds of fact, and we keep them on different pages. Readers who want the vocabulary of validators, amendments and thresholds explained from the beginning will find it in the Kripto Akadémia, and the way our research desk reads documents of this kind is described on the About page. Our earlier readings of regulatory and technical documents in this area are collected under Research.

XRPScan, amendments API, api.xrpscan.com/api/v1/amendments, read 20 September 2026 at 09:1x CEST: 145 amendments; BatchV1_1 count 30, threshold 28, validations 35, majority 842796401, enabled false, introduced 3.3.0; Batch count 12, deprecated; fixBatchInnerSigs count 10, deprecated. xrpl.org, Known Amendments, xrpl.org/resources/known-amendments, read 20 September 2026: entries for Batch, BatchV1_1 and fixBatchInnerSigs, identifiers and descriptions as quoted. The conversion of the majority timestamp uses the XRP Ledger epoch of 1 January 2000 00:00 UTC; the activation date is derived from the ledger's two-week rule and is not stated in either source.

Educational content. Not investment advice. This article describes a public amendment table and a technical specification; it contains no instruction to buy, sell or hold any asset.