The countdown for the Osaka/Mendel hard fork has begun. In this light, $BNB Chain Developer’s
The Osaka/Mendel hardfork will launch on the BSC mainnet in 16 days, on April 28 at 02:30 UTC.
Make sure your junction is ready before the Osaka/Mendel fork (April 28, 02:30 UTC):
• Upgrade to BSC v1.7.2
• Binary substitution is sufficient
• Clean up old configuration fieldsIf you miss this, your node is at risk of going out of sync. https://t.co/5xwT0kz8Z2 https://t.co/dA9RcDVK1e
— $BNB Chain Developers (@BNBChainDevs) April 12, 2026
Ahead of the Osaka/Mendel fork, node operators should get their nodes in order and upgrade to BSC v1.7.2. It is also important to ensure that binary replacement is set up correctly and to clean up outdated configuration fields. This is to prevent their nodes from losing synchronization.
The Osaka mainnet upgrade comes about a month after launch on testnet. On March 24, the Osaka/Mendel hard fork was activated on the BSC testnet at block 88.379.325. The upgrade delivered 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 at the protocol level.
BEP-652 proposes to introduce a protocol-level limit on the maximum gas consumption for each transaction on BSC, with a maximum of 16,777,216 (or 2^24).
This ensures that all nodes uniformly reject transactions that exceed the limit, which can better improve network stability and reliability compared to the previous approach of an optional soft cap mechanism.
The Mendel network upgrade includes nine BEPs. Of the thirteen proposed EIPs within Ethereum’s Fusaka scope, BSC integrated seven. This included six that required a hard fork and one as a client-side RPC update. The remaining six EIPs were not adopted, mainly due to architectural differences. In addition, the upgrade also brings two BSC-specific improvements. For example, BEP-657 limits the inclusion of blob transactions based on block number. BEP-648, on the other hand, aims to reduce latency and speed up finality.
