Table of Contents
BNB Chain is accelerating again. The Maxwell hardfork brings a major upgrade to BNB Smart Chain (BSC), reducing block times from 1.5 seconds to 0.75 seconds. This marks the next step in our mission to improve network responsiveness, transaction speed, and validator performance.
The Maxwell upgrade is powered by three key proposals—BEP-524, BEP-563, and BEP-564—each designed to improve core aspects of the chain’s speed and reliability.
What’s Changing?
With Maxwell, BSC will:
- Reduce block interval to 0.75 seconds
- Improve validator communication across the network
- Speed up block syncing between nodes
These enhancements will benefit all network participants—from users and developers to validators and node operators.
From Lorentz to Maxwell: A Continuous Push for Speed
The Lorentz hardfork reduced BSC block times from 3 seconds to 1.5 seconds—laying the groundwork for faster DeFi, smoother UX, and stronger validator performance.
Since then, BNB Chain has:
- Delivered an average transaction fee of just $0.04, according to Dune.
- Achieved the #1 rank in daily DEX volume, according to Dune.
These improvements prove that a faster, cheaper network directly drives user growth and adoption.
In addition to reducing block times from 3s to 1.5s, Lorentz significantly improved BSC’s network stability:
- Reorg frequency dropped from ~5/day to ~2/day
- Block finality became more consistent across validators
- Validator memory usage and block processing latency also decreased
Now with Maxwell, BSC is going sub-second—bringing block times down to 0.75 seconds.
Image Source: Dune
Key BEPs in the Maxwell Hardfork
BEP-524: 0.75-Second Block Intervals
BEP-524 introduces a new block interval of 0.75 seconds, building on the improvements from the Lorentz hardfork (which cut block time from 3 seconds to 1.5 seconds).
This change will:
- Accelerate transaction confirmations
- Improve dApp responsiveness
- Enable smoother DeFi and GameFi interactions
Read the full information about BEP-524 on our GitHub page.
BEP-563: Enhanced Validator Network
With faster blocks, validators need to reach consensus more efficiently. BEP-563 improves peer-to-peer messaging between validators, allowing for:
- Faster block proposal communication
- Reduced risk of missed votes or sync delays
- A more stable validator network under faster conditions
Read the full information about BEP-563 on our GitHub page.
BEP-564: Smarter Block Fetching
BEP-564 introduces two new message types in the bsc/2 protocol:
- GetBlocksByRangeMsg – Request multiple recent blocks in a single call
- RangeBlocksMsg – Return all requested blocks in one response
- This significantly improves sync speeds across the network.
Read the full information about BEP-564 on our GitHub page.
Why This Matters
For Users
Transactions will feel nearly instant. From swaps to mints, every dApp interaction becomes smoother.
For Developers
Lower latency unlocks new design space for dApps—but devs must update time-based logic to avoid race conditions or syncing issues.
For Validators & Node Operators
Expect slightly increased compute demand. With improved P2P messaging and block syncing, Maxwell ensures stable validator operations even under higher load.
To support faster blocks, several consensus parameters are being adjusted under Maxwell:
- Epoch length is increasing from 500 to 1000
- TurnLength is increasing from 8 blocks to 16 blocks (which still equals 12 seconds per validator turn at 0.75s/block)
- Fast Finality is now achievable in ~1.875 seconds, improving confirmation time and consistency
For MEV
A tighter block window changes the game for MEV searchers. MEV builders must adapt to the reduced time window to submit bids—less than one second per block. Some strategies may no longer be viable in a 0.75s block environment.
Timeline: What You Need to Know
- Testnet Hardfork: May 26, 2025
- Release Available: May 20, 2025
- Mainnet Hardfork: June 30, 2025
- Implementation PR
What to do now
- Node operators should upgrade their software before the testnet hardfork on May 26 to begin testing infrastructure compatibility.
- Developers should audit and test their dApps to ensure compatibility with 0.75-second block intervals.
- Validators should assess system performance and prepare for increased block frequency.
More details, including full upgrade instructions and mainnet release notes, will be shared in the coming weeks.
Testnet Exit Criteria
Before Maxwell can be deployed to mainnet, the following criteria must be met:
- Stable block production at 0.75s across testnet validators
- No increase in reorg frequency compared to Lorentz
- Validators must reach consensus without sync delays
- Explorers, RPCs, and indexers must confirm compatibility and performance
- MEV bidding and block proposal logic must be tested and stable under new TurnLength
- Epoch and finality configurations must run reliably for multiple sessions on testnet
