Block time is not wall-clock time: finality, reorgs, timestamps

A block explorer page for a transaction shows a timestamp and a confirmation count, and the comfortable reading is that the payment happened at that displayed time and is now permanent. In blockchain evidence, that reading fails twice: the timestamp is protocol metadata set under the chain's own timestamp rule, not a certified reading of a real-world clock, and the transaction's place in history can change until the network reaches finality. The operational question for litigators and experts is therefore narrow: what does a block timestamp establish about when an event happened, and what does it take before that event is final? This article separates six moments that timing disputes routinely conflate: local signing, network broadcast, mempool observation, block inclusion, confirmation depth, and protocol finality.

For the field-by-field reading of a transaction, see How to Read a Blockchain Transaction, and for the admissibility framework that will govern this material, Blockchain Evidence in Litigation. This piece addresses the temporal proof question those articles do not cover in depth.

What a Block Timestamp Is (and What It Cannot Prove)

A blockchain bundles transactions into blocks, each cryptographically linked to the previous one. NIST's technology overview (NIST IR 8202, Blockchain Technology Overview, October 2018) describes a block header carrying identifying metadata, including a timestamp, together with the transactions it commits to. When an explorer shows a transaction date and time in UTC, it is displaying that header field converted to calendar format.

The rules for what a Bitcoin producer may put in that field are loose by design. Bitcoin's accepted-stamp rule, set out in the Bitcoin Wiki's Block timestamp page, is that the value must be greater than the median timestamp of the previous 11 blocks and less than the network-adjusted time plus two hours, where network-adjusted time is the median of the timestamps reported by a node's connected peers. The documentation is blunt about the consequence: block timestamps are not exactly accurate and do not need to be, and block times are accurate only to within an hour or two. The same field feeds difficulty adjustment. Every 2,016 blocks, the Bitcoin developer documentation uses header timestamps to compute elapsed seconds against an ideal of 1,209,600 seconds (two weeks).

Ethereum's proof-of-stake regime is different in mechanics, including the timestamp field. The Merge specification (EIP-3675, created July 2021, status Final) replaced proof-of-work consensus with proof-of-stake and refers to the most recent finalized block. The detailed rules live in the ethereum/consensus-specs repository. Under the Bellatrix beacon-chain specification (v1.4.0), a valid execution payload timestamp must equal compute_timestamp_at_slot: genesis time plus the slot index times twelve seconds. A proposer cannot slide that field inside a two-hour band. The Phase 0 specification divides time into 12-second slots and 32-slot epochs; a checkpoint pairs an epoch with the block root at the start of that epoch. Missed slots leave 12-second gaps, and genesis time is a protocol parameter rather than a certified clock. The stamp remains chain-relative metadata: block time proves position in a sequence first and calendar time second. For a calendar-time claim, the needed foundation comes from external records, addressed below.

Six Moments in a Transaction's Timeline

Timing claims collapse when these six moments are treated as one event. A defensible analysis names the moment each claim refers to, and cross-examination of an opponent's expert should do the same. In order:

Local signing. The wallet creates and signs the transaction. The signature itself contains no time, and any timestamp on the device comes from a local clock that may be wrong, misconfigured, or altered.
Network broadcast. The transaction leaves the wallet for the network's nodes, which relay it into their mempools of pending transactions. Broadcast itself is not recorded on the chain.
Mempool observation. Indexers and exchanges log the pending transaction against their own clocks. An observation supports a claim that the observing system had the transaction at its recorded time; it does not establish inclusion. An unconfirmed transaction can be replaced, resubmitted with different fees, or dropped from mempools entirely.
Block inclusion. The transaction lands at a specific index in a specific block. This is the first moment the chain itself attests to, and the block header's timestamp is the on-chain time.
Confirmation depth. Each block built on top of the containing block is a confirmation. The Bitcoin whitepaper states the design: the network timestamps transactions by hashing them into a chain of proof-of-work, forming a record that cannot be changed without redoing the proof-of-work, and each additional timestamp reinforces the ones before it.
Protocol finality. A protocol-defined state beyond which the chain treats history as settled. It exists on some chains, and its conditions differ by chain as described below.

Probabilistic Confirmation on Proof of Work

Bitcoin never declares a block final. Full nodes independently store only blocks they validate, as the Bitcoin developer documentation puts it, and they resolve competing branches by following the most difficult chain to recreate. Settlement is therefore probabilistic: the whitepaper observes that blocks added after a transaction further confirm that the network has accepted it, and the more work accumulates on top, the harder any alternative history becomes. Familiar thresholds such as six confirmations are risk judgments. The Bitcoin developer documentation on payment processing calls six confirmations somewhat arbitrary and still recommends that software handling high-value transactions wait for at least that many before treating a payment as accepted. That wait is not a protocol event. For evidence purposes, deep confirmation plus sustained chain stability is usually more persuasive than any particular block count, but neither is an irreversible verdict.

Finality on Proof of Stake

