BNB Chain developers issued a mandatory software notice on April 12, ordering every BSC mainnet node operator to install version 1.7.2 before the Osaka/Mendel hard fork goes live on April 28, 2026, at 02:30 AM UTC.
Any node still running older software when the fork triggers risks falling out of sync with the chain. That means disrupted service for validators, RPC providers, exchanges, and infrastructure firms that build on BSC.
How the Upgrade Works, and Why the Steps Matter
The BNB Chain developer account on X confirmed that a straightforward binary replacement is enough to complete the transition. No full database resync or chain replay is required. Operators must also scrub any JournalFileEnabled entry from their configuration files and clear other outdated config fields. The team warned that missing either step leaves nodes at risk of losing chain sync at the fork boundary.
The GitHub release page for v1.7.2 marks the update as “Mandatory: YES” and lists the fork time as April 28, 2026, 02:30:00 AM UTC. The changelog includes blob sidecar validation support for bids and several fixes pulled from the upstream go-ethereum codebase.
What BEP-652 Changes About BSC Transaction Gas Limits
The Osaka/Mendel package bundles nine BNB Evolution Proposals. The most consequential is BEP-652, which ports Ethereum’s EIP-7825 to BSC and imposes a hard protocol-level gas ceiling of 16,777,216 (2²⁴) per transaction. The previous limit was an optional soft cap that individual node operators could configure differently, creating room for inconsistent behavior across the network.
Under BEP-652, all nodes will reject any transaction that exceeds the ceiling uniformly. Developers say that uniform enforcement reduces client inconsistency and lifts overall network reliability more than a voluntary mechanism can.
Two further BEPs address network timing. BEP-657 restricts when blob transactions can appear in a block, tying inclusion eligibility to block number. BEP-648 targets finality latency, aiming to shorten the time before a block is considered irreversible.
Beyond BSC-specific changes, the upgrade integrates seven of the 13 Ethereum Improvement Proposals from Ethereum’s Fusaka scope. Six required a hard fork; one was applied as a client-side RPC update. The remaining six EIPs were not adopted because of structural differences between the two chains.
Testnet Results From March 24 That Cleared the Way for Mainnet
BNB Chain activated the Osaka/Mendel fork on the Chapel testnet on March 24, 2026, at block 88,379,325. Developers reported the test phase produced more reliable block construction, better transaction handling at scale, and stronger execution accuracy. The mainnet date was set approximately one month after that run, following standard BSC upgrade practice.
What Operators Must Do Before the Fork
Three actions are required before April 28, 2026, at 02:30 AM UTC:
- Replace the existing BSC binary with v1.7.2 from the official GitHub repository.
- Verify that no
JournalFileEnabledfield remains in the node configuration file. - Remove any other deprecated config entries flagged in the release notes.
The BNB Chain developer team has not announced a rollback path for nodes that miss the deadline.
Disclaimer
For paid/sponsored articles, FintechMode neither endorses nor takes responsibility for the accuracy, timeliness, quality, and content of said articles. The statements, views and opinions expressed in paid/sponsored articles are solely those of the content provider and readers are reminded that Cryptocurrency products are unregulated in most locations and can be highly risky. Do your own research and consult relevant financial experts before making any investment decisions. FintechMode will not be held accountable, either directly or indirectly, for any harm or loss that may stem from or be linked to the usage or reliance on any information, goods, or services mentioned on this page. If you have any concerns, please email [email protected] or refer to our Terms & Conditions
