BaseTime Millisecond Timestamp

​

Abstract

​

Motivation

​

What changed

​

New interface and library

interface IBaseTime {
    function timestampMillisPart() external view returns (uint16);
    function timestampMs() external view returns (uint64);
    function version() external view returns (string memory);
}

library StdPredeploys {
    address internal constant BASE_TIME_ADDRESS = 0x4200000000000000000000000000000000000030;
    IBaseTime internal constant BASE_TIME = IBaseTime(BASE_TIME_ADDRESS);
}

​

Behavior

• No existing selector, event, error, or storage slot changes. The predeploy is new.
• Storage: uint16 timestampMillisPart sits in the low-order 2 bytes of slot 0.
• The protocol writes the millisecond component once per Denim block, through a depositor-only setter called by the block-scoped deposit at tx[1]. Until that deposit executes (for example, during the tx[0] L1-info deposit), timestampMs() combines the current block’s seconds with the previous block’s millisecond component.

​

Example

import {StdPredeploys} from "base-std/StdPredeploys.sol";

uint64 nowMs = StdPredeploys.BASE_TIME.timestampMs();
// block.timestamp == 1_800_000_000, timestampMillisPart() == 400
// nowMs == 1_800_000_000_400

​

Migration

• After Denim activates, read StdPredeploys.BASE_TIME.timestampMs() for millisecond block time.
• Code that runs before tx[1] in a block, such as the L1-info deposit, sees the previous block’s millisecond component.
• Before Denim, the predeploy has no implementation and calls to it revert. Don’t depend on it on a chain where Denim hasn’t activated.

​

Alternatives considered

• Read-only interface. Only the protocol deposit can write the value, so exposing the setter would give integrators a selector that always reverts for them.
• Separate StdPredeploys library. Predeploys are EVM bytecode and precompiles are native code. Separate libraries keep that distinction visible at the call site.
• Slot-0 mock layout. MockBaseTime stores the uint16 at slot 0 instead of an ERC-7201 namespace. This matches the real contract’s layout, so vm.store-based tests behave the same against either.