OSINT and linking on-chain and off-chain identifiers

Open-source research often supplies the link that on-chain analysis cannot: a post where a suspect published an address, a scam website's registration history, a handle reused on a second platform. Such overlaps have started many identifications. They are also frequent sources of error, because identifiers can be copied, spoofed, resold and matched by chance, and a screenshot with no URL, no time and no record of how it was found is an easy target in court. This lesson covers how to plan open-source work, collect items with provenance, judge each type of on-chain to off-chain link, and test a link before relying on it.

Information, intelligence and evidence

The Berkeley Protocol on Digital Open Source Investigations, published in December 2020 by the Human Rights Center at UC Berkeley School of Law with the UN Office of the High Commissioner for Human Rights, is the main international reference for open-source work intended for legal proceedings. It draws three distinctions:

• Open source information: information any member of the public can observe, purchase or request, without special legal status or unauthorized access.
• Open source intelligence (OSINT): open source information used mainly to support decisions, such as where to focus or what to request.
• Open source evidence: open source information with evidentiary value, which may be relied on to establish facts in proceedings.

Most OSINT in a crypto case stays intelligence, pointing to the service to approach. Only items collected and preserved to an evidential standard can become evidence, so plan for that from the first search: a page that disappears cannot be collected again. On where data sits, the Budapest Convention allows a Party to access publicly available stored computer data regardless of where it is located geographically (Article 32(a)); domestic rules on investigators' online research still apply and are set by the unit's legal advisers.

Planning and posture

Open-source work follows the intelligence cycle: direction (what do we need to know?), collection, processing, analysis, dissemination, and feedback. The Berkeley Protocol describes the investigative steps as online inquiries, preliminary assessment, collection, preservation, verification and investigative analysis. Before searching, write a short collection plan in the case file:

