Blockchain Evidence in Court: How to Preserve On-Chain Data and Maintain Chain of Custody

An investigator finds the transaction that moved stolen funds from a victim's wallet. They save a screenshot from a block explorer, copy the transaction hash into a report, build a fund-flow graph, and send the file to the client. Months later, the case reaches a lawyer or law enforcement. The analyst is asked: which data source was used? What labels were available at the time? What filters were applied? Has the exported file been modified since collection? The screenshot shows a timestamp, but not whether the explorer's interface, labels, or decoded data have changed since the image was captured.

The blockchain may preserve the transaction. It does not preserve the investigator's evidence process.

A ledger record can remain public and immutable for the lifetime of the network. But the screenshot, the CSV export, the JSON response, the PDF report, the fund-flow graph, the entity label, and the analyst's notes are separate digital evidence objects. Each of them requires documented collection, integrity verification, controlled storage, access records, and transformation history — because none of them live on the blockchain. They live on someone's hard drive, in a cloud folder, or in an email attachment. And without a defensible record of how they were collected, stored, and handled, the strongest on-chain evidence can become the weakest exhibit.

A blockchain record also does not, by itself, prove who owns a wallet, what someone intended, whether funds are legally stolen property, or whether a crime occurred. It proves that a specific transaction was included in a specific block at a specific time. Everything beyond that — identity, intent, ownership, culpability — requires additional evidence and analysis.

This article explains what qualifies as native on-chain fact versus analytical conclusion, what data should be preserved, how to distinguish a transaction hash from an evidence-file hash, how to maintain chain of custody for collected blockchain files, how to document methodology and attribution, and what a defensible evidence package for legal review should contain. Evidentiary and admissibility rules depend on jurisdiction, case type, and procedural context — this article describes defensible evidence practices, not a guarantee that any specific report will be admitted. For a broader overview of how crypto forensics turns blockchain data into investigative evidence, see our article on how crypto forensics turns blockchain data into evidence.

What Blockchain Evidence Can Prove — and What It Cannot

Three levels must be separated: native blockchain records, analytical findings, and interpretive or legal conclusions.

1. Native on-chain facts are data points that can be independently verified by querying the blockchain. These include the existence of a specific transaction, blockchain network, transaction hash, block height and block hash, addresses or script destinations involved, transferred asset and quantity, transaction fee, execution status, contract calls, emitted events, token transfers, sequence of transactions, data included in the transaction, observable balance or state changes, and confirmations or finalized status at the time of collection. The set of available fields depends on blockchain architecture — a Bitcoin UTXO transaction and an Ethereum-compatible contract transaction have different data structures. A report should preserve not only the human-readable interpretation but also the underlying raw fields.
2. Analytical findings and calculations include reconstructed fund-flow paths, balance calculations, allocation of funds between branches, identification of consolidation or dispersion, cross-chain correlation, exposure percentages, transaction chronology, and identification of probable swap, bridge, or service interaction. These are not necessarily subjective opinion, but they require documented input data, a clear method, reproducible formulas or logic, treatment of fees, partial amounts, and asset conversions, and an explanation of assumptions.
3. Attribution and expert opinion include wallet cluster attribution, entity labels (exchange, mixer, scam, darknet service), assumption of common control, identification of bridge exit, claims that transactions represent layering, theft proceeds, or laundering, and assessment of likely ownership or intent. Attribution may be based on provider data, open-source records, behavioral heuristics, service deposit patterns, or third-party records. The strength of any conclusion depends on source and methodology. A report should distinguish confirmed entity attribution, high-confidence inference, and unresolved hypothesis. A risk label is not a native blockchain fact.

Why Blockchain Immutability Does Not Replace Evidence Preservation