Ethereum defines finality explicitly. Under the Phase 0 beacon-chain specification, a checkpoint is justified when the balance attesting to that epoch's target is at least two-thirds of total active balance. The specification then applies defined justification-bit and epoch-linkage conditions to finalize an earlier justified checkpoint. Until those attestations land, recent Ethereum history is technically contestable, so a transaction with one or two confirmations is not yet final on Ethereum either. Conflicting Casper FFG attestations can be slashable, including double votes and surround votes. Chains that market instant finality use different consensus designs and settle on different terms, and layer-2 systems add their own sequencing and settlement assumptions. Identify whose definition of finality is at issue before the word appears in a brief. Disputes over smart contract execution raise the same chain-time questions from the contract side, covered in Smart Contract Disputes.

Reorganizations: When the Record You Read Changes

A reorganization, or reorg, is a change in which branch of the chain is canonical. Two miners can produce valid blocks near-simultaneously; nodes hold both temporarily; peers then follow the most difficult chain to recreate and throw away stale blocks, as the Bitcoin developer documentation describes in its treatment of simultaneous blocks and stale blocks. A later section of the same guide, on detecting forks, describes SPV clients connecting to several full nodes and comparing height as a hard-fork warning, which is a different problem from a short reorg of simultaneous blocks. NIST's overview shows the practical consequence: transactions that were in the orphaned block but not in the winning branch return to the pending transaction pool (NIST IR 8202). A transaction that briefly carried confirmations can therefore reappear in a different block with a different timestamp, sit again in a mempool, or in the worst case never be re-included at all.

On proof-of-stake Ethereum the hazard is compressed but real before finality: recent blocks can be displaced by a competing branch, and proposer splits or missed slots can shuffle the latest history. Checkpoint finalization changes the analysis because conflicting Casper FFG attestations can be slashable; the practical exposure window is ordinarily the unfinalized period rather than days of history. The general rule for evidence is the same on every chain: a point-in-time capture records what the chain looked like, not what it became.

Hypothetical Example: The Deadline Payment

Hypothetical example: a contract requires payment "received by 23:59:59 UTC" on a stated date. The client broadcasts at 23:58 local time. An explorer query at 23:59:41 shows the transaction included in a block stamped 23:59:41 with one confirmation. A short proof-of-work reorg then re-parents that block, and an hour later the transaction sits in a block stamped 00:01:17 UTC. The payment that looked timely at the moment of capture now looks late, and a screenshot from 23:59:41, contradicted by the current explorer page, is exactly the exhibit an opposing expert enjoys dismantling.

The technical record is richer than either snapshot. The first block existed and carried the transaction; a full node, archive node, or indexed service that recorded the view at 23:59:41 can support a conclusion that the transaction was included, at least briefly, before midnight, if the record is authenticated. Whether that satisfies "received by" is a contract question, but the sequence can be established if the point-in-time state was preserved. Corroboration from an exchange or from the recipient's own node at the same minute turns an ambiguous reorg story into a timeline. The opposite trap is the unconfirmed broadcast: a client who watched the transaction in a mempool at 23:59:30 and never checked again has no on-chain inclusion at all, and the eventual inclusion, after fee competition, can carry a timestamp hours later.

Corroborating Blockchain Time with Independent Records

Block time establishes order on its own chain more reliably than it establishes calendar time. Converting sequence into calendar time is a corroboration exercise, and the sources that do it well:

Exchange records. Deposits, withdrawals, order fills, and KYC events carry timestamps from the exchange's own systems and can provide an independent clock. Production must identify which system generated the timestamp, its timezone, and its clock basis. Practical production guidance is in How to Subpoena Cryptocurrency Exchange Records.
Server and application logs. A party's own API logs, payment-processor logs, and NTP-synced servers can fix broadcast or receipt times, once the log's clock configuration is established.
Device forensics. Wallet application data, browser history, and filesystem metadata show when software was installed, when keys were created, and when a transaction was initiated. The device clock itself must be assessed: timezone, synchronization, and whether the clock changed between the relevant date and imaging.
Communications and receipts. Emails, messages, and invoices that reference a transaction hash fix context and intent, and carrier or server headers add their own timestamps. They prove that someone was communicating about the transaction, not chain time itself.
Time-stamp services for documents. Where a party needs evidence that a document existed before a particular time rather than a consensus byproduct, a standards-based time-stamp service, such as one using the RFC 3161 protocol, can issue a token for the document's hash. The service's time source and policy still require examination. This is different evidence from a block stamp.

The corroboration principle: on-chain data is the sequence, external records are the calendar. Record every external timestamp with its clock basis and timezone, the same discipline applied to any electronically stored information.

What an Expert Can Safely Say About Timing

An expert opinion about timing is only as strong as the moment it specifies. In blockchain tracing work, conclusions are held to a test: can the claim be re-derived from the preserved data, and does it survive a reorg or a clock challenge?

Conclusions that hold up

That transaction X is included at index i of block N on chain C, and the block header records timestamp T, stated with the node or explorer queried, the retrieval time, and the block height at capture.
That X precedes Y in inclusion order on the same chain, a property the chain itself attests.
That as of a stated observation date X remained in the canonical chain with a stated confirmation depth.
That an independent indexer or exchange recorded the transaction at time S, attributed to that system's own clock.

