XRPL fixCleanup3_4_0 activates at ledger 108,112,129, closing a PaymentBurn mint bug

The XRP Ledger's fixCleanup3_4_0 amendment activated on Nov 4 at 14:52 UTC, at ledger 108,112,129, per XRPLWin as cited in CoinDesk's coverage. The xrpld 3.4.0 release notes name the amendment and enumerate the fixes it ships. Among them: rejecting PaymentBurn payments that cross a zero balance — the primary disclosed bug.

Activation ends a two-week supermajority window that opened after an October attempt slipped when validator support dipped below the 80% threshold required for 14 consecutive days (see xrpl-fixcleanup3-4-0-slips-november-4-validator-dip).

The bug

XRPL's permission delegation lets an account authorize another to perform a specific action — for example, to burn a particular issuer's tokens. CoinDesk reports that an account delegated only the PaymentBurn permission could, under certain conditions, also mint new tokens of the same issuer. The flaw applied to assets issued on the XRPL, including stablecoins, and did not affect XRP itself.

The xrpld 3.4.0 release notes describe the fix as "rejecting PaymentBurn payments that cross a zero balance." No public cases of exploitation have been confirmed.

What else fixCleanup3_4_0 ships

Per the release notes:

• OfferCreate: now honors asfDisallowIncomingTrustline the way payments already do.
• AMMClawback: no longer recovers zero when MPT rounding floors the amount.
• EscrowCancel / EscrowFinish: recycle the escrow owner reserve on exit.
• Signing hash prefixes: distinct prefixes for sfCounterpartySignature and sfSponsorSignature, so a signature can't be replayed in another role.
• PaymentBurn: payments that would cross a zero balance are rejected.

The same release also permanently promotes fixAMMOverflowOffer out of amendment gating (the fix for AMM offer-overflow handling is now part of the base protocol), and ships a new LendingProtocolV1_1 amendment that adds closed-ended vaults and cash-basis accounting — separate from fixCleanup3_4_0 and voted on its own timeline.

Numbers block

• Activation ledger: 108,112,129
• Activation time: 14:52 UTC, Nov 4 2026
• Amendment: fixCleanup3_4_0
• Software path: xrpld 3.4.0 (release notes dated 2026-09-16)
• Validator threshold: >80% for 14 consecutive days
• Prior attempt (October): interrupted by validator-support dip; timer restarted
• Affected assets: issued tokens on the XRPL, including issuer-controlled stablecoins; not XRP itself
• Bugs addressed by this amendment: at least five distinct consensus-rule changes (OfferCreate, AMMClawback, Escrow reserves, signing prefixes, PaymentBurn)
• Confirmed exploitation: none publicly reported

Operator impact

Validators and public nodes must be on xrpld 3.4.0 (or a compatible build) to follow consensus after activation. Issuers that had delegated PaymentBurn to a service account had, until now, an implicit instruction in the XRPL docs to avoid delegating that specific permission until this amendment landed; that caveat is now obsolete.

For stablecoin issuers specifically, the bug class matters: a mint path that the issuer did not intend to grant is the same primitive attackers chased in the Euler and Compound-style supply-side exploits of prior cycles, adapted to the XRPL's native permissioning. Closing it at the consensus layer is the right fix.

What to watch

1. Any late disclosure from Ripple or the researcher who flagged the bug on how the condition triggered in practice. The release notes credit MPT/DEX audit and attackathon work in general terms but don't name a reporter.
2. The next amendment window: LendingProtocolV1_1 shipped in the same xrpld 3.4.0 release and is now candidate-ready; its activation path is independent and ongoing.
3. Issuers that previously held off on granular permission delegation re-enabling PaymentBurn for service accounts now that it's safe.

Context

This is the second recent protocol-level fix in XRPL that walks back a bug in an issued-asset code path; see our earlier xrpl-fixcleanup3-5-0-restricted-tokens-pr-8650 coverage of the restricted-tokens tightening and xrp-ledger-bug-overflow-rippled-341-moteur-paiement-dix-ans on an older payment-engine overflow. The pattern is familiar: a feature expands the ledger's permissioning or settlement model, and the first fixes land in the audit tail that follows release.