The Road to 5000 TPS: Scaling Stellar in 2025

In 2025, one of the Stellar Development Foundation’s (SDF) primary goals is to increase Stellar Core’s theoretical throughput to 5000 transactions per second (TPS). As adoption of Soroban — the Stellar smart contracts platform — accelerates and new use cases emerge, scalability is essential to ensuring that Stellar remains fast, affordable, and developer-friendly.

This post provides a high-level overview of our comprehensive scalability efforts, categorized into five key themes. Consider this a brief introduction to our major projects; we will delve deeper into each optimization area in upcoming posts.

Protocol 23 introduces multi-threaded smart contract execution, caching WebAssembly modules, and smart contract state. Despite scaling to true N-way parallelism and using aggressive caching techniques, the good news is that node operators do not need to upgrade their hardware to benefit from these improvements.

These improvements will take full advantage of the CPUs and RAM already common in validator infrastructure. Over time, some hardware requirements may grow as throughput climbs — but our priority right now is unlocking unused capacity, not imposing new burdens.

Historically, Stellar Core was mostly single-threaded. Earlier this year, we enabled background processing of messages on Mainnet that yielded promising results (more on this in a separate blogpost). Now, we’re going even further — pushing even more work to the background, like signature verification and block execution. These features are currently opt-in, but are expected to become defaults after the Protocol 23 vote. The result: more opportunities for Stellar Core to make full use of available CPU cores.

Right now, Stellar Core’s consensus and execution stages run sequentially: the network must finalize voting on ledger `N` before transactions can be applied to the database, and doesn’t start voting on ledger `N+1` until execution finishes. This means that while executing a transaction set, the voting is idle, and while the Stellar Consensus Protocol is voting, the transaction set execution is idle.

We’re redesigning this flow to allow consensus and execution to run in parallel, where nodes vote on ledger `N+1` while executing `N`. This is made possible by Soroban's parallel-friendly design, where all the entries that will be read or written have to be specified in the footprint. Therefore, it allows for safe partitioning of transaction sets for Ledger N and N+1. This pipelined approach eliminates idle time and helps us push toward both our throughput and block-time goals.

All Stellar Core components rely on the BucketListDB to manage ledger state. At high volumes, repeated reads and writes can become a bottleneck. We’re addressing this with two changes:

• More aggressive in-memory caching to accelerate state loads for transaction validation and execution.
• In-memory post-processing to boost write speeds during commit time.

These changes deliver substantial performance improvements using the RAM already provisioned by most operators.

Scaling without measurement is guesswork. A We’re refining our benchmarking framework to minimize measurement noise from synthetic load tools and metrics overhead — helping us better understand real system limits.

With every release of Stellar Core, we publish our theoretical throughput results. You can follow those here:

https://github.com/stellar/supercluster/blob/main/doc/theoretical-max-tps.md

At this link, you can find the complete methodology, current results and instructions to reproduce. Our goal is to improve the benchmarking framework while continuing to publish results regularly with each release.

These improvements are expected to bring Stellar Core’s theoretical throughput to up to 5000 TPS in 2025 benchmarks. But achieving theoretical throughput is only one piece of the puzzle. These upgrades must be rolled out safely and incrementally — and downstream systems such as Horizon and Stellar RPC will also need to scale to handle greater transaction volumes.

Higher throughput opens the door for new applications, without compromising confirmation times or reliability. Ultimately, it makes Stellar more attractive to developers, more resilient to spikes in demand, and better positioned to serve users who depend on fast, low-cost transactions.

SDF is committed to helping the Stellar network scale responsibly: sharing performance data transparently, keeping hardware costs reasonable to boost decentralization, and delivering the capacity the ecosystem needs to grow.