Proposal to Address Memo Bloat on the XRP Ledger

[xrpl365]

Title:       Proposal to Address Memo Bloat on the XRP Ledger
Type:        Draft
Revision:    1
Author:      Chris Dangerfield @xrpl365

Abstract

The goal of this paper is to start a discussion around introducing a mechanism that respects and preserves what I consider the legitimate use of memos while discouraging patterns that result in what many refer to as ledger bloat.
The desired outcome is a fee model that reflects the true cost of memo usage without compromising the flexibility and openness of the XRP Ledger.

Defining the Intended Use of Memos on the XRP Ledger

A Memo field in an XRP Ledger transaction is described in the official documentation as “additional arbitrary information used to identify this transaction.”From this, we can infer that memos are intended to provide context or metadata about a transaction, not to serve as the reason or payload of the transaction itself.

The memo should support a meaningful transaction, not justify its existence.

In other words, the presence of a memo should enhance the utility, traceability, or interpretability of a transaction, such as a payment.
Transactions where the memo is the only meaningful component (e.g., zero-value payments with arbitrary or excessive data) fall outside the definition of intended use and place unnecessary strain on ledger storage.

Why Ledger Bloat from Memo Spam is a Problem Worth Addressing

While the concept of "ledger bloat" can be subjective, the consequences are tangible and measurable for operators running full-history servers.

Memos are permanently stored as part of the transaction record.
When transactions are used primarily to carry large or meaningless memos, especially in high volume, this directly contributes to the growth of the ledger’s historical footprint.

The current fee model — where memo size has no meaningful impact on transaction cost, does not scale with the real-world infrastructure impact.
As storage costs rise and ledger use increases, this creates a sustainability issue. Memo-based spam, even at low volume, has an asymmetric effect on the network: it is cheap to send, but expensive to store forever.

What Constitutes Memo-Based Ledger Bloat

In my opinion, it is where the memo is used to store data that does not add value to the transaction and simply is the primary reason for the transaction.
The main culprit of this is where the memo is used primarily as a messaging mechanism.

While memos can be included in any transaction type, not all transactions equally expose a messaging surface.
I refer to these as Message-Addressable Transactions (MATs): transactions that include a Destination field or otherwise directly reference another identifiable account.

Examples of MATs include:

• Payment (with Destination)
• NFTokenCreateOffer (specifying an Owner)
• CheckCreate, EscrowCreate, etc. (with destination fields)

This is not an exhaustive list. If this idea is progressed, I propose a full evaluation of all transaction types.

When Does a MAT Become Ledger Spam?

• When the value of the transaction is negligible and accompanied by a memo field.
• When an account has sent more than X similar messages during a period of Y.

Should All Memos Incur Additional Costs?

I have been back and forth on this one but I lean more towards no, if a solution to memo spam can be found without introducing a new cost.
We already have fees to pay for network usage, and these fees don’t fundamentally discriminate between transaction types that store more data than others.

That said, I remain fundamentally open to both sides of that argument.
This proposal proceeds on the basis that we should not introduce a cost for using a memo unless it falls into the criteria of unwanted spam.

Proposed Mitigation Strategy

I propose a mechanism that introduces increased costs for memos on MATs that meet my definition of ledger spam, with further escalation of the cost based on usage.
The cost should start very small and escalate to achieve the goal of the proposal.

Examples of Memo Costs

• An AccountSet transaction is not a MAT, so the network fee itself should be sufficient.
• A Payment of 100 XRP to another account with a memo is a MAT but would not be considered spam, as the transaction amount itself provides a disincentive to abuse.
• A Payment of 10 drops to another account with a memo would be considered spam and should incur an increased fee.

This fee could be dynamic, scaled by a simple rate-limiting rule e.g., no more than X similar transactions within Y time frame.
This ensures that a more genuine one-off message can still occur (even at higher cost), while an account sending 10,000 messages would find the cost prohibitive.

Handling Edge Cases & Legitimate Exceptions

What about users who want to store immutable data on-chain?
Currently, memos are the mechanism used and by my definition, these transactions are considered spam.

I would first question if XRPL is the best place for that kind of storage.
If it is, then we should design a specific transaction type for that use case and engineer it to provide the properties users want, rather than bending an existing mechanism.

We should assign a specific fee based on the value of that use case. This could also evolve to support both:

• Storage of immutable data on-chain
• Pointers to off-chain data, secured by hash

This is outside the scope of this discussion but worthy of a separate proposal.

Technical Implementation Outline

Add a series of logic checks for MAT transactions. Using Payment as an example:

If (Amount + Fee > Threshold)
    → allow transaction (normal fee)