1. Ledger integrity vs. evidence-file integrity. Ledger integrity means a transaction was included in the blockchain and can be independently queried. Evidence-file integrity means a saved JSON, CSV, PDF, screenshot, graph, or report remains the same file that was collected or produced at a documented time. An analyst can modify a spreadsheet. A graph can be regenerated with different settings. An explorer page can change its interface. An API output can adopt a different format. Entity labels can be updated. A PDF can be edited. Screenshots can be cropped or separated from context. The existence of an immutable transaction does not prove that a particular exhibit or report has not been changed.
2. Public availability vs. reproducibility. Public data supports independent verification, but a reviewer must know the exact chain, transaction, block, source, query method, and cutoff date. A transaction may be visible through different explorer interfaces. Providers may differ in how they interpret internal calls, token events, labels, or traces. An archived raw response allows verification of what the analyst actually saw at the time of collection.
3. Blockchain timestamp vs. evidence collection time. A transaction or block timestamp, the time a block was confirmed or finalized, the time the investigator collected data, the time a file was hashed, the time an analysis was performed, and the time a report was signed or transferred are all different events. Do not use one timestamp for all of them. The SWGDE (Scientific Working Group on Digital Evidence) recommends that the data-integrity process begin at the point of identification and collection, and that contemporaneous documentation include tools, logs, reports, screenshots, file details, and hash values.

Define the Evidence Scope Before Collection

1. Define the event and the question. Before collecting data, document the triggering incident, the alleged loss or suspicious activity, the relevant time period, asset and amount, known starting addresses or transactions, the question the investigation must answer, the intended audience (internal compliance, exchange, lawyer, regulator, law enforcement, or court), and whether the work concerns factual preservation, tracing, attribution, or expert interpretation.
2. Define networks, assets, and cutoff points. Specify the full blockchain name, mainnet or testnet, chain ID where applicable, native asset or token contract, token decimals, starting transaction, included addresses, block or date range, stopping condition, cross-chain boundaries, and the cutoff date of analysis. Do not use only a ticker symbol — identical or similar asset symbols may exist on different chains and contracts.
3. Assign collection and review roles. Determine who collects raw data, who conducts analysis, who verifies calculations, who stores original evidence, who may access it, who creates exhibits, who approves the final report, and when a qualified forensic expert or legal counsel is required. If one person performs several roles, document this rather than concealing it.

What On-Chain Data Should Be Preserved

1. Transaction and block records. For each material transaction, preserve the blockchain and network, chain ID where available, transaction hash, transaction status, block height, block hash, block timestamp, confirmation or finality status at collection, sender or input addresses, recipient or output addresses, transferred amount, asset, transaction fee, nonce where relevant, transaction type, raw input or call data where relevant, raw node or API response, and source and collection timestamp. For UTXO-based chains, additionally preserve all transaction inputs, previous transaction references, outputs, output indexes, scripts where relevant, change-output interpretation only if used in analysis, and spent or unspent status at the relevant time.
2. Token and smart contract data. For token or contract activity, preserve the token contract address, token name and symbol as displayed, decimals, transfer event, event-log index, contract called, function signature or decoded method where used, transaction receipt, execution status, emitted logs, internal calls or traces where material, contract creation or proxy relationship where relevant, and state change used in analysis. Displayed token name and symbol are not sufficient identifiers — contract address and blockchain must be the primary reference. Decoded data should be preserved alongside its raw form.
3. Address and balance context. If the report uses balances or address history, preserve the address, blockchain, block height or timestamp at which the balance was queried, native and token balances, transaction history range, query source, whether the result is current or historical balance, whether pending transactions were included, and relevant contract or staking positions if relied upon. A current balance cannot be presented as evidence of a historical balance without an appropriate historical query.
4. Exchange, bridge, and cross-chain references. If the transaction involves a service or cross-chain movement, preserve the identified service or protocol, relevant deposit or hot-wallet address, service attribution source, bridge contract, source-chain transaction, destination-chain transaction, asset entering and leaving, amounts before and after fees, timestamps, recipient addresses, correlation methodology, confidence level, and unconfirmed gaps.

