[{"data":1,"prerenderedAt":1232},["ShallowReactive",2],{"tag-blockchain-basics":3},[4,734],{"_path":5,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":9,"description":10,"slug":11,"date":12,"lastUpdated":12,"author":13,"readingTime":14,"category":15,"tags":16,"ogImage":21,"featured":7,"body":22,"_type":728,"_id":729,"_source":730,"_file":731,"_stem":732,"_extension":733},"\u002Farticles\u002F34-block-time-finality-reorgs-timestamps","articles",false,"","Block time is not wall-clock time: finality, reorgs, timestamps","A block timestamp is a protocol input, not a certified clock. How inclusion, confirmations, finality, and reorgs shape timing evidence in litigation.","block-time-finality-reorgs-timestamps","2026-08-01","Nick Kampe",16,"Education",[17,18,19,20],"blockchain-basics","evidence","finality","timestamps","\u002Fog\u002Fblock-time-finality-reorgs-timestamps.png",{"type":23,"children":24,"toc":703},"root",[25,33,55,62,77,100,141,147,152,227,234,255,261,282,288,308,313,319,324,329,335,340,410,415,421,434,440,463,469,500,519,525,558,571,577,615,621,627,637,643,652,658,667,673,682],{"type":26,"tag":27,"props":28,"children":29},"element","p",{},[30],{"type":31,"value":32},"text","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.",{"type":26,"tag":27,"props":34,"children":35},{},[36,38,45,47,53],{"type":31,"value":37},"For the field-by-field reading of a transaction, see ",{"type":26,"tag":39,"props":40,"children":42},"a",{"href":41},"\u002Fresources\u002Fhow-to-read-a-blockchain-transaction",[43],{"type":31,"value":44},"How to Read a Blockchain Transaction",{"type":31,"value":46},", and for the admissibility framework that will govern this material, ",{"type":26,"tag":39,"props":48,"children":50},{"href":49},"\u002Fresources\u002Fblockchain-evidence-admissibility",[51],{"type":31,"value":52},"Blockchain Evidence in Litigation",{"type":31,"value":54},". This piece addresses the temporal proof question those articles do not cover in depth.",{"type":26,"tag":56,"props":57,"children":59},"h2",{"id":58},"what-a-block-timestamp-is-and-what-it-cannot-prove",[60],{"type":31,"value":61},"What a Block Timestamp Is (and What It Cannot Prove)",{"type":26,"tag":27,"props":63,"children":64},{},[65,67,75],{"type":31,"value":66},"A blockchain bundles transactions into blocks, each cryptographically linked to the previous one. NIST's technology overview (",{"type":26,"tag":39,"props":68,"children":72},{"href":69,"rel":70},"https:\u002F\u002Fnvlpubs.nist.gov\u002Fnistpubs\u002Fir\u002F2018\u002FNIST.IR.8202.pdf",[71],"nofollow",[73],{"type":31,"value":74},"NIST IR 8202, Blockchain Technology Overview",{"type":31,"value":76},", 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.",{"type":26,"tag":27,"props":78,"children":79},{},[80,82,89,91,98],{"type":31,"value":81},"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 ",{"type":26,"tag":39,"props":83,"children":86},{"href":84,"rel":85},"https:\u002F\u002Fen.bitcoin.it\u002Fwiki\u002FBlock_timestamp",[71],[87],{"type":31,"value":88},"Bitcoin Wiki's Block timestamp page",{"type":31,"value":90},", 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 ",{"type":26,"tag":39,"props":92,"children":95},{"href":93,"rel":94},"https:\u002F\u002Fdeveloper.bitcoin.org\u002Fdevguide\u002Fblock_chain.html",[71],[96],{"type":31,"value":97},"Bitcoin developer documentation",{"type":31,"value":99}," uses header timestamps to compute elapsed seconds against an ideal of 1,209,600 seconds (two weeks).",{"type":26,"tag":27,"props":101,"children":102},{},[103,105,112,114,121,123,130,132,139],{"type":31,"value":104},"Ethereum's proof-of-stake regime is different in mechanics, including the timestamp field. The Merge specification (",{"type":26,"tag":39,"props":106,"children":109},{"href":107,"rel":108},"https:\u002F\u002Feips.ethereum.org\u002FEIPS\u002Feip-3675",[71],[110],{"type":31,"value":111},"EIP-3675",{"type":31,"value":113},", 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\u002Fconsensus-specs repository. Under the Bellatrix beacon-chain specification (",{"type":26,"tag":39,"props":115,"children":118},{"href":116,"rel":117},"https:\u002F\u002Fgithub.com\u002Fethereum\u002Fconsensus-specs\u002Fblob\u002Fv1.4.0\u002Fspecs\u002Fbellatrix\u002Fbeacon-chain.md",[71],[119],{"type":31,"value":120},"v1.4.0",{"type":31,"value":122},"), a valid execution payload timestamp must equal ",{"type":26,"tag":124,"props":125,"children":127},"code",{"className":126},[],[128],{"type":31,"value":129},"compute_timestamp_at_slot",{"type":31,"value":131},": genesis time plus the slot index times twelve seconds. A proposer cannot slide that field inside a two-hour band. The ",{"type":26,"tag":39,"props":133,"children":136},{"href":134,"rel":135},"https:\u002F\u002Fgithub.com\u002Fethereum\u002Fconsensus-specs\u002Fblob\u002Fv1.4.0\u002Fspecs\u002Fphase0\u002Fbeacon-chain.md",[71],[137],{"type":31,"value":138},"Phase 0 specification",{"type":31,"value":140}," 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.",{"type":26,"tag":56,"props":142,"children":144},{"id":143},"six-moments-in-a-transactions-timeline",[145],{"type":31,"value":146},"Six Moments in a Transaction's Timeline",{"type":26,"tag":27,"props":148,"children":149},{},[150],{"type":31,"value":151},"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:",{"type":26,"tag":153,"props":154,"children":155},"ol",{},[156,168,178,188,198,217],{"type":26,"tag":157,"props":158,"children":159},"li",{},[160,166],{"type":26,"tag":161,"props":162,"children":163},"strong",{},[164],{"type":31,"value":165},"Local signing.",{"type":31,"value":167}," 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.",{"type":26,"tag":157,"props":169,"children":170},{},[171,176],{"type":26,"tag":161,"props":172,"children":173},{},[174],{"type":31,"value":175},"Network broadcast.",{"type":31,"value":177}," 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.",{"type":26,"tag":157,"props":179,"children":180},{},[181,186],{"type":26,"tag":161,"props":182,"children":183},{},[184],{"type":31,"value":185},"Mempool observation.",{"type":31,"value":187}," 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.",{"type":26,"tag":157,"props":189,"children":190},{},[191,196],{"type":26,"tag":161,"props":192,"children":193},{},[194],{"type":31,"value":195},"Block inclusion.",{"type":31,"value":197}," 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.",{"type":26,"tag":157,"props":199,"children":200},{},[201,206,208,215],{"type":26,"tag":161,"props":202,"children":203},{},[204],{"type":31,"value":205},"Confirmation depth.",{"type":31,"value":207}," Each block built on top of the containing block is a confirmation. The ",{"type":26,"tag":39,"props":209,"children":212},{"href":210,"rel":211},"https:\u002F\u002Fbitcoin.org\u002Fbitcoin.pdf",[71],[213],{"type":31,"value":214},"Bitcoin whitepaper",{"type":31,"value":216}," 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.",{"type":26,"tag":157,"props":218,"children":219},{},[220,225],{"type":26,"tag":161,"props":221,"children":222},{},[223],{"type":31,"value":224},"Protocol finality.",{"type":31,"value":226}," 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.",{"type":26,"tag":228,"props":229,"children":231},"h3",{"id":230},"probabilistic-confirmation-on-proof-of-work",[232],{"type":31,"value":233},"Probabilistic Confirmation on Proof of Work",{"type":26,"tag":27,"props":235,"children":236},{},[237,239,244,246,253],{"type":31,"value":238},"Bitcoin never declares a block final. Full nodes independently store only blocks they validate, as the ",{"type":26,"tag":39,"props":240,"children":242},{"href":93,"rel":241},[71],[243],{"type":31,"value":97},{"type":31,"value":245}," 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 ",{"type":26,"tag":39,"props":247,"children":250},{"href":248,"rel":249},"https:\u002F\u002Fdeveloper.bitcoin.org\u002Fdevguide\u002Fpayment_processing.html",[71],[251],{"type":31,"value":252},"Bitcoin developer documentation on payment processing",{"type":31,"value":254}," 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.",{"type":26,"tag":228,"props":256,"children":258},{"id":257},"finality-on-proof-of-stake",[259],{"type":31,"value":260},"Finality on Proof of Stake",{"type":26,"tag":27,"props":262,"children":263},{},[264,266,272,274,280],{"type":31,"value":265},"Ethereum defines finality explicitly. Under the ",{"type":26,"tag":39,"props":267,"children":269},{"href":134,"rel":268},[71],[270],{"type":31,"value":271},"Phase 0 beacon-chain specification",{"type":31,"value":273},", 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 ",{"type":26,"tag":39,"props":275,"children":277},{"href":276},"\u002Fresources\u002Fsmart-contract-disputes",[278],{"type":31,"value":279},"Smart Contract Disputes",{"type":31,"value":281},".",{"type":26,"tag":56,"props":283,"children":285},{"id":284},"reorganizations-when-the-record-you-read-changes",[286],{"type":31,"value":287},"Reorganizations: When the Record You Read Changes",{"type":26,"tag":27,"props":289,"children":290},{},[291,293,298,300,306],{"type":31,"value":292},"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 ",{"type":26,"tag":39,"props":294,"children":296},{"href":93,"rel":295},[71],[297],{"type":31,"value":97},{"type":31,"value":299}," 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 (",{"type":26,"tag":39,"props":301,"children":303},{"href":69,"rel":302},[71],[304],{"type":31,"value":305},"NIST IR 8202",{"type":31,"value":307},"). 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.",{"type":26,"tag":27,"props":309,"children":310},{},[311],{"type":31,"value":312},"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.",{"type":26,"tag":228,"props":314,"children":316},{"id":315},"hypothetical-example-the-deadline-payment",[317],{"type":31,"value":318},"Hypothetical Example: The Deadline Payment",{"type":26,"tag":27,"props":320,"children":321},{},[322],{"type":31,"value":323},"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.",{"type":26,"tag":27,"props":325,"children":326},{},[327],{"type":31,"value":328},"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.",{"type":26,"tag":56,"props":330,"children":332},{"id":331},"corroborating-blockchain-time-with-independent-records",[333],{"type":31,"value":334},"Corroborating Blockchain Time with Independent Records",{"type":26,"tag":27,"props":336,"children":337},{},[338],{"type":31,"value":339},"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:",{"type":26,"tag":341,"props":342,"children":343},"ul",{},[344,361,371,381,391],{"type":26,"tag":157,"props":345,"children":346},{},[347,352,354,360],{"type":26,"tag":161,"props":348,"children":349},{},[350],{"type":31,"value":351},"Exchange records.",{"type":31,"value":353}," 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 ",{"type":26,"tag":39,"props":355,"children":357},{"href":356},"\u002Fresources\u002Fsubpoenaing-cryptocurrency-exchange-records",[358],{"type":31,"value":359},"How to Subpoena Cryptocurrency Exchange Records",{"type":31,"value":281},{"type":26,"tag":157,"props":362,"children":363},{},[364,369],{"type":26,"tag":161,"props":365,"children":366},{},[367],{"type":31,"value":368},"Server and application logs.",{"type":31,"value":370}," 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.",{"type":26,"tag":157,"props":372,"children":373},{},[374,379],{"type":26,"tag":161,"props":375,"children":376},{},[377],{"type":31,"value":378},"Device forensics.",{"type":31,"value":380}," 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.",{"type":26,"tag":157,"props":382,"children":383},{},[384,389],{"type":26,"tag":161,"props":385,"children":386},{},[387],{"type":31,"value":388},"Communications and receipts.",{"type":31,"value":390}," 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.",{"type":26,"tag":157,"props":392,"children":393},{},[394,399,401,408],{"type":26,"tag":161,"props":395,"children":396},{},[397],{"type":31,"value":398},"Time-stamp services for documents.",{"type":31,"value":400}," 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 ",{"type":26,"tag":39,"props":402,"children":405},{"href":403,"rel":404},"https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc3161.html",[71],[406],{"type":31,"value":407},"RFC 3161",{"type":31,"value":409}," 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.",{"type":26,"tag":27,"props":411,"children":412},{},[413],{"type":31,"value":414},"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.",{"type":26,"tag":56,"props":416,"children":418},{"id":417},"what-an-expert-can-safely-say-about-timing",[419],{"type":31,"value":420},"What an Expert Can Safely Say About Timing",{"type":26,"tag":27,"props":422,"children":423},{},[424,426,432],{"type":31,"value":425},"An expert opinion about timing is only as strong as the moment it specifies. In ",{"type":26,"tag":39,"props":427,"children":429},{"href":428},"\u002Fservices#blockchain-tracing",[430],{"type":31,"value":431},"blockchain tracing",{"type":31,"value":433}," 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?",{"type":26,"tag":228,"props":435,"children":437},{"id":436},"conclusions-that-hold-up",[438],{"type":31,"value":439},"Conclusions that hold up",{"type":26,"tag":341,"props":441,"children":442},{},[443,448,453,458],{"type":26,"tag":157,"props":444,"children":445},{},[446],{"type":31,"value":447},"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.",{"type":26,"tag":157,"props":449,"children":450},{},[451],{"type":31,"value":452},"That X precedes Y in inclusion order on the same chain, a property the chain itself attests.",{"type":26,"tag":157,"props":454,"children":455},{},[456],{"type":31,"value":457},"That as of a stated observation date X remained in the canonical chain with a stated confirmation depth.",{"type":26,"tag":157,"props":459,"children":460},{},[461],{"type":31,"value":462},"That an independent indexer or exchange recorded the transaction at time S, attributed to that system's own clock.",{"type":26,"tag":228,"props":464,"children":466},{"id":465},"conclusions-that-do-not",[467],{"type":31,"value":468},"Conclusions that do not",{"type":26,"tag":341,"props":470,"children":471},{},[472,477,490,495],{"type":26,"tag":157,"props":473,"children":474},{},[475],{"type":31,"value":476},"That a wallet screen timestamp proves when the defendant signed, without device-clock evidence.",{"type":26,"tag":157,"props":478,"children":479},{},[480,482,488],{"type":31,"value":481},"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 ",{"type":26,"tag":39,"props":483,"children":485},{"href":84,"rel":484},[71],[486],{"type":31,"value":487},"Bitcoin Wiki",{"type":31,"value":489},": 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.",{"type":26,"tag":157,"props":491,"children":492},{},[493],{"type":31,"value":494},"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.",{"type":26,"tag":157,"props":496,"children":497},{},[498],{"type":31,"value":499},"That a single explorer screenshot of two confirmations proves final status, without a current-state query answering whether the block survived.",{"type":26,"tag":27,"props":501,"children":502},{},[503,505,509,511,517],{"type":31,"value":504},"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 ",{"type":26,"tag":39,"props":506,"children":507},{"href":49},[508],{"type":31,"value":52},{"type":31,"value":510}," and the case law in ",{"type":26,"tag":39,"props":512,"children":514},{"href":513},"\u002Fresources\u002Fdaubert-blockchain-experts-courts",[515],{"type":31,"value":516},"Daubert and Blockchain Experts",{"type":31,"value":518},". A report that conflates the technical layer with the legal standard is the one that gets challenged.",{"type":26,"tag":228,"props":520,"children":522},{"id":521},"a-short-checklist-for-timing-evidence",[523],{"type":31,"value":524},"A Short Checklist for Timing Evidence",{"type":26,"tag":153,"props":526,"children":527},{},[528,533,538,543,548,553],{"type":26,"tag":157,"props":529,"children":530},{},[531],{"type":31,"value":532},"Name the moment: signing, broadcast, mempool, inclusion, confirmation, or finality.",{"type":26,"tag":157,"props":534,"children":535},{},[536],{"type":31,"value":537},"Record the exact query: node or explorer, block height, transaction index, retrieval time.",{"type":26,"tag":157,"props":539,"children":540},{},[541],{"type":31,"value":542},"Preserve both the point-in-time view and the current-state view, with hashes of any exports.",{"type":26,"tag":157,"props":544,"children":545},{},[546],{"type":31,"value":547},"State the confirmation depth and finality state at capture, and re-check afterward for reorgs.",{"type":26,"tag":157,"props":549,"children":550},{},[551],{"type":31,"value":552},"Corroborate calendar time with at least one independent clock, and name its basis.",{"type":26,"tag":157,"props":554,"children":555},{},[556],{"type":31,"value":557},"Test the alternative story: reorg, fee replacement, dropped mempool, or clock error.",{"type":26,"tag":27,"props":559,"children":560},{},[561,563,569],{"type":31,"value":562},"This checklist is the core of the ",{"type":26,"tag":39,"props":564,"children":566},{"href":565},"\u002Fmethodology",[567],{"type":31,"value":568},"methodology",{"type":31,"value":570}," applied to timing questions in our engagements.",{"type":26,"tag":56,"props":572,"children":574},{"id":573},"questions-to-ask-about-timing-evidence",[575],{"type":31,"value":576},"Questions to Ask About Timing Evidence",{"type":26,"tag":153,"props":578,"children":579},{},[580,585,590,595,600,605,610],{"type":26,"tag":157,"props":581,"children":582},{},[583],{"type":31,"value":584},"Which field did the analysis read: the explorer's rendered timestamp or the raw block header value from a node?",{"type":26,"tag":157,"props":586,"children":587},{},[588],{"type":31,"value":589},"What were the block height, index, and confirmation count at capture, and what are they now?",{"type":26,"tag":157,"props":591,"children":592},{},[593],{"type":31,"value":594},"Has the transaction reorged since capture, and how would the detection method know?",{"type":26,"tag":157,"props":596,"children":597},{},[598],{"type":31,"value":599},"For exchange production: which system generated the timestamp, in what timezone, and with what clock basis?",{"type":26,"tag":157,"props":601,"children":602},{},[603],{"type":31,"value":604},"For devices: timezone, NTP state, and any clock changes between the event and imaging.",{"type":26,"tag":157,"props":606,"children":607},{},[608],{"type":31,"value":609},"For communications: do they reference the transaction hash, and do message-header times agree with the exchange's internal times?",{"type":26,"tag":157,"props":611,"children":612},{},[613],{"type":31,"value":614},"What does the operative contract or statute select as the moment that matters, and which of the six moments can the evidence actually prove?",{"type":26,"tag":56,"props":616,"children":618},{"id":617},"frequently-asked-questions",[619],{"type":31,"value":620},"Frequently Asked Questions",{"type":26,"tag":228,"props":622,"children":624},{"id":623},"q-if-the-block-explorer-shows-140422-utc-is-that-the-exact-time-of-the-transaction",[625],{"type":31,"value":626},"Q: If the block explorer shows 14:04:22 UTC, is that the exact time of the transaction?",{"type":26,"tag":27,"props":628,"children":629},{},[630,635],{"type":26,"tag":161,"props":631,"children":632},{},[633],{"type":31,"value":634},"A:",{"type":31,"value":636}," 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.",{"type":26,"tag":228,"props":638,"children":640},{"id":639},"q-when-is-a-blockchain-transaction-truly-final",[641],{"type":31,"value":642},"Q: When is a blockchain transaction truly final?",{"type":26,"tag":27,"props":644,"children":645},{},[646,650],{"type":26,"tag":161,"props":647,"children":648},{},[649],{"type":31,"value":634},{"type":31,"value":651}," 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.",{"type":26,"tag":228,"props":653,"children":655},{"id":654},"q-my-clients-transaction-was-confirmed-and-then-disappeared-from-the-explorer-what-happened",[656],{"type":31,"value":657},"Q: My client's transaction was confirmed and then disappeared from the explorer. What happened?",{"type":26,"tag":27,"props":659,"children":660},{},[661,665],{"type":26,"tag":161,"props":662,"children":663},{},[664],{"type":31,"value":634},{"type":31,"value":666}," 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.",{"type":26,"tag":228,"props":668,"children":670},{"id":669},"q-can-a-block-producer-set-the-timestamp-to-anything-they-want",[671],{"type":31,"value":672},"Q: Can a block producer set the timestamp to anything they want?",{"type":26,"tag":27,"props":674,"children":675},{},[676,680],{"type":26,"tag":161,"props":677,"children":678},{},[679],{"type":31,"value":634},{"type":31,"value":681}," 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.",{"type":26,"tag":27,"props":683,"children":684},{},[685,687,693,695,701],{"type":31,"value":686},"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 ",{"type":26,"tag":39,"props":688,"children":690},{"href":689},"\u002Fservices#expert-witness",[691],{"type":31,"value":692},"expert witness",{"type":31,"value":694}," for the analysis, ",{"type":26,"tag":39,"props":696,"children":698},{"href":697},"\u002Fcontact",[699],{"type":31,"value":700},"contact us",{"type":31,"value":702}," to discuss it.",{"title":8,"searchDepth":704,"depth":704,"links":705},2,[706,707,712,715,716,721,722],{"id":58,"depth":704,"text":61},{"id":143,"depth":704,"text":146,"children":708},[709,711],{"id":230,"depth":710,"text":233},3,{"id":257,"depth":710,"text":260},{"id":284,"depth":704,"text":287,"children":713},[714],{"id":315,"depth":710,"text":318},{"id":331,"depth":704,"text":334},{"id":417,"depth":704,"text":420,"children":717},[718,719,720],{"id":436,"depth":710,"text":439},{"id":465,"depth":710,"text":468},{"id":521,"depth":710,"text":524},{"id":573,"depth":704,"text":576},{"id":617,"depth":704,"text":620,"children":723},[724,725,726,727],{"id":623,"depth":710,"text":626},{"id":639,"depth":710,"text":642},{"id":654,"depth":710,"text":657},{"id":669,"depth":710,"text":672},"markdown","content:articles:34-block-time-finality-reorgs-timestamps.md","content","articles\u002F34-block-time-finality-reorgs-timestamps.md","articles\u002F34-block-time-finality-reorgs-timestamps","md",{"_path":735,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":736,"description":737,"slug":738,"date":739,"lastUpdated":739,"author":13,"readingTime":740,"category":15,"tags":741,"ogImage":744,"featured":7,"body":745,"_type":728,"_id":1229,"_source":730,"_file":1230,"_stem":1231,"_extension":733},"\u002Farticles\u002F11-how-to-read-a-blockchain-transaction","How to read a blockchain transaction: a guide for attorneys","Learn to interpret a blockchain transaction with public block explorers, from Ethereum fields and token transfers to Bitcoin inputs and evidentiary limits.","how-to-read-a-blockchain-transaction","2026-05-16",8,[17,18,742,743],"block-explorer","transaction-analysis","\u002Fog\u002Fhow-to-read-a-blockchain-transaction.png",{"type":23,"children":746,"toc":1211},[747,760,766,771,776,782,821,826,832,837,847,857,867,877,887,897,907,917,927,933,946,951,956,968,974,979,984,1007,1012,1018,1023,1028,1034,1046,1051,1057,1062,1067,1073,1078,1111,1121,1127,1132,1137,1147,1151,1157,1166,1172,1181,1187,1196,1202],{"type":26,"tag":27,"props":748,"children":749},{},[750,752,758],{"type":31,"value":751},"When a client hands you a transaction hash, a long string of letters and numbers that looks like ",{"type":26,"tag":124,"props":753,"children":755},{"className":754},[],[756],{"type":31,"value":757},"0x3a9f...c841",{"type":31,"value":759},", and tells you it represents the fraudulent transfer at the center of their case, you need to know what to do with it. Reading a blockchain transaction is not a technical skill reserved for engineers. It is a core literacy skill for any attorney handling digital asset disputes. This guide explains what you are looking at and what it means for your case.",{"type":26,"tag":56,"props":761,"children":763},{"id":762},"what-a-transaction-hash-is",[764],{"type":31,"value":765},"What a Transaction Hash Is",{"type":26,"tag":27,"props":767,"children":768},{},[769],{"type":31,"value":770},"A transaction hash (also called a transaction ID or TXID) is a unique identifier for a single blockchain transaction. Every transaction ever recorded on a public blockchain has one, and no two are the same. The hash is computed from the transaction data itself, which means it is a tamper-evident fingerprint: if any detail of the transaction changed, the hash would change.",{"type":26,"tag":27,"props":772,"children":773},{},[774],{"type":31,"value":775},"This property makes blockchain transactions attractive as evidence. A transaction hash you look up today will show the same data it showed when the transaction was recorded, because the underlying blockchain ledger is immutable. The information is also publicly accessible. Anyone with internet access can look it up.",{"type":26,"tag":56,"props":777,"children":779},{"id":778},"where-to-look-it-up",[780],{"type":31,"value":781},"Where to Look It Up",{"type":26,"tag":27,"props":783,"children":784},{},[785,787,792,794,799,801,806,808,813,815,820],{"type":31,"value":786},"For Ethereum and most EVM-compatible blockchains, go to ",{"type":26,"tag":161,"props":788,"children":789},{},[790],{"type":31,"value":791},"Etherscan.io",{"type":31,"value":793}," and paste the transaction hash into the search bar. For Bitcoin, use ",{"type":26,"tag":161,"props":795,"children":796},{},[797],{"type":31,"value":798},"Blockchain.com\u002Fexplorer",{"type":31,"value":800}," or ",{"type":26,"tag":161,"props":802,"children":803},{},[804],{"type":31,"value":805},"Mempool.space",{"type":31,"value":807},". For Solana, use ",{"type":26,"tag":161,"props":809,"children":810},{},[811],{"type":31,"value":812},"Solscan.io",{"type":31,"value":814},". For Tron, use ",{"type":26,"tag":161,"props":816,"children":817},{},[818],{"type":31,"value":819},"Tronscan.org",{"type":31,"value":281},{"type":26,"tag":27,"props":822,"children":823},{},[824],{"type":31,"value":825},"Each of these is a block explorer: a publicly accessible interface to the raw blockchain data. The data they show is the same data that anyone else looking at the same blockchain can access. These platforms do not create or curate the data; they display it.",{"type":26,"tag":56,"props":827,"children":829},{"id":828},"what-you-will-see-ethereum-transaction-fields",[830],{"type":31,"value":831},"What You Will See: Ethereum Transaction Fields",{"type":26,"tag":27,"props":833,"children":834},{},[835],{"type":31,"value":836},"When you look up an Ethereum transaction on Etherscan, here is what each field means:",{"type":26,"tag":27,"props":838,"children":839},{},[840,845],{"type":26,"tag":161,"props":841,"children":842},{},[843],{"type":31,"value":844},"Transaction Hash",{"type":31,"value":846},": The unique identifier you searched for. If it matches what your client gave you, you are looking at the right transaction.",{"type":26,"tag":27,"props":848,"children":849},{},[850,855],{"type":26,"tag":161,"props":851,"children":852},{},[853],{"type":31,"value":854},"Status",{"type":31,"value":856},": \"Success\" means the transaction executed as intended. \"Failed\" means the transaction was submitted but reverted, typically due to a smart contract condition not being met. A failed transaction still costs gas and is still permanently recorded on the chain.",{"type":26,"tag":27,"props":858,"children":859},{},[860,865],{"type":26,"tag":161,"props":861,"children":862},{},[863],{"type":31,"value":864},"Block",{"type":31,"value":866},": The block number in which this transaction was confirmed. Blockchain records are organized into sequential blocks. Higher block numbers are more recent. The block timestamp tells you exactly when the transaction was confirmed.",{"type":26,"tag":27,"props":868,"children":869},{},[870,875],{"type":26,"tag":161,"props":871,"children":872},{},[873],{"type":31,"value":874},"Timestamp",{"type":31,"value":876},": The date and time the transaction was confirmed, expressed in UTC. This is evidence of when the transfer occurred. Blockchain timestamps are set by the network's consensus process and are generally accurate to within a few seconds of real-world time.",{"type":26,"tag":27,"props":878,"children":879},{},[880,885],{"type":26,"tag":161,"props":881,"children":882},{},[883],{"type":31,"value":884},"From",{"type":31,"value":886},": The address that initiated and signed the transaction. This is the sender. Every Ethereum transaction is cryptographically signed by the sender's private key. The \"From\" field is not self-reported. It is mathematically derived from the signature. This is why it cannot be forged.",{"type":26,"tag":27,"props":888,"children":889},{},[890,895],{"type":26,"tag":161,"props":891,"children":892},{},[893],{"type":31,"value":894},"To",{"type":31,"value":896},": The address that received the transaction. This may be a user wallet (an externally owned account) or a smart contract. If it is a contract address, the transaction is interacting with that contract's code, which is more complex to interpret.",{"type":26,"tag":27,"props":898,"children":899},{},[900,905],{"type":26,"tag":161,"props":901,"children":902},{},[903],{"type":31,"value":904},"Value",{"type":31,"value":906},": The amount of native cryptocurrency (ETH, in this case) transferred directly. Many ERC-20 token transfers show a value of 0 ETH, because the token transfer is handled by the contract, not by the native value field.",{"type":26,"tag":27,"props":908,"children":909},{},[910,915],{"type":26,"tag":161,"props":911,"children":912},{},[913],{"type":31,"value":914},"Transaction Fee",{"type":31,"value":916},": The gas fee paid to the network. This is important in some disputes but is not part of the transferred value.",{"type":26,"tag":27,"props":918,"children":919},{},[920,925],{"type":26,"tag":161,"props":921,"children":922},{},[923],{"type":31,"value":924},"Input Data",{"type":31,"value":926},": If the \"To\" address is a contract, this field contains the encoded instructions telling the contract what to do. This is where ERC-20 token transfers are encoded, and it is where DeFi protocol interactions are documented. Reading input data requires technical interpretation.",{"type":26,"tag":56,"props":928,"children":930},{"id":929},"token-transfers-vs-eth-transfers",[931],{"type":31,"value":932},"Token Transfers vs. ETH Transfers",{"type":26,"tag":27,"props":934,"children":935},{},[936,938,944],{"type":31,"value":937},"A common point of confusion: when someone transfers USDC, USDT, or any ERC-20 token, the ETH value field of the transaction will show 0. The actual token transfer is encoded in the \"Input Data\" as a function call to the token contract's ",{"type":26,"tag":124,"props":939,"children":941},{"className":940},[],[942],{"type":31,"value":943},"transfer()",{"type":31,"value":945}," function.",{"type":26,"tag":27,"props":947,"children":948},{},[949],{"type":31,"value":950},"Etherscan helpfully decodes this and displays it in an \"ERC-20 Tokens Transferred\" section beneath the main transaction fields. This shows the token, the amount, the sender, and the recipient. This is the information you need for most cryptocurrency dispute tracing involving stablecoins or tokens.",{"type":26,"tag":27,"props":952,"children":953},{},[954],{"type":31,"value":955},"Hypothetical example: A client provides a hash that shows 0 ETH in the Value field but an ERC-20 Tokens Transferred entry for USDC. The entry identifies the token movement even though no ETH moved directly.",{"type":26,"tag":27,"props":957,"children":958},{},[959,961,967],{"type":31,"value":960},"For a broader explanation of what public transaction records can establish, see ",{"type":26,"tag":39,"props":962,"children":964},{"href":963},"\u002Fresources\u002Fcan-blockchain-transactions-be-traced",[965],{"type":31,"value":966},"how blockchain transactions can be traced",{"type":31,"value":281},{"type":26,"tag":56,"props":969,"children":971},{"id":970},"what-a-bitcoin-transaction-looks-like",[972],{"type":31,"value":973},"What a Bitcoin Transaction Looks Like",{"type":26,"tag":27,"props":975,"children":976},{},[977],{"type":31,"value":978},"Bitcoin transactions work differently. Bitcoin has no \"From\" field in the same sense: instead, Bitcoin uses an Unspent Transaction Output (UTXO) model. Each Bitcoin transaction consumes specific prior outputs (inputs) and creates new outputs.",{"type":26,"tag":27,"props":980,"children":981},{},[982],{"type":31,"value":983},"On Blockchain.com or Mempool.space, a Bitcoin transaction shows:",{"type":26,"tag":341,"props":985,"children":986},{},[987,997],{"type":26,"tag":157,"props":988,"children":989},{},[990,995],{"type":26,"tag":161,"props":991,"children":992},{},[993],{"type":31,"value":994},"Inputs",{"type":31,"value":996},": One or more prior UTXOs being spent, with their addresses",{"type":26,"tag":157,"props":998,"children":999},{},[1000,1005],{"type":26,"tag":161,"props":1001,"children":1002},{},[1003],{"type":31,"value":1004},"Outputs",{"type":31,"value":1006},": One or more destination addresses and amounts",{"type":26,"tag":27,"props":1008,"children":1009},{},[1010],{"type":31,"value":1011},"The key distinction from Ethereum: there is no single \"sender\" address by design. Multiple input addresses may appear in the same transaction. Blockchain forensics uses this structure, the common-input ownership heuristic, to infer that multiple input addresses are likely controlled by the same party. That inference is probabilistic, not absolute.",{"type":26,"tag":56,"props":1013,"children":1015},{"id":1014},"confirmations-what-they-mean-for-evidence",[1016],{"type":31,"value":1017},"Confirmations: What They Mean for Evidence",{"type":26,"tag":27,"props":1019,"children":1020},{},[1021],{"type":31,"value":1022},"Every transaction shows a \"confirmations\" count: how many blocks have been added on top of the block containing this transaction. For Bitcoin, 6+ confirmations is the standard for finality. For Ethereum, finality is more complex but practically speaking, transactions older than a few minutes are permanent.",{"type":26,"tag":27,"props":1024,"children":1025},{},[1026],{"type":31,"value":1027},"For evidentiary purposes, a transaction with hundreds or thousands of confirmations is finalized. It cannot be reversed, altered, or removed. This is different from a bank transaction that can be reversed by the institution for days or weeks after it posts.",{"type":26,"tag":56,"props":1029,"children":1031},{"id":1030},"what-a-block-explorer-does-not-show",[1032],{"type":31,"value":1033},"What a Block Explorer Does Not Show",{"type":26,"tag":27,"props":1035,"children":1036},{},[1037,1039,1044],{"type":31,"value":1038},"Block explorers display on-chain data. They do not show you who controls an address. An Ethereum address is just a public key hash. The block explorer cannot tell you that ",{"type":26,"tag":124,"props":1040,"children":1042},{"className":1041},[],[1043],{"type":31,"value":757},{"type":31,"value":1045}," belongs to your opposing party's personal wallet without additional evidence. That attribution step, connecting an address to a person, requires external evidence: exchange KYC records, IP logs, device data, or other corroboration.",{"type":26,"tag":27,"props":1047,"children":1048},{},[1049],{"type":31,"value":1050},"This is the foundational limitation of blockchain evidence. The transaction is undeniable. The attribution of who initiated it is a separate question.",{"type":26,"tag":56,"props":1052,"children":1054},{"id":1053},"internal-transactions",[1055],{"type":31,"value":1056},"Internal Transactions",{"type":26,"tag":27,"props":1058,"children":1059},{},[1060],{"type":31,"value":1061},"On Ethereum, you will often see a tab labeled \"Internal Transactions.\" These are value transfers triggered by smart contract execution, not by a direct user transaction. When a DeFi protocol routes funds through multiple contracts in a single user transaction, those sub-transfers show up as internal transactions.",{"type":26,"tag":27,"props":1063,"children":1064},{},[1065],{"type":31,"value":1066},"Internal transactions are important for tracing fund flows through DeFi. A user's transaction may show 0 ETH value in the main record, but internal transactions reveal that the contract sent funds to multiple destinations. Forensic analysis of DeFi interactions requires reading internal transaction data.",{"type":26,"tag":56,"props":1068,"children":1070},{"id":1069},"how-to-preserve-this-evidence",[1071],{"type":31,"value":1072},"How to Preserve This Evidence",{"type":26,"tag":27,"props":1074,"children":1075},{},[1076],{"type":31,"value":1077},"For litigation purposes, screenshots of block explorer pages are acceptable exhibits but are better supplemented with:",{"type":26,"tag":341,"props":1079,"children":1080},{},[1081,1091,1101],{"type":26,"tag":157,"props":1082,"children":1083},{},[1084,1089],{"type":26,"tag":161,"props":1085,"children":1086},{},[1087],{"type":31,"value":1088},"Direct node queries",{"type":31,"value":1090}," or API exports with query parameters logged, establishing that the data came from the blockchain itself, not from a third-party display that could theoretically be manipulated",{"type":26,"tag":157,"props":1092,"children":1093},{},[1094,1099],{"type":26,"tag":161,"props":1095,"children":1096},{},[1097],{"type":31,"value":1098},"SHA-256 hashes",{"type":31,"value":1100}," of exported transaction data files recorded at the time of capture",{"type":26,"tag":157,"props":1102,"children":1103},{},[1104,1109],{"type":26,"tag":161,"props":1105,"children":1106},{},[1107],{"type":31,"value":1108},"Timestamps",{"type":31,"value":1110}," of when data was retrieved, establishing the point-in-time snapshot",{"type":26,"tag":27,"props":1112,"children":1113},{},[1114,1116,1120],{"type":31,"value":1115},"A blockchain forensic expert can provide authenticated blockchain data that has been preserved with proper chain of custody, and can explain the technical meaning of each field in a format appropriate for expert disclosure. This work is part of ",{"type":26,"tag":39,"props":1117,"children":1118},{"href":428},[1119],{"type":31,"value":431},{"type":31,"value":281},{"type":26,"tag":56,"props":1122,"children":1124},{"id":1123},"the-practical-takeaway",[1125],{"type":31,"value":1126},"The Practical Takeaway",{"type":26,"tag":27,"props":1128,"children":1129},{},[1130],{"type":31,"value":1131},"Understanding how to read a blockchain transaction lets you evaluate the strength of the blockchain evidence in your matter before you engage an expert. You can assess whether the transaction hash your client provided actually shows what they claim, understand what the opposing party's exhibit actually contains, and ask better questions of a forensic expert.",{"type":26,"tag":27,"props":1133,"children":1134},{},[1135],{"type":31,"value":1136},"The on-chain data is public and permanent. Getting to it requires only knowing where to look and what each field means. The harder part, attributing that transaction to a specific person, is where qualified forensic analysis begins.",{"type":26,"tag":27,"props":1138,"children":1139},{},[1140,1142,1146],{"type":31,"value":1141},"For an overview of how that analysis is conducted, see the ",{"type":26,"tag":39,"props":1143,"children":1144},{"href":565},[1145],{"type":31,"value":568},{"type":31,"value":281},{"type":26,"tag":56,"props":1148,"children":1149},{"id":617},[1150],{"type":31,"value":620},{"type":26,"tag":228,"props":1152,"children":1154},{"id":1153},"q-does-a-transaction-hash-prove-that-my-client-or-the-opposing-party-made-the-transfer",[1155],{"type":31,"value":1156},"Q: Does a transaction hash prove that my client or the opposing party made the transfer?",{"type":26,"tag":27,"props":1158,"children":1159},{},[1160,1164],{"type":26,"tag":161,"props":1161,"children":1162},{},[1163],{"type":31,"value":634},{"type":31,"value":1165}," No. A transaction hash can establish the recorded transaction and its originating address, but a block explorer does not identify the person who controlled that address. Attribution to a person requires corroborating evidence, such as exchange KYC records, IP logs, or device data.",{"type":26,"tag":228,"props":1167,"children":1169},{"id":1168},"q-does-a-0-eth-value-mean-that-no-asset-changed-hands",[1170],{"type":31,"value":1171},"Q: Does a 0 ETH value mean that no asset changed hands?",{"type":26,"tag":27,"props":1173,"children":1174},{},[1175,1179],{"type":26,"tag":161,"props":1176,"children":1177},{},[1178],{"type":31,"value":634},{"type":31,"value":1180}," No. ERC-20 transfers, including USDC and USDT transfers, commonly show 0 ETH in the native value field because the token movement is executed through the token contract. Review the decoded input data and the explorer's ERC-20 Tokens Transferred section to identify the token, amount, sender, and recipient.",{"type":26,"tag":228,"props":1182,"children":1184},{"id":1183},"q-can-i-describe-every-bitcoin-input-in-a-transaction-as-the-senders-wallet",[1185],{"type":31,"value":1186},"Q: Can I describe every Bitcoin input in a transaction as the sender's wallet?",{"type":26,"tag":27,"props":1188,"children":1189},{},[1190,1194],{"type":26,"tag":161,"props":1191,"children":1192},{},[1193],{"type":31,"value":634},{"type":31,"value":1195}," No. Bitcoin transactions can spend multiple prior outputs, and Bitcoin has no single From field like Ethereum. The common-input ownership heuristic may support an inference that the input addresses are controlled by one party, but the article describes that inference as probabilistic rather than absolute.",{"type":26,"tag":228,"props":1197,"children":1199},{"id":1198},"q-what-should-i-preserve-once-i-identify-a-transaction-relevant-to-a-case",[1200],{"type":31,"value":1201},"Q: What should I preserve once I identify a transaction relevant to a case?",{"type":26,"tag":27,"props":1203,"children":1204},{},[1205,1209],{"type":26,"tag":161,"props":1206,"children":1207},{},[1208],{"type":31,"value":634},{"type":31,"value":1210}," Preserve more than a screenshot. The article recommends retaining direct node queries or API exports with the query parameters logged, SHA-256 hashes of exported transaction data, and the time of retrieval. Those records help establish the source of the data, the point-in-time snapshot, and the chain of custody.",{"title":8,"searchDepth":704,"depth":704,"links":1212},[1213,1214,1215,1216,1217,1218,1219,1220,1221,1222,1223],{"id":762,"depth":704,"text":765},{"id":778,"depth":704,"text":781},{"id":828,"depth":704,"text":831},{"id":929,"depth":704,"text":932},{"id":970,"depth":704,"text":973},{"id":1014,"depth":704,"text":1017},{"id":1030,"depth":704,"text":1033},{"id":1053,"depth":704,"text":1056},{"id":1069,"depth":704,"text":1072},{"id":1123,"depth":704,"text":1126},{"id":617,"depth":704,"text":620,"children":1224},[1225,1226,1227,1228],{"id":1153,"depth":710,"text":1156},{"id":1168,"depth":710,"text":1171},{"id":1183,"depth":710,"text":1186},{"id":1198,"depth":710,"text":1201},"content:articles:11-how-to-read-a-blockchain-transaction.md","articles\u002F11-how-to-read-a-blockchain-transaction.md","articles\u002F11-how-to-read-a-blockchain-transaction",1790145013677]