The XRP Ledger is advancing toward activating a correction scheduled for Nov. 4 to address a vulnerability allowing accounts with burn-only authorization to create new tokens under specific conditions. Developers caution issuers against delegating PaymentBurn permission until the fixCleanup3_4_0 amendment becomes active, noting that validator backing currently stands at 33 of 35 and depends on sustained support for activation. This flaw impacts issued tokens such as stablecoins but does not affect XRP's native supply.
The proposed amendment also incorporates separate repairs for trading pools, vault accounting, and loan checks. XRPL's official documentation specifies that the issue resides in PaymentBurn, a permission mechanism intended to enable one account to destroy fungible tokens on behalf of an issuer. Until the fix takes effect, a delegate holding this permission can occasionally mint trust line tokens or Multi-Purpose Tokens (MPTs).
Validator Support Critical for November Activation
XRPL's official documentation points to a vulnerability within PaymentBurn, a mechanism allowing one account to destroy fungible tokens on behalf of an issuer. The permission reference distinguishes between PaymentMint and PaymentBurn; the former authorizes payments that generate fungible tokens, whereas the latter is meant to authorize their destruction without permitting a payment to cross a zero balance. This warning explicitly notes that other granular permissions are not affected by the flaw, advising users to refrain from delegating PaymentBurn until the fix is implemented.
Release notes from Sep. 16 regarding xrpld version 3.4.0 detail the specific correction: payments utilizing PaymentBurn will be rejected if they cross that boundary. This adjustment is included in an amendment package, indicating that merely installing the update into server software does not automatically enable the new transaction rule across the network.
The scope of the identified risk is limited to accounts that have accepted the compromised delegated permission, as neither the security alert nor the release documentation names a specific issuer whose tokens were illicitly generated. XRP's native asset supply remains unaffected by this flaw regarding issued-token permissions; instead, the vulnerability applies only to assets minted on the ledger via trust lines or the MPT framework.
Data from the XRPLWin tracker indicates that the fixCleanup3_4_0 update is supported by 33 out of the 35 monitored trusted validators, representing a 94.29% approval rate; to meet the activation requirement, 29 affirmative votes are necessary. Activation is expected on November 4 at roughly 14:46 UTC, contingent upon the support level remaining above 80% for the duration of the two-week observation window.
Voting history indicates an initial majority existed from Oct. 9 until Oct. 21, at which point the amendment lost the necessary backing to continue its countdown before a new majority emerged on Oct. 21 that moved the projected activation into November.
According to XRPL's delegation guide, an account owner confers specific powers on another account via a DelegateSet transaction and may modify or cancel those permissions using a subsequent transaction of the identical type. Meanwhile, the tracker marks Nov. 4 as a conditional activation time instead of a finished upgrade, since falling to 80% support or lower would reset the waiting period.
According to XRPL's delegation guide, an account owner bestows specific powers on another account via a DelegateSet transaction, whereas essential authorities like altering cryptographic keys or issuing new permissions stay non-delegable. The architecture allows for distinct accounts handling routine tasks while keeping full-control keys offline, permitting each delegate up to 10 permissions within these limits. Documentation highlights stablecoin compliance as a primary application, such as validating users who have passed identity verification.
Further instructions in the guide state that granular permissions come predefined and lack customization for specific currencies. Meanwhile, stablecoin activity on the XRP Ledger has evolved, highlighted by Ripple's RLUSD Coinbase launch on Oct. 28 which served retail and institutional markets across the XRP Ledger, Ethereum, and Base networks. This rollout is presented in the guide alongside its PaymentBurn warning.
Ripple points to Standard Custody & Trust Company, a New York-regulated limited-purpose trust entity, as the issuer of RLUSD; this company's transparency documentation notes that reserves sit in segregated accounts and that monthly filings match circulating tokens against their underlying assets. The official amendment text also details fixes for Single Asset Vault operations regarding deposits, withdrawals, and clawbacks, aiming to stop scenarios where assets are delivered with rounding errors causing over or under delivery.
PaymentBurn Flaw Affects Issued Tokens Only
Reparations to trading pools handle instances where clawback values round down to zero alongside situations concerning the leftover balance of the last liquidity provider. Ripple had earlier supported native lending initiatives allowing single-asset vaults to fund fixed-term loans, and those specific proposals require a separate validator approval workflow.
The cleanup amendment stipulates that assessments for loan lateness, impairment, and default must occur only after the due date has strictly elapsed. Additionally, a modification permits the withdrawal of fixed vault shares to yield zero assets in instances where the vault is completely impaired, rather than causing the transaction to fail.