BNB Chain is developing a separate blockchain for AI agents and high-frequency trading, promising sub-50-millisecond preconfirmations, more than 100,000 transactions per second and sub-second finality. Its private transaction flow could reduce sandwich attacks, but the harder test will be proving that validators cannot quietly replace public mempool traders as the new source of market power.
BNB Chain is preparing a new Layer 1 aimed at a category of blockchain activity that existing networks often handle poorly: automated, high-speed trading carried out by software agents.
The proposed network is designed for AI agents, quantitative strategies and other applications that need to submit and settle transactions quickly. According to reporting by The Block and Decrypt, BNB Chain is targeting preconfirmations in less than 50 milliseconds, throughput above 100,000 transactions per second and finality in less than one second. A testnet is planned by the end of 2026, with a mainnet launch targeted for early 2027.
Those figures put the project in competition with specialized trading networks as much as with conventional smart contract platforms. The more important distinction, however, is not simply speed. BNB Chain is proposing a transaction system without a public mempool, the waiting area where transactions are normally broadcast before inclusion in a block.
That choice is intended to make sandwich attacks and other forms of public front running impractical. In a conventional mempool, bots can observe a pending trade, place a transaction before it and then sell after it executes. The bot profits from the price movement created by the victim's order. If pending transactions are not publicly visible, the opportunity to copy and reorder them becomes more difficult.
But eliminating the public mempool does not eliminate the need for an ordering system. Transactions still need to be received, prioritized, proposed and finalized. The central question for BNB Chain's new network is therefore more demanding than whether bots can see pending orders.
It is whether validators, sequencers or other privileged infrastructure operators can gain the same information and control that public mempool bots once had.
Speed is the product
For the project's target users, sub-50-millisecond preconfirmation matters because an agent may need to submit several dependent trades inside a fleeting arbitrage or liquidation window. One transaction might acquire an asset on one venue, a second might sell it on another and a third might repay a loan or release collateral. A reliable preconfirmation for the first leg could let the agent decide whether to send the next leg before the opportunity disappears, rather than waiting for a full block and risking that the strategy becomes invalid. That speed can enable tightly linked execution across volatile markets, but it does not guarantee that an arbitrage will remain profitable, that every dependent transaction will be included, or that the promised ordering will be fair. It reduces execution uncertainty; it does not remove market risk, smart contract risk or validator discretion.
An agent may monitor prices across decentralized exchanges, identify a temporary price difference and attempt to execute a sequence of trades before the opportunity disappears. A delay of several hundred milliseconds can turn a profitable trade into a loss. The same issue applies to liquidations, market making, arbitrage and automated treasury management.
Traditional blockchain confirmation times create several sources of delay. A transaction must reach the network, wait for a block producer, compete with other transactions and then receive enough confirmations to be considered final. Even when the average block time is fast, unpredictable congestion can make execution difficult to model.
Preconfirmations address part of that problem. They are assurances that a transaction is expected to be included and ordered in a forthcoming block before full consensus finality has been reached. For a trading agent, a reliable preconfirmation can be valuable because it reduces uncertainty. The agent does not need to wait for a complete block cycle before deciding whether the next step in a strategy is safe to submit.
The stated target of less than 50 milliseconds is ambitious. It is close to the response time expected by professional electronic trading systems, although a blockchain preconfirmation is not identical to an exchange acknowledgment. In a centralized venue, an operator can match an order in a tightly controlled environment and maintain a database of balances. A blockchain must also provide cryptographic verification, consensus and a shared state that independent participants can trust.
The performance claim will therefore need to be measured under realistic conditions. A network can report impressive laboratory throughput by sending simple transactions between a small number of accounts. It is more difficult to sustain that performance when transactions invoke complex smart contracts, update liquidity pools, compete for the same state and arrive from users distributed across different regions.
The same applies to finality. Sub-second finality is useful only if it remains dependable during bursts of activity, validator failures and network congestion. AI agents are likely to create highly correlated demand. Thousands of agents may react to the same market signal and submit transactions at nearly the same time. That behavior could produce more intense bursts than ordinary human trading.
BNB Chain will need to publish measurements that separate raw transaction capacity from useful application capacity. Important data points would include latency at the 50th, 95th and 99th percentiles, sustained throughput over long periods, failed transaction rates, performance during contention and the time required for transactions to become irreversible.
Without that information, headline targets remain design objectives rather than evidence of a working trading infrastructure.
Why remove the mempool?
The public mempool is one of the most visible sources of value extraction in decentralized finance. Before a transaction is included in a block, it may be visible to infrastructure providers, searchers and other participants. Those observers can identify large swaps, liquidations or collateral movements and attempt to profit from their position in the transaction order.
A sandwich attack is the clearest example. A bot places one trade before a user's swap and another after it. The first trade moves the market price, the user's transaction executes at a worse rate and the bot closes its position after the price movement. The user pays the cost through slippage, while the bot captures the difference.
A private transaction flow changes the information environment. If transactions are sent through an authenticated or encrypted channel and are not broadcast to an open pool, ordinary searchers cannot inspect them before execution. That can reduce a major class of attacks.
It could also help agents trade with more predictable execution. An agent that knows its order will not be publicly exposed may be less vulnerable to copy trading and toxic order flow. This could make decentralized markets more attractive for strategies that currently operate through centralized exchanges or private execution systems.
Yet privacy is not the same as neutrality. The network must still determine which transactions are accepted and in what order. Someone has access to the transaction stream before the public does. That party may be a validator, a block builder, a gateway operator or a coordinated group of infrastructure providers.
If the private system uses trusted relays, those relays could become a new chokepoint. If it uses encryption, the network must explain when and how transactions are decrypted, who can decrypt them and whether the decryption process can be manipulated. If a leader receives all orders before constructing a block, it may possess a decisive trading advantage even without a public mempool.
The design therefore shifts the MEV question from public visibility to institutional access.
MEV, or maximal extractable value, describes the profit available from controlling transaction inclusion, exclusion and ordering. A no-mempool architecture may prevent one type of MEV while preserving others. A validator might not be able to sandwich a trade in the traditional way, but it could delay an order, censor a competing order, prioritize a favored agent or use private information to trade in a connected market.
That is why the claim that front running becomes impractical should be treated as a specific security claim, not a general guarantee that extraction disappears.
Fast leader rotation is not automatic decentralization
BNB Chain's proposed answer to validator power includes fast rotating block leaders and public ordering audits. These mechanisms are intended to reduce the time any single participant controls the ordering process and to make improper behavior detectable after the fact.
Frequent rotation can limit the duration of a leader's advantage. If a validator controls ordering for only a short interval, it may have less opportunity to manipulate a sustained stream of trades. Rotation can also make it harder for one operator to censor a user over a long period.
But rotation does not necessarily prevent coordination. A group of validators could share transaction information, agree on preferred ordering or divide opportunities among themselves. If the validator set is small or concentrated among related entities, the formal rotation schedule may conceal a practical concentration of power.
The relevant question is not simply how often leadership changes. It is how many independent entities participate, how much stake or reputation is required to become a leader, whether leaders can be identified in advance and what happens when one refuses to include a transaction.
Public ordering audits could provide an important accountability layer. A user or researcher should be able to reconstruct the order in which transactions were received, proposed and finalized. If the system records commitments to transaction batches before execution, an audit may reveal whether a leader changed the order, withheld an order or inserted an advantageous transaction.
Audits are most effective when they are timely and enforceable. A report published weeks after a trade may prove that manipulation occurred without returning the lost value or deterring future misconduct. The system would need clear rules for what counts as a violation, transparent evidence standards and penalties that outweigh the value of extraction.
There is also a distinction between detecting unfair ordering and proving that the ordering was unfair. If transactions are private, an external observer may know that an order was delayed but not know what the validator saw at the time. A validator can argue that a transaction arrived late, failed validation or conflicted with another transaction. The audit system must preserve enough cryptographic evidence to distinguish technical failure from discretionary censorship.
This is a difficult design problem because stronger privacy can reduce the information available for accountability. The network needs to hide pending orders from opportunistic traders while revealing enough execution data to let independent observers test whether operators behaved honestly.
Censorship is the broader risk
Front running receives most of the attention because it is easy to visualize, but censorship may be the more serious concern in a private order flow system.
A validator that controls transaction admission can decide which agents reach the execution stage. It may delay a liquidation until a preferred account is ready, reject an order that competes with its own strategy or restrict access to a particular trading venue. If the chain is used by AI agents managing funds automatically, even brief censorship could create material losses.
Censorship resistance depends on the ability of users to submit transactions through multiple independent paths. If all transactions must pass through a small set of official gateways, those gateways could become de facto intermediaries. The network might remain decentralized at the consensus layer while becoming centralized at the transaction access layer.
BNB Chain will need to clarify whether users can run their own submission infrastructure, whether encrypted transactions can be routed without permission and how the system handles a malicious or unavailable gateway. It should also disclose whether validators see transaction contents before execution and whether they can selectively refuse orders without being identified.
A credible system could combine private submission with mandatory inclusion rules. For example, once a transaction meets defined validity conditions and reaches the network within a specified window, a leader might be required to include it or provide a verifiable reason for exclusion. Such rules would not eliminate discretion, but they could narrow the space for hidden favoritism.
Fallback mechanisms could matter as well. If the private flow fails, users may need a public or alternative submission route. That route could carry different execution guarantees, but it would prevent a single private channel from becoming a single point of failure.
The bridge could decide whether the network has liquidity
A specialized trading chain faces a second problem after performance: market depth.
Agents need access to assets, stablecoins, liquidity pools and lending markets. If those resources remain on BNB Smart Chain, the new Layer 1 could offer excellent execution while lacking the capital needed for meaningful trading. If liquidity moves to the new network, users may face fragmentation between two BNB Chain environments.
BNB Chain plans to address that risk with an official bridge linking the new chain to BNB Smart Chain. The bridge could allow assets to move between the networks and give agents access to liquidity that already exists in the broader BNB ecosystem.
An official bridge is useful, but it does not automatically make liquidity fungible. Moving an asset across chains introduces time, fees, bridge risk and balance management. Market makers must decide how much capital to keep on each network. Traders must understand whether two tokens with the same name represent the same claim and whether withdrawals remain available during a network outage.
The bridge's design will be central to the project's security profile. A custodial bridge may be simple for users but concentrate control in an operator or multisignature group. A smart contract bridge may reduce reliance on a custodian while introducing verification and message passing risks. A native interoperability system may improve integration but require additional validator assumptions.
Liquidity fragmentation can also appear at the application level. A decentralized exchange deployed on BNB Smart Chain does not automatically become available on the new Layer 1. Developers may need to deploy separate contracts, market makers may need to seed separate pools and users may need to manage separate gas assets. The bridge can move capital, but it cannot by itself recreate the same trading depth and composability.
The most successful approach may be to make the new chain a specialized execution venue while keeping broader assets and applications connected to BNB Smart Chain. That model would resemble a high-performance market infrastructure layer attached to a general purpose ecosystem. Its success would depend on whether the connection is fast and reliable enough that users do not feel trapped on either side.
AI agents raise the stakes
BNB Chain's focus on agents reflects a broader change in how blockchain applications may be used. Today's onchain activity is still dominated by human-directed interfaces, including wallets, exchanges and decentralized applications. AI agents could create a more continuous form of activity. They may monitor markets, rebalance portfolios, pay invoices, manage collateral and negotiate transactions without a person approving each step.
That shift creates demand for fast execution, but it also changes the security model. A human may notice an unusually high fee or an unexpected transaction. An agent can repeat a flawed strategy thousands of times before an operator intervenes. A small ordering disadvantage, multiplied across a large number of automated trades, can become a significant cost.
Agents also need clear permissions and spending limits. A high-speed chain does not solve the problem of an agent acting on manipulated data, calling a malicious contract or submitting transactions under adverse conditions. The network could eventually support safeguards such as programmable limits, transaction simulation, encrypted intent submission and policies that allow agents to cancel or replace orders.
These features could become a competitive advantage if BNB Chain treats the Layer 1 as more than a faster settlement engine. Developers will want reliable software development kits, monitoring tools, agent identity systems and ways to audit automated behavior. Trading firms will want predictable fees and service-level data. Businesses will want compliance controls and recovery options.
The chain's architecture may also influence who can participate. If running a validator or accessing the private transaction flow requires specialized hardware or commercial approval, performance could come at the cost of openness. That trade-off may be acceptable for some trading applications, but it should be explicit. A network designed for professional agents will be judged not only by its decentralization claims but also by the quality of its access rules.
What to watch before launch
The planned testnet will offer the first opportunity to test whether the project's claims survive real conditions. Developers and independent researchers should look beyond the maximum transactions per second and examine how the system behaves when agents compete for the same liquidity.
Several measurements will be especially important. The first is end to end latency, from transaction submission to preconfirmation and then to irreversible finality. The second is performance under burst traffic, including simultaneous orders from thousands of agents. The third is the percentage of transactions that are delayed, dropped or reordered.
The testnet should also expose the validator architecture. Users will need information about the number and geographic distribution of validators, the admission process, the leader rotation schedule and the consequences of nonperformance. A small group of operators may deliver impressive speed, but it would raise questions about resilience and control.
The ordering audit system should be tested with adversarial examples. Can an independent observer determine whether a validator saw a transaction before another one? Can the system identify selective delays? Can users prove that an order was submitted on time? Are penalties automatic, discretionary or nonexistent?
Finally, the bridge should be tested under stress rather than demonstrated only through successful transfers. Researchers will want to know how the system handles delayed messages, validator disagreements, chain reorganizations and emergency pauses. A bridge that connects two fast networks can also connect their failure modes.
BNB Chain's new Layer 1 represents a credible attempt to build infrastructure around the needs of automated trading rather than adapting a general purpose chain after the fact. Its private transaction flow could reduce a well known source of harm in decentralized finance, and its focus on low latency may give AI agents a more practical environment for onchain execution.
The project's defining challenge, however, is institutional rather than purely technical. Removing the public mempool changes who can see orders, but it does not remove the economic value of seeing them. Fast leader rotation and public audits may constrain that power, but only if the validator set is independent, the evidence is complete and the penalties are real.
The testnet will show whether BNB Chain can turn ambitious performance targets into a usable market infrastructure. It will also reveal whether the network has found a way to make private execution accountable. If it succeeds on both fronts, the chain could become a foundation for automated finance. If it succeeds only on speed, it may create a faster venue where market power is harder for users to observe.