The XRP Ledger has activated PermissionDelegationV1_1, introducing granular account permissions on mainnet, while a second major amendment, BatchV1_1, approaches its own activation later on October 9. The two changes expand how XRPL accounts can distribute operational authority and coordinate multi-step transactions without treating software release and mainnet activation as the same milestone.
According to official XRPL documentation on permission delegation, PermissionDelegationV1_1 allows one account to authorize another account to perform specified actions on its behalf. On-ledger tracking shows the amendment became active at ledger 107,524,865 on October 8 at 21:29:50 UTC. A delegate signs transactions with its own credentials rather than receiving the delegating account’s private keys, allowing organizations to separate operational roles while retaining control of the primary account.
The mechanism uses Delegate ledger objects and supports both transaction-level and granular permissions. Owners can grant, modify or revoke those permissions through DelegateSet transactions, while delegated accounts pay the fees for transactions they submit. Delegation therefore reduces the need to share highly privileged signing keys, but it still gives the delegate real authority within the exact scope recorded on-chain.
Permission Delegation Goes Live With a Security Caveat
PermissionDelegationV1_1 replaces an earlier implementation that was withdrawn after a critical bug was identified. It originally shipped as part of the broader XRPL v3.3.0 amendment package alongside BatchV1_1, ConfidentialTransfer, DynamicMPT and Sponsor. The August software release made the code available to validators, but each protocol amendment still required separate approval before becoming active on mainnet.
One limitation remains important. XRPL’s current documentation advises users not to delegate the granular PaymentBurn permission until the separate fixCleanup3_4_0 amendment is enabled. Before that fix, a delegate holding PaymentBurn authority may also be able to mint certain fungible tokens under specific circumstances. Other granular permissions are not affected by that documented issue, but the warning means the new delegation framework should not be described as universally risk-free.
BatchV1_1 Still Awaits Final Mainnet Activation
BatchV1_1, meanwhile, remained in its activation process at the latest verified snapshot on October 9. Validator support stood at 30 of 35, above the 29 votes required to preserve the amendment’s supermajority. Its two-week window reaches completion around 14:46 UTC, after which XRPL’s flag-ledger process must formally enable the amendment. October 9 is therefore the activation window, not evidence that Batch was already live earlier in the day.
The timing follows an earlier BatchV1_1 validator reset that pushed activation to October 9. XRPL amendments must maintain support from more than 80% of trusted validators for two consecutive weeks, and falling to 80% or below restarts the clock. That governance rule previously erased BatchV1_1’s earlier countdown rather than merely pausing it.
Once enabled, BatchV1_1 will let users submit up to eight inner transactions together using four execution modes: All or Nothing, Only One, Until Failure and Independent. Only the All or Nothing mode provides the full atomic behavior in which every required transaction succeeds or none of them are applied. That can support workflows such as coordinated payments, asset swaps or multi-leg settlement without leaving one side completed while another fails.
The revised Batch implementation also follows earlier security work. The original Batch amendment never activated after researchers discovered a critical authorization flaw, and the corrected BatchV1_1 replaced it. XRPL subsequently released xrpld 3.4.1 with an additional fixBatchV1_2 amendment addressing another security-sensitive Batch issue; live network tracking showed that companion fix already enabled before BatchV1_1’s final activation window. The sequence illustrates why code release, validator approval, security fixes and mainnet activation remain distinct stages of an XRPL upgrade.
The upgrades should also be separated from raw network capacity. XRPL recently recorded 3,254 transactions in a single validated ledger, but that isolated event included both successful and unsuccessful transactions and was dominated by concentrated payment activity. BatchV1_1 changes how related transactions can be coordinated; it does not establish a higher sustained throughput ceiling for the ledger.
For XRPL developers, the immediate change is therefore twofold: granular delegated authority is already available on mainnet, while transaction batching is completing a separate consensus process. Together they expand account-control and settlement primitives, but their practical adoption will depend on applications actually integrating the new transaction models rather than on activation alone.
Jack Reynolds is SatoshiPick’s infrastructure mind. Based in Denmark, he follows Bitcoin, Ethereum, Layer 1 networks, stablecoins and DeFi with a practical question always in the background: does this actually make crypto work better?
His articles focus on the systems beneath the headlines: settlement rails, protocol upgrades, stablecoin usage, DeFi coordination and the regulatory limits around them. Jack avoids turning technical coverage into a maze. He explains what is live, what is still experimental and why the difference matters.