
The XRP Ledger’s revised permission amendment has entered its activation countdown. If support holds, accounts could begin assigning narrow operating roles on October 5 without sharing full control.
PermissionDelegationV1_1 is designed for organizations that process transactions frequently but do not want keys capable of controlling an entire account inside everyday operational systems.
A stablecoin issuer may need one system to approve customer trust lines, another to process payments and a more protected setup to manage account security. The amendment would allow those duties to be divided among separate XRPL accounts. Its “bank-style” element is the separation of responsibilities; it does not indicate regulatory approval or confirmed adoption by a bank.
A compromised delegate could still be abused within its assigned role. The attacker would not automatically receive every power held by the main account, reducing the potential damage from one exposed operational key.
XRPL would enforce each permission onchain
Under the XLS-75 specification, the account assigning authority is the delegator. It submits a DelegateSet transaction naming a second account and the actions that account may perform.
The relationship is stored in a Delegate ledger entry. The delegate signs with its own keys, identifies the account for which it is acting and pays the transaction fee. XRPL rejects requests outside the recorded authority. The delegator can later update or remove that authority.
The official documentation lists transaction-type permissions and narrower granular permissions. Each delegate can receive no more than ten. The available granular controls are predefined, so organizations cannot create any restriction they want. Delegates must also maintain funded accounts, while each delegation creates an onchain object that increases the delegator’s owner-reserve requirement.
Sensitive powers, including changing signing keys or appointing new delegates, cannot be delegated. Transactions that cannot enter the open ledger immediately also fail instead of entering the queue.
Twenty-nine votes began a conditional countdown
PermissionDelegationV1_1 entered its 14-day activation period on September 21 with support from 29 of the XRP Ledger’s 35 trusted validators, according to the live amendment tracker.
At least 28 validators must continue supporting it. Falling below that level would reset the clock. CoinDesk reported a projected activation time of October 5 at 11:18 UTC, provided support remains uninterrupted.
The code already exists in XRPL server software, but it cannot be used on mainnet before activation. The separate Batch V1.1 amendment follows the same two-week process, although it concerns linked transactions rather than account authority.
Delegation is not a replacement for multisigning
Multisigning determines how many approved parties must authorize an action. Permission delegation limits which actions an operational account may request. An organization could combine them by restricting a delegate to payments while requiring several people to approve each payment.
After a key compromise, multisigning can stop one stolen signer from meeting the approval threshold. Delegation can restrict the attacker’s available transaction types even after the delegated account is compromised. Neither control verifies that the business instruction is legitimate.
The original version failed before reaching mainnet
A community tester found that the first PermissionDelegation implementation could, under certain conditions, charge a transaction fee to another account even when the delegated transaction was improperly signed. Repeated high-fee submissions could have reduced the victim’s XRP balance without revealing its private key.
The flaw was discovered during testing, and the amendment never activated on mainnet. The official vulnerability disclosure reported no loss of live user funds.
Coindoo previously examined why Permission Delegation returned in revised form with the xrpld 3.3.0 amendments. The new vote shows that validators are now willing to consider activating the replacement.
Activation will not establish institutional adoption
Wallets and custody providers must still build interfaces for creating, reviewing and revoking delegated authority. No named bank deployment has been announced, and institutions remain responsible for deciding which accounts receive each permission.
Compliance decisions would also remain outside the ledger. A company would still perform identity checks, sanctions screening and risk reviews through its own systems. XRPL would enforce which delegate may submit the resulting authorization; it would not determine whether the customer should have been approved.
Use of the feature would be visible through public Delegate entries, although linking an address to a company may require voluntary disclosure. Delegate accounts also need XRP for reserves and fees, but activation establishes no usage volume or automatic demand for the token.
Production use becomes the next test
If validator support holds, evidence will come from wallet integrations, new Delegate entries and named deployments. Those signals will show whether organizations need protocol-level separation between account ownership and everyday operations.
The vote makes limited account access possible. Its value will depend on how narrowly organizations configure those permissions and whether they use the feature outside demonstrations.
This article is provided for informational purposes only and does not constitute financial, legal or security advice. Validator support and activation times can change.



Be the first to comment