Introducing Stellar Project Thruput: blockchain compute, unrationed

Most blockchains process transactions in one strict, global order. Some have found ways to run unrelated transactions in parallel, but the moment two transactions touch the same state or require the same data, they fall back into line. Adding hardware doesn't change that — extra machines sit idle while transactions wait their turn.

Stellar Project Thruput is a technology preview of a new execution model that removes the bottleneck. Transactions don't need a single global order, even when they compete for the same data, so capacity grows by adding machines. In early benchmarks, execution capacity within a single validator rose from 1.18 million payments per second on one machine to 7.02 million payments per second on eight machines — nearly 6x the original capacity.

Project Thruput is live on FutureNet today, with open-source code, white papers, and reproducible benchmarks. We're just getting started, and we want you to test it, push it, and show us what you'd build if compute stopped being a limit.

The industry has made remarkable progress on speed. Some networks shard work across separate transaction sequences. Some require transactions to declare which accounts they'll use, so independent work can run side by side. Others execute transactions in parallel and redo work when conflicts appear.

Still, contention remains the bottleneck. When thousands of transactions compete to update a single balance or liquidity pool, they often wait on one another because most designs treat touching the same state as depending on it. That limits how much the network can do, even with more hardware.

So developers build around the limits of ordering. They keep contracts small, split logic across transactions, and move work offchain, sometimes to servers users must trust. Users bear the costs, too. They pay to compete for scarce capacity, and wherever transaction order can be bought, it can be used against them.

With Project Thruput, transactions in a block start from the same ledger snapshot and can run side by side, even when they update the same state. Their compatible changes are combined when the block commits.

For a balance, a transaction can record “subtract 5” rather than “the balance is now 95.” Those changes can be combined in any order, as long as they respect the balance's limits. Many payments can update the same account in one block, but two payments can't both spend the same last dollar.

Contracts can enforce limits across transactions, too, such as a cap on the total amount withdrawn in a block. Developers choose storage types that tell Project Thruput which changes can be combined and which limits must hold.

Once transactions stop waiting on each other, extra hardware actually gets used. In Project Thruput, each validator can spread execution across many machines that work as one, against the same shared state.

This adds execution capacity without splitting the blockchain into shards, so applications don't have to divide their state to use more hardware. Compatible updates to the same account can run on different machines and land in one block. The goal is to make the hardware fit the application's workload: more transactions, more computation in those transactions, or both.

Under heavy contention, with every payment moving between just 100 accounts, execution capacity grew as we added cores and machines.

These benchmarks measure real RV32 ERC-20 transfers, including execution, signature checks, and block open-to-commit work in Thruput's core execution engine. They don't measure end-to-end network throughput. Each figure is the median of three runs on AWS r8a.16xl instances. The exact results can be found here.

When capacity can grow with demand, compute doesn't need to be rationed through transaction fees. Project Thruput has no per-transaction fees. A micropayment and a complex portfolio risk calculation both run without a gas charge.

That doesn't mean unlimited compute. Gas still measures and caps each transaction's execution. When demand exceeds capacity, an account's share of scheduling capacity is determined by its unlocked native-token balance. Scheduling doesn't spend those tokens, and transactions don't compete through priority fees. Storing data works similarly: it locks part of that balance, which is released when the data is removed.

Our mission is equitable access to the global financial system. Not just the one we have today, but the one we'll have in fifty years. Serving ten billion people, and the billions of AI agents that will transact on their behalf, will take far more compute than any blockchain has today.

Our goal is to make free smart contract execution practical at scale. There's plenty left to figure out, but that's where we're aiming: a world computer where developers can build the apps they've imagined and people can use them without worrying about the cost of every transaction.

If you have a contract you were told was too expensive to run, bring it. If you have agents that need no per-transaction fees, bring them. What you find will help us decide where Project Thruput goes next.

Explore Project Thruput:

• Learn more
• Read the docs