XRPL validators block amendment that could drain XRP

Validators on the XRP Ledger intervened in the amendment voting process to block a Permission Delegation proposal that could have allowed invalid offline-signed transactions to charge victim accounts and drain XRP through repeated transaction fees. Operators also previously stopped a separate Batch amendment after an authorization flaw was disclosed. No funds on mainnet were put at risk during the voting period.

Permission Delegation’s design would have let an offline-signed transaction, even after failing authorization, still levy a transaction fee on a target account. Repeated submissions of such failing transactions could gradually reduce an account’s balance by consuming its XRP to pay fees.

The original Batch amendment contained a different authorization flaw. That flaw could have enabled inner transactions to execute against arbitrary accounts without the accounts’ private keys, potentially allowing unauthorized payments and ledger changes. Network operators stopped the amendment before it could activate on mainnet.

RippleX is preparing a new xrpld release, 3.3.0, which includes rewritten versions of Batch and Permission Delegation along with other proposed features. On Aug. 1 the stable release remained xrpld 3.2.1; xrpld 3.3.0 was available in prerelease form with beta and release-candidate tags. The development registry marks BatchV1_1 and PermissionDelegationV1_1 as supported by the codebase but set to default No votes, meaning the software recognizes the amendments but validator approval and activation are separate steps.

Amendments on the XRP Ledger can activate only after two conditions are met: compatible server code must be released, and more than 80% of trusted validators must support the amendment continuously for two weeks. If support drops to 80% or below before the full two-week window completes, the activation countdown resets. At ledger 105,997,300 on Aug. 1, the mainnet Amendments object contained no Majorities field and did not list either replacement amendment as enabled, which indicates no two-week majority clock had begun. The ledger records only amendment clocks that have already crossed the majority threshold.

Operators should prepare for operational impact if an amendment activates. A server that does not understand an activated amendment can become amendment blocked, which prevents it from determining ledger validity, processing transactions, participating in consensus, or casting votes. If either rewritten amendment reaches activation, validators and node operators will need compatible xrpld builds to continue normal operation regardless of their earlier votes.

RippleX’s product head Jazzi Cooper identified five proposed features for the 3.3.0 release: Confidential MPT, Batch, Permission Delegation, Sponsored Fees and Reserves, and Dynamic MPT. Each requires validator approval and the activation process described above. Until a stable xrpld 3.3.0 is released and a sustained supermajority of validators supports any amendment for the required period, the rewritten proposals remain proposals rather than active protocol changes, and there is no mainnet exploit or loss to recover from.