Else if (SpamCounter < Limit)
    → increment counter
    → apply base memoSpam fee
Else
    → increment counter
    → apply escalated memoSpam fee

Each transaction identified as a MAT would require an update based on the principles of identifying the transaction as spam.

I believe this is implementable and would result in reduced ledger bloat, so when weighed against any computational over-head for the changes, seems a worthwhile conversation. There are also secondary benefits to this, such as recognising the fact that memos are used as a mechanism to scam people by embedding malicious links.

[desimmons]

I wonder if the presence of a threshold means the system could be gamed. Could the fee be proportional to:

(Size of memo) / (Size of transaction)?

[xrpl365]

It could and in fact Xahau has this now, but I don't favour charging for a memo that meets the definition of what a memo is meant to be used for, that's what network fee is for.

I believe an escalation of fee is only needed when the memo is no longer supporting the transaction and is in fact the entire reason for the transaction to exist.

[ximinez]

Ledger spam is an evergreen topic, but this looks to me like a pretty novel way of handling it.

You didn't specify, so I'll mention that it will be completely unworkable if it is made part of the consensus process. Consensus needs to be entirely deterministic based only on the state of the previous ledger and proposed transaction sets.

However, I think it could work well if it's a local node decision, the same way that fee escalation is local. Another advantage of making it a local decision is that it wouldn't necessarily require an amendment. It's just a node deciding whether or not to accept and relay a transaction, just as it would if it got overloaded.

A per-account threshold could easily be gamed. So keep the count across the whole ledger. If ledger spam stays below some acceptable "background noise" level, then there's no problem, but if anyone starts getting out of control, they ruin it for everybody.

[xrpl365]

One such idea is an account setting that simply allows the owner to reject memos; set default to on and you instantly prevent what I called MAT tx, if people want to receive messages, they turn the feature on. It's more aggressive but does solve the issue in a different way. This idea came from a convo with fomo.

This doesn't solve the FH issue because those memos will still be included in the ledger as a part of a failed transaction.

I think the idea was to drop the memo so it is not part of the tx. The tx doesn't fail, just the memo is dropped or at least is how I understood it.

Another idea is to just move all the memo data to a side-chain where we can have a dedicated MessageCreate function. We can then add extra features such as TTL for the message to help with compliance, and could go further with other features. Let's make a real messaging layer not force that square peg into the round hole.

I don't see how this solves either problem because why would spammers go over there to send their messages when it's easier and they get more reach on the XRPL?
It won't solve the problem in isolation but employing a solution of preventing them or make it super expensive, whilst providing a viable alternative incentivises them to use it. As for reach, it would reach the same accounts, so as long as the sidechain was adopted users would still get the message, however it wouldn't be a memo being used to bend the rules of the system, it would be a dedicated function designed for messaging with features that can benefit everyone. It's ultimately a better solution than today and then means a proposal like mine is less likely to brick up a genuine edge case. The sidechain aspect means we could really design a proper solution, I like it, the only downside is there is no way to monetise so it means there is no motivation for anyone to build and run it.

[ximinez]

I don't see how local escalation solves the problem as a spammer can just run their own infra and broadcast into the network.

Every node makes a local decision whether or not to process and broadcast a transaction. Even if a spammer runs their own infra, as soon as those transactions hit an honest node, they die.

It's similar to what happens with fee escalation and queued transactions. It is very easy to set up a node where you can submit 1000s of transactions without worrying about the fees. And those transactions will go into that open ledger, and get relayed. The nodes they relay too will escalate fees like normal, and queue those transactions instead of sending them further, or drop them if there are too many.

In some ways, it would be better if spammers ran their own infra, because at least they'd start bearing some of the costs they're imposing on everyone else.

If the account based limits are breached, you just get another account, well that means another reserve which in of itself is a deterrent. My limit would be maybe 10, not 1000, so that's a lot of accounts needed. Also the timeout doesn't have to be minutes, it can be hours or even days or longer.

This it true, but allowing the spammer to create a new account to bypass the limits creates two new problems:

1. Now you've traded memo spam (which only affects FH servers) for account spam (which affects all servers).
2. The new account is going to be able to send more memo spam.

Creating an account is relatively cheap, 1 XRP, which is about 2.40 USD right now. It's a deterrent, but if you're making enough money sending spam and running scams, it's not much of a derrent. I'd expect that that some of the spammers will create as many accounts as they need, and then rotate through them, staying just under the limits for each account. I'd also expect that some enterprising folks will start services where they sell the ability to send spam from their massive pool of accounts, just like they do with email spam now.