The plan keeps research to what the question needs (data minimization is among the Berkeley Protocol's principles, with accuracy, preservation and security by design) and answers the later question of why a source was or was not searched.

How the investigator appears online matters for safety and for the case. Attributable research is identifiable as the agency or firm and can tip off subjects. Non-attributable research uses infrastructure that does not reveal the organization and is passive viewing only; it suits most OSINT on subjects. Covert work, interacting with subjects under an assumed identity, is not passive OSINT and needs specific legal authority; the Berkeley Protocol warns that misrepresentation, such as joining closed groups under false pretenses, may violate privacy rights and taint an investigation. Even a lookup of a suspect address on a public explorer tells its operator that someone is interested; sensitive queries belong on your own node (Lesson 1.5).

Search, capture and provenance

Search operators ("…" for an exact string, site:, -term, OR, intitle:, filetype:, and on some engines before: and after:) differ between engines and change, so record the exact query string with each result. For crypto cases:

• Search full addresses, with and without quotes, across several engines, code repositories and paste sites; a hit on a long unique string is rarely a coincidence, though it may be a copy. Search handles with their variants (underscores, digits, substitutions).
• Check web archives such as the Internet Archive's Wayback Machine for versions from before a scam site removed its deposit addresses or a user edited a post; cite the archive URL and capture time as the archive records it.
• Capture first, analyze later. Live pages change and vanish, sometimes because the subject noticed interest.

Each item needs enough information to show later what it was, where it came from, when, how it was captured and that it has not changed. SWGDE's Best Practices for Acquiring Online Content (document 21-F-001) recommends capturing the full URL sequence, recording dates, times and time zone of access, preserving metadata, hashing every acquired file with NIST-approved algorithms, and documenting the examiner, the browser and the access IP; the Berkeley Protocol adds the tools and software used. A collection log entry:

{
  "item_id": "OS-0007",
  "case_id": "CF-2026-0142",
  "url": "https://forum.example/t/48213?page=3#post-912",
  "query": "\"bc1q…7k3f\" site:forum.example",
  "captured_utc": "2026-03-06T10:41:12Z",
  "method": "full-page capture + HTML source + WARC",
  "tool": "open-source capture tool v3.2, browser 128",
  "files": [
    {"name": "OS-0007.warc.gz", "sha256": "5b0e…11d4"},
    {"name": "OS-0007.png", "sha256": "c3a9…7e20"}
  ],
  "archive_copy": "web archive capture requested 2026-03-06T10:44Z",
  "posture": "non-attributable, research host RH-2",
  "collector": "EX-07",
  "note": "post dated 2023-11-14 shows address in user signature"
}

The entry keeps a WARC file (the web archive format standardized as ISO 28500), which preserves the HTTP exchange; a readable screenshot; and the HTML source, each hashed at capture, plus an independent archive copy as a third-party record. The note separates the date shown on the post, a claim by the platform, from the capture time, the examiner's own observation.

Link types and their strength

Each link is graded on its own with the scale of Lesson 4.5, and a chain of links takes the grade of its weakest member. The strength column is a typical starting point, not a grade: a signature you verified yourself is direct evidence of control at signing time (A on that scale), a single post or registration record is one indicator with known failure modes (C), a handle or activity-time match alone is usually a lead (D), and any of them rises to B when an independent indicator of a different type agrees.

Signed messages and naming services

The strongest overlap is a signed message. Under BIP-322 (Bitcoin) or EIP-191 (Ethereum), the holder of a key signs a text, and anyone can verify the signature. A valid signature shows that the signer could sign for the address at that time. BIP-322 itself notes what it does not prove: that the signer still controls the funds, or that they sent any past transaction. Verify every signature yourself with an open implementation, recording the tool and version.

The Ethereum Name Service (ENS) maps names to addresses in two directions of different weight. Forward resolution (name to address) is set by the name's owner and can point to any address without that address's consent; it shows what the name owner chose to display. Reverse resolution (address to primary name) is set by a transaction from the address itself, so it is a claim by whoever controlled the address when it was set, which is stronger, especially when forward and reverse records match. Names also carry text records such as url, email, com.twitter and avatar. They expire: after the grace period and a 21-day period of declining premium price, anyone can register an expired name, so record the registration history and the block at which each record was set. Verified wallet badges and "connect wallet" features on platforms are the platform's claim; its records of which account linked which address can be requested.

Handles, emails and domains

People reuse handles. In the Silk Road investigation, an investigator searching for the earliest online mentions of the market found posts from January 2011 by one handle promoting the site on two forums; a later post by the same handle, recruiting a developer, gave a personal email address for replies, which became a lead pursued through legal process. Weigh a handle match by rarity (quietharbor_77 on two forums means more than crypto_king; search how many unrelated users share it), consistency of topics, style, time zones and dates, account history (an account created the day after a public alert is more likely imitation than reuse) and direction (the earliest use usually matters most). A match supports a hypothesis; the account behind it is a service account whose subscriber records can be requested (Lesson 1.4).

Scam platforms, fake exchanges and phishing kits need domains, and domains leave records. For generic top-level domains, the Registration Data Access Protocol (RDAP) became the definitive source of registration data on 28 January 2025, replacing WHOIS. Public responses are often redacted for privacy, so the registrant's details usually come from the registrar through legal process; the Budapest Convention's Second Additional Protocol provides for direct requests for domain name registration information (Article 6). Historical registration data and passive DNS show which IP addresses a domain used and which other domains shared them. Certificate Transparency logs (RFC 6962) record publicly trusted TLS certificates in public, append-only logs, and searching them for a scam brand often reveals sibling domains. Shared infrastructure links sites to each other more reliably than to a person: a shared IP on a large hosting service is weak, while a shared unusual analytics identifier or deposit address is strong.

Copying, timing and IP evidence

Addresses are among the most copied strings on the internet. Donation and payment addresses are reposted by fans, scammers and aggregators. In address poisoning, attackers create lookalike addresses that share the first and last characters of a victim's counterparty and send tiny or zero-value transfers so that the lookalike appears in the victim's history; a truncated address in a screenshot may match either. Some platforms allow edits without visible history, so compare with archive captures. Always compare the full address, character by character or by hash. Timing is the strongest test: a post that shows an address before its first on-chain activity is far stronger than one appearing after a public alert, when anyone could copy it. In the example, post OS-0007 is dated 2023-11-14 and the address was first funded in December 2023.

IP addresses come mainly from service records (exchange login logs, wallet backends, node or API providers) obtained through legal process (Lesson 7.5). Biryukov, Khovratovich and Pustogarov (2014) showed that peer-to-peer network observers can sometimes link Bitcoin transactions to the IP address that first relayed them, but this is not routine evidence and Tor defeats it. An IP match needs context: VPN exits, Tor, carrier NAT and shared offices put many people behind one address, and logs use different time zones.

Activity-time profiles are supporting evidence at best. Counting a cluster's transactions by UTC hour (in SQL, EXTRACT(HOUR FROM block_timestamp), or HOUR() or date_part('hour', …) in some engines) gives a profile to compare with a handle's posting hours. Remember the limits: block time is not broadcast time (on Bitcoin, block timestamps can differ from real time by more than an hour), bots run around the clock, and many people share a time zone.

Verifying and testing a link

Collected items are claims until verified for authenticity, reliability, relevance and probative value. Examine the source (who published it; is the account authentic and established?), the content (consistent internally and with other information?) and the technical traces (metadata, page structure, archive history). The chain offers a strong independent check of dated claims. Then write down the competing explanations (the poster controls the address; copied it; was impersonated or compromised) and the evidence for and against each.

Ask how often a link would occur by chance. If a suspect withdrew 0.5 ETH from Exchange K ten minutes after a 0.5 ETH deposit elsewhere, count how many 0.5 ETH withdrawals Exchange K's hot wallets made in that window; if there were forty, the match is weak. Then run a checklist:

1. Is the identifier rare, and did you check how many others share it?
2. Was it observed before the case became public?
3. Could it have been copied, imitated or poisoned?
4. Does the time of the off-chain record fit the on-chain activity?
5. Is there an independent second link, ideally of a different type?
6. Have the competing explanations been written down and tested?

Record links that failed the checklist as well.

Documenting for court

An open-source exhibit is defensible when another examiner could follow the same path and check every item. The case file holds the collection plan and its changes; the hashed collection log and captures under chain of custody (Lessons 8.2 and 8.3); contemporaneous notes, including searches that found nothing; the verification of every item relied on; and a statement of posture confirming no unauthorized access or misrepresentation. In the report, cite items by identifier, quote only what is needed and redact uninvolved people; links to private individuals stay in a restricted annex until confirmed through legal process.

Exam focus: open source information, intelligence and evidence in the Berkeley Protocol (2020) and its investigation steps; Budapest Convention Article 32(a); a collection plan with a stop rule; attributable, non-attributable and covert postures and why covert work needs specific authority; recording the exact query and capturing before analysis; collection records with full URL, UTC time, method, tool version, SHA-256 hashes and WARC (ISO 28500), per SWGDE 21-F-001; the link types and their typical strength; what a signed message (BIP-322, EIP-191) does and does not prove; ENS forward versus reverse resolution and expiry; weighing handle matches (rarity, consistency, account history, first use); RDAP since 28 January 2025, passive DNS, Certificate Transparency (RFC 6962) and shared infrastructure; copied addresses, address poisoning and comparing full addresses; limits of IP and activity-time correlation; base-rate reasoning and the checklist against coincidental links.