XRPL Token Bug Fixed: What the fixCleanup3_4_0 Amendment Means for Stablecoins

The XRP Ledger (XRPL) is preparing to address a token permission vulnerability through its fixCleanup3_4_0 amendment, with activation projected for 4 November 2026. 

The issue involves delegated permissions that could allow an account authorised only to burn an issuer's tokens to create new tokens under specific payment conditions. 

Although XRP itself is unaffected, the flaw matters for issued assets, including stablecoins. The upgrade aims to strengthen supply controls by ensuring that token-burning authority cannot implicitly become token-minting authority.

Key Takeaways

• A token permission loophole is being addressed: A delegate with PaymentBurn permissions could potentially mint issued tokens in certain circumstances.
• XRP supply is unaffected: The vulnerability concerns issued assets, including trust-line tokens and Multi-Purpose Tokens (MPTs).
• The amendment strengthens issuer controls: PaymentBurn and PaymentMint will operate as separate permissions, protecting token supply management.

What Was the XRPL Token Bug?

source by AI

The vulnerability involves the XRP Ledger's permission-delegation system, which allows token issuers to grant specific transaction rights to other accounts.

For example, a stablecoin issuer might authorise a payment processor or redemption partner to receive tokens from customers and burn them when those customers exchange their stablecoins for traditional currency.

This arrangement is designed to give the partner limited authority. It should be able to remove tokens from circulation without gaining the ability to create additional supply.

However, before the fixCleanup3_4_0 amendment, an account holding only the delegated PaymentBurn permission could, under certain payment conditions, move a token balance across zero and effectively mint new fungible tokens.

In other words, an account authorised to destroy tokens could potentially create new ones without separately receiving PaymentMint permission.

How PaymentBurn and PaymentMint Work

The XRPL uses granular permissions to control what delegated accounts can do.

• PaymentBurn: Allows an authorised delegate to send payments that burn fungible tokens or MPTs.
• PaymentMint: Allows an authorised delegate to send payments that create new fungible tokens or MPTs.

The problem was that these permissions did not remain sufficiently separated in certain edge cases.

Consider a stablecoin issuer that delegates redemption operations to an external payments company. The company should only be able to burn tokens returned by customers. However, the vulnerability could create a pathway for unintended token issuance.

This is particularly important for fiat-backed stablecoins, where the circulating supply is expected to reflect the issuer's authorised issuance and redemption processes.

The issue does not mean that every XRPL stablecoin was compromised or that the vulnerability was necessarily exploited. CoinDesk reported that it found no public records or reports of exploitation.

What Does the fixCleanup3_4_0 Amendment Change?

source by AI

The fixCleanup3_4_0 amendment restores the intended separation between token-burning and token-minting permissions.

Once enabled, the amendment prevents a burn-only delegate from completing a payment that crosses a zero balance and effectively creates new fungible tokens. 

An account must have the separate PaymentMint permission to perform an authorised issuance operation. This means that token issuers can maintain clearer control over who is allowed to create additional supply.

Before and After the XRPL Upgrade

The amendment is not a new stablecoin issuance feature. Instead, it is a protocol-level security correction designed to make delegated permissions behave as intended.

It is also worth noting that fixCleanup3_4_0 is a broader collection of XRPL improvements covering areas such as vaults, lending, automated market makers, NFTs, escrow, sponsorship and transaction signing. The token permission correction is one particularly important part of that package.

Why the Fix Matters for Stablecoins and XRPL Issuers

Stablecoin infrastructure depends on reliable supply management. Issuers need to control how tokens are created, transferred, redeemed and removed from circulation.

A permission system that allows a redemption partner to gain unintended issuance capabilities can undermine those controls.

The fixCleanup3_4_0 amendment addresses this concern by ensuring that burning and minting remain distinct operations.

Stronger Operational Separation

Stablecoin issuers often work with external exchanges, payment processors, custodians and redemption partners.

These organisations may need permission to perform specific token operations, but they should not automatically receive broader authority over the stablecoin's supply.

By requiring separate PaymentMint authorisation, the amendment supports a more clearly defined permission structure.

This is particularly relevant for institutional tokenisation, where issuers need to demonstrate that supply changes follow controlled operational procedures.

