XRP Ledger Activates Permission Delegation for XRP Accounts on Oct. 8

Update 21:07 UTC: Batch is now live. XRPScan's dashboard shows BatchV1_1 active on mainnet with 30 of 35 validators in favor and five opposed, an approval share of about 85.7% sustained through the required two-week window.

Delegation Goes Live on XRPL

Until this week, a business moving payments across the XRP Ledger, the blockchain behind XRP, faced a blunt choice: keep the keys that control its main holdings on an internet-connected machine, or pull staff away from compliance work whenever a signature was needed. That constraint ended on Oct. 8, when the PermissionDelegationV1_1 amendment went live and let an account owner grant separate helper accounts narrow powers while the master keys stay in offline storage. The change does not touch the XRP price or XRP supply; it rewires who may act on an account, and for what. Activation followed the ledger's standard path: more than 80% support from its 35 trusted validators, the operators who confirm transactions, held for two straight weeks, a floor of 29 votes. The countdown had reset in September after support slipped below that bar, and on-chain monitoring records show the amendment cleared on its second attempt. The use case is round-the-clock compliance. A stablecoin issuer can authorize a compliance account to approve new customers under KYC procedures while keeping treasury keys cold, the same offline discipline a Ledger Recovery Key enforces for individual holders. Each helper can carry up to 10 permissions, defined by action type rather than a spending cap: approve customers, execute payments, freeze specific accounts. The helper signs with its own keys, can perform only the granted actions, and the owner can revise or revoke the grants at any time. Banks already divide payment and compliance duties between departments; the amendment makes those separations enforceable at ledger level. The audience is measurable: figures shared by XRP treasury company Evernorth put the network's average tokenized assets at $3.72 billion in the second quarter, alongside about $539 million in Ripple's RLUSD stablecoin, roughly $4.26 billion combined. That permissioned-issuer design echoes structures tested in central bank digital currency pilots, and it extends the ledger's push into stablecoin onboarding at scale.

On-chain records pin the activation to a specific point: validators confirmed the EnableAmendment transaction in ledger 107,524,865, and developers have already started testing the first delegated operations on the live network. One design detail worth adding to the earlier picture of revocable grants: delegating critical functions such as changing the master keys is technically impossible, so a helper account can never rewrite the ownership it borrows from. The change also passes untouched by most holders, since personal wallets that store or send XRP operate exactly as before, and the feature is aimed squarely at large accounts that need role separation among treasurers, operations staff and auditors. The practical rollout now depends on major custodial services building the permission tools into their interfaces.

The Batch amendments, fixBatchV1_2 and BatchV1_1, are set to go live within hours, closing a timeline that stretches back to Feb. 19, 2026, when security researchers and Cantina AI found a critical logic flaw in the first Batch amendment's signature verification while it was still in voting. Batch V1.1 shipped with XRPLD 3.3.0 as a replacement, and a smaller defect fixed in XRPLd 3.4.1. A community retall in September had restarted the two-week clock after a temporary rejection, but validators have now adjusted their vote to activate Batch and its fix at the same time, with no extra waiting period. The feature underpins atomic multi-party consensus transactions on the ledger.

Batch is now live. XRPScan's dashboard shows BatchV1_1 active on mainnet with 30 of 35 validators in favor and five opposed, an approval share of about 85.7% sustained through the required two-week window. The feature bundles two to eight inner transactions inside one outer transaction, and users pick from four execution modes: All or Nothing, Only One, Until Failure, and Independent. Under the all-or-nothing setting, a failed inner payment stops the whole group, though the Batch fee is still deducted, so the official tutorial tells developers to check individual transaction results and balances rather than rely on the outer result. XRPL validator Vet pointed to over-the-counter trades, delivery-versus-payment settlement and NFT-for-NFT exchanges as early use cases, calling the feature a big unlock for institutions and retail builders. Nesting a Batch inside another Batch, and duplicate inner transactions, are rejected by the protocol.

Two Bugs Trail the Upgrade

Delegation went live with one documented exception. Official guidance tells users not to delegate the PaymentBurn permission until a separate fix activates. The permission is meant to let a helper destroy tokens issued on the ledger, but under certain conditions it also lets the helper create new ones, which could inflate an issuer's supply without authorization. The warning covers ledger-issued tokens, not newly minted XRP, and other granular permissions are unaffected. The fix stood at 27 of 35 validator votes on Friday, two short of the 29 needed to open the two-week countdown that would lift the advisory. The rest of the framework works as designed: a helper signs each action with its own key pair, so a compromised helper machine exposes only the granted slice of authority, not the treasury behind it, and grants can be rewritten or revoked at will. A second defect sits in the counting itself. A bug report filed on Oct. 8 in the rippled codebase describes servers that drop a validator from their amendment tally after it rotates a routine security key, even though the validator stays online and keeps voting. A server that loses track of two validators would measure support against 33 instead of 35, which can make a proposal look closer to passing on that server's count than it truly is. A proposed patch would have servers identify validators by a permanent identifier rather than the rotating key, and it remains under review. The episode is a reminder that XRPL amendments pass through validator consensus rather than a governance token tally, and that the tallying software is itself a component that can fail.

Dashboard data adds precision to both defects. The reporter behind the bug report recorded 33 validations with a threshold of 26 instead of the correct 35 and 28, after three validators rotated their signing keys, though no amendment's pass-or-fail outcome differs so far. The proposed patch, which would track validators by a permanent node ID, was still open for review on Friday. XRPL Dashboard, meanwhile, lists 95 amendments live on mainnet and projects two Batch-related amendments, fixBatchV1_2 and BatchV1_1, could activate later Friday at 14:12 and 14:46 UTC. The amendments page also notes PermissionDelegationV1_1 replaced an earlier version pulled after a critical bug surfaced, and names the pending PaymentBurn fix as fixCleanup3_4_0.

Timing Is the Remaining Constraint

What the upgrade removes is a permission gap; what it leaves is a schedule. Institutions that held back from tokenized funds and payments for want of granular controls can now split duties on-ledger, but PaymentBurn stays off-limits until its fix reaches 29 votes, and September's reset showed how a drifting validator count can restart a two-week clock. Until both patches clear, delegation ships with a documented asterisk, and the ledger's consensus pace, measured in weeks, still sets the calendar.