XRP Ledger: permission delegation cannot go live before October 8

A protocol extension is close to activation on the XRP Ledger that will let accounts hand individual rights to other accounts without surrendering their own master key. The amendment is called PermissionDelegationV1_1 and carries the specification number XLS-75. Numerous trade outlets have named October 5, 2026 as the date in recent days, some of them to the minute at 11:18 UTC.

The ledger itself says something different. The majority on which the two-week period rests has only been recorded there since September 24, 2026 at 21:25 UTC. The amendment can therefore take effect no earlier than October 8, 2026 at around 21:25 UTC, a good three days later than announced. Cryptoticker.io compiled this analysis itself on October 1, 2026. It rests on the XRP Ledger's amendment data, verified at two mutually independent sources. All 113 amendments the network currently carries were checked, four of them with an ongoing or still open vote.

For you as a holder of XRP this is more than a calendar question. Around protocol updates, trading venues and custodians regularly suspend deposits and withdrawals for a short period, and anyone with the wrong day in mind will schedule a transfer into the very window in which it stalls. XRP is trading at $1.48, or 1.32 euros, down almost 2 percent within a day, at a market capitalisation of some $93.5 billion.

PermissionDelegationV1_1: the amendment stands at 29 of 35 validators

Changes to the XRP Ledger are voted on by the network's validators; no company switches them on. An amendment is a protocol change that these validators vote on and that only takes effect once it has held a qualified majority behind it for long enough.

PermissionDelegationV1_1 currently reaches 29 of the 35 trusted validators, which is 82.9 percent. The threshold the network itself applies to this amendment stands at 28 votes. The margin to the threshold is therefore a single vote: if one validator drops out or changes its position, the extension is on the edge.

The extension was introduced with version 3.3.0 of the reference server software; in the network the leading nodes are meanwhile running 3.4.1. The predecessor is notable: an older amendment of the same name and with the same specification number XLS-75 is still in the register, but reaches a single vote and is marked as superseded. The first attempt at this function therefore failed, and what now stands before activation is the revised second version.

Why one vote makes the difference

The threshold of a good 80 percent is deliberately set high and is meant to prevent a narrow majority from changing the rulebook of a chain on which payments are settled. The side effect: an amendment can lose its majority again shortly before the finish line, and that is evidently what happened here.

Two dates in circulation: October 8 stands in the ledger, October 5 in the reports

The timeline named in many reports begins on September 21, when the amendment reached the two-week phase. Fourteen days later that yields October 5. The entry in the ledger, however, carries September 24 at 21:25 UTC, and that is the point from which the period is actually counted.

The network's own rule explains how both dates can arise. If an amendment loses the necessary support during the waiting period, it is provisionally rejected and the two-week period starts again. Several trade services had reported in the same week that the attempt had been restarted; the date given was in many cases not carried along. Anyone relying on October 5 is going by a clock that was put back in the meantime.

The counter-check belongs to the picture: October 8 is the earliest possible date, not a commitment. If support stays above the threshold until then, the network switches the extension on. If it falls before that, the period begins again, and the date moves out by another two weeks.

Flag ledgers and the two-week period: an amendment's path to activation

The XRP Ledger counts the votes at fixed intervals. Every 256th block is a flag ledger, a block at which the network tallies the amendment votes. This happens every few minutes, and the process spreads across four consecutive blocks: in the block before, the validators cast their votes; in the flag ledger they are counted; in the next block the enablement is recorded; and in the block after that the change takes hold.

In practice that means the following for October 8: the extension takes effect at the first flag ledger tallied after 21:25 UTC, so possibly a few minutes later. For planning purposes, the evening of October 8 is precise enough, which in central European time means the late evening of the same day.

The official description of this procedure is in the XRP Ledger documentation on amendments. It also sets out the rule that the period restarts if support falls back below the threshold.

DelegateSet: ten rights per delegate, the master key stays with the account

Technically the change works through a transaction type of its own called DelegateSet. With it, one account grants individual powers to another account, alters them later or withdraws them. Permission delegation denotes precisely this principle: one account allows another to submit certain transactions on its behalf without passing on its own signing key.

The ceiling is ten powers per delegation entry. Anyone needing more is referred in the documentation to the multi-signing that already exists. That sounds like a footnote but is the actual use case: a company can allow its payments department to initiate transfers and its compliance department to approve them, without either one getting hold of the key to the overall account.

The key itself stays with the delegating account. That is exactly why the function is of interest to custodians, payment service providers and trading venues, which today work either with omnibus accounts or with laborious multi-signature arrangements. How you keep your own keys is untouched by this; anyone wanting to compare the devices will find the overview in the hardware wallet comparison.

What changes for a private account

For an ordinary XRP account, nothing changes at first. As long as you set up no delegation yourself, your account remains as usable as before. The extension creates an option, not an obligation. It becomes relevant to you in two places: in the software you use to access the account, and at the service that holds your XRP in custody.

Non-delegable rights: key rotation and granting rights stay barred

The specification draws a line that is decisive for the security assessment. Certain powers expressly cannot be handed over, among them those with which a delegate could swap out the account's keys or grant itself further rights. If a transaction attempts it anyway, the network rejects it with a malformed-transaction error.

This line prevents the obvious attack. Without it, a partial right once granted could be built up into the complete takeover of an account, because the delegate would make itself the key holder. With it, a delegation remains revocable, and solely by the account that granted it.

The full list of excluded powers is set out in the specification XLS-75 on permission delegation. Anyone operating wallet software or planning an integration cannot get around this document.

PaymentBurn: the caveat in the XRPL documentation on newly minted tokens

The technical description of the DelegateSet transaction contains a note that is easily missed on a skim read. As long as one further amendment is not switched on, a delegate holding the narrowly drawn PaymentBurn power may under certain circumstances also create new tradable tokens. The documentation lists this as a caveat, not as a bug.

The point has practical significance for issuers of their own tokens on the XRP Ledger, not for you as a holder of XRP itself. Anyone holding tokens of an issuer that works with delegations from the activation day onwards does, however, have a question for that issuer: which powers are granted, to whom, and how are they revoked.

The caveat also shows why such extensions arrive in stages. A single protocol change intervenes in a rulebook made up of dozens of earlier changes, and the interactions are not always clear from the outset.

BatchV1_1 and LendingProtocolV1_1: the other amendments in the window

Permission delegation is not the only change in the queue. Three periods run alongside each other in October, and a fourth vote is still at the beginning. The overview reflects the position as of October 1, 2026.

BatchV1_1 bundles several transactions into one package that is processed together, and reaches 30 votes. The accompanying bug fix carries the broadest support of all four at 34 of 35 votes. Both would take hold one day after permission delegation, on October 9.

The case of the lending protocol LendingProtocolV1_1, about which much has been written lately, is markedly different: it stands at 5 of 35 votes and has not reached a majority. There is no sign of an activation there in the coming weeks, and no date for one. Anyone reading reports of imminent lending on the XRP Ledger can hold this figure up against them.

Custody and exchange account: the activation day for holders in Germany

The day itself passes unspectacularly for most holders, with one exception: trading venues and custodians occasionally suspend XRP deposits and withdrawals for a few hours around protocol updates, in order to wait out the transition. That is routine and not an incident, but it affects everyone who has planned a transfer for that evening.

Anyone holding XRP with a provider will usually see an announcement in the status area or by notification, mostly one to three days beforehand. Anyone self-custodying needs wallet software that can handle the new transaction type; older versions may not display an unknown transaction type at all, or display it incorrectly. Which providers in Germany are authorised under the European regulation on markets in crypto-assets, and how they differ on fees and custody, is shown in the crypto exchange comparison.

A protocol update changes nothing for tax

An amendment activation is not an inflow, not a disposal and not a new token. Your holding period runs on unchanged, and no taxable event arises. It would be different only if a chain were to split; there is no indication of that here, because the extension is running with a broad majority and without a competing proposal.

Phishing with delegation rights: a new pattern for forged approvals

Every new permission function in a chain brings a new fraud pattern with it. On Ethereum the same pattern ran after delegated accounts were introduced: a purported approval page asks for a signature, and the signature grants not a payment but lasting rights over an account.

For the XRP Ledger that means, from the activation day onwards: a request to sign a DelegateSet transaction belongs among the operations where it pays to look twice. An account to which you grant rights can act within those rights until you revoke them. Because key rotation remains excluded from delegation, the damage is limited; that does not make it pleasant.

Such a request never reaches you from a network itself. Neither the XRP Ledger nor a wallet sends you a message saying you have to confirm rights for a protocol change to take effect. That notification is a forgery, without exception.

Permission delegation: your next three steps

1. Update your wallet software before October 8 arrives. A version that knows DelegateSet shows you a delegation transaction as such instead of listing it as an unknown type. Which programmes are maintained and which have stood still for months is set out in the software wallet comparison.
2. Check the window with your custodian. If you have planned an XRP deposit or withdrawal for October 8 or 9, move it to another day, or fetch your provider's status notice beforehand. Anyone thinking about switching anyway will find the authorised providers in the exchange comparison.
3. Keep larger holdings out of reach of the approval function. An account that never delegates cannot be attacked by this route either. For amounts you do not move, custody on a device of your own remains the calmer solution; the devices and their differences are set out in the hardware wallet comparison.

The date stays movable to the last. As long as support lies above the threshold of 28 votes, the evening of October 8 applies; if it falls below, the two-week period begins again. This can be followed through the validators' vote count, which changes continuously in the network.

(As of October 1, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)