Conclusions that do not

That a wallet screen timestamp proves when the defendant signed, without device-clock evidence.
That the transaction occurred "at T" because the block header says T, without stating which protocol's timestamp rule applies. Bitcoin's window, again per Bitcoin Wiki: greater than the median of the previous 11 blocks and less than network-adjusted time plus two hours. Ethereum's payload timestamp must equal slot time; that still does not prove when the wallet signed or when the transaction was first broadcast.
That the transaction "is irreversible," stated categorically. The defensible version names the protocol and its finality state: finalized under Ethereum's checkpoint rules, or deeply confirmed on Bitcoin as of the observation date.
That a single explorer screenshot of two confirmations proves final status, without a current-state query answering whether the block survived.

These are professional practices in a technical discipline. What a forum requires of the evidence is a separate legal question under its own evidence and expert-testimony standards; the federal and Missouri framework is covered in Blockchain Evidence in Litigation and the case law in Daubert and Blockchain Experts. A report that conflates the technical layer with the legal standard is the one that gets challenged.

A Short Checklist for Timing Evidence

Name the moment: signing, broadcast, mempool, inclusion, confirmation, or finality.
Record the exact query: node or explorer, block height, transaction index, retrieval time.
Preserve both the point-in-time view and the current-state view, with hashes of any exports.
State the confirmation depth and finality state at capture, and re-check afterward for reorgs.
Corroborate calendar time with at least one independent clock, and name its basis.
Test the alternative story: reorg, fee replacement, dropped mempool, or clock error.

This checklist is the core of the methodology applied to timing questions in our engagements.

Questions to Ask About Timing Evidence

Which field did the analysis read: the explorer's rendered timestamp or the raw block header value from a node?
What were the block height, index, and confirmation count at capture, and what are they now?
Has the transaction reorged since capture, and how would the detection method know?
For exchange production: which system generated the timestamp, in what timezone, and with what clock basis?
For devices: timezone, NTP state, and any clock changes between the event and imaging.
For communications: do they reference the transaction hash, and do message-header times agree with the exchange's internal times?
What does the operative contract or statute select as the moment that matters, and which of the six moments can the evidence actually prove?

Frequently Asked Questions

Q: If the block explorer shows 14:04:22 UTC, is that the exact time of the transaction?

A: It is the timestamp stored in the block header, displayed in UTC. On Bitcoin, a valid stamp must be greater than the median timestamp of the previous 11 blocks and less than network-adjusted time plus two hours, and the documentation states block times are accurate only to within an hour or two. On Ethereum, a valid execution payload timestamp must equal genesis time plus twelve seconds times the slot, so the field tracks slot time by validity rule rather than miner latitude. Neither is a certified clock of signing or broadcast. For an exact-time claim, corroborate with an independent clock: exchange logs, server logs, or device forensics.

Q: When is a blockchain transaction truly final?

A: It depends on the protocol. Bitcoin has no formal finality event; each block added on top reinforces acceptance, and the practical risk of reversal falls toward zero. Proof-of-stake Ethereum defines finality in the Phase 0 specification: a checkpoint is justified when the balance attesting to that epoch's target is at least two-thirds of total active balance, and the specification applies defined justification-bit and epoch-linkage conditions to finalize an earlier justified checkpoint. Conflicting Casper FFG attestations can be slashable. Finality thresholds differ by chain, and litigation rarely needs absolute irreversibility. It needs a defensible statement of the chain state at the relevant moment.

Q: My client's transaction was confirmed and then disappeared from the explorer. What happened?

A: Most likely a reorganization: a competing block branch won, the block that had contained the transaction became stale or orphaned, and the transaction returned to the pending pool, where it may be re-included later or expire. NIST's overview describes this behavior directly: transactions in the orphaned block that are absent from the winning branch return to the pending transaction pool. Unconfirmed transactions can also be replaced or dropped because of fee competition. Recover the current chain state and any archived views; the pre-reorg history is itself evidence of the sequence.

Q: Can a block producer set the timestamp to anything they want?

A: On Bitcoin, no, but the permitted window is wide. The stamp must exceed the median timestamp of the previous 11 blocks and stay below network-adjusted time plus two hours, so a producer has latitude inside that window, including times earlier than a node's clock. On Ethereum, a proposer cannot pick an arbitrary time: the payload timestamp must equal the computed slot time. That still leaves genesis-time accuracy, missed slots, and the fact that slot time is not a certification of when a user signed. External records with named clocks are how the calendar moment gets pinned down.

Timing evidence fails in predictable places: an unexamined device clock, a reorg between capture and hearing, an explorer view mistaken for a guarantee. The habits that protect a case are naming which of the six moments a claim is about, preserving the chain state at capture, and corroborating absolute time with an independent record. Cases vary in contract language, forum rules, and chain, and a consultation is the right place to work through the specifics of a particular matter. If you are litigating a timing question and need an expert witness for the analysis, contact us to discuss it.