Stellar’s 217.4 TPS Record Is Real. The Window Is a Choice.

On September 28, 2026, U.Today published an article by Gamza Khanzadaev with a headline that Stellar (XLM) had broken its all-time transaction speed record, as the original piece reports. The number came from Chainspect: a peak of 217.4 transactions per second measured over a 100-block window. The previous record, approximately 211 TPS, had stood for less than two weeks. The article attributed the surge to institutional money arriving on the network and drew a line between that and synthetic load. Its framing, in its own words:

The surge in throughput was driven by a real influx of institutional capital, rather than artificial stress tests.

U.Today, September 28, 2026

I read the headline and did not believe the definition. Not the number, which is almost certainly transcribed correctly. The definition. A peak is a maximum, and a maximum is only as meaningful as the window underneath it. And “transactions per second” is not one quantity on Stellar: settled transactions, submitted transactions, and the operations inside them differ by more than a factor of two. So I opened Stellar’s public Horizon API the next morning and measured. This is the log, including the parts I could not reproduce.

Both numbers are true, and they are not the same quantity.

Start with the verdict, because it is short. Chainspect is most likely reporting a real peak on a real day. My number, taken about twelve hours later, is also real. They differ by a factor of four because they answer different questions, and only one of them is the question a reader of that headline thinks is being answered.

The headline answers a different question than mine. It asks for the highest rate of transaction inclusion this chain can show on its best five-second window. I ask what the chain is doing while you watch. Those are not rivals. One is a sprint time; the other is the plant’s daily output. A steel mill can pour a record heat on Tuesday and still ship a modest month. Printing the record heat as the monthly rate is a choice, and the choice favors the larger number.

Stellar closes a ledger every five seconds. That cadence is not an emergent property; it is a protocol schedule. The ceiling is structural: whatever the chain accepts in five seconds, times twelve, is the sustained rate. A peak over a hundred ledgers is a window slid backward until it finds the fullest five seconds, and the record is those five seconds dressed as a rate.

What my 200 ledgers actually contained.

I pulled 200 consecutive ledgers from the public Horizon endpoint on 2026-09-29, covering 995 seconds of wall clock between 02:31 and 02:47 UTC. Because the chain closes a ledger every five seconds, 200 ledgers over 995 seconds means 199 close intervals. Inside the window the API reported 50,693 successful transactions and 17,029 failed ones. The failure rate is 25.1 percent, and it is not an artifact of one bad day; I will return to it.

Convert to rates and the picture flattens. Settled throughput is 50.9 transactions per second. Count every transaction admitted to a ledger, accepted or rejected, and you get 68.3. Count operations rather than transactions, because a path payment can carry several, and you get 92.8. The average ledger holds 321 submitted transactions and settles 249. The ledgers close every 5.000 seconds, metronomically: 995 seconds across 199 intervals. The network runs protocol version 28.

The hottest single ledger was sequence 64672854. It carried 966 transactions inside one five-second slot, which is 193.2 transactions per second if you count everything that entered, and only 272 of those 966 settled. Settled, that ledger is 54.4 transactions per second. So the best five seconds I caught, counted generously, still lands far under the headline; counted honestly, it lands at 54.

I want to be exact about what this is not. My sample is 200 ledgers, about sixteen and a half minutes, on September 29. It is not Chainspect’s window and it is not the record day. A genuine burst on another day could be higher than anything here, and I hold no data that contradicts 217.4 on its own terms. I will not pretend I reproduced a number I did not.

How many definitions does a throughput claim have?

A peak over a window is a free parameter, and a free parameter will be tuned. To show how much, I recomputed the peak from a 200-ledger sample taken the same morning, sliding several window sizes across it and taking the maximum, two ways: counting only successful transactions, and counting every submitted one. Both readings rise as the window narrows, because a narrow window can sit on the single best burst. The 100 blocks setting behind the headline is on the slow end of that curve.

Read the first and last rows together. On the settled count the peak falls from 82.6 to 54.4 as the window widens from five blocks to a hundred. On the submitted count it falls from 168.4 to 70.3. The spread is more than a factor of three, and nothing about the chain changed between those rows; only the window did. This is why a peak with a free window is not a throughput claim. It is a window setting wearing the costume of one. From the same sixteen minutes I can hand you a legitimate number anywhere between 54 and 168.

The method, so anyone can rerun it:

1. Pull the ledgers endpoint from Stellar’s public Horizon API for recent ledgers.
2. Take 200 consecutive ledgers so the sample is contiguous and close intervals line up.
3. Sum the successful and failed counts the API returns for each ledger.
4. Divide by the measured wall-clock span between the first and last close, not the nominal count.
5. Recompute the peak for several window sizes and both counting rules, and report the window next to the number.

The hundred days that actually moved.

The record headline is noise. Underneath it there is a signal, and the signal is worth reporting. I ran the same measurement, same method, same API, at five points across a hundred days, each sample 200 consecutive ledgers taken at that moment.

Two things move and one does not. Settled throughput more than doubled in a hundred days, from 23.4 to 50.9 transactions per second. The close interval tightened from about 5.7 seconds to exactly 5.000 seconds and stayed there. The failure rate swings between 11 and 51 percent with no trend: 50.7, 11.3, 33.4, 25.6, 25.1. If the headline were about capital arriving, that wandering failure rate should worry somebody.

Close time is the part I trust most, because it is an agreed schedule rather than a hope. The protocol does not race to close a ledger; it votes on what goes into the next one. Stellar’s documentation on ledgers describes the loop:

In every Stellar Consensus Protocol round, the network reaches consensus on which transaction set to apply to the last closed ledger, and when the new set is applied, a new “last closed ledger” is defined.

Stellar developer documentation, Ledgers

The schedule is where the engineering lives, and a consensus-layer swap shows up in close time before it shows up anywhere else. Moving from 5.7 seconds to 5.000 seconds is the removal of jitter, and jitter is what makes settlement expensive downstream. A network that lands a ledger at 5.000 seconds across a hundred days has fixed its membership, its agreement, and its scheduling.

These failures are arbitrage bots losing a race, not mistyped addresses.

A quarter of everything entering Stellar fails, and if you stop there you will assume users are mistyping addresses. I decoded the result XDR of 546 failed transactions from four recent ledgers. Of those, 119 were fee-bump wrappers whose inner transaction had failed, and because the inner operation is invisible in the outer result I set them aside rather than guess. That leaves 427 failures I can attribute, and the answer is not typos. It is slippage. A path payment is a first-class operation: one operation that converts value through several assets and delivers a guaranteed amount.

Here is the breakdown. 196 of the failures were PATH_PAYMENT_STRICT_RECEIVE operations returning result code -12, or OVER_SENDMAX: the path payment would have sent more than the sender allowed, so it refused to trade. 176 were PATH_PAYMENT_STRICT_SEND returning -12, or UNDER_DESTMIN: the recipient would have received less than the sender demanded. That leaves 19 MANAGE_BUY_OFFER at -11 (OFFER_CROSS_SELF), 12 PATH_PAYMENT_STRICT_SEND at -2 (UNDERFUNDED), 7 MANAGE_SELL_OFFER at -11, 5 MANAGE_SELL_OFFER at -7, and a handful of payments and claimable balances.

Add it up. Roughly 87 percent of the attributable failures are path payments whose slippage bound was breached. The price moved between the quote and the execution, the operation refused to trade, and the transaction paid its fee anyway. These are not people mistyping a destination. They are arbitrage and market-making bots losing a race they entered on purpose, and being charged for the loss.

One ledger makes the population visible. The API returned 200 transactions from it: 47 succeeded, 153 failed. The 153 came from 100 distinct fee-paying accounts. The busiest single account appeared 23 times inside one five-second ledger; the next busiest appeared 20 times. A hundred accounts, one ledger, five seconds. That is a crowd of software agents bidding for space, not one attacker.

Count the traffic that pays and walks away.

Forget the peak; look at the ratio. Of everything that entered a Stellar ledger in my window, one in four did not settle. The transaction was included, it consumed a slot, it paid a fee, and it produced nothing. Settled throughput was 50.9 per second; submitted throughput was 68.3. The gap, 17.4 transactions per second, is work the chain did and threw away, paid for by the sender.

Stellar is not a free-for-all. Space in a ledger is scarce and it is sold by auction: you bid a maximum fee, the network admits the highest bids, and the losers retry. What my window shows is what the auction actually allocates. It spends a quarter of every ledger’s capacity on transactions built to abandon themselves. The chain is not congested by users. It is selling slots to bots that bid and then decline to trade.

That ceiling is not fixed forever, and other ledgers have moved it mid-flight: a ledger switching a feature back on changes how many operations fit in a slot. I had no such sample on Stellar on either side of a change, so I will not attach a number to it.

The two numbers a payment chain should advertise.

Now the bill. Rejected transactions are not free; they still pay, because the fee is charged on inclusion, not success. In that same ledger’s first 200 transactions, split by outcome: the failed ones paid 4,260,213 stroops, or 0.426 XLM, while the successful ones paid 1,140,057 stroops, or 0.114 XLM. The traffic that did nothing paid almost four times as much as the traffic that worked.

The bids explain why. In one ledger the average max_fee on failed transactions was 12,529,390 stroops, about 1.25 XLM, roughly 125,000 times the 100-stroop base fee. A single sampled failed transaction bid 100,159 stroops and was charged 20,001. Bots are not bidding cautiously. They bid to win a slot, then discover the price moved and refuse to trade. The fee is the entry ticket, and they buy it on purpose.

Ask the only question that matters for a fee: who pays for the advertised number? Here, the traders whose slippage guards fired. They paid to be told no, a quarter of the ledger’s capacity at a time. That is not progress arriving; it is a cost of doing business inside a market with more bots than fills. An architecture that spends a quarter of its throughput on refused work has not lowered its cost per useful transaction. It has raised it.

None of this is a scandal. Stellar launched in 2014, built by Jed McCaleb and Joyce Kim on a fork of the Ripple protocol, so it began life as somebody else’s ledger and grew into one designed for issuance and settlement rather than general computation. Its contract engine, Soroban, is named after the Japanese abacus.

So here is what I think should have been measured. Not the peak of a window, but two steady numbers: the cost per successfully settled transaction, and the ratio of settled to submitted. The first tells you what it costs to move value; the second tells you how much of the chain’s work is real. Right now Stellar settles roughly three of every four transactions it accepts, and its close time is pinned at five seconds. That is a chain quietly getting better at its job while handing a quarter of the floor to bots that pay to lose.

Both facts fit in one honest sentence. Neither of them is 217.4, and the number that is 217.4 is a window somebody chose. Measure the ratio. Measure the cost per settled transaction. Then you will know whether the network got faster, or whether the headline found a narrower window to look through.