CryptoSlate
XRP Ledger validators have put the repaired BatchV1_1 amendment on a conditional path to activate at 14:06:41 UTC on Sept. 29. Thirty of 35 trusted validators backed the amendment, above its 28-vote threshold, with the majority first appearing on-ledger on Sept. 15. Under XRPL's rules, support must stay above 80% for two weeks, so the date remains conditional. The amendment replaces an earlier version pulled after researchers found a critical authorization flaw in February, before it ever reached mainnet.
Why it matters
The episode validated XRPL's amendment firewall. The original Batch amendment was still in its voting phase when researchers disclosed a signer-loop bug that returned success early instead of checking the remaining signers. Had it gone live, a forged entry could have executed a victim's transaction without their keys, though XRPL Labs' disclosure confirms no funds were ever at risk.
BatchV1_1 replaces that path with a rewritten authorization scheme under the XLS-56 specification. Every BatchSigner signature now binds the outer account, its sequence number or ticket, the batch mode, the ordered hashes of all inner transactions, and any nested signers, closing both the disclosed bug and adjacent replay vectors.
Market impact
The protocol fix shifts risk to implementation. An outer Batch can return tesSUCCESS even when inner transactions fail, so clients must inspect each inner result code. BatchV1_1 support shipped in xrpld 3.3.0 on Aug. 6, and servers that fail to upgrade become amendment-blocked once it activates. xrpl.js 5.0.0 built signatures on the older payload and gets rejected with temBAD_SIGNATURE, with compatible support arriving in 5.1.0.
Activation proves protocol availability, not adoption or XRP demand. The signals to watch afterward are whether outdated nodes get blocked, whether signing failures cluster around old client versions, and whether wallets and explorers present multi-account batches intelligibly.
Frequently asked questions
-
When will XRPL's BatchV1_1 amendment activate?
Conditionally at 14:06:41 UTC on Sept. 29, provided validator support stays above 80% for the required two-week period. Thirty of 35 trusted validators currently back the amendment, above its 28-vote threshold.
-
What was the flaw in the original XRPL Batch amendment?
A signer-loop bug returned success early when it hit a signer for a newly created account, so a forged entry purporting to authorize a victim account could have executed without the victim's keys. No funds were at risk.
-
Why can an XRPL Batch show success while inner transactions fail?
An outer Batch can return tesSUCCESS even when one or more inner transactions fail, and outside ALLORNOTHING mode partial execution is intentional. Clients must inspect each inner transaction's metadata and result code.
-
Which software versions support BatchV1_1?
xrpld 3.3.0 shipped BatchV1_1 support on Aug. 6, and xrpl.js 5.1.0 added the revised signing format. Version 5.0.0 produces signatures that BatchV1_1 nodes reject with temBAD_SIGNATURE, and outdated servers risk becoming amendment-blocked.
-
Does BatchV1_1 activation mean higher demand for XRP?
Not by itself. The vote and software releases establish protocol availability only. Useful signals will come after activation, such as blocked nodes, signing failures on old clients, and how wallets and explorers present batches.
CoinTelegraph
WatcherGuru
WuBlockchain
Crypto Rank News
TheBlock
Glassnode