Preserve Source Data, Not Only Explorer Screenshots

A block explorer page is a rendered interpretation of underlying blockchain data. It may display decoded contract calls, translated event logs, third-party entity labels, estimated fiat values, and formatted timestamps that can change between visits. A screenshot of an explorer page is a useful exhibit — but it should not be the only preserved evidence source.

1. Raw node or API responses from a blockchain node, an RPC endpoint, or a provider API represent the data closest to the ledger itself. Saving the full JSON response, including block data, transaction receipt, event logs, and trace data where available, creates a machine-readable evidence artifact that can be independently verified, re-parsed, and compared with the explorer presentation. For each raw response, record the source (node, endpoint, or provider), the request made, the response received, the date and time of collection, and the collector's identity.
2. Forensic platform exports from blockchain analytics tools provide risk scores, entity attribution, fund-flow graphs, and formatted reports. These outputs should be saved as received — not modified before storage. For each export, record the tool name and version, the export date, the queried address or transaction, the report or export ID, the export format, the visible data state, and the file hash. AMLBot's blockchain tracing tool supports export and visualization functions designed for investigative use — but no tool output is automatically admissible evidence. Admissibility remains a legal and procedural question.

Create Original, Archive, and Working Copies

1. Original acquisition copy. Created immediately after collection, stored in read-only or controlled storage, not used for normal analysis, assigned a unique evidence ID, hashed, linked to collection notes, and not edited or renamed without a recorded reason. If the source produces several files, they can be stored as an original evidence set with a manifest.
2. Preservation or archive copy. Created for redundancy and long-term retention, verified against the original hash, stored separately, subject to access restrictions, included in backup and retention processes, and not used as a casual working folder. Every evidence copy should have an understood purpose and location.
3. Working copy. Used for parsing, graph building, filtering, calculations, annotation, conversion, and report preparation. For the working copy, record which original it was created from, creation date, verification result, analyst, software used, and subsequent derived files. Changes to the working copy are acceptable as long as the original remains untouched and transformations are documented.

Hash the Evidence and Record Integrity Checks

NIST and the SWGDE recommend calculating an evidence hash as close to collection as possible, securely storing the baseline hash, and using subsequent verification to confirm that no changes have occurred.

1. Transaction hash is not an evidence-file hash. A transaction hash identifies a blockchain transaction and belongs to the blockchain protocol — it helps locate and verify the ledger record. An evidence-file hash is calculated from a collected JSON, CSV, PDF, image, archive, or report — it changes if the file changes and is used to verify the integrity of the preserved artifact. The existence of a transaction hash does not prove that a screenshot, report, or exported dataset has remained unchanged.
2. Acquisition hash. At collection, calculate a cryptographic hash of the original file or evidence package, record the algorithm, record the exact value, record the date and time, identify the person and system, store the hash separately in a controlled record, and include it in the evidence inventory. For multi-file datasets, use individual file hashes, a manifest with all files and hashes, a hash of the preserved archive, or both.
3. Verification hash. Re-verify the hash after transfer, after copying to archive, before analysis, before disclosure, before expert review, before final submission, and after recovery from backup. Record the expected hash, calculated hash, result, date, person or system, and any mismatch and response.
4. Protect the hash record. The hash log must be stored so that a person with access to the evidence cannot undetectably change both the file and the recorded hash simultaneously. Possible controls include a case-management system, a digitally signed manifest, an access-controlled register, a write-protected record, an independent custodian, or a secure audit log. Storing the hash on another blockchain is not required — NIST notes that blockchain can be used to secure hashes, but for most evidence units the associated overhead may not be justified.

Maintain a Chain of Custody for the Collected Evidence

Chain of custody applies to collected files, records, and exhibits — not to the transmission of the public blockchain itself.

