Attribution and OSINT · Lesson 4 of 5
Linking on-chain and off-chain identifiers
9 min read
Many identifications in crypto cases began with a single overlap between the chain and the rest of the internet: an address in a forum signature, a naming-service record, a handle reused on a second platform, a login IP that matched a withdrawal. Such overlaps are powerful leads and frequent sources of error, because identifiers can be copied, spoofed, shared, resold and matched by chance. This lesson covers the main types of on-chain to off-chain link, how strong each one is, and how to test a link before relying on it.
Link types and their strength
| Link | Evidence that supports it | Typical strength | Main ways it fails |
|---|---|---|---|
| Signed message from an address | Valid signature over a stated text and date | Strong for key control at signing time | Key later sold or shared; signer acting for someone else |
| Naming-service reverse record | Address set its own primary name | Moderate to strong for address control | Name expired and re-registered; compromised wallet |
| Address published in a post or profile | Dated post by an established account | Moderate | Copied address, impersonation, edited post |
| Handle reuse across platforms | Same unusual handle, overlapping topics and times | Weak to moderate | Common handle, deliberate imitation |
| Email or domain registration | Registration data, historical records | Moderate when obtained from the registrar | Privacy services, false details, resale |
| IP address match | Service logs, timing alignment | Moderate with corroboration | VPNs, Tor, shared and carrier-grade NAT addresses |
| Activity-time pattern | Hour-of-day profiles | Weak; supporting only | Automation, travel, coincidence |
Each link is graded on its own, using the scale described in the lesson From address to entity to person, and a chain of links takes the grade of its weakest member.
Handles and usernames
People reuse handles. A handle used to promote an illicit service may also appear years earlier on a hobby forum, a code repository or a marketplace, sometimes alongside an email address or other identifying detail. In the Silk Road investigation, an investigator searched for the earliest online mentions of the market and 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. That email address became a lead pursued through legal process.
To weigh a handle match:
- Rarity:
quietharbor_77on two forums is more telling thancrypto_king. Search the handle widely to see how many unrelated users share it. - Consistency: overlapping topics, writing style, time zones and dates of activity.
- Account history: an account created the day after a public alert, using the subject's handle, is more likely imitation than reuse.
- Direction: who used the handle first? Imitators copy known handles; the earliest use usually matters most.
A handle match supports a hypothesis; it does not establish identity. The account behind it is a service account whose subscriber records can be requested (see the lesson Working with service providers).
Email, domains and certificates
Scam platforms, fake exchanges and phishing kits need domains, and domains leave records.
- Registration data: 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 (rules on publishing registrant data differ between jurisdictions), 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 records: earlier registration data and DNS resolution history (passive DNS) show which IP addresses a domain used and which other domains shared them.
- Certificate Transparency: publicly trusted TLS certificates are logged in public, append-only logs (RFC 6962). Searching the logs for a scam brand often reveals sibling domains registered for the same campaign.
- Shared infrastructure: the same hosting IP, name servers, site template, analytics identifier or deposit address across several sites suggests a common operator.
Shared infrastructure links sites to each other more reliably than to a person. Hosting providers and registrars serve thousands of unrelated customers, so a shared IP on a large hosting service is weak; a shared, unusual analytics identifier or deposit address is strong.
Naming services, NFTs and social profiles
The Ethereum Name Service (ENS) maps human-readable names to addresses. Two directions matter, and they carry 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, not who controls the address.
- Reverse resolution (address to primary name) is set by a transaction from the address itself. It is therefore a claim made by whoever controlled the address when it was set, which is stronger evidence of a connection, 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. Record the registration history and the block at which each record was set; a name that changed owners in 2025 says nothing about 2023 activity.
NFT profile pictures, verified wallet badges and "connect wallet" features on social and marketplace platforms create further overlaps. The platform's records of which account linked which address, and how it verified that, are obtainable from the platform; the public badge alone is the platform's claim.
The strongest overlap is a signed message. Under BIP-322 (Bitcoin) or EIP-191 (Ethereum), the holder of a key signs a text with it, 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. Treat signatures posted by third parties with care, and verify each one yourself with an open implementation, recording the tool and version.
Forum posts, addresses and copying
An address in a dated post by an established account is a useful link, but addresses are among the most copied strings on the internet:
- Donation and payment addresses are reposted by fans, scammers and aggregators.
- 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 lookalike in the history is not a counterparty, and a truncated address in a screenshot may match either.
- Edited posts: some platforms allow edits without visible history. Compare with web archive captures.
- Timing: a post that shows an address before its first on-chain activity is far stronger than one appearing after a public alert.
Always compare the full address, character by character or by hash, never the truncated display form.
IP and timing correlation
IP addresses come mainly from service records: exchange login logs, wallet backend servers, node or API providers, all obtained through legal process (see the lesson Exchange and cloud accounts as evidence). Published research, for example Biryukov, Khovratovich and Pustogarov (2014), showed that observers of the Bitcoin peer-to-peer network can sometimes link transactions to the IP address that first relayed them, but this is not routine evidence and is defeated by Tor and other measures. An IP match is meaningful only with its context: VPN exit nodes, Tor, mobile carrier NAT and shared offices put many people behind one address, and logs record times in different time zones.
Activity-time profiles are supporting evidence at best. The query below builds an hour-of-day profile for the transactions sent by a cluster on an account-model chain:
-- Hour-of-day profile (UTC) of transactions sent by cluster C-4
SELECT EXTRACT(HOUR FROM t.block_timestamp) AS hour_utc,
COUNT(*) AS tx_count
FROM transactions AS t
JOIN cluster_members AS c
ON c.address = t.from_address
WHERE c.cluster_id = 'C-4'
AND t.block_timestamp >= TIMESTAMP '2025-01-01 00:00:00'
AND t.block_timestamp < TIMESTAMP '2026-01-01 00:00:00'
GROUP BY EXTRACT(HOUR FROM t.block_timestamp)
ORDER BY hour_utc;It joins the transactions table to the cluster's member addresses, restricts to one year, and counts transactions by UTC hour. EXTRACT is standard SQL; some engines use HOUR() or date_part('hour', …) instead. The result can be compared with the posting hours of a suspect handle. 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.
False links and coincidence
Before relying on any link, ask how often it 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 short checklist:
- Is the identifier rare, and did you check how many others share it?
- Was it observed before the case became public?
- Could it have been copied, imitated or poisoned?
- Does the time of the off-chain record fit the on-chain activity?
- Is there an independent second link, ideally of a different type?
- Have the competing explanations been written down and tested?
Record links that failed the checklist as well. Links involving private individuals stay in a restricted annex until confirmed through legal process (see the IDFE-BA lesson Data protection, ethics and responsible disclosure).
Exam focus: the main on-chain to off-chain link types and their typical strength; weighing handle matches (rarity, consistency, account history, first use); RDAP as the definitive gTLD registration source since 28 January 2025, redaction and registrar records via legal process (Second Additional Protocol Article 6); passive DNS, Certificate Transparency (RFC 6962) and shared infrastructure; ENS forward versus reverse resolution, text records and expiry; what a signed message (BIP-322, EIP-191) does and does not prove; copied addresses, address poisoning and comparing full addresses; limits of IP and activity-time correlation; base-rate reasoning and a checklist against coincidental links.