Why XRP Holders Should Not Confuse This With an XRP Supply Vulnerability

An important distinction is that the vulnerability affects issued tokens on the XRP Ledger, not XRP itself.

XRP is the native asset of the network and does not depend on an issuer granting delegated PaymentBurn permissions to manage its supply.

Therefore, the amendment should not be interpreted as a correction to a flaw that allowed stablecoin partners to print additional XRP.

For XRP holders, the development is primarily relevant to the broader health of the XRPL ecosystem, particularly its ability to support stablecoins and other issued digital assets.

A stronger token permission framework could improve confidence among businesses considering the network for payment and tokenisation applications.

When Will fixCleanup3_4_0 Activate?

The amendment was introduced in the XRPL 3.4.0 software release and requires more than 80% of trusted validators to support it continuously for 14 days before activation.

Following an earlier decline in validator support on 21 October, the activation countdown restarted after majority support was regained.

As of 4 November 2026, the amendment had support from 33 of 35 tracked trusted validators, exceeding the required 29 votes. Its projected activation time was 14:46 UTC on 4 November, equivalent to 21:46 WIB.

Importantly, this was still a projected activation time when this article was prepared, not confirmation that the amendment was already live. The network must complete its activation process and record the change on the validated ledger.

What Should Stablecoin Issuers and Node Operators Do?

Businesses and developers working with XRPL-issued assets should take several precautions:

1. Avoid premature PaymentBurn delegation: The official XRPL documentation warns developers not to delegate this permission until fixCleanup3_4_0 is enabled.
2. Verify amendment activation: Check the live XRPL amendment status rather than relying solely on validator approval or an estimated activation time.
3. Review delegated permissions: After activation, ensure that PaymentMint is granted only to accounts that genuinely require token-issuance authority.
4. Update XRPL software: Node operators should follow the latest compatible XRPL software releases and security guidance.
5. Review token-management procedures: Issuers should examine their redemption, burning and minting workflows to ensure that delegated accounts have only the permissions they need.

The wider XRPL security work also includes the 3.4.1 software release, which followed a separate historical XRP-related integer-overflow issue and its correction. 

Operators should review the relevant release notes rather than assuming that this separate issue is addressed solely by fixCleanup3_4_0.

Conclusion

The XRPL fixCleanup3_4_0 amendment is an important security improvement for stablecoins and other issued tokens. 

By separating PaymentBurn from PaymentMint, it closes a permission loophole that could potentially allow delegated accounts to create tokens without explicit minting authority. 

XRP's native supply was never affected, but the correction strengthens confidence in the XRP Ledger's token-management infrastructure. 

With activation projected for 4 November 2026, issuers and node operators should verify the live ledger status and update their systems accordingly. 

For easier and safer crypto trading, explore digital assets on Bitrue while conducting independent research and managing risks responsibly.

FAQ

What is the XRPL fixCleanup3_4_0 amendment?

It is a protocol update that addresses several XRP Ledger issues, including a permission-delegation vulnerability that could allow an account with only PaymentBurn authority to mint issued tokens under certain circumstances.

Did the XRPL token bug affect XRP's supply?

No. The vulnerability concerned issued assets, including trust-line tokens and Multi-Purpose Tokens (MPTs). XRP's native supply was not affected.

What is the difference between PaymentBurn and PaymentMint?

PaymentBurn allows authorised accounts to destroy issued tokens, while PaymentMint allows authorised accounts to create new fungible tokens or MPTs. The amendment ensures these permissions remain properly separated.

When will fixCleanup3_4_0 activate?

The projected activation time was 4 November 2026 at 14:46 UTC (21:46 WIB), provided sufficient validator support remained in place. The actual activation must be confirmed through the live XRP Ledger.

How does fixCleanup3_4_0 benefit stablecoin issuers?

It strengthens supply controls by ensuring that redemption partners with permission to burn stablecoins do not automatically gain the ability to mint additional tokens. This supports better operational security and clearer permission management.

Disclaimer: The views expressed belong exclusively to the author and do not reflect the views of this platform. This platform and its affiliates disclaim any responsibility for the accuracy or suitability of the information provided. It is for informational purposes only and not intended as financial or investment advice.