XRP Ledger activates permission delegation for banks and stablecoin issuers

The XRP Ledger activated a feature on Oct. 8 that lets an account owner give another account permission to perform specific jobs without handing over the keys that control the account. CoinDesk reported the activation, citing the monitoring site XRPL Dashboard.

The feature, called PermissionDelegationV1_1, required more than 80% support from trusted validators — the operators who confirm transactions — for two straight weeks. Against the current list of 35 validators, that means at least 29 supporters. Support slipped below that level in September and reset the countdown, CoinDesk reported. Earlier, the atomic-settlement upgrade's ten-day slip to Oct. 9 was a reset of the same kind.

Delegation splits signing authority by job. A stablecoin issuer can let a compliance account approve new customers while keeping its main keys offline. The helper signs with its own keys and can perform only the actions it has been granted; the owner can change or withdraw those permissions. Each helper can hold up to 10 permissions. These restrict the kinds of actions it may perform rather than automatically imposing a spending cap.

The upgrade gives businesses a way to enforce payment and compliance duties on the ledger itself. Firms that make routine transactions need signing keys available throughout the day, and holding broad powers on an internet-connected computer increases the damage a compromise can cause. A scoped helper key narrows what any single credential can do.

Official guidance tells users not to delegate PaymentBurn, a permission intended to let a helper destroy tokens, until a separate fix activates. Under certain conditions, that permission also allows the helper to create new tokens. The warning concerns tokens issued on the ledger, not newly minted XRP. The other granular permissions are unaffected.

Governance machinery has its own open item. A report filed Oct. 8 found that some XRP Ledger servers can drop a validator from their vote count after it changes a routine security key, even though the validator is still online and voting. A server that loses track of two validators would measure support against 33 instead of 35, making a proposal look closer to passing on that server's count than it is. A proposed patch would have servers identify validators by a permanent ID instead; it is still under review.