The Ghost Account Problem: What XRPL's Withdrawn Delegation Amendment Reveals About Design-Level Security

The bug did not live in a line of code. It lived inside an assumption about identity. When an independent security researcher operating under the handle Shotes filed a report through the XRP Ledger's bug bounty program, the finding was not a buffer overflow, a reentrancy guard, or a mismatched signature check. It was quieter, and considerably more dangerous. A delegate — the account receiving narrow permission from a delegator — could delete itself, recreate itself, and inherit permissions the original delegator had already attempted to revoke. The account identifier survived the deletion. The revocation did not. That single sentence, delete and rebuild and keep the grant, is the reason XLS-75, the Account Permission Delegation amendment, never reached mainnet in its first form. The proposal was retracted before activation, rebuilt as V1.1, and now sits in testnet behind a freshly published QA report and an external audit. Most of the coverage I have read treats this as a tidy happy ending. The narrative isn't that clean. To understand why this matters, you have to understand what XRPL is actually trying to build — and why an unused account could bring the whole thing down. The XRP Ledger is not a smart contract platform in the Ethereum sense. There is no EVM, no general bytecode execution, no contract deployment model in the conventional meaning of the phrase. What XRPL has instead is a fixed set of transaction types baked into the protocol, extended slowly through a governance mechanism called an amendment. An amendment is a proposed change to the ledger's rules. It activates only after a supermajority of validators — the Unique Node List, or UNL — signals sustained approval across a defined window. There is no emergency patch, no proxy upgrade, no admin key. Once a flawed amendment activates, the flaw is live. That architecture explains why the withdrawal of XLS-75 was not a setback dressed up as caution. It was the mechanism working as designed. XRPL amendments cannot be edited in place. If a proposal is wrong, it must be abandoned and resubmitted under a new version number. V1.0 dies; V1.1 begins. The cost of that rigidity is time. The benefit is that nothing sloppy is quietly retrofitted after the fact. XLS-75 itself introduces Account Permission Delegation: the ability for one account to grant another account a narrow, specific set of permissions rather than surrendering full control. Think of the difference between giving someone a key to one door and handing them the deed to the house. For years, XRPL's only realistic option for shared control was multisignature, which is secure but blunt. Every signer must be present for every action. There is no middle ground between one key and all keys, all the time. Permission Delegation inserts that middle ground. And it is not peripheral. Vaults, Lending, Batch transactions, and Confidential Multi-Purpose Tokens all reference it as a dependency. It is the connective tissue XRPL's DeFi ambitions have been quietly waiting on. Which is precisely why the V1.0 flaw deserves more scrutiny than a victory lap. Let me go into the mechanism first, because the flaw only makes sense against the architecture. Under XLS-75, a delegator specifies which transaction types a delegate may submit on their behalf. The permission set is narrow by design. A delegate might be allowed to sign payment transactions up to a cap, or manage a specific vault, or submit batch operations — but not to withdraw the entire account balance or reassign ownership. The delegator retains the account root. The delegate receives a scoped capability. Conceptually, this is the same primitive Cosmos introduced years ago with its Authz module, and that Ethereum has been chasing through ERC-4337 account abstraction and session keys. XRPL is not inventing a paradigm. It is porting a validated one into its own account model. That porting job is harder than it looks, and the reason is XRPL's AccountRoot object. On XRPL, every account is a persistent ledger object with an identifier derived from the address. The account's existence, sequence number, reserve requirement, and permissions all hang off that object. When you bind a permission to a delegate, you are not binding it to a person or a key. You are binding it to an identifier. That distinction is the crack the V1.0 exploit crawled through. Here is the sequence Shotes reported. A delegator grants a narrow permission to a delegate. Later, the delegator decides the delegate is no longer trustworthy and revokes the grant. Under V1.0, if the delegate had deleted their account and recreated it, the revocation either failed to find its target, or the recreated account re-inherited the grant. The permission persisted, bound to an identifier that had technically been destroyed and reborn. The delegator's intent was unambiguous. The ledger's state did not honor it. I want to be precise about why this is a design-level defect and not a coding bug, because the distinction changes how you read the V1.1 fix. A coding bug is a mistake in the implementation of a correct design — a missing bounds check, an inverted comparison, an unhandled edge. A design-level defect is a mistake in the model itself. The V1.0 authors appear to have treated account identity as a stable anchor for permissions, when XRPL's own account lifecycle explicitly allows an account to be removed and recreated with the same identifier. They modeled the grant as a property of the account. They should have modeled it as a revocable object with its own lifecycle, independent of whichever account happens to hold it. The consequence had this shipped is not abstract. Consider a custody provider using delegation to let an operations team submit payment transactions on behalf of client accounts. The provider audits the arrangement, decides a specific operator should lose access, and revokes. If that operator had already deleted and recreated their signing account, the revocation quietly fails. The operator retains the ability to move client funds inside the delegated scope. That is not a theoretical exploit path. It is a custody failure with a clean, audit-looking trail that says the permission was revoked. Based on my audit experience with early token distribution contracts, I have seen this exact category of error — a lifecycle assumption baked into a permission check — sit unnoticed for weeks because it looked correct at every single glance. The breadth of the V1.1 fix list is the second signal that matters. A single patch would suggest a localized flaw. What RippleX actually shipped addresses delegate identity edge cases, blocks accidental delegation from the Vault and Lending modules, corrects reserve accounting, closes multisig bypass paths, and tightens the revocation behavior itself. That is not one bug fix. That is a re-examination of the entire feature surface. When a revision log reads like a checklist of independent corrections, the honest interpretation is that the original submission was systematically immature rather than unluckily flawed. The narrative isn't we found a bug. The narrative is that the first design did not hold together under stress. The multisig bypass closure deserves its own note, because it exposes an architectural seam. Multisignature is XRPL's incumbent shared-control primitive, hardened by years of production use. Delegation introduces a second, parallel path to move the same funds. If the two paths interact badly, a delegate could route around a multisig requirement that was supposed to gate an action. V1.1 closes those routes, which is reassuring — but it also tells you the two systems were not originally designed with each other in mind. In a protocol with no admin key, that is the kind of seam where the next surprise tends to hide. Reserve accounting is the quieter fix. Every XRPL account must hold a minimum reserve, and delegation can change what an account is required to lock. Miscount it and a delegate could drain an account below its own existence floor, leaving it unable to pay the reserve that keeps it alive on the ledger. Individually small. Cumulative, corrosive. Small errors compound faster in systems that cannot be patched. Then there is isDelegable, the field that determines whether a given transaction type can be delegated at all. Researchers flagged an integer overflow in its handling. Severity was rated medium, and the accompanying note argued there was no meaningful impact absent malicious behavior from the delegator. I want to push back gently on how comforting that framing sounds. Integer overflow on an unsigned value is a canonical bug class, and its presence tells you something about the type-checking and serialization discipline underneath. It does not mean the feature is unsafe. It means code quality is uneven in exactly the places where XRPL's account model is most rigid. When a protocol has no emergency patch, uneven type handling is not a small thing. It is the raw material of the next surprise. The testing distribution deserves the same scrutiny. The QA summary reports more than five thousand individual tests. That number is impressive until you break it down. Functional tests dominate — over one hundred. Cross-functional tests, the ones that exercise how delegation behaves when it touches Vault, Lending, Batch, and other modules at once, number fewer than twenty. The feature's entire reason for existing is that it threads through multiple subsystems. A test ratio weighted almost entirely toward isolated behavior, with a thin band of integration coverage, is a profile that would make me uncomfortable if I were signing the release. The hardest bugs in modular systems are never inside modules. They live in the seams. Now the counterweight, because a fair analysis holds both sides. Three independent oversight layers sit around this amendment, and that combination is genuinely rare. Cantina, a recognized audit firm, reviewed the code. The bounty program did its job — it caught a design-level flaw internal review missed, which is exactly what a bounty is for. And, most interesting to me, an independent developer named Denis Angell built a public dashboard tracking how thoroughly each XRPL amendment has been tested on devnet. That dashboard is a community-built answer to a real historical complaint: amendment testing progress on XRPL has often been opaque. One developer deciding to make protocol readiness legible to everyone is a small act of governance maturity, and it is the kind of signal I weight heavily when I ask whether an ecosystem can be trusted with institutional capital. The governance process earned credit too. RippleX engineer J. Ayo Akinyele put his name on the response. Researcher Shotes was credited by handle rather than buried. The QA report was published rather than summarized. None of that is required. All of it is a tell. On market impact, I will be brief, because the honest answer is almost none. This is a process event, not a catalyst. XRP does not reprice on testnet QA reports. The real volatility trigger, if any, is the validator vote that activates the amendment on mainnet, and even that tends to be low-amplitude unless the surrounding market is already in motion. In a bear market, where capital is defensive and attention is scarce, a we fixed a serious flaw headline competes poorly with liquidation cascades and exchange drama. The value wasn't in the price. It was in the plumbing. And the plumbing here is regulatory. Permission Delegation is the closest thing XRPL has to a native implementation of least privilege. That phrase is not marketing. It is a documented expectation in financial custody: accounts should hold only the access they need, and that access should be separable and revocable. Delegation, done correctly, lets a custody provider grant operational roles without handing over ownership. For an ecosystem that spent years fighting the SEC and now leans hard into institutional and tokenized-asset narratives, a feature that makes compliant account management easier is strategically load-bearing. Had the revocation flaw reached mainnet, the failure story would not have been a bug report. It would have been a custody incident, and custody incidents draw regulators the way blood draws sharks. One anomaly I have to flag: the parsed source material places the amendment's introduction in 2025 and a re-support event in June 2026 — a sequence that is internally contradictory and almost certainly a transcription error. I am noting it rather than repeating it as fact. Treat those dates as unverified and check the official governance record. This matters, because if the real timeline is longer than the source implies, then the retract-and-rebuild cycle consumed more ecosystem momentum than anyone wants to admit out loud. The consensus read on this story is that XRPL's governance worked: a bounty caught a serious flaw, the team withdrew the amendment, rebuilt it, audited it, and is now preparing a safer launch. That is a comforting narrative, and it is mostly true. Here is the less comfortable part. The bounty caught a design-level flaw that structured design review should have caught first. Bug bounties are good at finding implementation errors — the off-by-one, the reentrancy, the missing check. They are poor substitutes for adversarial design review, because bounty hunters test the code that exists, not the assumptions the code was built on. That a delegate's account lifecycle could silently defeat a revocation is a modeling error. Modeling errors are supposed to die in the whiteboard phase, not in the bug tracker. So the correct lesson is not that XRPL's bounty program is excellent. It is that XRPL caught its assumption flaw through the most expensive possible channel, and only because a researcher happened to look. The next amendment may not be so lucky. Watch the validator vote, not the changelog. If XLS-75 V1.1 activates cleanly, the interesting question is not whether delegation works, but whether revoked permissions stay revoked under adversarial account behavior on a live ledger. The seam between account identity and permission lifecycle is where I will be looking. In a market this defensive, the honest posture is simple: a protocol that finds its own flaws before activation is worth more than one that finds them after. But only if it keeps finding them early.