A blockchain gives you a perfect ledger of movement and almost no idea of who is behind it. Open-source intelligence gives you names, handles and affiliations but no proof of value transferred. Neither view is enough on its own. The work of attribution, whether for a sanctions screening escalation, a fraud case or an investor complaint, is the discipline of fusing the two into a single claim you can defend to a regulator, a bank partner or a court.
This article is about how to do that fusion cleanly, and how to avoid the reasoning errors that make an attribution collapse under scrutiny.
Two partial views, two different failure modes
On-chain data is complete but pseudonymous. Every transaction is public, immutable and precisely timestamped, yet an address is just a string. You can trace flows across hops, cluster addresses that share spending patterns and see exposure to a mixer or a sanctioned entity. What you cannot see is the human or legal person controlling the key.
OSINT is the opposite. A forum post, a leaked database, an exchange support ticket, a GitHub commit, a social media bio or a court filing can tie a person to an identity. But OSINT is noisy, sometimes stale, often self-reported and easy to spoof. Someone claiming to own a wallet in a Telegram channel is not proof.
The two datasets fail in opposite directions. On-chain evidence is strong on the transaction and weak on the identity. OSINT is the reverse. Fusion works precisely because the strength of one covers the weakness of the other.
The link is a claim, not a fact
The core move in every fusion is connecting an off-chain identity to an on-chain address. That link is a hypothesis with a confidence level, not a settled truth. Treat it that way from the start.
Useful links tend to come from a small number of source types:
- Self-disclosure: a person publishes an address to receive donations, tips or payments (a tip jar in a bio, a fundraising page, a signed message).
- Service records: a KYC record at a Custodian or exchange, a merchant invoice, or a subpoena response that binds an account to a deposit address.
- Leaks and breaches: credential dumps or database leaks that pair emails, usernames and addresses. Handle these with care for both legal admissibility and data-protection reasons.
- Behavioural correlation: timing, amounts and counterparties that match a known real-world event, for example a ransom payment of a specific size at a specific hour.
Each type carries a different weight. A signed message proving control of a private key is close to conclusive. A username reused across a wallet label and a social profile is suggestive, not conclusive.
A working method
A repeatable process beats a lucky find. One practical sequence:
- Start from the anchor. Begin with whichever side is firmest, a confirmed address from a case file or a confirmed identity from a report, and expand outward.
- Cluster on-chain. Group addresses that plausibly share one controller using established heuristics such as common-input ownership, then note that heuristics are probabilistic.
- Enrich off-chain. Search for every string touching the cluster: address labels, ENS names, transaction memos, associated domains, usernames and email fragments.
- Cross-validate. Look for at least two independent paths to the same conclusion. One source can be wrong or planted; two unrelated sources agreeing is much harder to fake.
- Score and document. Record the confidence, the sources, the timestamps and the assumptions. An attribution you cannot reconstruct in six months is not usable.
Independence is the point that gets skipped most often. If your identity link and your on-chain cluster both trace back to the same forum post, you have one source dressed up as two.
Watch the reasoning traps
A few failure patterns recur across investigations:
- Cluster contamination. Deposit addresses at large exchanges, or use of CoinJoin, can merge unrelated parties into one cluster and produce a false shared owner.
- Stale OSINT. Wallets change hands. An address controlled by one person in 2022 may belong to someone else by 2026. Always align the identity evidence to the time of the transaction in question.
- Confirmation bias. Once you believe you know who an address belongs to, ambiguous evidence starts looking like confirmation. Write down what would prove you wrong.
- Spoofed self-disclosure. Anyone can paste someone else's address into their own bio. Self-disclosure is only strong when the person also demonstrates control.
Why fusion is now a compliance requirement, not just an investigative luxury
Under the EU framework, crypto-asset service providers face travel-rule style obligations to identify parties to transfers, and exposure to self-hosted wallets is an explicit supervisory concern. The FATF standards that shaped this expect providers to understand counterparty risk, not just screen a raw address. Meeting that bar means combining what the chain shows with what the wider record says about the people involved. See the ESMA overview of the Markets in Crypto-Assets Regulation and the FATF work on virtual assets.
Bringing it together
Good attribution is a chain of custody for reasoning: an anchor, an on-chain cluster, independent off-chain corroboration, a confidence score and a documented trail. Seqlense supports this shape of work on both sides. On-chain, Monitoring handles address surveillance, risk scoring and alerting so a cluster's exposure is visible as it evolves. Off the chain, the Investigation and OSINT services bring the identity research and evidence handling, while Notes keeps the case knowledge in one auditable place. The goal is never a clever guess. It is a claim you would be comfortable defending, with the sources attached.