How Blockchain Handles Time
In a traditional system, a trusted server provides the authoritative time. In a decentralized blockchain, there is no trusted authority — so time must be derived from the consensus mechanism itself. Each block in a blockchain contains a timestamp set by the miner or validator who produced that block.
Bitcoin's Block Timestamps
Bitcoin stores block timestamps as a Unix timestamp (32-bit, seconds since 1970) in the block header. The rules are loose:
- Must be greater than the median of the last 11 blocks (Median Time Past)
- Must be within 2 hours of the receiving node's current time
- Within these bounds, miners can set any timestamp they want
# Bitcoin block #800000 (example)
{
"height": 800000,
"time": 1690168629, # Unix timestamp set by miner
"mediantime": 1690165613, # Median of last 11 blocks
"ntime": "64ba7f65" # Hex-encoded timestamp in header
}Ethereum's Block Time
Ethereum uses Unix timestamps in block headers. With Proof of Stake (post-Merge), slots are fixed at 12 seconds, giving Ethereum more predictable block times. However, timestamps can still vary by ±1 slot (12 seconds) due to missed slots:
// Solidity — accessing block timestamp
contract TimeLock {
uint256 public unlockTime;
// WARNING: block.timestamp can be manipulated by validators
// within ~15 seconds. Never use for sub-minute precision.
modifier afterUnlock() {
require(block.timestamp >= unlockTime, "Too early");
_;
}
}The Miner Manipulation Problem
Because miners/validators set block timestamps, they can manipulate them within the allowed range. This is called the "timestamp manipulation" vulnerability and affects smart contracts that use block.timestamp for:
- Random number generation (easily exploited)
- Lock periods shorter than ~15 minutes
- Lottery contracts with timestamp-based winners
Safe Use of Block Timestamps
- Safe for: deadlines measured in hours or days (e.g., "unlock after 30 days")
- Unsafe for: deadlines measured in seconds or minutes (use block numbers instead)
- Block numbers for short periods: Ethereum produces ~1 block per 12 seconds, so block-count-based timing is more reliable for short windows
// Safer: use block numbers for short lock periods
contract ShortLock {
uint256 public unlockBlock;
constructor() {
unlockBlock = block.number + 50; // ~10 minutes at 12s/block
}
}Oracle Networks for Real-Time Data
For on-chain applications needing accurate real-world time, oracle networks like Chainlink provide timestamp data pulled from external sources, though they introduce trust assumptions and latency.