Permission delegation on the XRP Ledger gives an account operator a way to assign selected transaction powers without handing over the primary account’s signing keys. The useful comparison is not full control versus no access. It is a set of explicit, on-ledger permissions that can separate routine work from the keys that govern the main account.
A delegation is a ledger object
The XLS-75 specification defines a Delegate object that names the account granting authority, the account receiving it and the allowed permissions. One object can contain no more than ten permissions. A DelegateSet transaction creates the object, replaces its permission list or removes it when an empty list is submitted.
This structure makes authorization inspectable. An issuer could let one operations account submit payments while a separate compliance account authorizes trust lines. Each delegate signs with its own keys. For a delegated transaction, the main account remains the account whose action is being performed, while the delegate pays the network fee and supplies the signature.
Granularity does not eliminate trust
A narrow grant limits what a compromised delegate can attempt, but the permission name still needs careful review. A general payment permission is materially broader than a permission restricted to one field or flag. The standard also warns that some account-management transactions would let a delegate expand authority or change core controls, so actions such as AccountSet, SetRegularKey, SignerListSet and DelegateSet are not delegable.
That boundary matters for institutional workflows. Keeping a primary key offline reduces its exposure only if daily operations do not require repeated access to it. Delegation can support that arrangement, but it adds another key, another funded account and another authorization object to monitor. The delegate pays transaction fees, and creating a delegation consumes one object reserve on the granting account.
The replacement amendment carries a specific warning
The XRP Ledger amendment registry says PermissionDelegationV1_1 replaced the original permission-delegation amendment after a critical implementation bug was found. Its current warning is narrower: operators should not delegate the PaymentBurn granular permission until fixCleanup3_4_0 is enabled. Before that fix, the delegated capability can also mint certain fungible tokens in some circumstances. The registry says other granular permissions are unaffected.
That caveat should be treated as a live configuration check, not copied once into an internal runbook. An operator evaluating a delegation should confirm the amendment state on the intended network, inspect the exact permission values and avoid assuming that a similarly named permission has a similarly limited effect.
An operating checklist for delegated accounts
Start with a task inventory and grant only the transaction or granular permissions needed for those tasks. Use separate delegate accounts for duties that should not fail together. Record the owner, purpose and expected lifetime of every Delegate object. Alert on changes to the permission list and on delegated transactions outside the expected schedule.
Revocation also needs a test. The granting account must retain a protected signing path capable of submitting the empty permission list that deletes the delegation. Test that path before moving the primary key offline, and repeat the test after wallet, custody or signing-policy changes.
Source: BlockchainReporter.