The XRP Ledger’s PermissionDelegationV1_1 amendment has entered its 14-day activation countdown after 29 of the network’s 35 trusted validators backed the upgrade, setting up a potential October 5 go-live that would let XRPL accounts delegate specific powers to other accounts — without handing over control of their keys.
By Jennifer Kim | September 23, 2026
According to the live XRP Ledger amendment dashboard, the countdown began on September 21 and could put PermissionDelegationV1_1 into effect on October 5 at 11:18 UTC — provided validator support remains above the required threshold throughout the period. At least 28 of the 35 trusted validators must continue backing the amendment; if support falls below that level before the countdown ends, the activation timer resets.
What permission delegation actually does
Under the current account structure, businesses that need different systems or employees to carry out operations often end up giving an operational account far more authority than it actually needs. Permission Delegation is designed to split those responsibilities. An account could, for example, authorize another account to make payments on its behalf — without also granting it the power to change the primary account’s keys.
The institutional use cases are concrete. A stablecoin issuer could keep its main keys offline in cold storage while giving an internet-connected compliance system permission to approve customers to hold its token. Each delegated account can receive up to 10 permissions, and the account granting the authority can change or revoke them at any time. The arrangement mirrors the separation of duties that financial institutions have used for decades, where payment, compliance and administrative functions do not share the same level of access.
PermissionDelegationV1_1 forms part of a larger package of amendments introduced through xrpld 3.3.0, including BatchV1_1, ConfidentialTransfer, DynamicMPT and Sponsor — several of them aimed squarely at institutional transactions and token issuance. Sponsor would let another entity cover transaction fees and reserve requirements for users without controlling their accounts, while ConfidentialTransfer is designed to conceal Multi-Purpose Token balances and payment amounts from public view while retaining access mechanisms for authorized parties such as auditors.
Second attempt, after a 2025 security scare
This is not the first time permission delegation has approached the mainnet. The original amendment was halted before activation after a community tester reported a vulnerability on September 15, 2025. Under the affected implementation, the software checked whether an account had permission to perform a transaction before properly verifying its signature — meaning certain rejected transactions could still incur a fee. An attacker could have submitted unauthorized transactions carrying deliberately high fees and drained a victim’s XRP balance through repeated submissions.
Validators were advised not to support the amendment, preventing the vulnerable version from ever activating. The replacement in xrpld 3.3.0 changes how unauthorized transactions are handled: signature verification now takes place before the type of failure that could charge the targeted account. Permission Delegation is not the only feature to return after security work — BatchV1_1 likewise replaced an earlier implementation after developers found a separate critical signing vulnerability.
Will it move XRP’s price? Probably not by itself
For token holders, the honest answer is that the amendment has no direct mechanical link to XRP demand. PermissionDelegationV1_1 does not change XRP’s supply, issuance schedule or tokenomics. Institutions using delegated accounts would still use XRP for the ledger’s fees and reserve requirements, but the feature does not require them to buy or hold large amounts of the token.
Recent network history illustrates why XRPL adoption and XRP demand don’t always move together. RLUSD and tokenized assets have expanded on the ledger while XRP went through periods of price weakness, and a June institutional test involving JPMorgan, Mastercard, Ondo Finance and Ripple used the XRP Ledger for a tokenized Treasury redemption — with XRP’s role limited to network infrastructure rather than being the asset redeemed. An earlier analysis of Ripple Prime’s XRP exposure reached a similar conclusion: substantial institutional activity inside the ecosystem does not automatically translate into equivalent XRP buying.
The possible price connection is indirect: if delegated accounts make it easier for institutions to issue assets and process transactions on XRPL — keeping high-authority keys offline while operational systems handle routine tasks — the resulting activity would increase use of the network where XRP remains the native asset for fees and reserves. A short-term market reaction around activation is possible, since traders often respond to upgrade milestones, but any sustained effect would depend on actual adoption of the feature.
The verdict
PermissionDelegationV1_1 is infrastructure, not a catalyst — another brick in XRPL’s institutional toolkit alongside BatchV1_1, ConfidentialTransfer and the revised lending functions shipped in version 3.4.0 on September 16. If validator support holds, October 5 will mark the end of a two-year effort to bring safer, granular account permissions to the ledger. What it means for the XRP token depends on what institutions build with it next.
Market snapshot (CoinGecko, Sept. 23): BTC 85,636 USD, ETH 2,727 USD, SOL 117 USD.
Disclaimer: This article is for informational purposes only and does not constitute investment advice. Crypto assets are volatile and readers should do their own research.
29 of 35 validators and a 14 day countdown to oct 5. delegation without key handover is the feature XRPL business accounts have needed for years
agreed, paying bills from a delegated account without exposing your master keys closes a real operational risk gap
29 of 35 validators with a 14 day countdown means one or two flipping off resets the whole timer. oct 5 is optimistic but the design itself is solid, cold keys with delegated payment powers is what institutions actually want
The 10 permissions per delegated account cap feels low for a compliance team doing approvals at scale, but it is a start.
10 permission types per account is workable when you can delegate to multiple accounts segmented by role. compliance teams already split approvals that way internally
10 permissions feels tight until you realize most treasury ops teams use 3 or 4 of them anyway. approval chains get weird past that count
hanna has a point on the 10 permission cap but you can just spin up multiple delegated accounts, one per approval tier. cleaner audit trail than one giant key anyway
hanna has a point on the 10 permission cap but you can just spin up multiple delegated accounts, one per approval tier. cleaner audit trail than one giant key anyway
timer resets yes but validators rarely flip off an amendment this close with 29 already signaled. bigger risk is some exchange node running an old rippled build and panicking on activation day
one or two validators flipping resets the timer, sure, but 29 of 35 already onboard with two weeks left feels comfortable. the countdown exists so nobody rugs the activation last minute
oct 5 at 11:18 UTC, delegated payments without ever touching master keys. this is the kind of boring upgrade that actually gets institutions comfortable building on XRPL
PermissionDelegationV1 with revocable grants is honestly the feature XRP Ledger needed a decade ago. regular keys sort of did this but the 10 permission types make it auditable