Stellar's Thruput Hits 7 Million Payments a Second. The Real Question Is Who Can Reproduce It.

Can a blockchain do seven million payments a second? Stellar says its new execution engine can, on eight machines, in a lab. That's the whole story in one line, and it's worth unpacking, because most people will read the 7 million and stop there.

The Stellar Development Foundation published Project Thruput on October 28 as a technology preview. Not a mainnet upgrade. Not a roadmap commitment with a date attached. A preview, with open-source code and benchmarks you can rerun yourself on FutureNet. That distinction is doing a lot of work here, and most of the early coverage glossed right past it.

By the numbers

Start with what was actually measured. On a single validator machine, Thruput executed roughly 1.18 million payments per second. Spread across eight machines, the same workload hit about 7.02 million. That's a near six-fold jump from adding hardware, which is the interesting part. Most chains don't scale linearly with machines, because ordering becomes the constraint long before compute does.

The benchmark used a limited set of accounts and measured execution, signature verification, and the engine work around them. It didn't measure consensus. It didn't measure networking or storage propagation across independent machines. The foundation has said so explicitly, which is a rare bit of honesty in a sector where throughput numbers get thrown around like marketing copy.

For scale, Visa's commonly cited peak is around 24,000 transactions per second. Solana's theoretical ceiling gets quoted at 65,000. Those figures are also measured at different layers with different assumptions, which is exactly the point. Everyone's comparing dashboards built on different rulers.

Why execution is the real bottleneck

Here's the thing about parallel execution. Most systems can run independent transactions side by side just fine. The moment two transactions touch the same account or the same shared state, everything serializes. One waits. Ordering wins. And ordering is what most chains actually bottleneck on, not raw compute.

Thruput targets that specific problem. The claim is that it scales by adding machines even under heavily contended workloads, the messy case where lots of transactions collide on the same data. If that holds up outside a lab, it's a genuine engineering result, not a press release with a number attached.

But here's my first problem with how this will get read. Seven million per second in an execution sandbox has almost nothing to do with what a user experiences on a public network. Public throughput is consensus plus networking plus storage plus adversarial conditions. You can have the fastest execution engine on earth and still stall on finality. The component isn't the product.

So why does any of this matter? Because payments are the one use case where throughput has a dollar figure attached. Every second of settlement latency is working capital sitting still. Stablecoin rails are moving hundreds of billions a month now, and the bottleneck for the next order of magnitude isn't regulatory anymore. It's whether the chain can clear. Tokenization isn't a narrative. It's a rails upgrade, and rails get judged on throughput and uptime.

The fee model nobody's talking about

Tucked inside the Thruput design is a far stranger idea than the speed number. There are no per-transaction execution fees. Instead, when demand exceeds capacity, accounts receive a scheduling share tied to unlocked native-token balances. Individual transactions still hit computational limits, so it isn't unlimited free infrastructure. But the allocation mechanism is completely different from gas, and that deserves more attention than it's getting.

Think about what that means. A chain with no per-transaction execution fee is a chain where the business model shifts onto balance holders. Which raises obvious questions. How concentrated does the balance sheet become over time? What stops a large holder from crowding out small ones during peak demand? And what does that do to a payments company trying to price its own service on top of the rail?

This is the second thing I'd push back on. Stellar framed it as an alternative resource-allocation design, and fair enough. But designs like this are political, even when they're dressed up as engineering. Who gets priority during congestion is a governance question whether or not anyone wants to say it out loud. A permissioned payments corridor and an open retail network would produce very different outcomes under the same rule.

What to watch

Independent reproduction is the first gate. The benchmarks are reproducible, which means outside teams can and should rerun them, stress them with different workloads, and try to break the contention model. Until that happens, 7 million is a claim, not a fact. Watch for the first third-party writeup that isn't a rewrite of the same numbers.

Second gate is end-to-end performance on a public network. The foundation has been careful not to publish those figures, and it shouldn't, not until consensus, networking and storage are tested together with real adversarial traffic. A FutureNet soak test with a realistic account distribution, rather than a limited account set, would be the signal to look for.

Third gate is deployment specs. If Stellar wants processors and real-world asset issuers to build against this, they need documented operational requirements. How many machines, what hardware, what the failure modes look like. Builders shouldn't be writing service-level agreements against a preview, and the smart ones won't.

DePIN makes more sense when you ignore the name. Same logic applies here. Strip the 7 million headline and what's left is a credible research result about ordering under contention, published openly, with caveats the foundation put there itself. That's rarer than it should be. The real world is coming on-chain, one asset class at a time, and settlement capacity is the thing that decides which chains get used when it does.

If nobody outside the foundation can reproduce the benchmark by year-end, discount the number entirely. If they can, and consensus keeps pace, Stellar has a real argument for the payments layer underneath everything else. That's the only test that matters.