Ripple's confidential MPT transaction framework received three critical security hardening patches addressing invariant conservation gaps, amendment gating omissions, and arithmetic safety checks in ConfidentialMPTSend and ConfidentialMPTClawback.

> impact

Three security-critical fixes landed in the rippled confidential Multi-Purpose Token (MPT) subsystem, all targeting edge cases where the new confidential transaction types (ConfidentialMPTSend and ConfidentialMPTClawback) bypassed safety rails that protect every other MPT operation. The most significant change closes an invariant conservation gap: ConfidentialMPTSend had no post-execution check verifying that public balance fields (MPTAmount, OutstandingAmount) remained untouched, because it fell through both ValidMPTPayment (which skips confidential tx types) and ValidConfidentialMPToken (which only checks when coaDelta != 0, always false for Send). A second fix adds the missing checkExtraFeatures override to ConfidentialMPTSend, ensuring the sfCredentialIDs field is properly gated behind the featureCredentials amendment — without this, a timing mismatch between featureConfidentialTransfer and featureCredentials activation could allow credential-bearing transactions to slip through ungated, risking consensus divergence. The third fix adds an explicit preclaim guard in ConfidentialMPTClawback to verify the clawed amount does not exceed sfOutstandingAmount, preventing a potential uint64 underflow during doApply. These patches matter because invariant checks are the last line of defense in rippled's transaction engine — they fire after execution and halt the server if ledger corruption is detected. A missing invariant means silent corruption could persist across ledger closes. Similarly, amendment gating is a consensus-critical mechanism; bypassing it means different nodes could disagree on transaction validity depending on local feature flags. The unsigned integer underflow in clawback, while caught by the post-transaction invariant checker in theory, represents a defense-in-depth failure — preclaim should reject obviously invalid operations before state mutation begins. For developers building on or integrating confidential MPTs, these fixes ensure that the security model of confidential transfers matches the rigor of standard MPT payments. If you're running a validator or operating infrastructure that processes confidential MPT transactions, upgrading to a build containing these patches is strongly recommended to avoid edge-case invariant failures that could trigger server crashes or ledger divergence.

> Try this now

try this

# Walkthrough: The three confidential MPT hardening patches
# ============================================================

# --- FIX 1: Invariant conservation check for ConfidentialMPTSend ---
# File: src/libxrpl/tx/invariants/MPTInvariant.cpp
# In ValidConfidentialMPToken::finalize, the existing logic only
# checks conservation when coaDelta != 0. For ConfidentialMPTSend,
# coaDelta is always 0 — meaning NO invariant fires at all.

# Before (simplified):
# if (coaDelta != 0) {
#     // ... conservation checks ...
# }
# // ConfidentialMPTSend falls through with no check

# After — add an explicit branch for Send operations:
# if (tx.getTxnType() == ttCONFIDENTIAL_MPT_SEND && coaDelta == 0) {
#     // Public fields must not change during a confidential send
#     if (mptAmountDelta != 0) {
#         JLOG(j.fatal()) << "Invariant: MPTAmount changed during ConfidentialMPTSend";
#         return false;
#     }
#     if (outstandingDelta != 0) {
#         JLOG(j.fatal()) << "Invariant: OutstandingAmount changed during ConfidentialMPTSend";
#         return false;
#     }
# }

# Unit test (src/test/app/Invariant_test.cpp):
# Simulate a ConfidentialMPTSend, then manually mutate
# sfMPTAmount on the resulting SLE before invariant check.
# Expect the invariant to fire and the transaction to fail.
# env(confSend(alice, bob, mpt(100)), ter(tecINVARIANT_FAILED));


# --- FIX 2: checkExtraFeatures for sfCredentialIDs ---
# File: src/libxrpl/tx/transactors/token/ConfidentialMPTSend.h
# Add the override declaration:
# NotTEC checkExtraFeatures(PreclaimContext const& ctx) const override;

# File: src/libxrpl/tx/transactors/token/ConfidentialMPTSend.cpp
# Implement following the Payment/EscrowFinish pattern:
#
# NotTEC
# ConfidentialMPTSend::checkExtraFeatures(PreclaimContext const& ctx) const
# {
#     if (ctx.tx.isFieldPresent(sfCredentialIDs) &&
#         !ctx.view.rules().enabled(featureCredentials))
#     {
#         return temDISABLED;
#     }
#     return tesSUCCESS;
# }
#
# This ensures sfCredentialIDs is rejected if featureCredentials
# hasn't activated yet, even if featureConfidentialTransfer has.


# --- FIX 3: Preclaim bounds check in ConfidentialMPTClawback ---
# File: src/libxrpl/tx/transactors/token/ConfidentialMPTClawback.cpp
# Around line 89-91 in preclaim(), after validating vs COA:

# // Existing check:
# auto const clawAmount = ctx.tx[sfAmount].mpt().mpt();
# if (clawAmount > (*sleIssuance)[sfConfidentialOutstandingAmount])
#     return tecINSUFFICIENT_FUNDS;

# // NEW: Also validate against public OutstandingAmount
# // This prevents uint64 underflow in doApply (lines 159-161)
# // if COA and OA have diverged due to a separate bug.
# if (clawAmount > (*sleIssuance)[sfOutstandingAmount])
# {
#     JLOG(ctx.j.warn())
#         << "ConfidentialMPTClawback: clawAmount exceeds OutstandingAmount";
#     return tecINSUFFICIENT_FUNDS;
# }

# Unit test: Create an issuance where COA = 1000 but OA = 500
# (requires direct SLE manipulation in test harness).
# Attempt clawback of 750. Should fail at preclaim with
# tecINSUFFICIENT_FUNDS rather than wrapping OA to uint64_max.
# env(confClawback(issuer, holder, mpt(750)), ter(tecINSUFFICIENT_FUNDS));