Transaction fee threshold

[wojake]

Summary

Normally, when the network overloads in terms of transactions/traffic, the minimum transaction fee will rise to limit the load.

Creating a minimum transaction fee threshold could be a safety measure to ensure the network is stable and somewhat affordable during peak hours in the XRP Ledger.

Minimum transaction fee threshold is a limit where the minimum transaction fee in the XRP Ledger is capped off to control and manage the cost of utilizing the XRP Ledger, this will allow users of the XRP Ledger to continue utilizing the speed and stability of the network without needing to pay an extravagant amount of XRP when the network experiences abnormal amounts of traffic during peak hours.

Validators will propose their respective minimum transaction fee threshold periodically (e.g: 100 drops), there should be a way for them to calculate their respective proposal, this will allow the validators to agree on a general threshold.

When the network experiences regular traffic, the transaction fee threshold must not be met. In case the threshold is met when the network is experiencing regular traffic, the threshold is either too low or there is a sudden increase of users which is causing the minimum transaction fee rise, this should result in the validators agreeing on a higher threshold.

The threshold should normally be met when the network is experiencing abnormal traffic during peak hours, if the threshold is met for a long period of time in this scenario, the validators should agree on a higher threshold as usual.

If the threshold has not been touched and the minimum transaction fee maintains a reasonable gap between the threshold in a fixed period of time (I propose it being 256 ledgers, flag ledger), validators may propose to reduce the threshold to limit excessive rise of transaction fees in the future.

[wojake]

1. 2. 3.

[intelliot]

Ae you describing the reference_fee parameter that validators vote on as part of Fee Voting?

[wojake]

Ae you describing the reference_fee parameter that validators vote on as part of Fee Voting?

Yes.

[MarkusTeufelberger]

Is the y axis inverted or are you actually talking about a maximum fee? This would just slow down the response time to attacks that cause the fee to spike for whatever reason (legitimate or not). Which problem would be solved by this and what are the risks involved?

[ximinez]

somewhat affordable during peak hours in the XRP Ledger.

There are actually a couple of different types of fee scaling that happen on the XRPL.

1. The first is more a measurement of how busy individual servers are and how busy the validators on the UNL are as a whole. In the server_info response, this is the load_factor_server value. Even under heavy load, AFAIK, this does not usually go above 10 on the UNL validators.* (So a minimum fee of 100 drops.) Most importantly, though, if this does go high on the UNL validators, then the ledger does not care about affordability - it is trying to keep making forward progress, and it's doing that by (amongst other things) discouraging or slowing transaction submission.
2. My hunch is that the second type is what you're thinking about. This is the fee escalation that you can think of as a measurement of how busy the ledger is as a whole. It is intentionally designed to rise quickly and drastically when transaction submission peaks, because there's no way to tell the difference between a usage spike and an attack, and waiting for a full round of consensus for the validators to respond takes long enough that the attacker can easily work around it. This is generally what you're seeing when the fee goes above 5000 drops, and is the load_factor_fee_escalation value in the server_info response. What isn't as obvious is that no matter how high that value gets, you can almost always still submit a transaction for the minimum fee from the "1" above and have your transaction succeed. It will just take a little longer because it gets queued until the load goes back down - which usually only means 1 or 2 extra ledgers. The higher, 5000+ drops, fee can be thought of as a premium to get a transaction processed more quickly during peak times.

All of which is a long way to say that I believe that the fees are affordable in all but the most extreme of conditions - conditions which I've never seen, and in which we would not want fees to stay affordable. It's just a matter of deciding on how long you're willing to wait for a transaction to succeed, and how much you're willing to pay for it to succeed quickly.

There is a lot more detail about all of this on the "Transaction Cost" page.

* It can go higher on public client servers, e.g. s1.ripple.com, but that is a consequence of using publicly shared resources and have little to do with the health of the network as a whole. If that is a problem, I strongly suggest running your own private server and submitting transactions to it.

[wojake]

Is the y axis inverted or are you actually talking about a maximum fee? This would just slow down the response time to attacks that cause the fee to spike for whatever reason (legitimate or not). Which problem would be solved by this and what are the risks involved?

Well, the chart was just there to explain the basic concept of the feature and no, I am not talking about a maximum fee;

This feature would create a temporary maximum reference fee(Fee Voting) in a sense, the threshold can be voted to rise or fall by the participating validators based on a few variables like:

1. network load
2. local node's load/queue
3. rate of transactions being proposed to be included in a new ledger

Just to name a few, I really have no idea how this equation/protocol should be structured.

In a situation where the threshold is met when the network is experiencing abnormal amount of high traffic, users that pay the bare minimum amount of transaction fee will be queued on the local node, users could increase their transaction fee to get faster settlement time for their transactions since they'll be prioritize in the local node's queuing system.

Risk/Issue

So, users could still increase their transaction fee based on their preferences but this is not efficient since users that pay the bare minimum amount of transaction fee will end up with their transactions queued and this goes on and on until a lot of transactions are pilled up, queuing which will result in an absurdly bad transaction settlement time. If we could resolve this specific issue, I don't think there will be any other major problems. I'll try my best to come up with an idea to mitigate this problem.

Benefits

One of the benefits that this feature would facilitate is control over transaction cost and network stability: This feature would be a safety measure for extreme cases to control the minimum transaction fee during high demand of transaction settlement, although I wouldn't really say this feature is efficient compared to other security measures placed to control fees & the network load as @ximinez said.

After thinking about how this feature could be "useful" compared to the other safety measures placed, this feature could simply control shockingly high amounts of traffic during peak hours by capping the minimum transaction fee to control the cost and availability of the XRP ledger to process & finalize financial transactions, yes, this would 'delay' the end user's transaction finality but it would allow your average Joe to send payments without paying a hefty amount of fee.

The XRP Ledger was meant to facilitate 7.9 Billion people's finances, so implementing this feature is necessary for extreme cases.