Two XRP Ledger Fixes for Token Permissions Are Open, and Neither One Is Live Yet

Two pull requests. Same day. Neither one moves a single transaction on mainnet.

That's the whole factual core of what's happening inside rippled, the reference server for the XRP Ledger. Proposal 8648, opened October 27, would require any account acquiring a liquidity-provider token to satisfy authorization requirements for both assets sitting inside the corresponding automated market maker. Proposal 8650, opened the same day, goes after a narrower hole in the payment engine, where an unauthorized trust line carrying a zero balance could still be used as a landing spot for more of an issuer's token. Both are filed under the planned fixCleanup3_5_0 amendment.

No activation. No vote. No changed behavior on the network you're using right now.

What the two proposals actually do

Start with 8648, because the logic there's the more interesting of the pair. A liquidity-provider token isn't a standalone thing. It's a claim on two assets at once, and the pool is just the mechanism that holds them. If an issuer restricts who may hold its token, then checking authorization only at the direct deposit step is close to meaningless, because a customer can reach the same economic exposure by receiving a pool token through a transfer or by taking an exchange offer. Same risk, different door.

The proposal closes the other doors. That's not a dramatic change in philosophy. It's the difference between a lock and a lock that only covers the front of the house.

Proposal 8650 is smaller and more surgical. The payment engine previously applied an authorization check when the trust line in question had a zero balance. The proposed behavior would stop an existing unauthorized balance from being topped up through further receipts. The code discussion draws a line that matters more than it looks: receiving an issuer's tokens isn't the same as returning an obligation in the other direction. Blocking a new unauthorized holding doesn't have to block a legitimate redemption or a cleanup path. Get that distinction wrong and you trap users in positions they can't exit, which is a worse outcome than the gap you set out to fix.

One housekeeping note for anyone following along from older coverage. Two broader proposals referenced in the discussion threads are now closed. Reading the current open changes is more reliable than treating an earlier description of four planned fixes as the finished package. Scope shifted. That's normal, and it's also why the diff matters more than the summary.

The XRPL Foundation didn't immediately respond to a request for comment.

Code review isn't a rule change

Here's where the market usually gets ahead of itself. Amendment documentation for the XRP Ledger is explicit about sequence. A change affecting transaction processing has to be included in released software, then hold more than 80% validator support for two full weeks before it activates. An open pull request has cleared none of those gates. Review can rewrite the design. A release can carry it or defer it. Validators decide for themselves, and they've said no before.

Reading the amendment tea leaves, the realistic timeline is measured in release cycles, not weeks of headlines.

So who wins here? Issuers running authorization controls on trust lines, mostly. Stablecoin issuers, tokenized fund managers, anyone who has told a regulator that they know who holds their paper. For them, a permission check that holds at one entry point and leaks at three others is an enforcement liability dressed up as a feature. Two people familiar with how these controls get audited would tell you the same thing: the examiner asks how a restricted asset can travel, not where it first landed.

Who loses? In the narrow, immediate sense, nobody. In the slightly longer sense, application developers who assumed the current behavior was permanent. If your integration surfaces a rejected transaction as a generic error with no explanation, the new checks will make that interface problem worse, not better. A technically correct rejection that renders as "transaction failed" is still a bad user experience, and it's the kind of thing that generates support tickets at two in the morning.

And the loudest misread to kill right now: this has nothing to do with native XRP. The proposals concern permissioned issued-token relationships and claims on liquidity pools. XRP itself doesn't become an issuer-controlled asset. Anyone telling you the network is adding an identity check on every holder is describing a different proposal that doesn't exist.

The question now is whether the gap under review was ever exploited. The public development record doesn't establish that. It establishes a tightening, and tightening is cheaper before the incident than after.

What to watch, and what to do

My read is that this is unglamorous, correct work, and it's arriving later than it should have. Permission controls that hold along one route aren't controls. They're a speed bump with a compliance memo attached. The team is right to close the routing gap and right to preserve redemption paths while doing it, because a restriction that traps holders is a restriction issuers won't deploy.

But let's be honest about pace. Two pull requests opened on a single day in October, sitting under an amendment that needs 80% validator support sustained for two weeks, on top of a merge and a release. That's a long runway for a fix that addresses a live design weakness. For a settlement chain, slow is mostly a feature. For developers shipping permissioned asset products, it's a planning constraint they've to price in.

If an issuer can restrict who holds its token, does it really matter how the holder got there? It shouldn't. That's the entire argument behind 8648, and it's hard to rebut.

Concrete next steps for anyone affected. Map every path through which a customer can end up holding a restricted asset, including pool tokens, transfer receipts, and exchange offers. Then check how your application displays an authorization failure, and whether it offers a redemption route alongside the rejection. Test proposed behavior in a separate environment rather than assuming production will return the error you read about in a diff.

Watch three things and ignore the rest. The merged implementation, the release notes that carry it, and the amendment status page. Until all three line up, the story is about consistency in permission controls, not a rule in force. That's the number that matters, and today it's zero.