build (buildwithbsc)

<p>XRP Ledger validators are backing a rebuilt transaction-bundling feature more than twice as fast as a rebuilt account-permissioning one, even though the slower amendment just cleared a second independent security review. Permission Delegation, disabled last year after a bug that could drain fees from other accounts, has 11 of 35 validators, about 31%. Batch, pulled in February after its own critical flaw, has 24, or 68.57%. Both need more than 80%, held for two straight weeks, before either activates.</p>
<ul>
 <li>Permission Delegation V1.1 sits at 31% validator support (11 of 35), up from 20% (7 of 35) on August 21.</li>
 <li>Batch V1.1 sits at 68.57% (24 of 35), per XRPScan, more than double Permission Delegation’s total.</li>
 <li>Only one of the six amendments in this release, a smaller fix called fixCleanup, has reached the 80% bar so far. It activates September 11.</li>
</ul>
<h2 id="why-the-gap-matters">Why the gap matters</h2>
<p>Both amendments carry the same scar. Each shipped once, each got pulled for a critical bug found before it could be exploited on mainnet, and each came back rewritten in the same release, xrpld 3.3.0, launched as one six-amendment package in early August. Eight months on, one of them is closing in on activation and the other is barely a third of the way there. A second clean audit was supposed to be Permission Delegation’s answer to its history. So far, on the numbers, it hasn’t been enough to catch it up.</p>
<h2 id="what-went-wrong-the-first-time-twice">What went wrong the first time, twice</h2>
<p>Permission Delegation is meant to let an account hand off narrow jobs, DEX trading, token minting, clawback-related compliance work, without giving up its keys. It shipped in rippled 2.6.1, then got disabled in September 2025 after a community member testing on devnet found that the permission check ran before the signature check. An attacker could submit a transaction with no valid signature at all and still trigger a fee charge against the victim’s account. The fix reorders the two checks and ships as Permission Delegation V1.1.</p>
<p>Batch’s bug was different but landed the same way. It lets up to eight transactions from different accounts execute as one atomic unit. In February, a researcher and Cantina’s automated review tool found a flaw in how the outer transaction’s signature was validated, one that could have let an attacker act on an account without ever holding its keys. An emergency rippled release blocked the flawed version within days, and BatchV1_1 replaced it.</p>
<h2 id="a-clean-second-audit-and-a-standing-warning">A clean second audit, and a standing warning</h2>
<p>A validator who reviewed the fix says Cantina’s follow-up review of Permission Delegation, run over roughly two weeks in the spring, turned up nine issues, two of them rated high risk, and that all were resolved in a build that has since run through more than five thousand tests without a new one turning up. That specific account, relayed by a single validator rather than published directly by Cantina or Ripple, hasn’t been independently corroborated here beyond the validator’s own track record on XRPL security topics.</p>
<p><img src="https://cryip.co/wp-content/uploads/2026/09/EThereum-Delegation-Graph.png" alt="" width="1270" height="600"></p>
<p>It’s also not the first time this exact feature has been audited and still missed something. An earlier review by a different firm, run in June 2025, found only a shadowed variable and two informational notes, three months before the fee-draining bug turned up in ordinary devnet testing. XRPL developer Wietse Wind made a related point in November, arguing that audits, hackathons, and developer testing each catch different things and that none of them alone is a reason for validators to vote on trust rather than verification. He wasn’t talking about this specific review. The caution applies anyway.</p>
<p>None of this means Permission Delegation is unsafe, or that Batch’s faster climb proves validators trust it more for that specific reason. Batch may simply be more useful right now to the institutional users XRPL is courting, and validators don’t publish their reasoning behind a yes or no vote. What the numbers show is narrower and harder to argue with: two amendments that failed the same way, in the same release, are not recovering at the same pace, and a second clean audit hasn’t closed that gap on its own. Whether it eventually does is worth watching alongside fixCleanup’s September 11 activation, the first sign of how fast this particular batch of validators moves once they’re satisfied.</p>
<p>This post first appeared in <a rel="noopener noreferrer nofollow" href="https://cryip.co/xrp-ledgers-two-rebuilt-amendments-are-winning-back-trust-at-very-different-speeds/">XRP Ledger’s Two Rebuilt Amendments Are Winning Back Trust at Very Different Speeds</a></p>

XRP Ledger’s Two Rebuilt Amendments Are Winning Back Trust at Very Different Speeds

Table of Contents

CRYIP

Other articles published on Sep 9, 2026

Join our free newsletter for daily crypto updates!