• XRP Ledger developers have proposed four fixes to close gaps in issuer approval requirements for restricted tokens.
• The changes would strengthen checks on trading pool shares and token transfers, preventing unapproved accounts from acquiring restricted assets through exceptions.
• Holders without approval would generally only be able to return affected tokens to the issuer, unless the issuer authorizes their account.
• The proposals are not live on mainnet. The XRP Ledger Foundation described the work as routine protocol hardening and reported no known outsider exploitation of the remaining exceptions.

XRP Ledger Developers Target Token Approval Gaps

XRP Ledger developers are proposing tighter controls over who can receive and hold tokens that require issuer authorization.

The four proposed fixes are grouped under an amendment called fixCleanup3_5_0. They aim to make existing approval requirements apply consistently across different ways tokens move through the network.

Issuers of assets such as regulated stablecoins or tokenized funds can require approval before an account holds their tokens. This allows an issuer to conduct identity checks or apply other eligibility requirements.

That authorization is recorded on a trust line, the connection an account establishes to hold another party’s issued token.

The proposed changes address exceptions in how those requirements are enforced. They concern restricted issued tokens, rather than introducing an issuer-approval requirement for holding native XRP.

Trading Pool Shares Face Stronger Checks

One proposed fix would require an account to have the necessary authorization for both assets in an automated market maker pool before acquiring its liquidity provider token.

These pool shares, often called LP tokens, represent a claim on the assets held inside the pool.

Developers identified a gap between depositing directly into a pool and receiving its LP tokens through another route. Although deposits already required the relevant authorizations, transfers of pool shares could allow an unapproved account to gain exposure to restricted assets.

The proposal extends checks across those acquisition routes, including payments, trading offers and NFT offers involving LP tokens.

The aim is to ensure that receiving a pool share cannot bypass the approval requirements attached to its underlying assets.

Existing Balances Would No Longer Bypass Authorization

A second proposal addresses an exception involving trust lines that already carry a token balance.

Under the behavior developers identified, an authorization check in the payment engine applied when a trust line’s balance was zero. A line that already held tokens could continue receiving more despite lacking approval.

The fix would prevent unauthorized trust lines from receiving additional restricted tokens through that route.

The broader package also seeks to keep authorization rules consistent across existing and future XRP Ledger features.

For an account already holding restricted tokens without approval, the proposed rules would generally allow those tokens to be returned to their issuer. The issuer could subsequently approve the holder’s trust line and restore normal use.

Foundation Says Work Is Unrelated to a Security Incident

The XRP Ledger Foundation described the proposals as routine improvements to protocol safeguards.

Speaking to CoinDesk, Hussein “Vet” Zangana, the foundation’s director of community and product, said the discussion concerned the guarantees the protocol should provide, rather than a report of affected users.

According to Zangana, known unauthorized balances originated from payments by issuers themselves or accounts those issuers had previously approved. The foundation said it knew of no balance created by an outside party exploiting the remaining exceptions.

Developers have also examined earlier routes involving NFT trades, including an issue addressed in August 2025.

XRP Ledger Changes Still Require Validator Support

As of the October 30 report, the four fixes had not been merged into the network’s main software or activated on mainnet.

Software inclusion would be only one step toward implementation. The amendment would also need sustained support from the network’s trusted validators for two consecutive weeks before activation.

Validator approval is also central to other network changes, including the separately proposed XRP Ledger Batch upgrade.

If adopted, the restricted-token fixes would give issuers more consistent enforcement of their existing approval requirements. For holders, the practical distinction would be whether their account has the issuer’s authorization.

Follow Bitcoinist’s latest Ripple news for further coverage of XRP and developments across the ecosystem.

A hardware wallet’s strongest cryptography offers little protection when an attacker can interfere with the device before its owner even switches it on. That is the uncomfortable lesson from the CryptoBilis case now facing Ledger customers in Southeast Asia.

TL;DR: Investigators have linked roughly $90 million or more in reported crypto losses to tampered wallet devices sold through a reseller channel. Ledger says its own systems were not compromised and has warned affected customers to move to newly generated recovery phrases.

The incident involves physical modifications rather than an ordinary phishing message. Reports describe implants that could capture a recovery phrase during device setup and transmit information to attackers. Once someone else possesses that phrase, they may be able to recreate the wallet without needing physical access to the device.

Ledger said confirmed cases involved wallets sold through CryptoBilis, a reseller listed in parts of Southeast Asia. It asked the reseller to stop sales and shipments while investigations continued. Customers who received affected devices were advised not to initialize them, and those already in use were told to secure funds with new credentials using trusted equipment.

The precise loss figure is still an estimate, and investigators have not publicly established a complete count of affected units. A device successfully passing an ordinary software or chip authenticity check should not automatically be interpreted as proof that no unauthorized physical component has been added elsewhere.

This attack is especially troubling because hardware wallets are bought to reduce dependence on third parties. Here, the supply chain itself became the point of exposure. For anyone buying a security device, provenance and physical integrity now deserve attention alongside firmware version and backup discipline.

Written by the News Desk and edited by Samuel Rae.

TL;DR: The XRP Ledger’s BatchV1_1 amendment remains in its activation window and is expected to enable around October 9 if validator support stays above the required threshold. The upgrade allows multiple transactions to be bundled into an atomic group, replacing an earlier Batch version that was halted after a critical bug was found.

A major XRP Ledger upgrade is approaching activation after one of the more unusual validator coordination episodes in the network’s recent history.

BatchV1_1 is currently inside the XRPL amendment process and is expected to activate around October 9 if support remains above the required supermajority threshold.

The feature allows multiple transactions to be bundled together so they either succeed as a group or fail as a group.

That opens the door to more complex operations such as atomic swaps and workflows where several ledger actions need to complete together.

The route to activation has not been smooth.

An earlier version of Batch was prevented from activating after a critical issue was discovered.

Validators then coordinated around a corrected version, with support temporarily adjusted so the activation countdown could reset and the Batch amendment could arrive alongside its associated fix.

XRPL amendments require more than 80% support from trusted validators for two consecutive weeks before they can become active.

If support falls below that threshold, the clock resets.

That mechanism is deliberately conservative.

An amendment changes the rules understood by the network. Once it activates, servers that do not support the new rules can become amendment blocked and stop following the ledger correctly.

The corrected BatchV1_1 feature is therefore being paired with newer software designed to address the earlier problem.

The upgrade matters because atomic transaction groups are a basic building block for more sophisticated financial applications.

Without them, a developer may need to coordinate several separate ledger operations and deal with the possibility that one succeeds while another fails.

Batching lets the application treat those actions as one logical unit.

That can be useful for trading, tokenization and other workflows where partial execution would create risk.

The XRP Ledger has increasingly been adding features aimed at institutional assets and more complex on-chain finance.

Batch transactions fit into that broader direction, alongside work on multi-purpose tokens, permission controls and other features designed to support financial applications beyond basic XRP transfers.

The current countdown is not an absolute guarantee.

Validator support has to remain above the required level until the activation process completes.

But the network is much closer to enabling Batch than it was when the first version ran into trouble.

In some ways, the delay may be the more reassuring part of the story.

A decentralized network found a serious issue before activation, validators coordinated to stop the change, and the amendment process was reset around a fix.

Now the feature gets another attempt.

This time, the XRP Ledger is trying to make sure the batch arrives as a complete package rather than simply arriving on time.