Beacon

Test

<ul>
 <li>BNB Chain is developing a parallel EVM-compatible Layer 1 that retains BNB as its native asset, with a public testnet targeted for late 2026.</li>
 <li>Transactions will be charged on their declared gas limits rather than actual consumption, changing how developers and users manage execution costs.</li>
 <li>A new state-storage model removes standard Ethereum state-proof support, while the planned bridge introduces a separate security dependency.</li>
</ul>
<a href="https://ethnews.com/bnb-chain-ai-layer-1-trading-agents/" rel="noopener noreferrer nofollow">BNB Chain is preparing</a> a second Layer 1 blockchain that prioritizes transaction speed over several conventions of Ethereum-compatible networks, including gas refunds, conventional state proofs and synchronous execution.
The network, currently identified as New L1, will operate alongside BNB Smart Chain and use BNB for transaction fees, validator staking and governance. Its development targets include 200-millisecond blocks, approximately 20-millisecond pre-confirmations and throughput exceeding 100,000 transactions per second.
The architecture is more consequential than the headline performance figures suggest. Developers are replacing parts of the execution and storage pipeline that normally constrain EVM throughput, introducing different assumptions for transaction pricing, settlement and infrastructure compatibility.
An internal multi-validator devnet is running, <a href="https://docs.bnbchain.org/newl1/" rel="noopener noreferrer nofollow">according to BNB Chain’s technical documentation</a>. The public testnet is targeted for late 2026, with mainnet planned for early 2027. No publicly accessible network is available for independent production-scale benchmarking.
<h2 id="bnb-chain-is-replacing-execution-bottlenecks-not-just-shortening-blocks">BNB Chain Is Replacing Execution Bottlenecks, Not Just Shortening Blocks</h2>
BNB Smart Chain has already reduced its block interval through successive upgrades. <a href="https://www.bnbchain.org/en/blog/bnb-chain-h2-2026-tech-roadmap-doubling-down-on-speed" rel="noopener noreferrer nofollow">Its July 2026 roadmap reported</a> a reduction to 450 milliseconds and benchmark throughput of approximately 5,200 transactions per second.
New L1 adopts a different architecture.
Under conventional synchronous execution, validators process transactions and establish their resulting state before completing block validation. New L1 separates transaction ordering from execution, allowing consensus to progress while the execution engine processes previously ordered transactions.
Validators use an enhanced version of Parlia’s Proof-of-Staked-Authority consensus, with cross-block BLS votes designed to establish fast finality for transaction ordering.
A block’s ordering can become final before the execution commitment associated with its transactions has been verified and finalized. Applications cannot safely treat an early ordering confirmation as proof that a trade succeeded or a transfer settled.
The network also introduces validator-signed pre-confirmations that can be withdrawn or superseded before finality.
For exchanges and payment processors, a pre-confirmation can inform user interfaces or transaction monitoring, but irreversible delivery of funds or assets requires execution finality.
BNB Chain documents this distinction in its <a href="https://docs.bnbchain.org/newl1/developers/transaction-lifecycle/" rel="noopener noreferrer nofollow">transaction lifecycle specification</a>.
<h2 id="the-gas-model-creates-a-new-cost-for-overestimating-transactions">The Gas Model Creates a New Cost for Overestimating Transactions</h2>
One of New L1’s most consequential changes concerns transaction fees.
On Ethereum and BSC, users generally pay for gas actually consumed, subject to the network’s refund rules. New L1 instead charges the full gas limit declared when the transaction is submitted.
The reason lies in asynchronous execution.
Blocks are assembled before transactions execute, so validators reserve capacity according to declared gas rather than measured execution consumption. The protocol charges for that reservation, including unused capacity.
Consider a transaction requiring 70,000 gas. If a wallet submits it with a 500,000-gas limit, New L1 charges for the entire 500,000.
That is approximately 7.14 times the gas required by the underlying execution.
At an illustrative gas price of 1 gwei, the difference would be 0.00043 BNB for that transaction. The actual cost depends on the prevailing gas price, which is not established by this example.
A failed execution can also consume the declared gas allocation under the proposed charging model.
For automated market makers, trading bots and payment applications, excessive safety margins therefore become a direct operating expense rather than largely unused capacity.
The developer migration guide warns against blindly applying conventional gas-padding practices. It recommends tighter estimates and identifies newl1_estimateGas as a network-specific tool.
Faster ordering consequently comes with greater responsibility for accurately forecasting execution requirements.
<h2 id="flat-state-storage-removes-a-standard-ethereum-proof-mechanism">Flat State Storage Removes a Standard Ethereum Proof Mechanism</h2>
New L1 also replaces the traditional Merkle-Patricia trie approach to state commitments with a flat key-value database and an LtHash accumulator.
Ethereum-style state tries support cryptographic proofs that particular account or storage values belong to a committed state.
Maintaining and updating those structures introduces computational and storage overhead, particularly when applications frequently modify large numbers of state entries.
BNB Chain’s proposed system maintains a cumulative state commitment that can be updated as individual entries change. According to the state database specification, the commitment-update cost does not grow with the total number of existing accounts.
That removes one source of state-commitment overhead, although it does not eliminate database reads, writes or contention between transactions.
The trade-off is compatibility.
The standard eth_getProof method is unsupported because the LtHash commitment does not provide conventional Merkle-Patricia inclusion proofs. Snap synchronization is also unavailable.
Applications that rely on Ethereum-style storage proofs, including certain light-client bridges and verification systems, cannot simply migrate their existing proof infrastructure.
BNB Chain indicates that an accumulator-native proof scheme is planned, but developers cannot treat it as an available feature today.
Smart contracts may deploy without modification while indexers, bridge verification systems and RPC-dependent services require substantial changes.
<h2 id="parallel-execution-still-faces-shared-state-contention">Parallel Execution Still Faces Shared-State Contention</h2>
BNB Chain’s throughput ambition depends partly on processing independent transactions concurrently.
That approach works well when transactions modify unrelated accounts or storage locations. It becomes more difficult when many transactions compete for the same liquidity pool, order book or contract state.
A decentralized exchange provides a useful example.
Thousands of transfers between unrelated wallets can potentially execute in parallel.
Thousands of swaps against one concentrated liquidity pool cannot necessarily achieve the same scaling because each swap may depend on the pool state produced by preceding transactions.
Execution engines must preserve deterministic results even when transaction workloads are highly interdependent.
The published 100,000-plus TPS target therefore cannot be interpreted as demonstrated capacity for complex decentralized exchange transactions.
Performance testing needs to distinguish simple transfers from contract-heavy workloads, measure sustained throughput under state contention and account for validator hardware requirements.
New L1 also removes the conventional public mempool through its transaction-streaming architecture, routing transactions toward block producers.
That can reduce exposure to public-mempool front-running, but it does not eliminate the possibility of transaction-ordering advantages held by producers or participants with privileged connectivity.
The relevant question is whether the network can deliver predictable execution quality under competitive trading conditions, not merely how quickly it can order transactions.
<h2 id="bnb-s-expanded-utility-does-not-automatically-increase-token-burns">BNB’s Expanded Utility Does Not Automatically Increase Token Burns</h2>
The decision to retain BNB across both networks avoids introducing a separate native token for the new execution environment.
Binance co-founder Changpeng Zhao, known as CZ, summarized the approach as “Multiple chains, one coins.”
<blockquote class="twitter-tweet">
 Multiple chains, one coins.
 — CZ <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/1f536.png" alt="🔶" style="height: 1em; max-height: 1em;"> BNB (@cz_binance) <a href="https://x.com/cz_binance/status/2114442971768647881?ref_src=twsrc%5Etfw" rel="noopener noreferrer nofollow">October 25, 2026</a>
