Disallow Incoming Minimum

[Handy4ndy]

Title: Disallow Incoming Minimum 

Revision: 2 ( 2025/07/22 )

Type: Draft 

Author: Andrew Spencer @handy_4ndy

Abstract

This proposal introduces a new flag, lsfDisallowIncomingMinimum, to the XRP Ledger’s AccountRoot object, enabling accounts to enforce a dynamic minimum XRP amount for incoming payments, set to the current base fee (ctx.view.fees().base, in drops). Developed during the XRPL Commons Core Developer Bootcamp ( 2025/07/11 ), this amendment combats dusting attacks, with confirmed data showing 90,000 transactions in 24 hours from a single spam account. The implementation is complete, tested, and ready for community review, addressing privacy and compliance risks.

Motivation

Spam transactions, particularly dusting attacks, are a critical issue on the XRP Ledger, with confirmed data highlighting:

• 90,000 transactions in 24 hours from one spam account.
• 22,347 daily dusting transactions on average.

With regulatory clarity on the horizon (e.g., global cryptoasset frameworks), spam poses compliance risks, including anti-money laundering (AML) challenges and data retention obligations. This proposal, inspired by XLS-76d Proposal, introduces a dynamic minimum tied to the base fee, requiring no user configuration, that has been developed during the bootcamp to deter spam effectively.

Specification

• New Flag: lsfDisallowIncomingMinimum, added to the AccountRoot object, toggleable via the AccountSet transaction.

• Behavior: When enabled, incoming XRP payments must exceed the current base fee. Payments below this threshold are rejected with a tecNO_PERMISSION error. (Note: The original proposal suggested twice the base fee, but the implemented code uses the base fee for simplicity, with potential adjustment post-review.)

• Implementation: Modify the preclaim function in Payment.cpp to check for lsfDisallowIncomingMinimum and enforce the minimum:

  if (sleDst && (sleDst->getFlags() & lsfDisallowIncomingMinimum) &&
      dstAmount.native() && dstAmount.xrp() <= ctx.view.fees().base)
  {
      XRPAmount const minAmount = ctx.view.fees().base;
      JLOG(ctx.j.trace())
          << "Payment blocked: DisallowIncomingMinimum flag requires minimum "
          << "payment of " << minAmount << " but payment is "
          << dstAmount.xrp();
      return tecNO_PERMISSION;
  }

• Transaction Example:

  • Enable: {"TransactionType": "AccountSet", "Account": "rExampleAccountID", "SetFlag": 18} (using asfDisallowIncomingMinimum = 18 from TxFlags.h).
  • Disable: {"TransactionType": "AccountSet", "Account": "rExampleAccountID", "ClearFlag": 18}.

• Error Code: Define tecNO_PERMISSION as the transaction error code to indicate rejection due to insufficient payment.

Rationale

This proposal builds on XLS-76d Proposal, which allows user-defined minimums, by introducing a dynamic minimum tied to the base fee, ensuring adaptability to network conditions. The urgency is driven by the 90,000-transaction spam event and regulatory pressures, as spam complicates AML compliance and ledger integrity. Unlike XLS-76d, lsfDisallowIncomingMinimum requires no configuration, making it accessible. Developed during the XRPL Commons Core Developer Bootcamp, it leverages community expertise for implementation and testing.

Backward Compatibility

The lsfDisallowIncomingMinimum flag is optional and does not affect accounts without it set.

Test Cases

• Case 1: Account with lsfDisallowIncomingMinimum enabled receives 9 drops when base fee is 10 drops. Result: Payment rejected (tecNO_PERMISSION).
• Case 2: Account with lsfDisallowIncomingMinimum enabled receives 11 drops when base fee is 10 drops. Result: Payment accepted.
• Case 3: Account without lsfDisallowIncomingMinimum receives 5 drops. Result: Payment accepted.
• Case 4: SetRegularKey and Escrow transactions succeed despite the flag.

Security and Compliance Considerations

• Spam Mitigation: Prevents dusting attacks by rejecting small transactions, reducing the 90,000-transaction spam case and 22,347 daily events, easing ledger clutter and privacy risks.
• Regulatory Compliance: Addresses AML and data retention concerns by minimizing unauthorized transactions, critical with regulatory clarity approaching.
• Edge Cases (aligned with XLS-76d concerns):
  • Partial Payments: Ensure compatibility, rejecting only if the delivered amount is below the minimum.
  • Account Reserves: Verify payments to low-balance accounts near the reserve are not unduly blocked.
  • Misuse: The base fee minimum reduces overly restrictive thresholds, unlike static highs in XLS-76d.
• Performance: Minimal impact, as the check occurs during preclaim, leveraging existing validation logic.

Acknowledgments

This proposal is heavily inspired by XLS-76d Proposal by Chris Dangerfield, introducing the minimum incoming amount concept. The dynamic approach builds on its foundation, addressing partial payments, reserves, and misuse while offering adaptability. Implementation and testing are led by Andrew Spencer @Handy4ndy during the XRPL Commons Core Developer Bootcamp, with @dangell7.

Sources

• Bithomp: https://bithomp.com/en/whales/submitters (90,000 transactions in 24 hours).
• XRPLWin: https://x.com/XRPLWin/status/1947077257069007324 (22,347 daily dusting transactions).
• X Discussion: https://x.com/Handy_4ndy/status/1946715198770811044

[Handy4ndy]

##Revision 2 - Disallow Incoming Minimum

Renamed from Dynamic Minimum Amount to Disallow Incoming Minimum.

The title and flag names have been changed to match naming convention's and provide more clarity of it's intended use case. The proposed flag is now asfDisallowIncomingMinimum matching asfDisallowIncomingNFTokenOffer, asfDisallowIncomingCheck asfDisallowIncomingPayChan and asfDisallowIncomingTrustline.

Change to the minimum amount.

Reduced the incoming minimum amount to equal the base fee. Although a multiplayer on the base fee would amplify the impact on rejecting small transactions, this could be deemed excessive in a number of years time. As the base fee can be voted on by validators on the UNL there remains an element of flexibility in the future without the need for an amendment.

Sources Added.

Incorporated up-to-date information provided by community members, with source links to daily monitoring and a community discussion.

Removed XRPL Commons Affiliation and Boot camp participants.

Advised to remove Affiliation to prevent any misconceptions, moved to acknowledgements.