Going back to fee escalation, it doesn't decide "Ok, alice sent 100 transactions, so her fee is 5000, but bob only sent 2, so his fee is 10". It looks at all the transactions, and raises the open ledger fee for everybody.

My approach is in my opinion quite soft, I'm trying to not brick up genuine usecases but make a tangible difference.

Same.

That said this conversation has prompted a few other cool ideas I'd like to see explored. On such idea is an account setting that simply allows the owner to reject memos; set default to on and you instantly prevent what I called MAT tx, if people want to receive messages, they turn the feature on. It's more aggressive but does solve the issue in a different way. This idea came from a convo with fomo.

This is an interesting idea, but may be too limiting, since as you said, there are a lot of legitimate use cases for using memos, including compliance and legal requirements.

[ximinez]

I think the idea was to drop the memo so it is not part of the tx. The tx doesn't fail, just the memo is dropped or at least is how I understood it.

Dropping the memo invalidates the signature. That causes all kinds of problems, especially for auditing and replay purposes.

There was an idea a long while back about adding a MemoHash field that would be signed instead of the memo data, thus allowing memo data to be stored separately, and purged when desired. I don't remember all the objections, but one was that in many cases, the size of the hash was larger than the size of the memo data, thus making the problem worse. I mention this not to resurrect the idea, but perhaps someone with more knowledge of ZKP could suggest a way to store a proof in less space than the memo that proves that the transaction hash is valid without needing the memo.

[xrpl365]

This is an interesting idea, but may be too limiting, since as you said, there are a lot of legitimate use cases for using memos, including compliance and legal requirements.

It started out as a thought process and I've enjoyed the several engaging conversations that have followed, whether some part of this is able to be beneficial in future maybe, but I'm still keen to know if you see memo spam as a problem we need to solve or if it's just an annoyance we have to just live with, but maybe the question itself is flawed cus it only affects a handful of operators, unless we ever reach the point where it deters them at which point we have a much more serious problem.

[ximinez]

It started out as a thought process and I've enjoyed the several engaging conversations that have followed, whether some part of this is able to be beneficial in future maybe, but I'm still keen to know if you see memo spam as a problem we need to solve or if it's just an annoyance we have to just live with, but maybe the question itself is flawed cus it only affects a handful of operators, unless we ever reach the point where it deters them at which point we have a much more serious problem.

Oh yeah. It's absolutely a problem.

[ximinez]

• When the value of the transaction is negligible and accompanied by a memo field.

Another thing that I realize is that we're going to need a precise definition of "negligible" that

• accounts for XRP, IOUs, and MPTs.
• has no internal concept of the value of a currency.
• can be made without running the transaction or payment engine.
• preferably can be made without loading anything from the ledger.

That's not an easy decision, because while I would consider 0.001 USD annoying spam, I'd consider 0.001 BTC a lovely gift, but rippled has no idea what "USD" or "BTC" actually mean.

[shortthefomo]

There were quite a few interesting ideas. I Don't think @xrpl365 has listed them all so ill do so here, from the conversations i've herd.

one limitation @ximinez did mention is that the memo is part of the checksum currently. However this could be altered and removed that enables a few of these options.

1. add flag to account object and default accept memo to off. Becomes much like a trustline where use has to opt in.
2. simply don't store the memos on FH nodes, only persist them as long as the other nodes keep them around and they can only be fetched from those nodes.
3. remove the memo totally and force off ledger communication, @dangell7 even has a example network that facilitates just memos.
4. transform the memo to pointers where by the actual memo is kept off ledger and only a URI can be specified.

those are the main ideas I've herd so far.

[mvadari]

IMO adding a MemoHash field would make the problem worse, not better. Most memos (e.g. "this transaction is from XYZ.com") are shorter than 256 bytes as-is, and adding a MemoHash field would mean that those memos now take up 256 bytes. I don't have any data on this though.

[shortthefomo]

option 1 - does not require the memos be removed from the hash.
however that option is more restrictive, as then not every transaction can contain a memo unless the user has opted into allow them.

option 3 - would be totally stripping them from the tx.

[mvadari]

1. Doesn't solve the FH problem, you need a tec error if you're checking the ledger state.
2. Discussed above
3. Let's not cut off our nose to spite our face. Memos are very useful when used properly, on legitimate transactions.
4. That doesn't really solve the problem - if you're enforcing memos to be a valid URI, you could still do this: http://example.com/this_is_a_valid_url_and_also_a_really_long_message_and_i_can_keep_going.html. And if you're going to restrict the length to prevent that sort of thing, you may as well just restrict the length and not force people to only use that field for URIs.

[shortthefomo]

1. still does solve for it going forward, you would return a tec correct.

[mvadari]

tec error transactions are still stored by FH.