Ethics, privacy, data protection and investigator safety

Crypto investigations reach deep into people's lives: exchange records, chats, devices and the finances of people who have done nothing wrong. Blockchain data is public, but not everything derived from it is fair to collect or share: once an address is linked to a person, pseudonymous entries become a permanent record of that person's finances, and a mistaken link can expose an innocent person to harassment, fraud or physical danger. The same work exposes investigators to hostile subjects, harmful material and their own biases. Ethical failures damage evidence, endanger people and give the defense its best arguments. This lesson covers the judgments made on every case, from the first request to the last disclosure.

Why public data still needs protection

Three properties make on-chain data more sensitive than it looks:

• Linkability: one attribution unlocks a whole history. Linking a single address to a name exposes every past and future transaction of the cluster behind it.
• Permanence: the ledger cannot be corrected. A wrong attribution published today stays attached to those transactions for anyone who searches later.
• Aggregation: individually harmless facts (a naming-service record, a social-media post, a deposit pattern) combine into a profile no single source revealed.

The harms are concrete: published victims become targets for "recovery" scammers; people known to hold large balances have faced extortion and physical coercion; misidentified people lose accounts or reputations; and a public post naming a suspect's address can tip off the suspect before funds are frozen. Most data protection frameworks treat identifying information as personal data even when public. The practices below are a professional baseline whatever the local law; the legal team decides how they apply in a given jurisdiction.

Necessity, proportionality and minimization

Every intrusive step should pass two tests. Necessity: is this step needed to answer a question in the scope, or would a less intrusive step do? Proportionality: is the intrusion into privacy, including that of third parties, reasonable given the seriousness of the matter and the value of what it may yield? International human-rights law and the safeguards in both cybercrime conventions (Article 15 of the Budapest Convention, Article 24 of the UN Convention against Cybercrime) build on these ideas. Tracing a nine-figure exploit to exchange deposit addresses is proportionate; profiling every small counterparty along the way is not.

