BNB Smart Chain (BSC) smart contracts can now see block time down to the millisecond. The change comes from BEP-706, which is part of the Jenner hardfork and adds a precompile at address 0x70. Calling it returns the timestamp of the current block in milliseconds. Contracts built on block.timestamp see no change and keep receiving whole seconds.
Players won’t notice anything here, since the upgrade is aimed at developers and doesn’t name a single game. Its audience is any BSC app that has to separate events happening less than a second apart, for example auctions with tight deadlines or offers that expire fast.
Why whole seconds fall short
Reading block.timestamp gives a contract the time in whole seconds. Because BSC regularly produces more than one block within a single second, contracts miss timing detail that the chain is already storing.
Picture one block stamped 12:00:00.200 and another stamped 12:00:00.800. They sit 600 milliseconds apart, yet block.timestamp reports the same second for both. For an auction deadline under a second, or a signed quote, that difference counts.
The example BEP-706 gives is request-for-quote settlement. Say a market maker signs a quote that stays valid for only a few hundred milliseconds. A settlement contract limited to whole seconds must round that cutoff, which means it could honour the quote for longer than planned or turn it down too soon.
Millisecond timestamps let apps draw those lines more tightly. The same values work for auction deadlines and for checking how fresh a price feed update is. Whether pricing or execution actually improves comes down to how each app is built.
Inside the precompile
Under BEP-520, BSC block headers already include millisecond data. The seconds field hasn’t moved, and a separate header component holds the leftover milliseconds within that second. Consensus already has nodes validating this data.
What the new precompile does is expose that value to smart contracts. A contract sends a read-only static call to 0x70 and receives a 32-byte unsigned integer giving milliseconds since the Unix epoch. No arguments are needed, and any calldata is ignored.
BEP-706 puts the precompile’s computation charge at 20 gas. On top of that, the calling contract pays the normal call and memory costs, so a full read costs more than 20 gas.
Millisecond precision only applies to contracts that call the precompile. Anything computing deadlines with block.timestamp and second-based durations keeps its current units and behaviour.
What stays the same
The precompile returns the timestamp of the block being executed, so all transactions in that block see an identical number. It tells you nothing about when a transaction hit the network or the precise moment a particular transaction ran.
Trust works as it does with block.timestamp. Validators provide timestamps inside consensus constraints, and the added precision doesn’t alter the timing assumptions apps already rely on.
Developers should spell out units in contracts, signatures and backends alike. A deadline signed in milliseconds needs to be checked against a millisecond timestamp. Mix seconds and milliseconds and an expiry can come out far too short or far too long, with nothing raising an alarm.
Integration checks and simulation tools
Integrations should confirm both that the call succeeds and that it returns the expected 32 bytes. Until activation, the address acts like an empty account, so a low-level call can succeed and still return no timestamp. A successful call alone doesn’t show the feature is live.
The release notes for reth-bsc v0.1.3 cover a related change for tools that override block values during simulation. In eth_call, eth_estimateGas, debug_traceCall and eth_simulateV1, any supplied blockOverrides.prevRandao has to encode a millisecond remainder between 0 and 999 as a 32-byte hexadecimal value.
The time override still uses seconds, and overriding only the time sets the millisecond remainder back to zero. These checks kick in once a node moves to v0.1.3, even ahead of Jenner’s activation, so teams relying on block overrides should refresh their test inputs when they upgrade the client.