BNB Chain is heading into another major upgrade, and this time the focus is not on how much faster the network can go, but on how well it can hold up when real users start pushing it hard. 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, with v1.7.2 listed as the required release ahead of the fork. The upgrade bundles nine BEPs and includes changes such as a protocol-level transaction gas cap under BEP-652, along with blob-related and execution-level fixes in the mainnet release.
That timing matters because BNB Chain has spent the past year aggressively chasing speed. The Lorentz hard fork cut block times from 3 seconds to 1.5 seconds, setting the stage for faster confirmations and stronger validator synchronization. Maxwell then pushed BSC down further to 0.75-second block times, while the Fermi hard fork most recently took BSC to about 0.45 seconds and emphasized predictable performance under growing network usage. Together, those upgrades turned BNB Chain into one of the fastest major EVM networks, but they also raised the importance of stability, gas consistency, and execution quality.
Osaka/Mendel looks like the next step in that story, but with a different emphasis. Instead of trying to squeeze block production even lower, the fork is aimed at tightening how the chain behaves under pressure. That means fewer surprises during congestion, more predictable gas behavior, and a cleaner experience for developers who have to model how transactions will actually perform in live conditions. In a network that is already operating at sub-second speed, the difference between a chain that is merely fast and one that is fast and consistent becomes much more visible.
Aiming to Refine Network Performance
One of the clearest changes in the Mendel documentation is the introduction of a protocol-level cap on individual transaction gas through BEP-652, which implements EIP-7825 and rejects transactions above 16,777,216 gas during validation. That is not the kind of change casual users notice at a glance, but it is exactly the sort of rule that helps a chain stay stable when activity spikes. By setting hard boundaries around heavy transactions, BNB Chain is trying to keep execution predictable rather than allowing outlier workloads to distort block processing.
The Osaka side of the upgrade also brings in several Ethereum-aligned execution changes that point in the same direction. In the BSC changelog, the Osaka code sync includes EIP-7823 for upper bounds on MODEXP, EIP-7825 for transaction gas limits, EIP-7883 for ModExp gas cost increases, EIP-7918 for bounding blob base fees by execution cost, EIP-7934 for execution block size limits, EIP-7939 for the CLZ opcode, and EIP-7951 for secp256r1 curve support. In practical terms, that means more precise execution rules, more efficient low-level computation, and better compatibility with cryptographic standards that sit outside the usual Ethereum stack.
That cryptography piece is especially important for developers building infrastructure that has to talk to more than one ecosystem. The secp256r1 support makes it easier to connect with systems that rely on different standards than Ethereum’s default curve, which could matter 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.
The Mendel release notes also show that BNB Chain is paying close attention to blob-related behavior and fast finality. The changelog includes support for blob sidecar validation for bids, while earlier Osaka/Mendel testnet notes show BEP-657 for limiting blob transaction inclusion by block number and BEP-655 for block size checks. Separate BNB Chain notes also reference BEP-648, described as enhanced fast finality via an in-memory voting pool. Taken together, those changes suggest the fork is about more than throughput alone. It is about making sure confirmations remain quick, reliable, and resilient as usage grows.
There is also a broader strategic message in the fork. BNB Chain has already proven that it can move from 3-second blocks to 1.5 seconds, then to 0.75 seconds, and then to Fermi’s 0.45-second target. Osaka/Mendel suggests the chain is now shifting from raw 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 job of making sure that speed actually survives 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 is why Osaka/Mendel feels significant even if it does not arrive with a dramatic new speed record attached to it. It is a maintenance of momentum, but also a refinement of purpose. BNB Chain is still moving fast, yet this time it is trying to make sure speed comes with discipline. If the upgrade lands as planned on April 28, the real test will not be whether BNB Chain can go faster than before. It will be whether it can stay this fast without making developers or users pay for the privilege.
