XRP Ledger’s Batch upgrade sits one validator vote from activation
The XRP Ledger’s Batch V1.1 amendment has moved within one validator vote of starting its two-week activation process, after developers fixed another 11 software issues uncovered during security reviews. RippleX said Monday that the latest review of Batch V1.1 identified problems involving transaction signatures, authorization checks and server crashes, with the fixes incorporated into the version now being considered by validators.
Support stood at 27 of the 35 trusted validators on the default Unique Node List on Tuesday, equal to roughly 77 percent — just below the 80 percent threshold required for the amendment to enter its activation period. Under XRP Ledger governance rules, an amendment must maintain at least 80 percent validator support for 14 consecutive days before it can activate. One more supporting vote would push Batch V1.1 over the line and start that countdown, though validators can still change positions, and support falling below 80 percent during the window would interrupt the process.
What Batch actually does
Batch V1.1 would allow as many as eight transactions to be grouped into a single operation, with execution rules that can require linked transactions to succeed together. For a token swap between two users, the feature could make both transfers dependent on each other — if one side of the exchange fails, the other transaction would not be completed independently. Wallets and marketplaces could use the same structure to process a customer payment and a platform fee in one atomic bundle, eliminating a class of partial-failure risk that currently requires workarounds like escrow or payment channels.
RippleX said commercial projects using Batch are already under contract or development, though the team has not publicly identified the companies involved. XRP traded near 1.40 USD on Tuesday, up roughly 0.3 percent over 24 hours, as the broader market holds steady ahead of this week’s Federal Reserve decision.
Validator support has climbed quickly
Momentum has built over the past week. On Sept. 8, Batch V1.1 had 24 votes from the 35 validators on the default Unique Node List, equal to 68.57 percent. Three more validators have since backed the amendment, bringing it to the current 27.
A similar process played out in July, when the fixCleanup3_2_0 amendment secured 85.71 percent support and entered its activation window. That package subsequently activated on July 29 after retaining enough validator backing for the required period — a reminder that crossing 80 percent starts the clock rather than finishing the race.
A rebuild after a serious authorization flaw
The current vote follows the withdrawal of the original Batch design after researchers found a vulnerability before the feature reached mainnet. Under certain conditions, the flaw could have allowed an attacker to place transactions from another user’s account inside a batch without obtaining the required authorization. No user funds were put at risk because the affected amendment never activated.
Developers rebuilt the feature, and Batch V1.1 was later included in xrpld 3.3.0, released on Aug. 6, alongside several other proposed protocol features — each of which still requires separate validator approval. RippleX software engineer Mayukha Vadari said the original signature problem was found in February, before mainnet deployment. “After the v1.0 signature bug was caught in February (pre-Mainnet, no funds at risk), we rebuilt it,” Vadari wrote on X on Sept. 14, describing a root-cause fix, reviews by four senior engineers, a Sherlock security contest and audits from Halborn and Common Prefix.
The review that found 11 more issues
The additional findings from the latest review covered signature handling, authorization checks and software conditions capable of crashing servers. Common Prefix classified one of the vulnerabilities as critical. According to RippleX’s review, the issue could have allowed an attacker to reuse permission that a user had signed and carry out more transactions than the user originally intended to authorize. Developers addressed the reported problems before the amendment reached its current stage of voting.
For XRP holders, the near-activation of Batch is a signal of protocol momentum rather than an immediate market event: the feature’s value will show up in whatever commercial deployments RippleX has under contract. But the episode also illustrates the XRP Ledger’s amendment process working as designed — a serious flaw caught before mainnet, a rebuilt implementation, multiple independent audits, and a slow, validator-by-validator consensus before anything ships. The next single validator vote determines when the two-week countdown begins.
11 more bugs found in a security review and it is still one vote from going live. better they surface now than after activation i guess
yeah tbf that is literally what the review process is for. tx signature bugs getting caught pre-activation is the system working
27 of 35 validators, one short of 80 percent. Feels like watching paint dry, but that gap is basically nothing. Expect it flips this week.
flipping assumes nobody drops off. 27 of 35 held through two review rounds already, momentum is real
flips this week assumes the hold rate sticks. last amendment sat at 27 of 35 for nine days before the 28th vote showed up, patience
nine days stuck at 27 votes last time is exactly why im not refreshing the unl page every hour. it flips when it flips
nine days last cycle and this one already cleared two security review rounds before the vote count stalled. the 28th validator isnt hesitant, theyre just making everyone sweat for it
throughput was the real bottleneck and grouping 8 txs into one ledger slot is a quiet capacity multiplier nobody prices in
batching eight transactions together is the actually useful part here. fees were never the xrpl bottleneck, throughput was
one vote from the 14 day countdown and nobody is watching. 8 txs per batch in a single fee actually matters for escrow and marketplace flows on xrpl
^ exactly, one fee across 8 txs is the part that matters for escrow flows. everyone else in here arguing about xrp price again
27 of 35 on the UNL, one vote short. they fixed 11 bugs including signature and auth check issues and validators are still dragging feet
27 votes held through two security review rounds, doubt its dragging feet. more likely nobody wants to blink first on new transaction semantics
nobody blinking on new tx semantics is honestly the correct read. atomic batches change failure modes, cautious validators beat a rushed 28th vote
Thats how XRPL moves though, 80 percent for 14 straight days. Slow by design.
eight txs in one atomic batch finally kills the partial fill anxiety on xrpl swaps. been waiting on this since the feature tracker went up
batch transactions alone wont move price but devs quietly shipping after 11 security fixes is the kind of thing that matters in 2 years
facts. 11 bugs caught in review instead of after mainnet is the system working. most chains just deploy and patch in prod
77 to 80 percent is literally one validator. someone is getting a lot of dm requests this week lol
lol imagine the telegram pestering that 28th validator is getting right now. hope they at least disclose publicly if they flip
Signature and auth check bugs caught in review instead of after activation. Plenty of chains still ship first and audit later.
auth check bugs caught in review is good, but it does make you wonder what the earlier reviews missed
eleven bugs fixed in one rippled batch and the feature still waits on a single validator vote. someone is refreshing unl vote counts nightly lol
^ the threshold math is the real story. quorum sits right at the edge so every holdout validator suddenly matters more than the code
one vote short, then 14 straight days above 80 percent, and support can still drop mid window. the amendment process really does test your patience like a slow epoch
slow epoch is generous. a two week window where support is allowed to dip feels designed to force a re-vote every single cycle