​
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 seconds

​
Chainstack nodes are Lorentz-ready

Chainstack nodes are prepared for the Lorentz network upgrade.

Here’s what you need to know:

  • 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

The most important changes that may affect you as a dApp developer are gas limit per block and faster block times.

The gas limit per block is an obvious one—slashing 140 million gas to 70 million gas means you can fit fewer heavy compute transactions in a block.

Now let’s focus on faster block times

​
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:

  "baseFeePerGas": "0x0",
  "blobGasUsed": "0x0",
  "difficulty": "0x2",
  "excessBlobGas": "0x0",
  "extraData": "0xd883010509846765746888676f312e32332e37856c696e7578000000c011f0d2f8b27fb860a72b39a61672bf9410fecd9432d18ab0285d4475cc22583b71cf485b0c35d4109d83576db2dd1244484e36a6d9133f46159499e3db3db964b9dd4b9b2c7e185dbc2e3716df7b77befbd89ee2df8dd3d66c54f4a1fad622e1480dc019e35373c8f84c840303fa92a0db41c2b264c7bf23960962bc8e3d92f3538671c28f705760f0d700b17982d0fc840303fa93a0be106c47b19b9cc0341e36e6635202c3ed9b8548511f5f6c9bff56e9168f41b5801c415589572c27ab7d9ba60074e2148896ec1c10881891a52f43ead9084310fa58d5d44846a51c87a42d0f94194df1dc6e226747a693e64694bf9dce51610cd600",
  "gasLimit": "0x42c1d80",
  "gasUsed": "0xe464f9",
  "hash": "0xe58794d2ee429567b8107cbad4a67eb70929616748c4a0f4d76df436e5c56f6b",
  "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  "milliTimestamp": "0x1965c14398c",
  "miner": "0xd447b49cd040d20bc21e49ffea6487f5638e4346",
  "mixHash": "0x00000000000000000000000000000000000000000000000000000000000001f4",
  "nonce": "0x0000000000000000",
  "number": "0x303fa94",
  "parentBeaconBlockRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "parentHash": "0xbe106c47b19b9cc0341e36e6635202c3ed9b8548511f5f6c9bff56e9168f41b5",
  "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  "requestsHash": "0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
  "size": "0x37f",
  "stateRoot": "0x7c7abdcf4b9b0e660e5a3002f9946be0be54b1e99e3208e621598b443f254e37",
  "timestamp": "0x6807302f",
  "totalDifficulty": "0x6043378",
  "transactions": [],
  "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  "uncles": [],
  "withdrawals": [],
  "withdrawalsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421"

And pre-fork and pre-node-upgrade:

  "baseFeePerGas": "0x0",
  "blobGasUsed": "0x0",
  "difficulty": "0x2",
  "excessBlobGas": "0x0",
  "extraData": "0xd883010508846765746888676f312e32342e30856c696e7578000000ce18f5d3f8b5831effffb8609291fcd043ec871f0f8c00a11ef5a4e74164698519f3b391ed741010d736594d024b346d36092761a54899cdee613aa5063c028128f9a26884426ae237ea09ff38735645774849ccaf3e644655dcecf65e723ea971cb7aeeab8a25dd1185fa52f84c8402e52cffa04a0bda48a3d029c68c6663306c341213aad0ba3ff5d16f8c3251a59895641b4a8402e52d00a05e4a10dd4dcaa30a1eb6c194ae42abbda4f49632a0bbd37e4d6b48b45c9093f48030faf0179c11484aa23403d9619926beda9cb93ea4fc6e40e5e03ab46b64839b2474871bc03cd01bb57497c3fd7c97af75a42f7095dda366761ec21014bdb6df01",
  "gasLimit": "0x8583b00",
  "gasUsed": "0xe464f9",
  "hash": "0xe58794d2ee429567b8107cbad4a67eb70929616748c4a0f4d76df436e5c56f6b",
  "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  "miner": "0xd447b49cd040d20bc21e49ffea6487f5638e4346",
  "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "nonce": "0x0000000000000000",
  "number": "0x303fa94",
  "parentBeaconBlockRoot": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "parentHash": "0xbe106c47b19b9cc0341e36e6635202c3ed9b8548511f5f6c9bff56e9168f41b5",
  "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
  "size": "0x37f",
  "stateRoot": "0x7c7abdcf4b9b0e660e5a3002f9946be0be54b1e99e3208e621598b443f254e37",
  "timestamp": "0x6807302f",
  "totalDifficulty": "0x6043378",
  "transactions": [],
  "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  "uncles": [],
  "withdrawalsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421"
FieldPre-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.
milliTimestampNot presentAdded (e.g., 0x1965c14398c)Introduced by BEP-520 to support 1.5-second block spacing without breaking the EVM’s second-based timestamp system.
mixHashAll 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.
requestsHashNot presentPresent (e3b0…b855 = empty SHA-256)Introduced in EIP-7685 and implemented on BSC as part of BEP-466 and exposed with the upgrade node version.

Let’s have a look at 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:

timestamp = int("0x6807302f", 16)      # 1745301551 s
ms        = int("0x1f4", 16)           # 500 ms
milli_ts  = timestamp * 1000 + ms      # 1745301551500
hex(milli_ts)                          # '0x1965c14398c'

And there you have it. Unless your service heavily relies on block numbers or block timestamps, you don’t have much to worry about.

​
About the author

8_Bi4fdM_400x400

Ake

Director of Developer Experience @ Chainstack

Talk to me all things Web3

20 years in technology | 8+ years in Web3 full time years experience

Trusted advisor helping developers navigate the complexities of blockchain infrastructure