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 calle
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.
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.
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.
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.
29 of the 35 trusted validators carry the amendment, six do not.
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.
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.
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.
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.
Permission delegation means passing on individual rights and keeping the master key.
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.
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.
Amendment Specification Validators Majority since Earliest active PermissionDelegationV1_1 XLS-75 29 of 35 Sept 24, 21:25 UTC Oct 8, 21:25 UTC BatchV1_1 XLS-56 30 of 35 Sept 25, 14:46 UTC Oct 9, 14:46 UTC fixBatchV1_2 bug fix 34 of 35 Sept 25, 14:12 UTC Oct 9, 14:12 UTC LendingProtocolV1_1 XLS-66 5 of 35 no majority openBatchV1_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.
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.
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.
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.
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.)
