Acting for another account

4 minDifficulty Checked 2026-11-10

Key takeaways

The delegator sends DelegateSet to name a delegate and list its permissions.
The delegate signs with its own keys. The delegator's keys are never shared.
The delegate pays the transaction cost. The transaction acts on the delegator's account.

Say you run a shop. You keep the safe key at home. You give the cashier a key that opens only the till.

Permission delegation is the till key.

Your account is the delegator. Another account is the delegate. You tell the ledger: "This account may send these kinds of transactions for me, and nothing else."

After that, the delegate can send those transactions. Each one acts as if you sent it. But:

The delegate signs with its own keys. You never hand over yours.
The delegate pays the fee.
Anything outside the list is refused.

Why bother? Some jobs need a key on a server that is always online. A stablecoin issuer, for example, must approve each new holder's trust line. That means signing all day. Keeping the issuer's full key online for that is a big risk. With delegation, the online server holds a delegate's key that can approve trust lines and do nothing else. The issuer's own key stays offline.

If the delegate's key is stolen, the thief gets only those permissions. You remove the delegate with one transaction.

You can have several delegates, each with a different list. Each one locks a small reserve on your account, 0.2 XRP today.

Permission delegation went live on mainnet on 2026-10-08.

Granting. The delegator sends DelegateSet:

Field	Meaning
`Authorize`	The delegate's address
`Permissions`	Up to 10 `Permission` objects, each with a `PermissionValue`

The transaction creates a Delegate ledger entry, or updates it to match the new list exactly. Permissions left off the list are revoked. An empty list deletes the entry. It is valid only when an entry exists. Otherwise the result is tecNO_ENTRY.

Errors:

tecNO_TARGET: the Authorize account does not exist.
tecPSEUDO_ACCOUNT: the Authorize account is a pseudo-account, such as an AMM.
temARRAY_TOO_LARGE: more than 10 permissions.
temMALFORMED: Authorize is the sender, the list has duplicates, or a permission cannot be delegated.

Using. A delegated transaction sets two common fields:

Account: the delegator.
Delegate: the delegate.

It behaves as if the delegator sent it, with two exceptions. The signature must be valid for the delegate, and the Fee is paid by the delegate. The delegate may sign with its master key, a regular key or its own signer list. Multi-signatures are checked against the delegate's signer list, not the delegator's.

If the delegate lacks the permission, the result is terNO_DELEGATE_PERMISSION.

Reserve. One Delegate entry is one item toward the delegator's owner reserve, regardless of how many permissions it holds. The entry is not a deletion blocker. Deleting either account removes it.

Compared with multi-signing, from xrpl.org:

	Delegation	Multi-signing
Fee paid by	The delegate	The account that owns the list
Scope	Only the granted permissions	Almost any transaction
M-of-N	Not supported	Quorum and weights, up to 32 signers
Unfunded signers	Delegates need funded accounts	Signers may be bare key pairs

account_tx accepts a delegate filter to list transactions sent for an account, or by it for others.

TermsPermission delegation Delegate Master key Regular key Multi-signing Owner reserve Transaction cost

Check yourself3 questions

1. Who pays the transaction cost of a delegated transaction?

2. Which keys sign a delegated transaction?

3. What does each delegate cost the delegator?

Sources

Permission DelegationRead 2026-11-10
DelegateSetRead 2026-11-10
Transaction Common FieldsRead 2026-11-10
DelegateRead 2026-11-10
Known AmendmentsRead 2026-11-10

Next lessonWhat can be delegated4 min