XRP Ledger Permission Delegation: The Flaw, the Fix and Why Banks Care
A flaw in XRPL's permission delegation upgrade was caught before it went live. How the fix works, why institutions want the feature, and the October 5 vote.
Key takeaways
- The original permission delegation amendment had a flaw that could let an attacker drain another account's XRP through transaction fees. It never activated on mainnet.
- A community tester reported the flaw, validators were advised not to support the amendment, and developers rebuilt it as version 1.1.
- The fix rejects a transaction before any fee is charged when the required signature isn't valid.
- Permission delegation lets an account give narrow powers, such as making payments, to other accounts without handing over its master keys.
- Activation is conditional: version 1.1 needs at least 80% validator support for 14 straight days, or the countdown resets.
A flaw in a planned XRP Ledger upgrade could have let an attacker repeatedly drain XRP from someone else’s account without a valid signature. That sounds alarming, but the vulnerable version never activated on the live ledger. A community tester found the problem before activation, developers pulled the upgrade, and they rebuilt it.
The replacement, permission delegation version 1.1, has now crossed the validator threshold and is in its activation countdown. This article explains what went wrong, how it was fixed, and why banks, stablecoin issuers and custodians might want the feature.
Was anyone’s XRP at risk?
No. Your XRP was not exposed to this bug on mainnet. The vulnerable version never activated; it was found while the feature was still being tested outside the live network. This was not a case of hackers draining wallets. A potentially serious flaw was caught before deployment, the original amendment was rejected, and the feature was redesigned.
What is permission delegation?
It is a way for an account to hand out narrow powers without handing over the master keys.
Picture a financial institution whose main account controls a lot of money. It doesn’t want every employee, automated system or compliance app to have the keys to everything. Instead it wants rules like:
- this system can make payments, but cannot change the keys;
- that system can approve customers, but cannot move money;
- another account can do operational work, but cannot grant itself more permissions.
That mirrors how banks already work internally. The compliance team can’t wire the whole balance sheet, and the payments team doesn’t hold every security credential. CoinDesk notes that permission delegation version 1.1 could let stablecoin issuers, custodians and other businesses separate routine duties from the keys that control an XRPL account. According to CoinDesk, each delegate can receive up to 10 permissions, and the primary account can change or revoke them later.
What went wrong with the original version?
The original implementation checked whether an account had permission to perform a transaction before properly validating the signature. And some failed transactions still charged XRP fees.
Under specific circumstances, that meant an attacker could submit unauthorized transactions with deliberately high fees and repeatedly reduce another account’s XRP balance through those fees, without ever holding a valid signature.
The timeline, per the video:
- A community tester reported the flaw on September 15, 2025.
- Validators were advised not to support the amendment.
- It never activated.
- Developers rebuilt the feature as version 1.1.
How does version 1.1 fix it?
The revised version rejects the transaction before any fee can be charged when the required signature isn’t valid. It is a small technical change with a large effect: an unauthorized transaction can no longer cost the targeted account anything.
The video argues the catch itself is the important part. Every system has bugs, including Bitcoin, Ethereum, banks and large tech companies. The better question for anyone judging a blockchain for institutional use is whether the process catches critical problems before they reach production. In this case it did.
Why would banks and stablecoin issuers want this?
Because institutions care about separation of duties. The video gives two examples:
- A regulated stablecoin issuer may need an internet-connected compliance system to approve which customers can hold its token. With permission delegation, that system could get only the narrow permission it needs while the most powerful keys stay offline.
- A company operations account could make routine payments without the authority to change security settings.
The questions institutions ask go beyond speed: who can authorize transactions, who holds the keys, can authority be separated and revoked, and can a compliance system work without access to treasury funds? Those are dull questions for retail investors, the video says, but they are exactly the ones that matter when large amounts of money are involved.
When will permission delegation 1.1 activate?
Possibly on October 5, 2026, but it isn’t guaranteed. CoinDesk reported that the amendment entered its 14-day activation countdown on September 21, after 29 of 35 tracked validators supported it.
| Item | Detail |
|---|---|
| Countdown started | September 21, 2026 |
| Support at the time | 29 of 35 validators |
| Threshold | at least 80% (28 of 35) |
| Earliest activation | October 5, 2026, 11:18 UTC |
| If support drops | the 14-day countdown resets |
So the date depends on support holding continuously above 80%.
Does this make XRP worth more?
Not directly. A software feature activating does not automatically raise XRP’s price. What it may do is remove an operational obstacle that keeps institutions away from public blockchains.
The video also set the upgrade against the market at the time of recording. It said XRP had rallied above $1.60 earlier that week before falling back toward roughly $1.47 to $1.50, down about 7 to 8% in 24 hours. It cited FXStreet, using Santiment supply data, reporting that wallets holding 10 million to 100 million XRP, plus another large-holder group, accumulated roughly 350 million XRP since that Sunday, while wallets holding 1 million to 10 million sold around 50 million. It also noted some analysts pointing to a possible double-top pattern with $1.28 as a key level. The video framed that as the opposing case, not a prediction, and stressed that nobody knows what XRP does next.
Three things to watch
The video’s checklist once the countdown ends:
- Does it activate? Watch validator support through October 5. If it stays above the threshold, the feature goes live; if it falls, the countdown resets.
- Who uses it? A feature can be technically strong and unused. Watch for stablecoin issuers, custodians, payment firms, tokenization platforms or banks actually integrating permission delegation.
- Does it create value for XRP? Ask whether network activity and liquidity increase, whether XRP becomes more useful in these workflows, and whether the feature drives real commercial activity. XRPL adoption and XRP value capture are connected, but not identical.
To check the vote yourself, the video recommends verifying current network status through official XRPL sources, since amendment votes can change.
Frequently asked questions
Was XRP stolen because of the permission delegation bug?
No. According to the video, the vulnerable version never activated on the live XRP Ledger. It was found during testing, the original amendment was rejected and the feature was redesigned.
What is permission delegation on the XRP Ledger?
It lets an account owner grant specific permissions to other accounts, such as making payments, without giving them the master keys. CoinDesk reports each delegate can receive up to 10 permissions, and the main account can change or revoke them later.
When does permission delegation version 1.1 activate?
It entered a 14-day activation countdown on September 21, 2026, after 29 of 35 tracked validators supported it. If support stays at or above 80%, it could activate on October 5 at 11:18 UTC. If support drops below 80%, the countdown resets.
How did the original permission delegation flaw work?
The old version could check whether an account had permission before properly validating the signature, and some failed transactions still charged XRP fees. An attacker could submit unauthorized transactions with high fees to repeatedly reduce another account's XRP balance.
Education and commentary only, not financial advice. Crypto is volatile and you can lose money. Do your own research and speak to a qualified advisor before making investment decisions. Figures and quotes are as reported in the video on September 27, 2026 and may have changed since.
