Ripple CTO David Schwartz breaks down XRP fee spikes on XRPL as transaction load nears 200 TPS capacity, triggering validator fee escalation and node stress.
The XRP Ledger is under pressure. Transaction volumes are pushing toward levels rarely seen in the network’s history, and fees are behaving in ways that caught many users off guard this week.
X user Vet_X0 flagged the development first, posting that sustained activity above 200 transactions per ledger has only happened a handful of times across XRPL’s entire history. The network is approaching that threshold again.
Only a few times in history of XRP did we had sustained > 200 transactions per ledger.
We getting there again. 🌊 pic.twitter.com/OKCZFcg6v3
— Vet (@Vet_X0) March 24, 2026
Source: Vet_X0
When Demand Breaks the Normal Fee Floor
Then ScamDetective5 noted on X that load factors spiked the previous night. Fee escalation hit. Many nodes went into an overloaded state. That is when Ripple CTO David Schwartz, known on X as JoelKatz, stepped in with a detailed breakdown.
The core mechanics, according to JoelKatz on X, work like this. If the network receives even one more transaction per second than it can clear, fees do not just rise slightly. They rise to whatever level filters demand down to a manageable rate. A network capped at 200 TPS will charge whatever fee keeps only 200 transactions per second willing to pay. The ceiling is, in theory, unlimited.
This is not a bug. It is the design. The XRPL fee escalation mechanism acts as a self-correcting throttle when demand outpaces capacity.
Validators Hold the Keys to the Clearing Rate
Schwartz also explained who actually decides when fee escalation starts. It is not Ripple. It is not a protocol constant. Validators negotiate it.
Each validator independently calculates how many transactions it can reliably fit in a ledger, based on what recent ledgers actually looked like. Schwartz described an exponential fee curve that kicks in above that estimated ceiling. The cutoff the network actually uses comes from, roughly, the median of what validators agree on.
ScamDetective5 followed up on X asking specifically how that calculation works. Schwartz went deeper.
If the last few ledgers each had around 200 transactions and consensus is running smoothly, validators will generally start pushing fees above the minimum only beyond that 200 mark. But if consensus rounds start dragging, say, taking 12 seconds instead of the usual few, all validators see it. They respond by sliding their threshold down, tightening the fee curve sooner.
Node Health Is a Separate Problem Entirely
There is another layer here that the CTO wanted to make clear. Fee escalation and node overload are not always the same event.
As Schwartz explained in a follow-up post on X, a server that is barely keeping pace under normal load could fall behind even if fees never escalate at all. If TPS doubles, that node struggles regardless. So how validators are provisioned matters. Kick in fee escalation too early, and the network runs below its real capacity for no reason. Wait too long, and a transaction flood takes out underpowered nodes before fees ever correct the demand.
The algorithm handles valid but unprocessed transactions through a queue, ordered by fee size and arrival time. Ledger slots fill until the first transaction is unwilling to pay the going rate. Then, validators vote individually on what gets included. Typically, the majority rule decides.
This broader pattern of rising XRPL network activity and infrastructure demands on validators has been building for months, with Schwartz himself previously flagging plans to strengthen node infrastructure to support the growing load.
The timing also matters. Getting the fee curve calibrated correctly means the difference between a network that scales and one that sheds nodes every time activity spikes.
This article is for informational purposes only and does not constitute financial or investment advice. The content reflects publicly available information and on-chain observations.
