XRP Ledger Activates Security Fix for Token Minting Vulnerability, Native XRP Unaffected

The XRP Ledger has reportedly activated the fixCleanup3_4_0 amendment to address a vulnerability that could allow accounts with delegated token-burning permissions to create issued tokens under specific conditions. The fix took effect on November 4, 2026, following validator approval. Native XRP was not affected by the flaw.

The XRP Ledger (XRPL) has implemented a protocol amendment designed to address a security issue involving delegated permissions and the creation of issued tokens.

According to the XRPLWin amendment tracker, the update, identified as fixCleanup3_4_0, became active on November 4, 2026, at 14:52 UTC, at ledger index 108,112,129.

The amendment resolves an issue in which accounts granted permission to destroy certain issued tokens could, under specific circumstances, cause new units of those assets to be created.

The vulnerability involved the network’s PaymentBurn delegation mechanism, a feature intended to let authorised accounts burn tokens without receiving broader control over the issuer’s assets.

According to the supplied technical disclosures, the problem occurred when a delegated PaymentBurn transaction crossed a zero-balance boundary.

The newly activated amendment blocks that transaction behaviour.

The vulnerability potentially affected issued assets, including stablecoins and other tokens operating on XRPL. However, it did not affect XRP, the network’s native cryptocurrency, because XRP is not governed by the same issued-token permission mechanism.

There have been no publicly reported cases of exploitation in the supplied disclosures.

XRP Ledger Activates fixCleanup3_4_0 Amendment

The latest security update is part of the XRP Ledger’s protocol amendment system, which allows network transaction rules to change after sufficient validator support.

The fixCleanup3_4_0 amendment reportedly became active on November 4 at 14:52 UTC.

XRPLWin identifies the activation at ledger 108,112,129.

The fix had previously been included in XRP Ledger server version 3.4.0, released in September 2026, according to the supplied information.

However, including an amendment in the server software does not automatically make its rules active across the network.

A protocol amendment must pass the XRP Ledger’s validator approval process before becoming part of the active transaction rules.

That distinction is important because a software release and a network-level amendment activation are separate events.

XRP Ledger Security Patch: Key Details

What Was the XRP Ledger Token Minting Vulnerability?

The vulnerability involved the relationship between delegated permissions and token balances on XRPL.

The network allows accounts to grant selected transaction permissions to other accounts.

This lets an account owner authorise specific activities without handing over unrestricted control.

One such permission is PaymentBurn.

PaymentBurn is intended to allow an authorised party to destroy issued tokens under certain conditions.

This can be useful in financial applications involving token redemption.

For example, a stablecoin issuer might permit an authorised redemption service to burn tokens after customers have exchanged them for the corresponding fiat currency.

The service could then remove redeemed tokens from circulation without requiring broad token-issuance authority.

However, the previous transaction rules contained an edge case.

According to the technical information supplied, a delegated account with PaymentBurn permission could, in particular circumstances, execute a transaction that crossed a zero-balance boundary.

That behaviour could result in the creation of issued tokens, even though the delegated account was intended to possess only token-burning authority.

This represented a permission-enforcement problem.

An account authorised to destroy tokens should not be able to use that permission to create new ones.

What Is PaymentBurn on the XRP Ledger?

PaymentBurn is a delegated transaction permission associated with destroying issued assets.

Token burning generally refers to reducing the outstanding supply of a token by removing units from circulation under the relevant ledger rules.

In a stablecoin redemption process, burning can help ensure that tokens are retired after the underlying value has been redeemed.

For example, when a user exchanges issued stablecoin units for fiat currency, the corresponding digital units may need to be removed from circulation.

A delegated burning permission can allow an approved service to carry out that operation.

The key limitation is that a burning permission should not provide the broader authority needed to issue additional tokens.

The vulnerability described in the report undermined that separation under a narrow set of balance conditions.

Why Did the Zero-Balance Boundary Matter?

The issue centred on transactions that crossed a zero-balance boundary.

In an issued-token accounting system, the direction and sign of a balance can have important implications for how the ledger interprets the relationship between parties.

According to the release notes, the problematic delegated PaymentBurn payments were those that crossed a zero balance.

Under the earlier rules, the transaction could reportedly produce an outcome inconsistent with the limited purpose of the delegated burning permission.

The fixCleanup3_4_0 amendment addresses the issue by rejecting such payments.

The XRPL release notes describe the change as rejecting:

“PaymentBurn payments that cross a zero balance.”

This is a targeted restriction rather than a complete removal of the PaymentBurn functionality.

Legitimate token-burning transactions that satisfy the applicable permission rules are not described as being universally disabled by the amendment.

The technical importance is that a delegated authority intended for token destruction can no longer be exercised through the identified boundary-crossing behaviour.

Which XRP Ledger Assets Were Potentially Affected?

The issue concerned assets created or issued on the XRP Ledger rather than native XRP itself.

According to the supplied security information, the affected categories could include stablecoins, trust-line tokens and Multi-Purpose Tokens.

Stablecoins

Stablecoins are digital assets generally designed to maintain a value linked to another asset, such as a fiat currency.

Where stablecoin supply is managed through issuance and redemption, unauthorised token creation could undermine confidence in the relationship between circulating supply and the backing assets.

However, the vulnerability’s existence does not establish that any particular XRPL stablecoin suffered an unauthorised minting incident.

Trust-Line Tokens

The XRP Ledger supports issued assets using trust-line relationships.

These balances are governed by rules that differ from those applying to XRP itself.

