Changpeng Zhao speaking at Web Summit with a Binance logo on his shirt

BNB Chain Wants 100,000 TPS. One Draft Shows What the Speed Race Can Cost

By Isaac • July 13, 2026 11:23 am • Comments

BNB Chain has put an enormous number on its next act: more than 100,000 transactions per second.

It is also promising transaction preconfirmation in under 50 milliseconds, block finality in under one second, no public mempool, protected lanes for critical traffic and privacy built into the protocol.

Those are exchange-grade ambitions.

Trending: Twenty-Seven Crypto Firms Are Building a Court for AI Agents

They are not live network results.

The distinction is especially important because BNB Chain is describing two different engineering tracks at once.

The existing BNB Smart Chain is being tuned for another round of performance gains in the second half of 2026. Beyond it, a separate next-generation Layer 1 is still being designed for a testnet by year-end and a mainnet launch in early 2027.

BNB Chain says the new architecture will combine parallel execution and a storage system based on LtHash to target more than 100,000 TPS. Its TxStream design would send transactions directly to the block leader instead of placing them in a public mempool, while PriorityLane would reserve block space for traffic such as oracle updates, liquidations and bridge messages.

The same design sketch calls for confidential transactions with selective disclosure, gas sponsorship, transaction batching, passkeys, scheduled execution and access-key controls. BNB would remain the asset tying the new chain to the wider ecosystem.

A performance target is only the beginning of that story.

BNB Chain has not yet published the new L1’s validator model, minimum node hardware, benchmark configuration, state-growth assumptions or results under adversarial load. There is no public testnet on which independent operators can reproduce the 100,000-TPS claim.

The roadmap is much more concrete about today’s BSC.

It says BSC reduced its block interval from 750 milliseconds to 450 milliseconds during the first half of 2026, cut in-memory finality from 1,125 milliseconds to 650 milliseconds and lifted benchmark throughput from roughly 2,800 TPS to about 5,200 TPS. The near-term objective is to double mainnet throughput again, not jump the existing chain straight to 100,000.

Current network documentation also provides a useful baseline.

BNB Smart Chain elects 45 active validators each day. Twenty-one serve in the consensus validator set for a given epoch: 18 drawn from the highest-staked cabinet and three from the remaining candidates.

That leaves consensus work in the hands of a rotating committee of 21 at any moment, while the broader group competes for daily selection. Validators are responsible for producing blocks, checking transactions and participating in governance.

Faster blocks raise the operating stakes for that group. Each member has to execute transactions, store the resulting state and receive new blocks quickly enough to stay in sync.

The number of independent operators able to sustain that load will matter alongside the top-line throughput benchmark. A machine that falls behind can miss its slot regardless of the chain’s advertised ceiling.

The BSC client repository recommends 16 CPU cores, 64 gigabytes of RAM and roughly 3 terabytes of SSD storage for a mainnet full node. More speed can raise those demands unless parallel execution, storage design and state management offset them.

None of those current figures should be projected onto the new L1. They simply show the questions that still need answers before its performance and decentralization can be judged together.

Those requirements already put a validator-class machine far beyond a consumer laptop. A short benchmark cannot show how bandwidth, storage cost and state size will grow after months of sustained high-volume use, or how slower operators fare during bursts.

One current post put the issue more bluntly:

BNB Chain’s own technical work offers a concrete look at the pressure behind the speed race.

A separate draft called BEP-675 proposes changing how builder-produced blocks reach validators on the existing BSC. The next-generation L1 may take a different route; this draft still exposes a real cost of shaving time from block production.

Under BSC’s legacy builder path, a builder executes a proposed block and sends the transaction list to a validator. The validator then simulates those transactions again before sealing the block.

That second execution is a safety check. It is also slow.

BEP-675 would let a builder submit a fully executed block containing the state root, receipts root and other results. The validator would verify deterministic header fields, add its own system-transaction signatures, seal the block and broadcast it without replaying every user transaction first.

Only after broadcast would the validator import and re-execute the block locally to confirm that the builder’s results were valid.

The draft estimates that removing one execution pass from the critical path could raise the practical gas-limit ceiling by about 50 percent. Builders would have a wider window to assemble blocks, and validators could process more gas inside the same block interval.

The price is that some verification moves from before publication to after it.

If a builder submits an invalid block, the validator can detect the problem during import and revoke that builder’s fast-path permission for 24 hours. The builder then falls back to the older route with full pre-seal simulation.

The draft’s own worst-case analysis says each registered builder could cause one missed block in a 24-hour revocation window before being downgraded. The proposal acknowledges that bounded failure mode, which shows exactly how a throughput gain can relocate risk.

The new L1 may use a different mechanism entirely.

Still, any architecture chasing sub-50-millisecond preconfirmation has to decide what gets verified immediately, what can be checked later, who is trusted to order transactions and how quickly the network recovers when that trust fails.

Removing the public mempool creates another tradeoff.

Direct transaction streaming can reduce public front-running because pending orders are no longer visible to every bot watching the network. It can also make the block leader and the private routing layer more important.

Users will need evidence that transactions are not quietly delayed, filtered or reordered for favored parties.

PriorityLane raises a similar governance question.

Reserving block space for oracles, liquidations and bridges can keep essential systems alive during a demand spike. The policy for deciding which traffic qualifies, how much capacity is reserved and who can change those rules will determine whether the lane is resilience infrastructure or privileged access.

Native privacy could be the most consequential feature of all.

Selective disclosure can make onchain payments and institutional finance usable without exposing every balance and counterparty to the public. The cryptography, compliance controls and performance cost of that privacy layer remain undisclosed.

Another current post captured the scope of the pitch:

AI agents make these design choices more urgent.

A human trader may submit a handful of transactions and tolerate a short delay. Autonomous software can generate orders, payments and contract calls continuously.

It can also amplify a bug or abusive strategy at machine speed.

A chain built for agents therefore needs more than raw capacity. It needs rate controls, permission boundaries, predictable fee markets, strong key security and failure containment that works when thousands of programs react to the same event at once.

BNB Chain has given itself a fast timetable.

By the end of 2026, the testnet should make four things measurable: sustained throughput with realistic transactions, finality during validator or network failures, the cost and hardware needed to run a node, and whether private routing treats users fairly.

If those results hold under independent testing, 100,000 TPS will be more than a roadmap number.

Until then, the most credible signal is not the size of the claim. It is whether BNB Chain publishes the conditions, compromises and failure cases behind it.

Join the conversation!

We have no tolerance for comments containing violence, racism, profanity, vulgarity, doxing, or discourteous behavior. If a comment is spam, instead of replying to it please click the icon below and to the right of that comment. Thank you for partnering with us to maintain fruitful conversation.

 

Search ProCoinNews