Skip to content
Blockchain Posts

protocol

XRPL developers patch four restricted-token holes in fixCleanup3_5_0

XRPLF's fixCleanup3_5_0 amendment (PRs #8650, #8648) closes four exceptions that let unapproved accounts hold permissioned tokens on the XRP Ledger. No users affected, routine hardening.

by 5 min read
protocolxrplrippleresearch

The XRP Ledger Foundation has opened a pair of pull requests on the rippled reference client that tighten who can hold restricted (permissioned) tokens on the XRP Ledger. The bundle, planned to ship as a single on-chain amendment named fixCleanup3_5_0, closes four exceptions through which unapproved accounts could receive tokens that are supposed to require issuer approval. The Foundation says no users were affected; it is framing the work as routine hardening, not an incident response.

What is in the patch

The two PRs on XRPLF/rippled:

  • PR #8650 — the main fixCleanup3_5_0 bundle.
  • PR #8648 — an AMM-adjacent fix pulled into the same amendment.

Between them, the PRs rewrite four code paths where approval was skipped on restricted-token transfers. Two matter in particular, per the Foundation's description to CoinDesk and the PR diffs:

  1. AMM buy-ins without approval. A user could join an automated market maker (AMM) pool containing a permissioned token even if the issuer had not approved them to hold the token. The patch requires issuer approval on both pool tokens before a deposit succeeds.
  2. Zero-balance trust-line check only. The permissioned-token approval check was previously evaluated only when a trust line held a zero balance — a trust line that already held the token could receive additional transfers without being re-checked. The patch moves the check so that every receiving account must be approved at the time of the transfer, regardless of current balance.

Two further exceptions, covering edge paths in payment flows and offer execution, are closed in the same PR. Hussein "Vet" Zangana, the Foundation's director of community and product, told CoinDesk the issues were caught during an internal audit of the restricted-token feature set.

Why it matters

Permissioned tokens are the XRPL's answer to the "regulated stablecoin and tokenized security" demand that institutional issuers have been voicing since MiCA and the SEC's recent tokenized-equity enforcement waves. The format is simple: an issuer defines a token whose transfers require a per-account AuthAccount approval, letting the issuer enforce KYC on the holder set and freeze or seize balances when needed. Products already in flight on top of this primitive include RLUSD (Ripple's stablecoin, which drew Moody's A2/P1 deposit ratings earlier this month), BNY-custodied XRPL invoices, and a growing list of tokenized MMFs. Any hole in the approval gate is a problem for every one of those issuers' compliance posture.

Importantly, the Foundation says exceptions were not exploited in the wild. The patches are preventive: no funds moved, no issuer freeze was bypassed.

Mechanism of the fix

The approval check lives in XRPL's transaction preflight path. In the pre-patch client, several transaction types evaluated approval conditionally — only on the first interaction with a trust line, only when the counterparty's balance was zero, or only on explicit payment transactions and not on AMM or offer-executed transfers. The patched code promotes the approval check to a single invariant: every state change that credits a restricted token to an account must first verify that the account appears in the issuer's AuthAccount set.

Activation path

Because the fix changes consensus-level behavior, it will ship as an amendment rather than a client-only update. The XRPL amendment process requires:

  1. The PRs merge into rippled.
  2. The amendment is included in a tagged release.
  3. More than 80% of trusted validators run the release and vote yes for two consecutive weeks.
  4. The amendment then activates at the end of that window.

If any step stalls — in particular, if validator operators do not upgrade in time — the amendment lingers in a supported-but-not-enabled state. Nothing on the ledger changes until the two-week threshold is cleared.

Under the post-amendment behavior, an unapproved account that holds a restricted-token balance can still exist, but can only send that balance back to the issuer. They can no longer trade it on an AMM, offer it for sale, or pass it to another holder.

Numbers block

  • Four exceptions closed in fixCleanup3_5_0.
  • Two PRs: #8650 and #8648.
  • Zero users affected per the XRPL Foundation.
  • >80% validator support for 2 consecutive weeks required to activate.

What to watch

  1. The merge timeline for PR #8650 and #8648 — the Foundation has not committed to a release tag yet.
  2. Validator uptake: whether UNL operators (the set rippled nodes trust by default) run the release quickly after merge.
  3. Issuer response from RLUSD, BNY-custodied products, and the tokenized MMF partners (BlackRock, SBI, Startale per the recent JPYSC MOU) — these are the first institutional users of restricted tokens, and their posture on the patch will shape the activation vote.

Context — amendments as the XRPL's quiet upgrade channel

XRPL amendments have shipped at roughly a quarterly cadence over the past year. Prior cleanups — fixCleanup3_4_0, fixCleanup3_3_x — have targeted smaller execution bugs, but this is the first fixCleanup to touch the restricted-token subsystem specifically. It arrives alongside XRPL PR #8606, the sponsored-account-create amendment covered on Blockchain Posts earlier this cycle, suggesting the Foundation is pushing hardening work in parallel with new institutional features.

Sources

Related stories