Block Timestamps

Block timestamps are how Arbitrum One smart contracts answer "what time is it" — vesting schedules, auction deadlines, staking lockups, and TWAP windows on protocols like Uniswap and GMX all read block.timestamp to make decisions, and off-chain indexers use the same field to order and chart on-chain events. But on a Nitro rollup the timestamp is assigned by the sequencer, not by a decentralized set of miners, and it is bounded against Ethereum L1 time rather than being a precise wall clock, so treating it as exact will eventually burn you. This guide is for smart contract and backend developers: it explains how Arbitrum One timestamps are set, what accuracy you can and cannot rely on, how drift against L1 shows up, and how to write time-based logic that stays correct against https://arbitrum.therpc.io/YOUR_API_KEY.

Understanding Block Timestamps

• Who sets them: On Arbitrum One the sequencer assigns each block's timestamp as it orders transactions. There is no PoW miner or validator set racing to propose blocks, so the timestamp reflects the sequencer's clock, constrained by the rollup's relationship to Ethereum L1 time.
• Accuracy guarantees: Timestamps are monotonic (non-decreasing across blocks) and broadly track real time, but they are not a precise wall clock and are bounded relative to L1 rather than guaranteed to the second. Expect seconds-level imprecision, not sub-second accuracy.
• Manipulation bounds: A misbehaving or compromised sequencer has limited room to skew timestamps because they are clamped within a window tied to L1 time and must stay monotonic — but within that window small shifts are possible, so any contract whose outcome flips on a few seconds of timestamp difference is at risk.
• Network time drift: Drift is the gap between the on-chain block.timestamp and true wall-clock or Ethereum L1 time. On Arbitrum One it manifests as the L2 clock leading or lagging L1 slightly before reconciling, which matters most for cross-chain logic that compares an Arbitrum One timestamp against an Ethereum mainnet timestamp.

Working with Timestamps

1// Get block timestamp
2const getBlockTimestamp = async (blockNumber) => {
3  const block = await web3.eth.getBlock(blockNumber);
4  return block.timestamp;
5};
6 
7// Calculate average block time
8const getAverageBlockTime = async (blockCount = 100) => {
9  const latestBlock = await web3.eth.getBlockNumber();
10  const oldBlock = await web3.eth.getBlock(latestBlock - blockCount);
11  const newBlock = await web3.eth.getBlock(latestBlock);
12 
13  return (newBlock.timestamp - oldBlock.timestamp) / blockCount;
14};

Best Practices

• Do not rely on exact precision: Never gate a contract outcome on second-level timestamp equality on Arbitrum One. Because the sequencer-set timestamp is only accurate to within seconds and bounded against L1, write comparisons as ranges (>=, <= with margin) rather than exact matches.
• Account for manipulation: Assume a small adversarial nudge is possible within the L1-clamped window. For anything valuable — auction closes, randomness seeds, reward cutoffs — do not let a few seconds of timestamp drift change who wins or how much they earn; add tolerance or use an external time source.
• Prefer block numbers for ordering: When you only need a strict, tamper-resistant order of events, use block numbers instead of timestamps — block height is strictly increasing and not subject to the same clamping, making it the more reliable sequencer of events on Arbitrum One.
• Handle drift in cross-chain/off-chain code: When comparing an Arbitrum One timestamp against an Ethereum L1 timestamp or an off-chain server clock, allow for the L2-vs-L1 drift; do not assume the two clocks are identical at any instant, and reconcile using a tolerance window.
• Safe buffers: Size deadlines and lockups with a buffer that comfortably exceeds expected drift — a margin on the order of tens of seconds to a minute is a reasonable starting point for most Arbitrum One time-based logic, widened further for high-value or cross-chain conditions.

See also

• eth_getBlockByNumber - Retrieve block information including timestamps
• Working with Blocks - General block handling
• Block Gas Management - Managing gas costs over time