BNB Chain Flags Critical Update Ahead of April 28 Hard Fork

The countdown for the Osaka/Mendel hard fork has begun. In this light, BNB Chain developers' X account issues a notice to node operators on a mandatory update to perform before April 28. The Osaka/Mendel hard fork will launch on the BSC mainnet 16 days from now, on April 28 at 2:30 a.m. UTC.

Before the Osaka/Mendel fork (April 28, 02:30 UTC), make sure your node is ready: • Upgrade to BSC v1.7.2 • Binary replacement is enough • Clean up old config fields

Missing this puts your node at risk of falling out of sync.

— BNB Chain Developers (@BNBChainDevs) April 12, 2026 Ahead of the Osaka/Mendel fork, node operators need to get their nodes in order and upgrade to BSC v1.7.2. It is also important to ensure that binary replacement is properly set up and to clean up any outdated configuration fields. This is to prevent their nodes from losing sync. The Osaka mainnet upgrade comes about a month after its launch on testnet. On March 24, the Osaka/Mendel hard fork was activated on the BSC testnet at block 88,379,325. The upgrade brought about more reliable block construction, improved transaction handling at scale, stronger network stability and execution accuracy.

Osaka/Mendel hard fork

Mendel introduces EIP-7825 via BEP-652, which adds a transaction gas limit cap at the protocol level. BEP-652 suggests implementing a protocol-level limit on the maximum gas consumption for each transaction on BSC, capping it at 16,777,216 (or 2^24). This ensures all nodes uniformly reject transactions exceeding the limit, which can better improve network stability and reliability compared to the prior approach of an optional soft cap mechanism. The Mendel network upgrade encompasses nine BEPs. Of the 13 EIPs proposed within Ethereum's Fusaka scope, BSC integrated seven. This included six necessitating a hard fork and one as a client-side RPC update. The other six EIPs were not adopted, primarily because of architectural discrepancies. Beyond these, the upgrade also brings two BSC-specific improvements. BEP-657, for instance, restricts the inclusion of blob transactions based on block number. BEP-648, on the other hand, aims to decrease latency and accelerate finality.