rippled 8650 would stop unauthorized XRPL trust lines from receiving at all
Serguey Asael Shinder2 min readPull request 8650 in the rippled repository, opened on 27 October and still under review, is the second of two changes split out of an earlier PR at a reviewer's request; the first, 8648, has to be reviewed before it. Both sit behind the same amendment, fixCleanup3_5_0, so nothing changes on the ledger unless validators enable it.
The problem it addresses is in the payment engine. On the XRP Ledger an issuer can require authorization before an account may hold its token, but the authorization check in DirectIPaymentStep::check only fired when the trust line's balance was exactly zero. A line that already carried a balance kept receiving, which the PR says is how an unauthorized position could grow, and a payment crossing zero could turn a holder into an unauthorized holder of the counterparty's token. The PR names these as the mechanism behind issue 5450.
Under the amendment an unauthorized line may not receive at all, and the step fails with the final code tecNO_AUTH instead of the retriable terNO_AUTH. The gate applies only when the step would hand the destination the source's token, so an account that itself requires authorization can still redeem a foreign IOU. A redemption is capped at the redeemable amount, and an oversized one fails as tecPATH_PARTIAL. A balance already sitting on an unauthorized line stays spendable, since authorization governs holding and receiving, not sending; the PR leaves such balances to freezing. It reports no API impact and adds a new TrustLineAuth test suite.
What it means
For issuers of regulated tokens, the gap mattered more than the code size suggests: "requires authorization" was a promise that held only at zero. The fix makes it hold at any balance, but it also shows where the rule stops. Funds that already reached an unauthorized line will not be pulled back by the amendment; dealing with them stays the issuer's job.