Documentation Index
Fetch the complete documentation index at: https://chainstack-mintlify-flesh-empty-pages.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
Main article
Lorentz is an upgrade hardfork on the BNB Smart Chain mainnet that activates on April 29, 2025. Lorentz introduces one single change: BEP-520: Short Block Interval Phase One: 1.5 secondsChainstack nodes are Lorentz-ready
Chainstack nodes are prepared for the Lorentz network upgrade.- Block time halved from 3 seconds to 1.5 seconds
- Gas limit per block halved from 140 million to 70 million
- Epoch extended from 200 blocks to 500 blocks
- Consecutive block validation per validator increased from 4 blocks to 8 blocks
1.5 second block time
Going from 3 seconds to 1.5 seconds means you will need to be ingesting the blocks at 2x the pre-fork speed. Chainstack infrastructure is handling the nodes, so just make sure your client-side service is ready for that. Now let’s have a look at the block structure.Lorentz block structure
Compare post-fork and post-node-upgrade:| Field | Pre-fork (v1.5.7) | Post-fork (v1.5.11 / Lorentz) | Comment |
|---|---|---|---|
gasLimit | 140,000,000 gas (0x8583b00) | 70,000,000 gas (0x42c1d80) | Block gas limit is halved, but blocks are produced twice as often (every 1.5s instead of 3s). This maintains the same overall throughput while improving transaction confirmation times. |
milliTimestamp | Not present | Added (e.g., 0x1965c14398c) | Introduced by BEP-520 to support 1.5-second block spacing without breaking the EVM’s second-based timestamp system. |
mixHash | All zeros (unused in PoSA; legacy field from PoW) | Low 2 bytes contain sub-second remainder (0x01f4 = 500ms, 0x0000 = 0ms, etc.) | Allows clients to reconstruct the full millisecond timestamp while maintaining the same header size. |
requestsHash | Not present | Present (e3b0…b855 = empty SHA-256) | Introduced in EIP-7685 and implemented on BNB Smart Chains as part of BEP-466 and exposed with the upgrade node version. |
milliTimestamp.
The milliTimestamp field is introduced to keep the original timestamp in integer seconds. With the switch from 3 seconds to 1.5 seconds, the value becomes more granular, allowing for precise millisecond-level timing while maintaining backward compatibility with the existing second-based timestamp system.
The original timestamp value is preserved post-fork, and the previously unused mixHash value now contains the last bytes of the sub-second timestamp to complement the original timestamp value.
This means you can retrieve the post-fork block timestamp either via the milliTimestamp field or via the timestamp + mixHash calculation.
The timestamp + mixHash calculation algorithm:
1. Convert timestamp to decimal seconds: 0x6807302f > 1745301551 s
2. Multiply by 1000 to get milliseconds: 1745301551 × 1000 > 1745301551000 ms
3. Extract the ms remainder from mixHash: 0x…01f4 > 0x1f4 > 500 ms
4. Add them together: 1745301551000 + 500 > 1745301551500 ms
5. Convert back to hex if desired 0x1965c14398c
Or in Python:
