# Blockchain Forensics and OSINT: An Evidence Workflow > Learn how blockchain forensics and lawful OSINT fit into a defensible workflow for evidence preservation, analysis, confidence and reporting. Published: 2026-04-04 | Author: MRHB Network Editorial Team Canonical: https://mrhb.network/blogs/blockchain-forensics-osint/ See also: https://mrhb.network/llms.txt --- **Last updated:** October 02, 2026 · **Reading time:** 9 minutes · **Author:** MRHB Network Editorial Team > **Important:** This guide is for lawful, authorised investigations. It is not legal advice and does not authorise surveillance, account access, data purchase, identity exposure, seizure or contact with a suspected person. Rules for privacy, evidence, employment, financial crime and criminal procedure vary by jurisdiction. Use qualified legal and investigative professionals for a real case. ## Quick answer Blockchain forensics examines records created by a blockchain. Open-source intelligence, or **OSINT**, examines information that is lawfully available from public sources. Used together, they can connect a transaction trail with useful context. But neither method automatically proves who controlled an address or why a transaction occurred. A defensible investigation keeps three things separate: 1. **Observed facts** — what the source directly records. 2. **Analytical inferences** — what a pattern may suggest. 3. **Attribution claims** — who may be linked to the activity. The safe workflow is to define authority, preserve the starting evidence, reconstruct the on-chain activity, add lawful OSINT, test alternative explanations, record confidence and report the result with its limits. ## What blockchain forensics can—and cannot—show Public blockchains can expose transaction identifiers, addresses, amounts, block position, fees and smart-contract activity. The exact fields depend on the network. Bitcoin uses an **unspent transaction output**, or UTXO, model. A transaction consumes earlier outputs and creates new ones. Ethereum uses an account-based model in which a signed transaction changes network state and may trigger smart-contract actions. These models produce different evidence paths; an investigator should not apply one network's assumptions to another. Blockchain data can help answer questions such as: - Which transactions followed a known incident? - Which assets and networks were involved? - Did funds enter a bridge, exchange deposit address or smart contract? - Which events happened before or after a known timestamp? It usually cannot answer these questions alone: - Who controlled an address at a particular time? - Whether two addresses had the same controller? - Why a transfer occurred? - Whether the activity was criminal, accidental or legitimate? - Whether funds can be frozen or recovered? An address is not a person. A cluster is not proof of common control. A service label may be incomplete, stale or wrong. Treat these as leads that require independent support. ## The seven-stage evidence workflow ### 1. Define the question and authority Write down the question before opening an explorer or analytics platform. Examples include: “Where did the reported payment move?” or “Which public transactions match the incident window?” Avoid a broad goal such as “find the criminal.” It invites confirmation bias and premature attribution. Record: - who authorised the work; - the legal and organisational basis; - the networks, dates and assets in scope; - what data may and may not be collected; - retention, disclosure and escalation rules; and - when legal or specialist review is required. Public availability does not remove privacy, data-protection, employment or evidential duties. The [Berkeley Protocol](https://humanrights.berkeley.edu/publications/berkeley-protocol-on-digital-open-source-investigations/) provides a useful model for professional, legal and ethical open-source investigation, even though its primary context is international human-rights work. ### 2. Preserve the anchor evidence An **anchor** is the verified starting point: for example, a transaction hash, address, signed message, complaint record or exchange receipt. Preserve the original source before analysis. Record the collection date and time, network, block number or height, source URL or node, tool and version, timezone and the person who collected it. Export the underlying data when permitted rather than relying only on a screenshot. NIST describes digital forensics as identifying, collecting, examining and analysing data while preserving integrity and maintaining a chain of custody. The current [SWGDE collection guidance](https://www.swgde.org/documents/published-complete-listing/18-f-002-2-0/) also stresses accurate, consistent and reliable handling throughout the evidence lifecycle. > **Evidence note:** A blockchain may preserve its own transaction history, but your interpretation, labels, explorer pages, API results and screenshots can still change. Preserve those separately. ### 3. Reconstruct the on-chain activity Start with the network's native transaction structure. Confirm identifiers against more than one reliable source when the consequence of error is high. For each relevant step, record: - transaction hash and network; - block position and timestamp; - input and output addresses or sending and receiving accounts; - asset, amount and fee; - token transfers and smart-contract events; - bridge, swap or service interaction; and - whether the record is observed directly or supplied by a third-party label. Do not flatten every movement into “A sent money to B.” A smart-contract transaction may produce several token transfers and internal calls. A Bitcoin transaction may have multiple inputs and outputs, including change. The official [Bitcoin transaction guide](https://developer.bitcoin.org/devguide/transactions.html) and [Ethereum transaction documentation](https://ethereum.org/developers/docs/transactions) show why the evidence model must match the chain. ### 4. Add lawful OSINT as a separate layer OSINT can provide context from public webpages, official notices, company records, developer documentation, archived pages or public communications. Collect only what the scope permits and what is relevant to the question. For each OSINT item, keep: - the original URL or public source; - access date and time; - an archived or preserved copy where lawful; - the account, author or publisher as presented; - the exact statement or artefact relied on; and - reasons the source may be incomplete, manipulated or misidentified. Do not use stolen credentials, leaked private datasets, impersonation, pretexting or unauthorised account access. Do not publish personal information because it appears to match an address. A public clue is not a licence to expose someone. ### 5. Test the connection—and alternatives This is where many investigations become overconfident. A matching username, timing pattern or address label can support a hypothesis, but it may also have an innocent explanation. Use a simple evidence matrix: | Finding | Directly observed? | Alternative explanation | Corroboration needed | Confidence | |---|---|---|---|---| | Transaction entered a labelled service address | Transaction is direct; label is third-party | Label may be stale or shared | Service or independent label evidence | Moderate | | Several addresses appear in one Bitcoin transaction | Yes | CoinJoin or shared payment workflow | Transaction-pattern review and additional evidence | Low to moderate | | Public post includes an address used in the trail | Yes, if preserved | Repost, typo, impersonation or old control | Source history and independent ownership evidence | Moderate | | Timing matches an incident window | Yes | Coincidence or automated activity | Additional technical and contextual evidence | Low | Confidence should reflect the weakest important link in the reasoning. Several weak clues do not automatically become one strong conclusion. ### 6. Handle breaks in the trail honestly Bridges, swaps, hosted services, smart contracts, batching, mixers and privacy-preserving systems can change or weaken what the public record shows. Cross-chain analysis may require matching a deposit event on one network with a release or mint event on another. A hosted service may combine many customers' activity. When the evidence stops, say so. Use terms such as: - **confirmed movement** — directly supported by the ledger; - **probable continuation** — supported by several consistent signals; - **possible connection** — plausible but not adequately corroborated; or - **unresolved** — the available evidence does not support a conclusion. Do not present an automated risk score or clustering result as a legal finding. FATF's 2026 virtual-asset update notes the importance of technical capability and cross-border cooperation, but actual disclosure, freezing and seizure depend on competent authorities, applicable law and the relevant provider. ### 7. Report for repeatability A useful report allows another qualified reviewer to understand what you did and test the result. Include: 1. the authorised question and scope; 2. sources and collection times; 3. tools, versions and settings; 4. a chronological transaction table; 5. an evidence map that distinguishes observations from inferences; 6. confidence and alternative explanations; 7. known gaps and excluded data; and 8. recommended escalation, if any, through the proper legal or organisational route. NIST's forensic process moves from collection through examination and analysis to reporting. The report should not be stronger than the evidence. Replace “this address belongs to X” with precise wording such as “Source A publicly associated the address with X on the checked date; independent control evidence was not available.” ## Tool categories—not endorsements Choose tools by evidence need, validation and legal authority, not by marketing claims. | Tool category | Useful for | Main limitation | |---|---|---| | Node or trusted data interface | Raw network records | Requires chain-specific expertise and reproducible queries | | Block explorer | Quick inspection and cross-checking | Interface, labels and decoded data may change | | Graph analysis platform | Mapping flows and testing hypotheses | Clusters, labels and risk scores are inferences | | Archive and capture tool | Preserving public web evidence | A capture does not prove authorship or truth | | Case-management system | Notes, provenance, review and access control | Poor process can still produce an unreliable record | Where possible, export the evidence and record the query or settings. Do not let a visual graph replace the underlying transaction list. ## What to preserve after a suspected scam If the article's reader is supporting a victim rather than conducting a formal investigation, the safest first step is preservation and official reporting—not confronting a suspected actor or paying a recovery service. Keep transaction hashes, addresses, asset types, amounts, dates, communications, domains, app names and receipts. The FBI's [IC3 cryptocurrency guidance](https://www.ic3.gov/CrimeInfo/Cryptocurrency) requests these transaction details and warns people to be cautious of recovery services, especially those charging an up-front fee. Readers outside the United States should use the appropriate law-enforcement, regulator or fraud-reporting channel in their jurisdiction. Never share a seed phrase, private key, password or one-time code with an investigator, recovery service or support account. ## Quality-control checklist Before finalising an analysis, confirm that: - the authority and scope are recorded; - every anchor was checked against the correct network; - source data and screenshots were preserved with dates and provenance; - observations are separated from labels and inferences; - tool outputs were independently checked where practical; - alternative explanations were tested; - no identity claim relies on one heuristic or public clue; - confidence language matches the evidence; - privacy and disclosure risks were reviewed; and - another qualified reviewer can repeat the important steps. If any answer is no, the work is not ready to support a high-consequence decision. ## Frequently asked questions ### Can blockchain analysis identify a person from a wallet address? Not by itself. It may reveal transaction patterns and links to known services. Identity attribution normally requires separate, lawful and independently verified evidence. ### Is blockchain data immutable evidence? Blockchain records can be tamper-evident within the network's consensus history, but that does not make every explorer label, screenshot, interpretation or copied dataset accurate. Those items still need provenance and preservation. ### Are clustering heuristics reliable? They are analytical aids, not proof. Reliability changes with the network, wallet behaviour, transaction type and available context. CoinJoin, batching and shared services can produce misleading clusters. ### Can tracing guarantee asset recovery? No. Identification of a transaction path does not create legal authority, provider cooperation, possession or recoverability. Anyone promising guaranteed recovery should be treated with caution. ### What is the difference between this guide and the beginner guide? This page covers advanced evidence integration, confidence and reporting. The separate beginner guide owns the basic step-by-step explanation of transaction mapping. Its contextual link is being held until that page completes the same remediation and review gates. ## Final takeaway The value of blockchain forensics and OSINT is not that they make attribution easy. It is that they can preserve and organise separate evidence layers so a qualified investigator can test a clear hypothesis. Start with authority. Preserve the source. Match the method to the network. Treat labels and clusters as leads. Test alternatives. Report uncertainty. That discipline protects both the investigation and the people who could be affected by it.