BNB Chain has issued an urgent warning to all node operators, validators, and exchange partners: upgrade your software before April 28 or risk being left behind on the wrong chain. On April 12, BNB Chain developers posted a formal notice through their official X account confirming that the Osaka/Mendel hard fork is scheduled to activate on the BSC mainnet at 2:30am UTC on April 28. The required update, BSC version 1.7.2, has been live for download since the testnet activation on March 24, and the development team has made clear that failure to complete the upgrade before the fork time will leave non-compliant nodes out of sync with the rest of the network. With fifteen days now remaining and a hard fork affecting one of the largest smart contract networks in crypto, the window for action is narrowing.
What the Warning Actually Says
BNB Chain told node operators to install BSC v1.7.2 before the Osaka/Mendel hard fork launches. The April 28 mainnet upgrade follows testnet activation and adds stability, gas limits, and finality. BNB Chain said outdated settings and poor binary replacement could cause nodes to lose sync.
Ahead of the Osaka/Mendel fork, node operators need to upgrade to BSC v1.7.2, ensure that binary replacement is properly set up, and clean up any outdated configuration fields. This is to prevent their nodes from losing sync.
The official GitHub release note is equally direct. The release is marked “Mandatory Update Required: YES” with the target audience listed as all BSC mainnet users. The procedure is described as “simply binary replacement should be good,” with the additional instruction to ensure no ‘JournalFileEnabled’ field remains in the configuration file. The schedule is set for before April 28, 2026 at 2:30am UTC.
What the Osaka/Mendel Upgrade Actually Changes
The naming convention follows BNB Chain’s tradition of pairing city names with scientists. Osaka refers to the broader upgrade package, while Mendel, named after the father of modern genetics, refers to the specific set of protocol changes being introduced at the consensus layer. Together they represent nine BNB Evolution Proposals, or BEPs, landing simultaneously on mainnet.
The most significant technical change is a new protocol-level gas cap. The Mendel upgrade adds BEP-652, which brings EIP-7825 into BNB Chain through a protocol-level gas cap for each transaction. The cap is set at 16,777,216 gas. That change means all nodes will reject transactions above the limit in the same way. BNB Chain said this method is more reliable than the earlier soft cap model that operators could treat differently.
This standardisation matters for network consistency. Under the previous soft cap model, individual node operators could configure their own transaction gas limits differently, creating potential divergence in how the network processed large transactions. The hard cap enforced at protocol level means the entire network behaves identically, removing a source of edge-case inconsistency that could cause issues at scale.
Beyond the gas cap, two BSC-specific improvements address performance and blob handling. BEP-657 restricts the inclusion of blob transactions based on block number. BEP-648 aims to decrease latency and accelerate finality. Reduced latency and faster finality are persistently important objectives for BNB Chain, which targets high-throughput applications including DeFi protocols, GameFi, and payment infrastructure that require near-instant transaction confirmation to function effectively.
The Ethereum Fusaka Connection
One of the less-discussed but structurally significant aspects of the Osaka/Mendel upgrade is BNB Chain’s selective adoption of Ethereum Improvement Proposals from Ethereum’s own Fusaka upgrade. BNB Chain said it adopted seven of the 13 Ethereum proposals linked to Fusaka, including six that required a hard fork and one client-side RPC change. The other six EIPs were not adopted, primarily because of architectural discrepancies.
This selective adoption reflects BNB Chain’s ongoing strategy of tracking Ethereum’s technical development while adapting proposals to fit its own architecture. BNB Chain was originally forked from go-ethereum and has maintained compatibility with the Ethereum Virtual Machine throughout its evolution, giving dApp developers the ability to deploy the same code across both networks. Staying aligned with Ethereum’s core improvements where architecture permits keeps that compatibility intact while allowing BNB Chain to skip proposals that would create more problems than they solve given its different validator set and consensus model.
What the Testnet Results Showed
The April 28 mainnet deployment is not going in cold. 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.
This upgrade, which follows a successful testnet deployment, aims to enhance stability and transaction efficiency. The upcoming Osaka and Mendel upgrades introduce significant protocol changes, including a strict gas limit cap per transaction and various network efficiency improvements. These changes are designed to improve performance and reliability, with the deadline marking a critical compliance point for node operators to prevent disruptions.
The month-long gap between testnet and mainnet activation is standard practice for BNB Chain hard forks and gives validators, exchanges, and infrastructure providers sufficient time to prepare. The timing of the public warning, issued fifteen days before the fork, is consistent with the development team’s established communication pattern on mandatory upgrades.
Who Needs to Act and What Happens if They Don’t
The mandatory update applies to every operator running a BSC mainnet node. That includes independent validators, exchanges that run their own BSC nodes for deposit and withdrawal processing, DeFi protocol infrastructure teams, and any developer running a full node for data indexing or application purposes.
Nodes that fail to upgrade to BSC v1.7.2 before April 28 at 2:30am UTC will not recognise the new consensus rules introduced by the Osaka/Mendel fork. They will continue processing blocks according to the pre-fork ruleset while the rest of the network moves forward, causing them to fall out of sync. For exchanges, this creates a practical risk: deposit and withdrawal processing that relies on an out-of-sync node will operate on stale data, potentially causing transaction failures or incorrect balance readings until the node is manually updated and resynchronised.
The Ethereum treasury sector context is relevant here too. BNB Chain’s tokenised assets have recently hit a record $16.6 billion, with funds reaching $31.9 billion, meaning the network’s upgrade infrastructure directly affects a significant volume of real financial activity. A clean hard fork execution is not just a technical milestone. It is a prerequisite for the continued reliable operation of every protocol, exchange, and application built on BNB Chain’s mainnet.
For node operators who have not yet acted, the process is straightforward. Replace the existing binary with BSC v1.7.2, ensure the configuration file no longer contains the deprecated ‘JournalFileEnabled’ field, and verify the node reconnects cleanly to the network. The development team has confirmed that no database migration or complex reconfiguration is required for operators upgrading from recent prior versions. April 28 is fifteen days away. The window is open and the instructions are clear.
