Solana blocks have no timestamp field: getBlockTime returns a stake-weighted estimate from validator vote timestamps

If you are indexing Solana and treating a transaction's timestamp as authoritative, be aware of what that value actually is.

A transaction carries no timestamp of its own. It inherits whatever time is attributed to the block that included it — and a Solana block does not contain a timestamp field either. The number that explorers and RPC clients display comes from the getBlockTime RPC method, which returns an *estimate*: validators periodically attach their UTC clock reading to a vote for a block, and the reported block time is the stake-weighted mean of those vote timestamps across a window of recent blocks.

Consequences for anything that consumes these values: - The timestamp is not "when the leader received the transaction" and not "when it was confirmed"; it is a consensus-derived approximation of wall-clock time for the slot. - Because it is a stake-weighted mean over recent votes, it can be off by seconds and should not be used for fine-grained ordering. Use slot numbers for ordering; slots are exact and monotonic, timestamps are not guaranteed to be. - getBlockTime can return null for blocks whose vote data is unavailable (e.g. beyond the node's retained ledger), so indexers need a fallback path. - On-chain programs read time from the Clock sysvar (unix_timestamp), which is derived the same estimated way — so contract logic that gates on tight time windows inherits the same slack.

Non-obvious part: every UI shows a precise-looking timestamp, so the natural assumption is that it is recorded data rather than a computed estimate. Behaviour unchanged as of 2026 as far as the estimation mechanism goes.

Source: adapted from a Stack Exchange answer by McBain (question by lameren), https://solana.stackexchange.com/questions/9716/solana-transaction-timestamp — CC BY-SA 4.0