Data minimization means collecting and keeping only what the question needs. It appears in the OECD Privacy Guidelines (1980, revised 2013) as the collection limitation principle, and the Berkeley Protocol on Digital Open Source Investigations (UC Berkeley's Human Rights Center with the UN Human Rights Office, 2020) lists it as a methodological principle: collect and process only what is justified by an articulable purpose, necessary for it and proportional to it.

Record the reasoning in the case file. "We needed it" is not a justification; "Question 3 cannot be answered without login IPs for the period of the transfers" is.

Collateral data

Almost every return contains collateral data: information about people outside the investigation. An exchange ledger shows the counterparties of every internal transfer; a seized phone holds the messages of family and friends; a seized server database holds thousands of users, most of them never suspects. Good practice:

• minimize: request, extract and keep only what the scope needs;
• segregate: keep collateral data apart from the working set, with identities in a restricted annex readable only by those who need it;
• use for purpose: do not mine it for unrelated leads without fresh authority and a recorded decision;
• retain and delete by rule: apply the retention period set by policy and confirmed at closure.

Once an address is linked to a named person, its history becomes personal financial data, so reports and appendices show third-party addresses and identities only where a finding needs them.

Bias and tunnel vision

Confirmation bias leads investigators to seek and weigh evidence that supports what they already believe. Anchoring makes the first label or the first suspect hard to let go. Contextual bias arises when an examiner learns things irrelevant to the technical question, such as that the suspect has confessed, and reads the data in that light. Tunnel vision is the case-level result: one theory, pursued to the exclusion of others. Crypto tracing is especially exposed, because heuristics produce plausible links and a confident tool display looks like fact.

Controls that work:

1. Write competing hypotheses at planning and record what evidence would eliminate each (Lesson 1.2).
2. Give examiners only the information their task needs. Linear sequential unmasking, proposed in forensic science by Dror and colleagues in 2015, asks examiners to analyze and document the evidence before seeing reference material or case context that could steer them.
3. Use blind verification for key findings: a second examiner re-performs the work without knowing the first result.
4. Record disconfirming evidence and how it was dealt with. A file that contains only supporting evidence invites the question of what was left out.

Operational security and open sources

Investigators leave traces too. Attributable research is done openly as the agency or firm, as when sending a request to a provider. Non-attributable research hides the investigator's identity, as when viewing a scam site or a subject's forum, and uses dedicated, policy-approved equipment and research identities. Guessing passwords or logging into accounts that are not yours is never open-source research. Anything beyond passive viewing, such as engaging with a subject or creating personas, is covert work that needs specific authorization; private analysts should not do it at all, because it can harm the case and break the law.

Crypto-specific risks:

• Interacting with subject addresses. Sending a "test" transaction to a suspect's address, signing messages or connecting a wallet to a scam site alerts the subject and may compromise the investigator's own systems. Do not.
• Queries that leak. Public explorers, RPC providers and third-party APIs see what is looked up and from where; repeated queries on a small set of addresses can reveal interest. Querying your own node avoids this and also improves reproducibility.
• Tipping off. Premature freezes, contacting associates, following social accounts or publishing addresses can warn a subject before devices are seized or funds secured. Coordinate timing with the investigation lead.
• Personal exposure. Investigators named in reports or court papers can become targets of harassment, doxxing or phishing. Keep personal accounts separate and private.

For open-source material, preserve each item with its URL, capture time in UTC and a cryptographic hash of the saved file, and verify it independently: a screenshot of a post is a claim, not a fact, until a second source or on-chain data the post could not have faked corroborates it. Avoid breached data, such as leaked customer databases, unless the organization has a clear legal basis and policy for it. A naming-service record that resolves to a human-looking name may belong to that person, to an impersonator or to someone who later sold the name: it is a lead to verify, never an attribution to publish. The Berkeley Protocol also sets out digital, physical and psychosocial security measures for online investigators; Lesson 4.7 applies it.

Sharing findings responsibly

What may appear, and how to redact

The default for any document leaving the team is no addresses, identifiers or names that point to a private individual, unless the reader needs them to act (an exchange freezing an account, an authority executing legal process) and receives them through a restricted channel. Generally acceptable in a public report: names of services, protocols and companies; addresses that authorities, courts or the victim organization have published; exploit contracts and the addresses that directly received stolen funds in a publicly reported incident. Not acceptable: victims' addresses, uninvolved counterparties and private individuals linked by inference alone.

Redaction is harder than it looks. Truncating an address (bc1q…7k3f) is not enough if the report also gives the exact amount and minute of the transaction: anyone can search for a 0.95000000 BTC output in that block and recover the full address. Also round amounts, widen times to the day, or replace the details with a label.

Stolen-fund alerts

After a theft, minutes matter: funds at a service can sometimes be frozen, and issuers can freeze centrally issued stablecoins at the contract level. But a wrong alert can freeze an innocent customer. Notify directly the receiving services through their published compliance or law-enforcement channels before posting anything publicly. Share the minimum: addresses, transaction hashes, amounts, timestamps and the likelihood and confidence of each link (Lesson 9.2). Label inferred links as inferred: an amount-time match is a reason to look, not to freeze. Weigh public alerts: a post reaches services you have not contacted but tells the thief which addresses are watched; coordinate with the victim organization and correct wrong links promptly.

Vulnerabilities

Exploit analysis sometimes shows a flaw is unfixed, or that forks copied the vulnerable code and still hold funds. Coordinated disclosure means telling those who can fix it first, privately, and publishing only after they have had a reasonable chance to act. ISO/IEC 29147 (vulnerability disclosure), ISO/IEC 30111 (vulnerability handling) and RFC 9116, which defines the security.txt file naming a project's security contact, are useful references. Report the minimum needed to fix, agree a timeline, publish no working exploit path while vulnerable contracts hold funds, and do not "rescue" funds yourself unless under an established, documented whitehat arrangement with the project; the legal position varies by jurisdiction.

Working with victims

Victims are witnesses, sources of evidence and people who have often lost savings. Treat them with patience and respect, explain what will and will not happen, and record what they provide and how.

• Do not promise recovery. Many cases recover nothing; false hope causes harm and can later be used against the investigation.
• Collect evidence with consent and record its provenance. Ask before examining a victim's device or account, and explain what will be looked at.
• Warn about recovery scams. Victims are targeted again by people offering to recover funds for a fee, often posing as lawyers, investigators or authorities (Lesson 10.4).
• Protect their privacy in reports and disclosure.

Wellbeing and harmful content

Some cases require reviewing child sexual abuse material, violent extremist content or victims' distress. In the Welcome to Video investigation, made public in 2019, investigators traced bitcoin payments to a darknet site distributing child abuse material, work that combined tracing with exposure to the content. Repeated exposure causes harm that builds over time. Units limit it by design: view only what the task needs, use reduced-size, grayscale or audio-off review, rotate tasks, avoid working alone with such material, and provide confidential psychological support with regular check-ins. Wellbeing is also an evidence issue: exhausted, distressed examiners make more mistakes.

Conflicts of interest

An examiner must be, and appear to be, independent. Typical conflicts in crypto work:

• holding the asset or token whose issuer, exchange or protocol is under investigation;
• previous work for a party, an exchange or a protocol involved in the case;
• personal links to the victim, the subject or an expert on the other side;
• a fee that depends on the outcome, such as a share of recovered funds, which is hard to reconcile with an expert's duty to the court.

Declare potential conflicts at the start, record the decision on whether to proceed, and follow the unit's policy on personal crypto holdings. A conflict disclosed early is manageable; one discovered in cross-examination can sink the evidence. Lesson 9.1 takes this further for expert witnesses.

Exam focus: expect scenarios testing whether a step or disclosure is necessary, proportionate and minimal, and how the reasoning is recorded. Know linkability, permanence and aggregation and why attribution makes chain data personal; handling collateral data; contextual bias and its controls (linear sequential unmasking, blind verification); attributable, non-attributable and covert research and why investigators never transact with subject addresses; re-identification from a truncated address plus exact amount and time; direct, minimal, confidence-labeled stolen-fund alerts; coordinated vulnerability disclosure; victim care; limiting exposure to harmful content; and declaring conflicts, including contingent fees.