1. Evidence inventory. For each evidence item, record the case ID, evidence item ID, description, source, blockchain and network, relevant transaction or address, file name, file type, file size, acquisition hash, collection date and time, collector, storage location, and sensitivity or access classification. If one item contains several files, add a manifest.
2. Custody, transfer, and access log. Record who received access, the purpose, date and time, from whom, to whom, transfer method, storage location before and after, integrity verification, whether the copy or original was transferred, signature or electronic approval, and return, destruction, or further disclosure. The SWGDE recommends creating chain-of-custody documentation at collection and maintaining it throughout the life of the case; notes should be created contemporaneously.
3. Transformations and derived evidence. For each derived item, identify the source evidence item, describe the transformation, record the tool and version, date, analyst, output file, output hash, whether the transformation changes content or only format, and whether calculations or annotations were added. Examples of derivative evidence include filtered CSV, transaction chronology, translated table, annotated graph, converted PDF, redacted exhibit, summary chart, and calculated exposure table.
4. Third-party productions. For data from an exchange, custodian, analytics provider, cloud service, or other third party, preserve the original delivery email or transfer record, sender, request or legal-process reference, download link where relevant, date received, original file, provider metadata, hash immediately after receipt, certificate or declaration of authenticity where available, and working and archive copies. The SWGDE specifically recommends hashing the original third-party production, preserving its source, creating archive and working copies, and requesting appropriate authenticity documentation where available.

Make the Collection and Analysis Reproducible

1. Record tools, providers, and versions. Document the node software, RPC or API provider, blockchain explorer, analytics platform, script or query tool, software version, operating environment where material, decoder or parser, export format, time zone settings, and known limitations. If a proprietary tool version is not available, record the product, report ID, export date, and available environment details.
2. Record the query and parameters. Save the request method, endpoint category, transaction or address queried, block range, chain ID, filters, include/exclude settings, pagination, token-decimal treatment, trace options, timezone, and price source and valuation time if fiat calculations are included. For custom scripts, preserve code version, input files, dependencies, configuration, execution log, and output hashes.
3. Record cutoff dates and data state. Specify data collected through which block, report prepared as of which date, attribution database checked when, sanctions or watchlist checked when, exchange or protocol label current as of when, whether the investigation continued after the report, and whether later updates are included in a supplement.
4. Preserve errors and deviations. Do not hide failed API requests, missing archive-node data, incomplete traces, unavailable chain history, provider disagreement, manual corrections, deviations from standard procedure, chain reorganization or finality concerns where relevant, or data lost before collection. A deviation does not automatically make evidence unusable, but the reason and impact must be documented. The SWGDE also notes that deviations from best practices should be recorded in detail.

Separate Confirmed Facts, Calculations, Attribution, and Legal Conclusions

1. Confirmed blockchain facts should be formulated narrowly: transaction X was included in block Y; address A transferred amount B to address C; contract D emitted event E; funds reached an address attributed to a specified service by a documented source; the transaction failed or succeeded; the balance at a specified block was a specified amount. Even factual statements should cite the source and reference.
2. Calculated or reconstructed findings — total amount traced, proportion of funds reaching each branch, value at historical exchange rate, amount remaining after fees, time between transactions, suspected cross-chain equivalent, exposure percentage — should be marked as calculations and presented with methodology and inputs.
3. Attribution and inference should use language matching confidence: confirmed by provider records; attributed by a named analytics source; consistent with; likely; probable; possible; not independently confirmed; no conclusion possible. For clustering, explain the heuristic, supporting signals, competing explanations, confidence level, and whether a service deposit model could affect the conclusion.
4. Legal conclusions — that a defendant committed money laundering, that a wallet legally belongs to a named person, that someone had criminal intent, that evidence is admissible, that funds are legally stolen property, that a court must freeze or return assets — belong to counsel, authorities, and the court under applicable law. An analyst may describe observed movement, risk indicators, known service links, pattern consistency, and evidence limitations — but should not make legal characterizations without proper role and authority.