</blockquote>
For BNB holders, the more important issue is how additional network activity translates into token demand and supply reduction.
BNB Smart Chain already operates a real-time burn mechanism under BEP-95, which destroys a governance-defined portion of eligible gas fees.
However, New L1’s published documentation does not establish that every BSC fee-distribution and burn rule will automatically apply identically to the new network.
Its devnet configuration specifies a zero base fee, with transaction pricing determined by priority fees.
A zero base fee does not mean transactions are free. It means the fee structure differs from networks that adjust a nonzero base fee in response to congestion.
The devnet setting is not necessarily the final mainnet policy. Future governance decisions involving govBNB could determine whether a base fee is introduced and whether any portion of transaction fees is burned through a mechanism comparable to BEP-95.
Until those rules are finalized, New L1’s contribution to BNB supply reduction cannot be reliably estimated.
Higher transaction volumes could increase aggregate BNB usage while generating relatively modest fee revenue if transaction prices remain low.
Conversely, the declared-gas charging model could increase fees paid for some workloads even without equivalent growth in actual computational consumption.
Neither outcome can be quantified from the performance roadmap alone.
<h2 id="a-second-layer-1-reintroduces-a-familiar-bridge-risk">A Second Layer 1 Reintroduces a Familiar Bridge Risk</h2>
BNB Chain has operated a dual-chain architecture before. Its original BNB Beacon Chain and BSC structure was consolidated through BNB Chain Fusion in 2024, partly to simplify infrastructure and reduce security risks.
The proposed New L1 restores two separate execution environments connected through a native bridge. Three considerations stand out:
<ul>
 <li>Historical bridge vulnerabilities: In October 2022, attackers exploited the BSC Token Hub bridge through forged cross-chain proofs, resulting in the unauthorized creation of approximately 2 million BNB, according to BNB Chain’s incident report. The incident demonstrates the consequences of compromised cross-chain verification, although it does not establish a vulnerability in New L1.</li>
 <li>Different state-proof architecture: New L1 replaces conventional Merkle-Patricia state commitments with LtHash. Bridge developers cannot automatically reuse verification systems that depend on Ethereum-style storage proofs, making the eventual cross-chain authentication design particularly important.</li>
 <li>Execution finality and emergency controls: A secure bridge must distinguish transaction ordering from completed execution, authenticate cross-chain messages and define how transfers can be suspended during an incident. These mechanisms have not yet been fully documented for the proposed network.</li>
