Stellar’s Thruput Hits 7 Million Payments a Second in Execution Test
Project Thruput is an experimental execution architecture; its benchmark does not measure Stellar mainnet throughput. Image: Stellar Development Foundation
Technology & Security

Stellar’s Thruput Hits 7 Million Payments a Second in Execution Test

Stellar’s Thruput engine reached 7.02 million payments per second in a single-validator benchmark. Its mainnet path remains undecided.

Make us preferred on Google

Key Notes

  • Thruput’s published execution benchmark reached 7.02 million payments per second inside one validator.
  • The test used eight execution hosts plus three support machines and excluded consensus and the mempool.
  • The preview has no per-transaction fee, while its relationship to Stellar’s existing L1 remains undecided.

The Stellar Development Foundation has introduced Project Thruput, an experimental execution engine that reached 7.02 million payments per second in its published benchmark. The result measures work inside a single validator, rather than the throughput of Stellar’s live public network.

The October 28 announcement describes a technology preview available on FutureNet. Its aim is to let validators add computing capacity by spreading execution across machines, including when transactions update the same accounts.

Eight Execution Servers, Plus Supporting Infrastructure

The project’s benchmark repository reports 1.18 million payments per second with one execution host and 7.02 million with eight, a gain of roughly six times. The high-contention workload moved payments among just 100 accounts, deliberately concentrating activity on shared balances.

Those eight AWS execution hosts were accompanied by three support machines for the load generator, database and event service. Each published result is the median of three repetitions. A separate workload using 10,000 accounts reached 6.33 million payments per second on eight execution hosts.

The methodology includes contract execution, signature verification and opening, closing and committing blocks. It excludes consensus, the mempool, validator re-execution and the normal client-submission path. The published setup also uses RAM-backed storage, rather than a durable validator configuration.

This is therefore a controlled test of the execution core. It does not show that a geographically distributed network can receive, agree on and settle seven million user payments every second. CoinScreamer has reviewed the published results and methodology, rather than independently rerunning the AWS tests.

Shared Balances Can Receive Compatible Updates

Thruput’s execution model starts transactions from the same snapshot of the ledger. Instead of replacing a balance with a final number, a transaction can record the change it wants to make. Compatible changes can then be combined.

For example, two increases of five and three to a starting balance of 100 can produce 108 without either transaction first calculating the other’s result. The design lets work on a shared account run concurrently, rather than assuming every shared-account operation must wait its turn.

Compatibility still matters. Conflicting changes can be excluded from a proposed block, and combined withdrawals must remain within the available balance. Adding hardware does not remove those rules or make every type of contract operation independent.

No Transaction Fee Does Not Mean Unlimited Capacity

The project’s resource documentation describes a model without conventional per-transaction gas charges. Gas still measures and limits computation; it is not used as a payment deducted for each transaction.

When demand exceeds capacity, scheduling is allocated over time in proportion to an account’s unlocked native-token balance. Scheduling does not spend those tokens. Storing data instead locks tokens as a refundable deposit, reducing the balance available for scheduling until the data is deleted.

The current experimental network’s native token has no monetary value, according to the documentation. This should not be interpreted as a new investment token announcement or a confirmed change to XLM’s role on Stellar.

Its Relationship to Stellar Remains Open

The project’s introduction says no decisions have been made about timelines or its relationship to Stellar’s existing L1. The preview does not commit the foundation to incorporating Thruput into mainnet or launching it as a separate production blockchain.

That distinction also separates the research from existing commercial activity. Our JQQQ report covered Janus Henderson’s tokenized Nasdaq-100 fund on Stellar. The fund announcement does not establish that it uses Thruput or receives the benchmark’s execution capacity.

Disclaimer: CoinScreamer is an independent media brand owned and operated by NuvexMedia LLC, publishing news, research, and market insights on digital assets and related technologies. NuvexMedia LLC invests in and collaborates with companies across the digital asset, blockchain, and technology sectors. These relationships do not influence CoinScreamer’s editorial coverage, and the publication maintains full editorial independence to provide accurate, timely, and objective information. © 2025 NuvexMedia LLC. All rights reserved. This content is for informational purposes only and should not be considered legal, tax, investment, financial, or other professional advice.

News, Technology & Security