The Two Missing Votes: XRP Ledger's Permission Delegation Window

On October 8, the XRP Ledger activated PermissionDelegationV1_1. The validator tally read 27 of 35 in favor. Activation required 29. In the space between those two numbers — two votes short — sits the entire technical story of this upgrade: a feature went live while its own security patch waited in line behind it. The feature itself is unremarkable for 2024. Fine-grained account permission delegation is XRP Ledger's late answer to account abstraction, a capability EVM chains standardized years ago. What is remarkable is the ordering. One of the permissions the feature introduces, PaymentBurn, was designed to let a delegatee destroy tokens. Before a separate amendment called fixCleanup3_4_0 activates, that same permission can also create them. The patch that closes the gap exists, has been reviewed, and is stuck — short of threshold, inside a governance system whose counting software, as of rippled 3.4.1, has a defect of its own. I have spent enough years inside liquidation engines and constant-product curves to recognize this shape. It is not a dramatic exploit. It is a window — narrow, quiet, and open. To see why a two-vote gap matters, you need the mechanics of how XRP Ledger changes at all. XRPL does not upgrade through hard forks in the Bitcoin sense, and it is not an EVM chain. It runs federated consensus: a set of validators, curated by node operators into a Unique Node List, agree on ledger state, and protocol changes arrive as amendments. Each amendment is a discrete code change that activates only when a supermajority of trusted validators signals support across a sustained window. The ledger currently carries 95 activated amendments. This is a network that iterates constantly, and most of that iteration happens out of sight. PermissionDelegationV1_1 is one such iteration, and it is worth being precise about what it does. It lets an account grant another account the right to send specific transactions on its behalf without surrendering the master key. The mental model is proxy signing with a scope list: a delegatee receives authorization for a defined set of actions and nothing more, while the delegator keeps ultimate control. The design caps permissions per delegatee at ten. That ceiling is not arbitrary. It is the kind of deliberate trade-off a team makes when it would rather constrain flexibility than widen the attack surface — the same instinct I applied when I spent three months comparing ERC-721 and ERC-1155 metadata costs, choosing to optimize for the ordinary user's gas bill rather than the headline feature. Seen against the broader market, permission delegation is a catch-up move, not a lead. EVM chains standardized account abstraction through ERC-4337, and newer L1s like Aptos and Sui built native account abstraction into their execution models from the start. XRPL is adding the capability years later, through its own non-EVM path. That does not make it worthless — a settlement network with programmable permissions is more useful than one without — but it does mean the feature arrives as parity, not advantage. Networks that catch up rarely earn a premium for the catch-up itself. The detail that matters most is that V1_1 is not the first version. An earlier PermissionDelegation amendment was withdrawn after a serious flaw surfaced. What shipped on October 8 was the second attempt. And as of this writing, it still carries a vulnerability that the first version's withdrawal should have taught the team to prevent. For a network positioning itself around payment settlement and institutional adoption, that history is not a footnote. It is the context in which everything that follows should be read. The vulnerability is specific, so let me state it plainly before unpacking it. PaymentBurn is a permission meant to let a delegatee burn tokens — to destroy trust line tokens or multi-purpose tokens held by the delegator. Burning is deflationary. It removes supply. On its face, it is the safer half of any token operation, because destruction cannot enrich anyone. Before fixCleanup3_4_0 activates, however, PaymentBurn does not only burn. In the current mainnet state, a delegatee holding this permission can also create new trust line tokens or MPTs. This is not a rounding error or a semantic quibble. It is a minting path. A permission whose sole purpose is to subtract has, in its present form, the ability to add — and addition is how you dilute every other holder of the same asset. This is a textbook breach of least privilege, and it is a shape I have seen before in different clothing. When I audited the MakerDAO contracts through 2018, working remotely and unpaid, the three race conditions I traced in the liquidation engine were not backdoors. They were logic that granted a little more authority than the surrounding code assumed. The exploit surface was never the intended function; it was the gap between what a function was named and what it could do. PaymentBurn is that gap, exposed on a live network, months before the fix arrives. The severity depends on who is exposed. Any project that has issued a trust line token or an MPT on XRP Ledger faces a theoretical inflation risk if it has delegated PaymentBurn to a party that misuses it. That population is not trivial. Stablecoin issuers, tokenized asset platforms, and any application using XRPL's semi-fungible token standard all live in the blast radius. The official guidance is blunt: do not delegate PaymentBurn. That guidance is also the problem. It places the entire mitigation burden on user discipline, across a window that stays open until fixCleanup3_4_0 clears its vote — and it does nothing for a project that already granted the permission before the warning was issued. From a cost perspective, the asymmetry is what unsettles me. The cost of the fix is a code change the team has already written. The cost of the gap, if exploited, is the dilution of token holders who did nothing wrong and may not even know they are exposed. Tracing the hidden vulnerabilities in the code is routine work; anticipating who pays for them is the part that should shape priorities. One economic point is worth drawing out, because it is easy to misread. This event does not touch XRP's supply model. XRP is not being minted, and the amendment does not alter issuance. The indirect effect on XRP itself is, if anything, faintly positive: permission delegation lowers the account-management barrier, which could raise transaction activity on the network, and every XRPL transaction burns a minuscule amount of XRP as a fee. But the magnitude is negligible and should not be sold as a catalyst. The real economic exposure sits one layer down, in trust line tokens and MPTs, where the minting gap is a live inflation surface for anyone who has granted the wrong permission. Now to the second flaw, which is the more interesting one. rippled 3.4.1, the client software that runs the network, has a defect in how it counts amendment votes. When a validator rotates its signing key, the client stops counting that validator's votes and removes it from the threshold calculation. A validator that changes its key — a normal and recommended security practice — quietly drops out of governance until the software is patched. The reporter who filed this described the effect precisely: votes vanish, and the denominator shrinks with them. Sit with that. XRP Ledger's amendment mechanism is its constitution. It is how the network decides, collectively, what the protocol may become. The tool that tabulates those decisions carries a counting error that can silently exclude legitimate participants. The reporter noted that no amendment outcome has yet been flipped by the bug. That is reassuring, and also beside the point. A governance mechanism that miscounts produces provisional outputs. Whether the error has changed a result yet is a question about luck, not about soundness. Here is where the two flaws entangle, and I want to separate what is documented from what I am inferring. fixCleanup3_4_0 — the patch that closes the PaymentBurn minting gap — is itself an amendment. It activates through the same vote-counting process that rippled 3.4.1 renders unreliable. The current tally, per the dashboard, is 27 of 35, with 29 required. Note the threshold discrepancy: GitHub discussion describes a threshold of 28 for a 35-validator set, while the dashboard lists 29 for this specific amendment. That one-vote difference could be an artifact of the counting bug, or it could reflect a genuine difference in how the threshold is computed for this proposal. I cannot resolve it from the public data, and I will not pretend to. What I can say is this: the patch that fixes the minting vulnerability needs votes, and the software counting those votes has a bug that can drop them. The threshold discrepancy and the missing two votes may be unrelated. They may not be. That uncertainty is the reason I would not file this under routine governance. There is a further wrinkle worth flagging for anyone operating infrastructure. The counting bug does not just threaten the fix; it can produce divergent views of the same vote across nodes. If a validator has rotated keys, some nodes may report a tally that includes it and others may not, depending on their rippled version. Exchanges, custodians, and RPC providers watching governance may find themselves looking at inconsistent numbers — 33 of 26 on one node, 35 of 28 on another — and drawing different conclusions about whether a threshold has been met. In a federated system, divergent observations of the same governance event are not a cosmetic problem. They are how coordination failures begin. What makes the PaymentBurn case instructive is that the fix, when it lands, is elegant. The proposed patch tracks validators by permanent node ID rather than by rotating signing key, which is the correct abstraction: identity should be stable even when credentials change. The bug existed precisely because those two concepts were not properly separated. That same confusion — conflating a rotating credential with a durable identity — is one of the oldest failure modes in account and key management, and it is why I have argued for years that ownership and authorization need to be modeled as distinct primitives. Redefining what ownership means in the digital age is not a marketing slogan; it is a concrete design requirement, and here is a case where getting it wrong quietly corrupted a governance process. Step back, and the design choices here tell a story about XRP Ledger's priorities. The ten-permission cap is the signature of a team thinking about attack surface. The decision to ship delegation before the cleanup amendment is the signature of a team thinking about roadmap. Both can be true at once, and the tension between them is where the window opened. A more conservative sequence — activate fixCleanup3_4_0 first, then delegation — would have eliminated the gap entirely. That sequence was available. It was not chosen. I want to be fair to the team here. The response to the vulnerability report was prompt: filed October 8, a patch proposed within the review cycle, an official warning issued to the community. In my experience auditing under time pressure, promptness is not nothing. Most protocols that ship a gap like this spend weeks in denial before acknowledging it. The problem is not the reaction. The problem is that the reaction was needed at all, for the second time, on the same feature. For institutional adopters, the implication is uncomfortable. The pitch for XRPL in settlement and tokenized assets rests on predictability: institutions tolerate slow, not surprising. A feature that ships ahead of its own safety patch, on a network courting regulated counterparties, is exactly the kind of surprise that slows institutional adoption. The gap will close. The impression it leaves — that functionality can outrun safety on a network positioning itself as enterprise-grade — is harder to patch. For developers building on XRPL, the practical guidance is narrow and clear. Do not delegate PaymentBurn. If you have already delegated it, revoke it. If you issue trust line tokens or MPTs, audit every permission grant you have made and treat the window as live until fixCleanup3_4_0 activates. For wallets and node operators, the work is operational: surface warnings at the point of delegation, and standardize rippled versions so that governance tallies stay consistent across the network. None of this is glamorous. Quietly securing the layers beneath the hype rarely is. The instinct, reading all this, is to fixate on PaymentBurn. A permission that mints when it should burn is a clean, alarming story. The clean story, though, is not the most important one. The most important detail is the sequence. A first version of permission delegation was withdrawn for a serious flaw. A second version shipped with a different serious flaw. A counting bug in the client software went unpatched long enough to touch live governance. Three defects, arriving in series, point at something the single-vulnerability framing hides: the review process is the weak link, not any one bug. I have written before about the difference between finding bugs and preventing them. A team that patches a flaw quickly — and this team did — is doing the reactive half of security well. The reactive half is necessary and insufficient. When a second version of a feature ships carrying a defect of the same severity as the one that killed the first, the problem is not the defect. It is the gate the defect passed through. There is a structural reason this happens, and it is uncomfortable to name. XRP Ledger has activated 95 amendments. That cadence is a feature — it is how the network stays competitive on functionality. It is also a pressure. Fast iteration and rigorous review pull in opposite directions, and when a network is chasing account abstraction years after ERC-4337 made it standard on EVM chains, the pull toward shipping is real. The PaymentBurn gap and the counting bug are both consistent with a process optimized for delivery. And the absence of independent audit here is telling. The available material references no external security firm and no academic peer review — only official pages and GitHub reports. For a feature whose first version was withdrawn for a serious flaw, the absence of outside scrutiny is not a neutral fact. A quieter concern sits underneath. XRP Ledger's validator set is curated through the Unique Node List, and that curation is concentrated among a small number of entities. Thirty-five trusted validators is not a large set. The counting bug matters more, not less, in that context. When governance is already centralized by curation, a tabulation error is not a minor accounting glitch — it is a flaw in the one mechanism that lends the system its claim to collective decision-making. If the votes cannot be trusted, the decentralization narrative rests on less than it appears. This is the part of the story that will not show up in a price chart, and it is the part I would flag first to anyone building on XRP Ledger. The window closes when fixCleanup3_4_0 clears its threshold and activates. Until then, PaymentBurn carries a minting path its own documentation says should not exist, and the vote that would close it is being counted by software with a known defect. What I will be watching is not the PaymentBurn gap itself — that will be patched, and the response has been competent. I will be watching whether the counting bug is resolved before it interferes with the vote on its own fix, and whether the next amendment to ship arrives with fewer defects than the last two. The XRP Ledger's pitch to institutions rests on reliability, and reliability is not a property you assert. It is one you demonstrate, amendment by amendment, in the unglamorous space between activation and repair. Two votes is not much. But in governance, the distance between 27 and 29 is the whole question.