$BNB Chain is headed for another major upgrade, and this time the focus isn’t on how much faster the network can go, but on how well it can hold up when real users start working hard on it. The Osaka/Mendel hard fork is scheduled for April 28, 2026 at 02:30 UTC, and $BNB Chain’s own release notes say the mainnet upgrade is mandatory for BSC users, listing v1.7.2 as the required release prior to the fork. The upgrade bundles nine BEPs and includes changes such as a protocol-level transaction gas limit under BEP-652, along with blob-related and execution fixes in the mainnet release.
That timing is important because $BNB Chain has been aggressively chasing speed over the past year. The Lorentz hardfork cuts block times from 3 seconds to 1.5 seconds, paving the way for faster confirmations and stronger validator synchronization. Maxwell then pushed BSC further back to block times of 0.75 seconds, while the Fermi hardfork recently pushed BSC to around 0.45 seconds and emphasized predictable performance as network usage grows. Together, these upgrades have changed $BNB Chain in one of the fastest major EVM networks, but they have also emphasized the importance of stability, throttle consistency and execution quality.
Osaka/Mendel seems to be the next step in that story, but with a different emphasis. Rather than trying to push block production even lower, the fork is focused on tightening up how the chain behaves under pressure. That means fewer surprises during congestion, more predictable throttle behavior, and a cleaner experience for developers who need to model how transactions will actually perform under live conditions. In a network that already operates at sub-second speeds, the difference between a chain that is merely fast and one that is fast and consistent becomes much more visible.
Aimed at refining network performance
One of the clearest changes in the Mendel documentation is the introduction of a protocol-level limit on individual transaction gas via BEP-652, which implements EIP-7825 and rejects transactions above 16,777,216 gas during validation. That’s not the kind of change that regular users will notice at a glance, but it’s exactly the kind of rule that helps a chain remain stable when activity spikes. By setting hard limits around heavy transactions, $BNB Chain tries to keep execution predictable rather than allowing outliers to disrupt block processing.
The Osaka side of the upgrade also brings several Ethereum-aligned execution changes that point in the same direction. In the BSC changelog, the Osaka code sync includes EIP-7823 for upper limits on MODEXP, EIP-7825 for transaction gas limits, EIP-7883 for ModExp gas fee increases, EIP-7918 for capping blob base fees based on execution costs, EIP-7934 for execution block size limits, EIP-7939 for the CLZ opcode, and EIP-7951 for secp256r1 curve support. In practical terms, this means more precise execution rules, more efficient low-level computations, and better compatibility with cryptographic standards outside the usual Ethereum stack.
That cryptography piece is especially important for developers building infrastructure that needs to talk to more than one ecosystem. The secp256r1 support makes it easier to connect to systems that rely on standards other than Ethereum’s standard curve, which can be important for authentication flows, enterprise integrations, and applications that need to bridge onchain and offchain security models. The CLZ opcode is the kind of addition that most users will never see, but developers can use it to make execution more efficient at the bytecode level, which is exactly where small optimizations start to matter once the network is already moving quickly.
This is also evident from Mendel’s release notes $BNB Chain pays a lot of attention to blob-related behavior and fast finality. The changelog includes support for blob sidecar validation for bids, while previous Osaka/Mendel testnet notes show BEP-657 for limiting the inclusion of blob transactions based on block number and BEP-655 for block size checks. Different $BNB Chain notes also refer to BEP-648, described as enhanced fast finality via a memory voting pool. Taken together, these changes suggest that the fork is about more than just transit. It’s about ensuring fasteners remain fast, reliable and resilient as usage grows.
There is also a broader strategic message in the fork. $BNB Chain has already proven that he can go from 3-second blocks to 1.5 seconds, then to 0.75 seconds, and then to Fermi’s goal of 0.45 seconds. Osaka/Mendel suggests that the chain is now shifting from pure speed gains to maturity. In other words, the network has already won the headline race. What comes next is the less glamorous but often more important task of ensuring that speed actually outlives real-world demand, heavy computation, and the messy edge cases that appear once a blockchain is used by millions rather than measured in a lab.
That’s why Osaka/Mendel feels important, even if it doesn’t come with a dramatic new speed record. It is a maintenance of momentum, but also a refinement of purpose. $BNB Chain still moves fast, but this time it tries to ensure that speed comes with discipline. If the upgrade lands on April 28 as planned, the real test won’t be whether $BNB Chain can go faster than before. The question will be whether it can remain this fast without developers or users having to pay for the privilege.