XRPL’s BatchV1_1 amendment was above the validator threshold in an XRPSCAN snapshot checked at 17:05 UTC on 15 September, but it was not enabled. The feed recorded 29 supporting validations out of 35, against a listed threshold of 28.
| What you need to know |
|---|
| XRPSCAN recorded 29 supporting validations out of 35 at 17:05 UTC on 15 September 2026. |
| The feed listed a threshold of 28 and still marked BatchV1_1 as not enabled. |
| XRPL amendments require sustained validator support for two weeks before activation. |
| BatchV1_1 replaces the original Batch amendment; its batching modes have different rules for failed transactions. |
The figures can be checked in the XRPSCAN amendments feed and its amendments overview. They describe the recorded state at that time. They are not an activation announcement, and the support count can change.
Support has to last
Under the XRPL amendment process, a proposal needs more than 80% support for two weeks. If it loses the required support during that period, the waiting period starts again once it regains it. A single above-threshold reading therefore cannot establish when an amendment will become available.
XRPL’s known-amendments documentation identifies BatchV1_1 as the replacement for Batch, which was disabled in version 3.1.1 because of a critical bug. That history makes the amendment’s exact name and enabled status relevant when checking whether an application can use it.
One batch can have different failure rules
The XLS-56 specification describes grouping transactions and choosing how the group behaves if a transaction fails. In its all-or-nothing mode, every transaction must succeed for any to succeed. Its independent mode instead allows transactions to be processed regardless of failures elsewhere in the batch.
For example, the specification describes minting an NFT and creating an offer in one all-or-nothing operation. If creating the offer fails, the mint is reverted too. That behaviour depends on the selected mode; it should not be assumed for every batch.
For a wallet developer, that leaves two separate checks: whether BatchV1_1 is enabled on the intended network, and whether the chosen mode matches the result promised to the user. An above-threshold vote count answers neither question on its own.
