TL;DR

• BEP-706 lets contracts read block timestamps in milliseconds.
• Existing block.timestamp values remain in seconds.
• Integrations should check timestamp units and returned data.
• Reth v0.1.3 changes how testing tools handle time overrides.

A smart contract reading block.timestamp sees time in whole seconds. When several BNB Smart Chain (BSC) blocks fall within the same second, that leaves applications unable to read timing detail the chain already records.

BEP-706, included in the Jenner hardfork, makes that detail available through a new precompile at address 0x70. Contracts can use it to read the current block’s timestamp in milliseconds, while existing uses of block.timestamp continue to return seconds.

Why Milliseconds Matter

Imagine two blocks timestamped 12:00:00.200 and 12:00:00.800. A contract using block.timestamp sees the same second for both, even though they are 600 milliseconds apart. For a signed quote or an auction with a deadline shorter than a second, those readings lose useful detail.

BEP-706 uses request-for-quote settlement as an example. A market maker may sign a quote that is valid for only a few hundred milliseconds. With whole-second time, the settlement contract has to round the cutoff, potentially accepting the quote longer than intended or rejecting it earlier.

Millisecond timestamps let applications express those cutoffs more precisely. They can also support auction deadlines and checks on how recently a price feed was updated. Whether that improves pricing or execution depends on the application’s wider design.

Figure 1: Whole seconds can hide differences between blocks. The precompile exposes existing millisecond precision. Source: BEP-706.

How Contracts Read Millisecond Timestamps

BSC block headers already carry millisecond information under BEP-520. The seconds field remains in place, while a separate header component records the remainder within that second. Nodes already validate this information through consensus.

The new precompile makes that value available to smart contracts. A contract makes a read-only static call to 0x70 and receives a 32-byte unsigned integer representing milliseconds since the Unix epoch. The precompile takes no arguments and ignores calldata.

BEP-706 sets the precompile’s computation charge at 20 gas. The calling contract also pays the applicable call and memory costs, so the total cost of using it is higher.

Applications opt into this finer precision when they need it. Contracts calculating deadlines with block.timestamp and durations in seconds continue to use the same units and behavior.

Figure 2: The new read path is additive. Existing block.timestamp semantics and units remain unchanged. Source: BEP-706.

What Developers Need to Check

The returned value is the executing block’s timestamp. Every transaction in that block reads the same value. It does not record when a transaction reached the network or the exact moment an individual transaction executed.

The timing trust model also remains the same as block.timestamp: validators supply timestamps within consensus constraints. Finer precision preserves the timing assumptions applications already rely on.

Keep Timestamp Units Consistent

Use explicit units across contracts, signatures, and backends. A deadline signed in milliseconds must be compared with a timestamp in milliseconds. Mixing seconds and milliseconds can silently make an expiry far too short or far too long.

Figure 3: A hypothetical quote expires within one second. Applications compare the deadline with block time using matching units. Source: BEP-706.

Check the Returned Data

Integrations should check both that the call succeeds and that it returns the expected 32 bytes.

Before activation, the address behaves as an empty account. A low-level call can therefore succeed without returning a timestamp. A successful call alone does not establish that the feature is available.

RPC Changes for Simulation Testing

The reth-bsc v0.1.3 release notes describe a related change for tools that override block values during simulation.

In eth_call, eth_estimateGas, debug_traceCall, and eth_simulateV1, a supplied blockOverrides.prevRandao must encode a millisecond remainder from 0 to 999 as a 32-byte hexadecimal value.

The time override remains in seconds. Overriding time alone resets the millisecond remainder to zero.

These checks apply immediately after upgrading to v0.1.3, including before Jenner activation. Teams using block overrides should update their test inputs alongside the client.

Figure 4: Simulation overrides combine seconds with a millisecond remainder. These v0.1.3 input checks apply before fork activation too. Source: release notes.

Further Reading

• BEP-706 Millisecond Timestamp Precompile
• Jenner upgrade specification
• reth-bsc v0.1.3 release notes