BNB Chain's new L1 adds one more chain, but not one more coin. Early this morning, CZ quoted a Chinese interpretation, simply stating "Multiple chains, one coin" refers to the same thing. @BNBCHAIN has uploaded the new L1 technical documentation to the official website. I. What's New This Time? The new L1 isn't new news. The H2 roadmap on July 8th mentioned that the design goal for the next-generation L1 is over 100,000 TPS, pre-confirmation within 50 milliseconds, and finality within 1 second, with a planned testnet launch at the end of 2026 and a mainnet launch in early 2027. The change this time is the documentation. The GitHub docs: add NewL1 docs were merged on October 22nd (Beijing time). The parameters are more specific than in the roadmap: block interval is 200 milliseconds, sub-block pre-confirmation is approximately 20 milliseconds, consensus is an enhanced version of Parliament, each validator produces 16 consecutive blocks per round, and the gas asset is BNB, which was transferred from BSC. Comparing the two, the same roadmap shows BSC's performance in the first half of the year as: block time 450 milliseconds, memory finality 650 milliseconds, and baseline throughput of approximately 5,200 TPS. The new chain's figures represent design goals, while BSC's are actual results; they cannot be directly compared. Second, the documentation clearly states that BNB is the new chain's native asset, and no new token will be issued. BNB uses a native bridge to cross from BSC to pay gas. Staking BNB on StakeHub yields non-transferable govBNB at a 1:1 ratio for governance. The native bridge is still under development. A common practice for public chains creating a second chain is to create a new token. BNB Chain chooses to channel demand back to a single asset; this is what CZ referred to as "one coin." Whether demand will ultimately return to BNB depends on actual transaction volume after the new chain launches; there is no data to confirm this today. Third, three easily overlooked details: 1. There is no public mempool; transactions are directly sent to the current and next block producer. The advantages are low latency and prevention of block preemption; my question is that the ordering is more concentrated in the hands of the block producer, and we need to see how subsequent rules will constrain this. 2. Billing is based on the declared gas limit, not actual consumption. Because execution is done after ordering, the wider the declared gas limit, the higher the cost. 3. Bounded EVM behavior remains unchanged, but eth_getProof, EIP-4844, and EIP-7702 transactions are not supported. The FAQ for the native privacy pool circuitry states that it has not yet been audited and is not suitable for storing real funds. IV. What to watch next: Currently, it's still the internal development network with multiple validators, with just over two months until the end-of-year testnet. Three things to watch: whether the public testnet can be launched on time, when the native bridge will be available, and how the reserved channels for Multi-Lane will be allocated (they need to be registered in the LaneRegistry and undergo governance). This is more indicative of who will ultimately use this chain than TPS figures. High-frequency trading, payments, and AI proxies—BNB Chain is betting its next phase on these areas, and has chosen the path of not decentralizing BNB. @binancezh Documentation: https://docs.bnbchain.org/newl1/overview/