XRP Ledger switches on delegated account controls for banks, stablecoin issuers and tokenized funds

What happened

The XRP Ledger activated a feature called PermissionDelegationV1_1 late on Thursday, October 8, according to CoinDesk reporting published on October 9 that cited the XRPL Dashboard monitoring site. The feature lets an account owner give another account permission to perform specific jobs without handing over the keys that control the main account. The helper account signs with its own keys, can perform only the actions it has been granted, and the owner can change or withdraw those permissions.

Protocol upgrades on this network require more than 80 percent support from trusted validators sustained for two straight weeks. With the current validator list of 35, that means at least 29 supporters. The delegation countdown reset in September after support slipped below that level, and the successful activation on October 8 followed a renewed two week period above the threshold. Each helper account can receive up to 10 permissions. The permissions restrict the kinds of actions a helper can perform. They do not automatically impose a spending cap, a distinction the reporting emphasized.

The stated use case is operational separation. A business that makes routine crypto transactions needs signing capability available through the working day, but keeping keys with broad powers on an internet connected system increases the damage if that system is compromised. Under delegation, a stablecoin issuer can let a compliance account approve new customers while its main keys stay offline. A separate operations account can receive permission to make payments without gaining the power to change keys or grant authority to anyone else. Banks already divide payment and compliance duties among staff and systems. The upgrade makes that division enforceable in the ledger's own rules rather than only in internal policy.

The activation arrived with one explicit warning. Official guidance tells users not to delegate the PaymentBurn permission, which is intended to let a helper destroy issued tokens, until a separate fix activates. Under certain conditions, that permission can also allow a helper to create issued tokens. The warning concerns tokens issued on the ledger, not newly created XRP, and other granular permissions are unaffected. The fix for that issue had 27 of 35 validator votes on Friday and needs 29 to begin the two week countdown that would lift the warning. Developers are also reviewing a separate reporting issue in which some servers can drop a validator from their vote count after a routine security key change, which can distort how close a proposal appears to passing on an affected server.

CoinDesk placed the feature against the network's current institutional footprint. The ledger held an average of 3.72 billion dollars in tokenized assets and 539 million dollars in the RLUSD stablecoin during the second quarter, a combined total of about 4.26 billion dollars, according to a report shared with CoinDesk by an XRP treasury company. Those figures describe the scale of holdings the new controls are built to serve. They are background measures of network use, not a result of the upgrade itself.

Why it matters

Key management is the operational problem that keeps regulated firms cautious about holding assets on public ledgers. A single key that can move funds, change account settings, and grant new permissions is efficient for an individual and unacceptable for an institution with separation of duties obligations. Auditors, insurers, and compliance teams all ask the same question: which system can do what, and what happens if that system is breached. Delegation gives a ledger native answer. A compromised compliance account can approve customers it should not approve, which is a real problem, but it cannot empty the issuer's account or rewrite the account's keys.

The absence of an automatic spending cap is equally important to understand. Permissions divide authority by action type, not by amount. A helper granted payment permission can make payments within whatever limits the owner's own systems impose off ledger, but the ledger rule itself restricts the category of action rather than the size. Institutions evaluating the feature will need their own amount controls, monitoring, and revocation procedures around it. The upgrade supplies the separation. It does not supply the whole control framework.

The PaymentBurn warning shows the other side of shipping account level features. A permission designed to destroy tokens carrying a condition under which it can create them is exactly the kind of flaw that granular control systems must catch before delegation spreads. Publishing the warning at activation, scoping it to one permission, and reporting the fix's vote count at 27 of the 29 needed gives users a concrete basis for deciding what to delegate now and what to wait on. Institutions that need token destruction workflows have a clear instruction: wait for the fix and its two week countdown to complete.

The validator counting report matters beyond this one upgrade. Amendments live or die by sustained supermajority support measured across servers. If some servers undercount validators after routine key rotations, different parts of the network can disagree about whether a threshold has been met. The proposed remedy, identifying validators by a permanent identifier, is still under review. Until it ships, activation timelines for future amendments carry a small measurement caveat that did not exist in the headline result.

What to watch

Watch actual delegation use rather than announcements. The feature's value will show up in DelegateSet activity, in stablecoin issuers and custodians moving routine approvals to helper accounts, and in security documentation describing how permissions are granted, monitored, and revoked. Activation proves the network can switch the feature on. Adoption proves that institutions trust it with live operations.

Watch the PaymentBurn fix. It needs 29 of 35 validator votes to start a two week countdown. Reaching that threshold, holding it for two weeks, and lifting the warning without incident would close the one documented gap in the launch. A stalled vote would leave token destruction workflows on manual processes and would say something about validator engagement with unglamorous fixes.

Watch whether issuers publish their permission structures. A stablecoin issuer that discloses which accounts hold which permissions, and how quickly those permissions can be revoked, gives customers and auditors something to verify. Silence on that point would not make the feature unsafe, but disclosure is how a protocol capability becomes institutional confidence.

Finally, watch the follow on amendment pipeline. Delegated permissions address who can act. They do not address batching, lending, or privacy features that the ecosystem has discussed separately. The next proposals and their validator support levels will show whether the network can sustain the two week supermajorities that this activation required after one reset, and whether the counting question is resolved before a closer vote makes it matter.