</ul>
Until the bridge specification and implementation are available for independent assessment, its security assumptions remain an unresolved part of BNB Chain’s expansion.
<h2 id="the-2027-test-is-economic-as-well-as-technical">The 2027 Test Is Economic as Well as Technical</h2>
New L1’s public testnet will provide the first opportunity to evaluate its proposed performance outside an internal development environment.
Developers will be able to examine execution latency, gas-estimation behavior, RPC compatibility and throughput under realistic contract workloads.
For BNB, the larger question is whether the second network attracts applications that generate sustained activity rather than redistributing transactions already taking place on BSC.
A shared native asset simplifies the ecosystem’s token structure, but it does not remove the operational costs of maintaining two networks or the risks associated with transferring assets between them.
BNB Chain’s next phase will be measured less by its fastest pre-confirmation and more by the reliability, economics and security of the applications built on top of it.
The post <a href="https://ethnews.com/bnb-chains-new-l1-trade-off-200ms-speed-for-no-gas-refunds-and-bridge-risks/" rel="noopener noreferrer nofollow">BNB Chain’s New L1 Trade-Off: 200ms Speed for No Gas Refunds and Bridge Risks</a> appeared first on <a href="https://ethnews.com" rel="noopener noreferrer nofollow">ETHNews</a>.

BNB Chain’s New L1 Trade-Off: 200ms Speed for No Gas Refunds and Bridge Risks

Table of Contents

ETHNews

Other articles published on Oct 26, 2026

Join our free newsletter for daily crypto updates!