The XRP Ledger activated a new security amendment on Wednesday to eliminate a protocol flaw that could have allowed accounts authorized to burn an issuer’s tokens to mint additional tokens under certain conditions. The vulnerability did not affect the XRP cryptocurrency.

The update, named fixCleanup3_4_0, became operational at 14:52 UTC, at ledger 108,112,129, according to XRP Ledger explorer XRPLWin. Its rollout followed 14 consecutive days of validator support after an earlier activation attempt was interrupted in October.

The flaw was discovered within XRPL’s permission delegation framework, which enables account holders to assign specific transaction privileges to other accounts without transferring full control of their wallets.

For example, a stablecoin issuer can authorize a payment processor to burn tokens when customers redeem them for dollars without granting permission to create new tokens.

However, the previous protocol rules contained a weakness that could potentially allow an account with limited token-burning authority to issue new tokens under certain circumstances. The latest software correction closes this loophole and reinforces the distinction between token creation and destruction permissions.

The vulnerability was limited to assets issued on the XRP Ledger, including stablecoins, and did not involve XRP itself. No publicly confirmed exploitation of the bug has been reported.

Alongside the security patch, the release delivers accounting improvements for XRPL’s planned lending infrastructure and Single Asset Vaults. These features are intended to let users deposit assets into pools that can be used to support lending services.

The changes also refine how vault deposits and withdrawals are calculated and how loans are categorized when borrowers fall behind on payments.

Additional fixes cover token recovery from automated market-making pools, permissioned trading functionality and transaction signing.

The amendment’s activation took longer because of the XRP Ledger’s validator approval requirements. Under its governance process, any proposed network change must maintain support from more than 80% of trusted validators for 14 consecutive days before going live.