Wed., Oct. 28, 2026New York 3:29 p.m. ET · London 7:29 p.m. GMT · Singapore 3:29 a.m. GMT+8NY 3:29p · LDN 7:29p · SGP 3:29a

Le Coin / Protocols & Policy / Technology preview

Pastel 3D soft clay parallel conduits expanding through frosted rings in soft butter, pale champagne and cream.
Le Coin

Protocols & Policy · Technology preview

Stellar Development Foundation opens Project Thruput technology preview on FutureNet

SDF's Oct. 28 Foundation News post frames a new L1 execution model that removes the single-global-order bottleneck so capacity can grow by adding machines, with early single-validator benchmarks of 1.18 million payments per second on one machine to 7.02 million on eight (nearly 6×), and says the preview is live on FutureNet, not as a mainnet capacity claim.

The Stellar Development Foundation on October 28 published a technology preview of Project Thruput, a new Layer 1 execution model it says removes the single-global-order bottleneck so capacity can grow by adding machines [1]. In early company benchmarks labeled as single-validator execution, capacity rose from 1.18 million payments per second on one machine to 7.02 million payments per second on eight machines, nearly 6× the original capacity [1]. The preview is live on FutureNet today; those figures are not presented as mainnet production capacity or as end-to-end network throughput [1].

In plain terms, Project Thruput is an SDF technology preview of how a validator can execute many payments in parallel against shared state, including when those payments compete for the same accounts [1]. The mainstream business read is payment-rail infrastructure: whether more hardware can raise execution capacity without sharding the chain. Same-day Meridian conference chrome (Oct. 28–29, Lisbon) is label only [1][2]. This piece is distinct from the same-day Securitize×Stellar tokenization KEEP and from soft Archax Meridian color.

Why a single global order caps machines

Most blockchains process transactions in one strict global order [1]. Some designs run unrelated work in parallel, but when two transactions touch the same state they fall back into line, and extra machines sit idle [1]. Contention remains the bottleneck when many payments compete to update one balance or pool, because designs often treat touching the same state as depending on it [1].

SDF says Project Thruput changes that model. Transactions in a block start from the same ledger snapshot and can run side by side even when they update the same state; compatible changes combine when the block commits [1]. For a balance, a transaction can record a delta such as “subtract 5” rather than a final absolute, so many payments can update the same account in one block while still respecting the balance’s limits [1]. Each validator can spread that execution across many machines that work as one against shared state, adding capacity without splitting the blockchain into shards [1].

The benchmarks, with the company’s caveats

Under heavy contention, with every payment moving among just 100 accounts, SDF reports the 1.18 million to 7.02 million payments-per-second path as machines were added [1]. Those benchmarks measure real RV32 ERC-20 transfers and include execution, signature checks, and block open-to-commit work in Thruput’s core execution engine [1]. They do not measure end-to-end network throughput [1]. Each figure is the median of three runs on AWS r8a.16xl instances; the blog points exact results to the GitHub repository thruputchain/whitney and does not invite invented intermediate machine counts or extra pps figures into this story [1].

@StellarOrg posted around 11:30 a.m. ET the same day calling Project Thruput a technology preview of a new blockchain execution model and quoting SDF CEO and Executive Director Denelle Dixon; that company post links outward to The Defiant coverage and is treated here as X lead only, not a second numeric primary [2]. The numeric claims stay on the Foundation News blog [1].

SDF also describes a fee posture for the preview: no per-transaction fees; gas still measures and caps each transaction’s execution; when demand exceeds capacity, an account’s scheduling share is set by its unlocked native-token balance without spending those tokens or competing through priority fees [1]. That is company framing for Project Thruput as bloged, not a mainnet fee-roadmap claim.

The objection, and what would change the view

The objection is mechanical. Early single-validator execution numbers on a technology preview venue are not a claim about today’s public Stellar mainnet capacity [1]. The contention setup is deliberately narrow (100 accounts), and the company itself says the figures do not measure end-to-end network throughput [1]. Aspirational mission language about serving ten billion people and making free smart-contract execution practical at scale is company framing in the same post; it is not a verified outcome [1].

Le Coin’s view is that the ops-relevant tell is whether capacity scales by adding machines under contended shared state without sharding [1]. What would change the view is reproducible third-party verification of the whitney results under the same caveats, or a later company filing that labels mainnet or end-to-end network throughput with numbers this Oct. 28 post does not state [1]. Until then, the checkable public record is the October 28 Foundation News post and the FutureNet technology preview as labeled [1].

Sources

  1. Stellar Development Foundation, “Introducing Stellar Project Thruput: blockchain compute, unrationed,” Foundation News, Oct. 28, 2026, https://stellar.org/blog/foundation-news/introducing-stellar-project-thruput ; technology preview of a new execution model that removes the single-global-order bottleneck so capacity grows by adding machines; early single-validator execution benchmarks 1.18 million payments/sec on one machine to 7.02 million on eight machines (nearly 6×); heavy contention among 100 accounts; real RV32 ERC-20 transfers including execution, signature checks, and block open-to-commit in Thruput’s core execution engine; do not measure end-to-end network throughput; median of three runs on AWS r8a.16xl; exact results pointer GitHub thruputchain/whitney; live on FutureNet today with open-source code, white papers, and reproducible benchmarks; no per-transaction fees; gas measures/caps; scheduling share from unlocked native-token balance; aspirational ten-billion / free smart-contract execution framing; explore links stellar.org/thruput and thruput.network docs; accessed Oct. 28, 2026, ~12:28 p.m. ET.
  2. Stellar Development Foundation (@StellarOrg) on X, status 2115466287165882368, Oct. 28, 2026, ~11:30 a.m. ET (created_at 2026-10-28T15:30:40.000Z). Company-stated technology preview of a new blockchain execution model; quote of Denelle Dixon; link expands to The Defiant (not the blog). X lead only; numeric primary remains [1]; accessed Oct. 28, 2026, ~12:28 p.m. ET.

Holding the Corner.

Not financial advice.

PublishedOct. 28, 2026, 1:32 p.m. ET

Corrections: none. A correction is a new version with its own hash; the old proof stays up.

Proof slipLe Coin · Protocols & Policy · Oct. 28, 2026
Version
v1 · published
Credits
Checked by Le Coin Copy & Fact Desk AI agent
Published HTML hash
2a474286a3a58d9b6b4ac88af0246085618d7846c6e136af1e904414c5a0a786 On the Proof page
OpenTimestamps
Submitted, pending Bitcoin confirmation
Bitcoin tx
— none yet

The published HTML hash is the SHA-256 of the article element as served on this page. Proof page

Verify this article

  1. Download both files.

    Article file (.html)Proof file (.ots)

  2. Go to opentimestamps.org. Drop the proof file (.ots) in the box first, then drop the article file (.html) in the second box that appears.

How verification works

Version history (1)

  • v1 · Oct. 28, 2026, 1:32 p.m. ET · published. No earlier version.