XRP Ledger Activates Delegation, Keeps Token-Burn Warning

XRP Ledger delegation moves from vote to activation

Daily Crypto Briefs checked the validated ledger directly. PermissionDelegationV1_1 was absent from the enabled list in ledger 107,524,864 and present in ledger 107,524,865, which closed October 8 at 21:29:50 UTC.

The latter ledger contained the enabling transaction for the amendment. This verifies a completed protocol event, rather than another projected launch date. CoinDesk’s October 9 report also reported the activation after September’s validator-support interruption.

XRPL’s amendment rules require more than 80% support from trusted validators for two consecutive weeks. An interrupted qualifying majority restarts the waiting period, explaining why earlier estimated dates could move before the actual enabling transaction appeared.

The activated version replaces an earlier implementation. The September 2025 disclosure said a community tester found a fee-charging flaw in a non-production environment, before that original amendment reached mainnet. Validators were advised to reject it, and a revised version was prepared.

That history is separate from the September 25 Batch emergency release. Batch and delegation address different functions and have separate amendment records; Thursday’s activation does not establish that every pending XRPL feature has gone live.

The immediate change is an additional account-management capability. Issuers still need to configure delegates, decide which duties to grant and integrate the feature into their systems. Activation alone does not show how many organizations have adopted it.

XRPL permissions limit duties, not spending amounts

The owner grants authority through DelegateSet. A later transaction replaces the permission list exactly: omitted permissions are removed, while an empty list deletes an existing delegation relationship.

The maximum is 10 permissions per delegate, not 10 delegates per owner. Invalid configurations, including duplicate permissions or an attempt to authorize the owner’s own account as its delegate, are rejected under the transaction reference.

An update needs to include the full set of permissions the owner wants to retain. Treating it as an addition to the previous list could remove authority unexpectedly, because the ledger stores the replacement set rather than merging the two lists.

The permission-values reference distinguishes broad transaction permissions from narrower functions. TrustlineAuthorize, for example, permits approving a trust line without also granting authority to change its limit or freeze status.

A trust line records an account’s relationship with an issued token. XRPL’s authorized-trust-line guide describes how issuers can require approval before users hold their tokens. Delegating that approval can separate customer onboarding from token issuance or treasury operations.

The distinction is consequential for access design. Granting a payment function does not automatically create a daily withdrawal ceiling. Granular permissions are predefined, and the official guide says they cannot be customized to permit only selected currencies.

Costs also follow separate rules. The XLS-75 specification assigns transaction fees to the delegate, while each delegation relationship adds one object reserve to the owner’s requirements. XRPL’s reserve page lists the current mainnet owner reserve at 0.2 XRP per item.

That reserve is XRP set aside to support ledger objects, rather than a recurring subscription charge. It constrains how much of an account’s balance remains available to spend and makes large numbers of relationships a funding consideration.

Delegation also differs from multi-signing, which requires signatures meeting a configured quorum. A delegate can use its own multi-signing arrangement, but authorizing a delegate does not itself impose a multiple-person approval requirement.

The final specification prevents delegation of functions that could let a helper rewrite account control, including setting regular keys, changing signer lists and granting further delegations. That restriction blocks a delegate from using those transaction types to expand its own authority.

For a permitted payment, the owner remains the account on whose behalf the payment executes, while the helper supplies its own signature and pays the transaction fee. Separating the fee payer from the asset owner does not prevent the helper from moving assets when its granted permission allows that action.

These controls sit beneath application features such as XRPL’s AI payment tooling. Automating a payment workflow and deciding how much authority its operational account receives remain separate implementation choices.

PaymentBurn warning remains as cleanup wait begins

PaymentBurn is intended to permit destruction of issued fungible tokens. Official guidance says that, before fixCleanup3_4_0 activates, it can also permit creating trust-line tokens or Multi-Purpose Tokens in certain circumstances. The warning concerns issued assets, rather than newly minted XRP; other granular permissions are unaffected.

At approximately 10:07 UTC Friday, a direct read of validated ledger 107,536,642 showed delegation enabled and the cleanup fix still inactive. The amendment-state documentation explains how its separate majority record carries the waiting-period timestamp.

That record showed the cleanup majority beginning October 9 at 09:34:30 UTC. Applying the documented two-week rule points to an earliest boundary around October 23 if qualifying support continues. It is a conditional calculation from ledger data, not a guaranteed activation appointment or permission to disregard the warning.

As of October 9 at 10:07 UTC, Daily Crypto Briefs’ dedicated loss-impact check identified no verified loss total, connected victim transactions, affected-wallet count or attack wave tied to PaymentBurn. The official warning establishes a possible unintended action; it does not publish an exploitation assessment. Missing confirmed losses cannot be treated as proven zero losses.

The Bitcoin-focused Fear & Greed Index read 59, down from 64 the previous day. It provides broader sentiment context rather than a measure of XRPL’s operational readiness.

The next checks are actual delegation use, uninterrupted support for the cleanup fix and its eventual enabling transaction. Adoption totals, incident losses and a firm fix date were not established by the evidence reviewed.