XRP Ledger Enables Account Delegation as a Token-Minting Fix Lacks Two Validator Votes

XRP Ledger’s New Account‑Delegation Feature: What It Means and What to Watch

The XRP Ledger (XRPL) activated the PermissionDelegationV1_1 amendment on October 8, 2026, at ledger 107,524,865. The change lets an account hand specific transaction‑authorisation duties to other accounts without sharing its private keys. Each delegate can hold up to ten granular permissions, and the granting account can update or revoke the list at any time. The feature is a welcome step toward more flexible, multi‑party workflows on the ledger.

How Delegation Works

• Granular permissions – Delegates can be granted a subset of the granting account’s capabilities (e.g., `Payment`, `PaymentBurn`, `TrustSet`).
• Dynamic lists – A new `AccountSet` transaction with a fresh permission list replaces the old one; any permission omitted is automatically revoked.
• No key sharing – Delegates operate with their own keys, reducing the risk of key compromise for the primary account.

The amendment replaces an earlier version that was pulled after a critical bug was discovered. The XRPL documentation now advises caution around one particular permission.

The PaymentBurn Caution

The ledger’s amendments page warns: “Until the fixCleanup340 amendment is enabled, it is recommended not to delegate the PaymentBurn granular permission.” Why? The current `PaymentBurn` permission, if delegated, could allow a delegate to create new trust‑line tokens or multi‑purpose tokens, not just destroy existing ones. All other granular permissions remain unaffected.

Why the fix hasn’t activated

`fixCleanup340` is currently at 27 of 35 trusted validators—two votes shy of the 29‑vote threshold required for activation. Amendments that reach the threshold enter a 14‑day countdown before they go live. Until the fix is activated, users should avoid delegating `PaymentBurn`.

A Vote‑Counting Bug Under Review

On October 8, a GitHub issue reported that rippled v3.4.1 stops counting a validator’s amendment votes after that validator rotates its signing key, and it also drops the validator from the threshold calculation. The reporter’s node showed 33 validations and a threshold of 26 instead of the expected 35 and 28 after three validators rotated keys. While the bug does not currently affect any amendment’s pass‑or‑fail outcome, a proposed patch would track validators by a permanent node ID instead of the rotating key. The issue remains open for review.

Implications for the community

If the bug persists, it could delay the activation of future amendments that rely on a precise validator count. The dashboard already projects that two batch‑related amendments—`fixBatchV12` and `BatchV11`—might activate later Friday at 14:12 UTC and 14:46 UTC, respectively. Users should monitor the validator counts closely, especially if they rely on the timely rollout of new features.

Practical Takeaways for Developers and Users

1. Use delegation wisely – Grant only the permissions you truly need, and keep the list as short as possible.
2. Avoid PaymentBurn until the fix lands – Until `fixCleanup340` activates, do not delegate this permission to prevent unintended token creation.
3. Track validator votes – If you run a validator or rely on specific amendments, keep an eye on the validator count and any reported bugs that might affect vote tallies.
4. Stay informed – Follow the XRPL dashboard and the rippled GitHub repository for real‑time updates on amendment activation and bug fixes.

The XRPL’s move toward account delegation is a significant step toward more modular, secure operations. By staying alert to the remaining caveats—particularly around `PaymentBurn` and validator vote counting—users can fully leverage the new feature while mitigating risk.

---

TL;DR: The XRPL enabled account delegation on Oct 8, but users should avoid delegating the `PaymentBurn` permission until the `fixCleanup340` amendment activates, and they should monitor a reported vote‑counting bug that could delay future amendments.