Preserve Attribution and Risk Data as Time-Stamped Evidence

Entity labels, risk categories, and sanctions results can change even though the transaction itself remains unchanged. Record the attribution source — attributed entity, address or cluster, provider or source, report or dataset ID, date and time, attribution category, confidence, supporting records, and whether attribution is direct or inherited from a cluster. Preserve the historical snapshot — screenshot or PDF, raw export, risk report, checked categories, last processed block where available, provider timestamp, report hash, and related watchlist or sanctions data. Do not replace the original snapshot with an updated report — a later result should be a separate supplemental evidence item. If attribution later changed, preserve old and new results, record the date discovered, explain what changed, assess the effect on previous conclusions, issue a supplement or corrected report, and do not silently overwrite the original.

Preserve Cross-Chain and DeFi Evidence Without Hiding Gaps

1. Preserve both sides of a bridge. Save the source-chain transaction, bridge entry contract, asset and amount sent, fees, event logs, source block, destination-chain transaction, bridge exit or mint contract, asset received, destination address, destination block, timestamps, bridge model, and correlation method. Source and destination ledgers record separate events, and continuity may require analytical correlation. For more on how cross-chain transactions are reconstructed, see our article on how cross-chain transactions are reconstructed.
2. Preserve swaps, pools, and contract calls. For a swap or DeFi interaction, save the transaction receipt, router, pools, input asset, output asset, event logs, internal calls, slippage and fee treatment if used, recipient, actual output amount, any aggregator route, and decoded and raw call data. Do not describe a contract address as the final beneficiary if the contract only routed funds.
3. State where continuity is inferred. Cross-chain evidence may contain confirmed protocol-generated links, unique bridge identifiers, provider-reported links, exact mapped events, amount-and-time correlations, behavioral inferences, or unresolved breaks. The report must clearly state which category applies. Do not silently assume continuity where it has not been confirmed.

Add Off-Chain Evidence That Connects Transactions to Real Events

On-chain data rarely proves identity, ownership, authorization, or intent by itself.

1. Service-provider and account records may include exchange KYC/KYB, account holder details, deposit-address assignment, withdrawal records, account login history, devices and IPs, authentication changes, support communications, internal transaction IDs, bank or payment records, and freeze or disclosure responses. Obtaining such records must comply with legal authority, consent, privacy rules, and applicable process.
2. Wallet ownership and control evidence may include wallet creation or backup records, signed messages, controlled test transactions (if legally and operationally appropriate), device forensic evidence, wallet application records, exchange withdrawal history, private communications referencing the address, accounting or treasury records, and testimony of a person with knowledge. Seed phrases and private keys should not be included in a report or evidence package unless properly seized and handled by authorized specialists under specific procedure.
3. Communications and incident records — emails, messages, website pages, invoices, payment instructions, contracts, support tickets, call records, incident logs, internal approvals, screenshots, and original files with metadata — should be preserved alongside on-chain evidence to connect transactions to real-world events. For a practical checklist of what information theft victims should collect immediately, see our article on what information to collect after crypto theft.

Build a Blockchain Evidence Package for Legal Review

1. Factual case summary. Briefly state the matter and scope, instructing party, purpose of the report, relevant incident, assets and networks, starting transaction, analysis period, high-level confirmed findings, and exclusions and limitations. Do not place detailed methodology in the executive summary.
2. Chronology and transaction schedule. Prepare a chronological table with event number, date and time, blockchain, block, transaction hash, sender, recipient, asset, amount, transaction function, factual description, and evidence-item reference. For large cases, the table may contain material transactions while the full dataset sits in the appendix.
3. Technical methodology appendix. Include sources, tools, versions, queries, collection method, parsing, calculations, clustering methodology, cross-chain methodology, attribution sources, time zone, valuation method, quality-control review, and known limitations.
4. Evidence index and chain-of-custody record. Include evidence IDs, file descriptions, hashes, locations, collectors, custody history, derivative relationships, disclosure history, and retained original and working copies.
5. Visual exhibits. Graphs and charts should have exhibit numbers, identify source data, state whether simplified, preserve direction and chronology, show chain and asset, explain labels and legends, distinguish known entity from inferred cluster, reference underlying transactions, and avoid hiding branches that contradict the narrative. A visual exhibit is a presentation layer, not a replacement for underlying data.
6. Findings, confidence, and limitations. For each material conclusion, state the finding, evidence supporting it, classification as fact, calculation, or opinion, confidence, alternative explanation, unresolved information, and effect of missing data.