A flaw in delegated issued-token permissions could therefore affect relevant token accounting operations.

Multi-Purpose Tokens

The supplied disclosure also identifies Multi-Purpose Tokens among the categories potentially affected by the issue.

The precise exposure for any particular token would depend on its configuration and use of the relevant delegated permission.

Not every issued token should automatically be assumed to have been exploited or exposed to the same operational conditions.

Why Native XRP Was Not Affected

The XRP Ledger’s native cryptocurrency, XRP, was not affected by the reported PaymentBurn vulnerability.

The distinction arises from how XRP differs from issued assets on the network.

XRP is the ledger’s native asset, while issued tokens operate under separate token issuance and permission rules.

The flaw involved the delegated PaymentBurn permission used for issued assets.

Because native XRP is not governed by that issuance-permission mechanism, the identified behaviour did not provide a method for creating additional native XRP.

This is an important distinction for readers.

The report concerns potential unauthorised creation of certain issued assets, not a vulnerability that allowed attackers to mint new units of XRP itself.

The supplied information also does not indicate a change to XRP’s native supply rules as a result of the amendment.

Was the XRP Ledger Vulnerability Exploited?

The supplied security disclosures do not identify any confirmed incident in which attackers successfully exploited this vulnerability to create unauthorised tokens.

They also do not name an issuer that suffered losses or an unexpected increase in token supply because of the issue.

That is relevant when assessing the severity and real-world impact of the report.

A security flaw may create the possibility of harmful behaviour without evidence that the behaviour actually occurred.

However, an absence of reported exploitation does not conclusively establish that no exploitation ever took place.

The available evidence supports the narrower conclusion that no confirmed exploitation is described in the supplied disclosures.

There is also no verified evidence here of customer losses, a stablecoin depegging incident or an exchange disruption directly attributable to the vulnerability.

How XRP Ledger Amendments Receive Validator Approval

The XRP Ledger uses a validator-based amendment process to activate changes to its transaction rules.

According to the supplied explanation, an amendment must receive support from more than 80 percent of trusted validators for 14 consecutive days.

This sustained approval requirement is designed to prevent major protocol changes from activating based on a brief or unstable period of validator support.

The approval system also separates preparation for a new protocol rule from its actual activation.

Developers may release software containing support for an amendment before the network adopts it.

Validators then participate in the process that determines whether the amendment becomes enabled.

What Does the 80 Percent Requirement Mean?

Consider a tracked trusted-validator set containing 35 validators.

Eighty percent of 35 is 28.

Because the requirement is more than 80 percent, at least 29 validators would need to support the amendment.

The required support must also be maintained for the specified consecutive period.

This is an illustrative calculation using the validator-set size given in the supplied report. It should not be taken as an assertion that the network always has exactly 35 validators or that all participants use identical trusted-validator lists.

Why Was the Fix Not Active Immediately After the Software Release?

The PaymentBurn fix was reportedly included in XRP Ledger server version 3.4.0 in September 2026.

However, the protocol change did not become active until November 4.

This gap reflects the difference between software availability and amendment activation.

Installing software that recognises a proposed amendment does not independently change the live ledger’s rules.

The network must also complete its amendment approval procedure.

The supplied report mentions an interruption to the amendment process during October, after which the approval period restarted.

However, the exact nature and timing of that interruption require confirmation from the amendment tracker.

What matters for the reported security update is that the amendment eventually satisfied the necessary conditions and became active at the specified ledger index.

What Does the Fix Mean for Stablecoin Issuers?

The change is particularly relevant to organisations using delegated permissions for the management of issued assets.

Stablecoin issuers and redemption services may rely on delegated transaction authority to separate operational responsibilities.

For example, a redemption operator may need permission to retire tokens without receiving the ability to create additional units.

The PaymentBurn vulnerability weakened that distinction under certain transaction conditions.

By rejecting payments that cross the zero-balance boundary, the amendment is intended to restore the expected restriction.

However, the update should not be interpreted as eliminating every risk associated with issued tokens or stablecoin operations.

Issuers still need to manage private keys, account permissions, transaction authorisation and operational security.

The amendment addresses a specific protocol-level behaviour rather than all potential sources of token issuance risk.

XRP Ledger Security Fix: Before and After

The amendment is a focused correction to the transaction rules.

It is not a general guarantee against smart contract vulnerabilities, compromised accounts or other risks associated with blockchain-based assets.

Why the XRP Ledger Patch Matters

Security in blockchain networks depends on more than preventing unauthorised access to accounts.

Protocols must also enforce the intended boundaries between different types of transaction authority.

A permission designed to destroy issued tokens should not allow the creation of new tokens, even under unusual accounting conditions.

The reported PaymentBurn flaw illustrates how a narrow transaction edge case can undermine an otherwise restricted permission.

The fixCleanup3_4_0 amendment aims to remove that behaviour through a network-level protocol change.

For organisations using XRPL-issued assets, the development is relevant because token supply integrity is an important part of operating reliable financial systems.

The activation process also demonstrates how updates to the XRP Ledger’s rules require sustained validator support.

The central finding is that XRPL has reportedly closed a delegated-permission loophole that could have enabled unintended issued-token creation, while native XRP itself was not vulnerable to this issue.

There have been no confirmed exploitation incidents identified in the supplied disclosures.

TechLayers will continue covering blockchain security updates, cryptocurrency infrastructure and vulnerabilities affecting digital asset platforms.

Have a story tip or feedback? Contact [email protected].

© TechLayers. Original editorial content.