XRP Ledger switches on permission delegation; Batch upgrades slated for late Oct. 9

A feature that lets an XRP Ledger (XRPL) account hand specific tasks, such as payments or token authorizations, to another account went live on mainnet at 6:29 a.m. KST on Oct. 9 (9:29 p.m. UTC on Oct. 8). According to the XRPSCAN explorer, the amendment, PermissionDelegationV1_1, was enabled in ledger 107,524,865. It is a fixed version of an earlier implementation that was halted after a security flaw surfaced in 2025.

An XRPL amendment activates only after it holds support from more than 80% of trusted validators for two uninterrupted weeks. Permission delegation crossed that threshold at 6:25 a.m. KST on Sept. 25 and completed the two-week period. Two Batch transaction upgrades waiting in the same queue are set to activate one after the other on the night of Oct. 9 if their support holds.

Master keys stay in the vault while a delegate does the work

With permission delegation, an account owner uses a DelegateSet transaction to specify which transactions another account, the delegate, may send on its behalf. The delegate signs with its own keys rather than the owner's and can send only the transaction types it has been granted. The delegate also pays the transaction fees. Each delegate can hold up to 10 permissions, and the owner can change or revoke them at any time by sending another DelegateSet.

Transactions tied directly to control of the account cannot be delegated as a whole: account settings changes (AccountSet), setting a regular key (SetRegularKey), changing a multi-signing list (SignerListSet), delegation settings (DelegateSet) and account deletion (AccountDelete). Only some settings, such as changing the domain, can be delegated separately as granular permissions. XRPL's official documentation says the feature lets frequently used online keys handle routine work while master keys stay offline. It said the feature is especially useful for compliance-heavy issuers, such as stablecoin issuers that must approve users one by one.

The first version could charge fees to someone else's account

According to a vulnerability report posted on the official XRPL site (xrpl.org) on Sept. 29, 2025, the first version (PermissionDelegation) checked permissions before verifying a transaction's signature. As a result, a transaction with an invalid signature could still fail as "no permission" and have a fee deducted, letting an attacker drain another account's XRP with fake transactions carrying high fees. A community developer known as tequ found the flaw on Sept. 15, 2025, while testing on devnet.

The feature had not yet been enabled on mainnet, so no losses occurred. The first version was disabled starting with server software 2.6.1, and validators voted against it to block activation. The fixed version no longer charges fees before a signature is verified and first shipped in server version 3.3.0.

Hold off on delegating token burns

XRPL's official list of known amendments advises against delegating the granular permission for burning tokens (PaymentBurn) until a follow-up fix, fixCleanup3_4_0, is enabled. Before the fix, a delegate holding that permission can, under certain conditions, also mint new tokens (trust line tokens or MPTs). Other granular permissions are unaffected, it added. As of Oct. 9 afternoon, XRPSCAN data showed the fix had not yet won 80% support and had not entered the two-week countdown.

XRP at 1,916 won on Upbit, under half its high from a year ago

XRP traded at 1,916 won on Upbit's Korean won market at around 3:30 p.m. KST on Oct. 9, up 1.0% from the previous close. It was also 1,916 won on Bithumb at the same time, and $1.4006 on Binance's spot market. The Upbit price was about 1.9% above the Binance spot price converted at 1,342 won to the dollar, a gap known as the kimchi premium (the gap between prices on Korean exchanges and global markets). XRP's 52-week high on Upbit is 3,970 won, set on Oct. 27, 2025.