
Safe scopes and the first version
4 minDifficulty Checked 2026-11-10- Prefer granular permissions. A whole transaction type like Payment is a wide grant.
- DelegateSet replaces the whole list. An empty list removes the delegate.
- The original PermissionDelegation was disabled in rippled 2.6.1. It never ran on mainnet.
Delegation is a tool for limiting damage. It only works if the grants are small.
Habits that keep it small
- Pick a slice over a whole type. "Approve trust lines" is safer than "send any TrustSet".
- Think hard before granting Payment. A delegate with it can send your funds anywhere.
- One job, one delegate. Do not pile ten permissions on one online key.
- Check your list now and then. Remove delegates you no longer use.
- Remember that an update replaces the list. Send the full list each time, or you drop permissions by accident.
To remove a delegate, send the same transaction with an empty list.
It changes what "locked forever" means. Some token issuers give up all their keys so nobody can ever mint more. That is called a blackholed account. An account that still has a delegate is not blackholed. Someone can still act for it. Anyone checking an issuer now has to look for delegates too.
The first version never went live. Delegation first shipped in June 2025 and went to a validator vote. In September 2025, a community member testing on Devnet found a flaw. An attacker could make a victim's account pay transaction fees for transactions the victim never signed. Repeat that with high fees, and the victim's XRP drains away.
The feature was still in voting, so mainnet was never exposed. Validators voted No. The old amendment was switched off in the next release. A corrected one took its place and went live on 2026-10-08.
Timeline
| Date | Event |
|---|---|
| 2025-06-24 | rippled 2.5.0 ships PermissionDelegation |
| 2025-09-15 | tequ reports the bug from Devnet testing. Validators are advised to vote No |
| 2025-09-29 | Disclosure report published |
| 2025-10-06 | rippled 2.6.1 release post: the amendment is disabled |
| 2026-08-06 | xrpld 3.3.0 ships PermissionDelegationV1_1 |
| 2026-10-08 | PermissionDelegationV1_1 enabled on mainnet |
Root cause. For a delegated transaction, the server checked the delegate's permission before it checked the signature. A missing permission returned tecNO_DELEGATE_PERMISSION. Results in the tec class charge the fee. So a transaction naming a victim as Delegate, with a high Fee and no valid signature from the victim, still cost the victim that fee. The path needed a transaction signed offline. Signing through a server's RPC caught the bad signature first.
Fix. The disclosure report gives two rules. An error returned before signature verification must not be a tec code. And checks that can return tec must run after the signature check. The code is now terNO_DELEGATE_PERMISSION. A ter result means the transaction was not applied, so no fee is taken. The report also planned an invariant check so no fee is deducted unless the signature was verified.
PermissionDelegationV1_1 replaces both PermissionDelegation and an interim DelegateV1_1. xrpld 3.3.0 also rejects delegation to pseudo-accounts and blocks delegated transactions from the queue.
Revoking. DelegateSet with an empty Permissions array deletes the Delegate entry and frees its owner reserve.
Auditing. List an account's Delegate entries with account_objects. xrpl.org's conditions for a blackholed account include that no Delegate entry exists for it.
Live status: PermissionDelegationV1_1. The Batch amendment has a similar history: Why Batch was replaced.
Related: How amendments happen, Check before you hold.
- Vulnerability Disclosure Report: XRPL Permission DelegationRead 2026-11-10
- Introducing XRP Ledger version 2.6.1Read 2026-11-10
- Introducing XRP Ledger version 3.3.0Read 2026-11-10
- Known AmendmentsRead 2026-11-10
- Blackholed AccountsRead 2026-11-10
- DelegateSetRead 2026-11-10