Authentication and Admissibility Depend on the Jurisdiction

Courts and tribunals apply local evidence rules. Requirements differ between civil, criminal, arbitration, forfeiture, and regulatory proceedings. Authentication, hearsay, expert testimony, disclosure, and privacy rules may all apply. Qualified local counsel should determine the procedural route. Strong preservation improves defensibility but does not guarantee admission. As an illustration — not a universal standard — the U.S. Federal Rules of Evidence provide a useful reference framework.

1. Authentication of the evidence. Under U.S. Federal Rule of Evidence 901, the proponent must show that evidence is what it is claimed to be. Authentication may rely on a witness with knowledge, distinctive characteristics, or evidence describing an electronic process or system and showing an accurate result. For blockchain evidence, this may require explaining how data was obtained, from which network, how the transaction was identified, how the output was preserved, how integrity was checked, and how the graph or table was produced.
2. Electronic records and certified copies. Rule 902 includes certified records generated by an electronic process or system and certain certified data copied from electronic devices, storage media, or files. Exact applicability to blockchain exports or provider records depends on the evidence type and certification available. An analyst should not independently promise self-authentication.
3. Expert testimony and methodology. When a report contains clustering, tracing interpretation, entity attribution, bridge correlation, laundering-pattern analysis, or specialized blockchain explanation, expert evidence may be required. Under Rule 702, specialized testimony is evaluated through expert qualifications, sufficient facts or data, reliable principles and methods, and reliable application to case facts. Not every blockchain record requires an expert witness — native transaction facts and complex analytical opinions may require different foundation.
4. Summaries, charts, and underlying data. Large transaction datasets are often presented through chronologies, summary tables, graphs, and calculations. Under Rule 1006, summaries of voluminous material may be used under specified conditions, while underlying originals or duplicates must be made available to other parties.

Quality-Control Review Before Evidence Is Disclosed

Before the evidence package is transmitted, conduct an independent or second-person review. Confirm every material transaction hash. Confirm blockchain, chain ID, and asset. Verify amounts and token decimals. Recalculate totals. Check UTC and displayed time zones. Verify all evidence-file hashes. Compare report references with the evidence index. Check that every chart points to underlying data. Review attribution sources and dates. Identify statements presented too strongly. Check alternative explanations. Confirm cross-chain gaps are disclosed. Confirm personal data and privileged information handling. Confirm original files remain preserved. Confirm custody and disclosure logs are complete. Record the reviewer, date, and findings. Issue a controlled final version.

If the report changes after review, generate a new version, calculate a new hash, preserve the previous controlled version, record the reason, update the evidence index, and notify recipients where required.

Conclusion

Blockchain preserves the transaction history. It does not preserve the investigator's collection process. A transaction hash identifies a ledger record but does not protect exported evidence files. Screenshots and graphs are useful exhibits but should remain connected to raw source data. Original, archive, and working copies must be separated. Integrity requires early hashing and later verification. Chain of custody must record collection, access, transfer, and transformation. Attribution and clustering must be presented with source and confidence. Cross-chain gaps must be disclosed. Wallet ownership and intent usually require off-chain evidence. Admissibility depends on jurisdiction and court.

Blockchain evidence becomes defensible not because the ledger is immutable, but because every step from collection to conclusion is transparent, preserved, and verifiable.

FAQ