Hack Registry Methodology

What is included

An incident belongs in the registry when funds were taken from someone who did not consent to losing them, and the loss reached $100,000 or more. That covers protocol exploits, exchange and bridge breaches, compromised keys, wallet-drainer phishing, insider theft, and rug pulls where operators removed user funds.

The line that decides most borderline cases is theft versus fraud. This registry records money taken from where its owner already had it. It does not record money the owner was persuaded to hand over. A drained exchange, a compromised key and a phishing signature that moves funds without the owner's intent all belong here. Investment fraud, Ponzi schemes, fake trading platforms and romance or “pig butchering” scams do not, however large the number — the victim initiated those transfers, and mixing the two would make every total in this registry incomparable with itself.

These are also deliberately excluded:

• Trading losses, liquidations and depegs — money lost to markets is not money taken.
• Bankruptcies and insolvencies, unless a specific theft is established inside them. A collapse is a different kind of event and mixing the two inflates every total.
• Claimed losses with no evidence beyond an unverified assertion by an anonymous account.
• Incidents below the threshold. The cut-off is arbitrary but has to be somewhere, and a stated one is better than a moving one.

The registry currently covers incidents from 2021 onward. Earlier events are added when they can be documented to the same standard.

Verified and reported

Entries carry one of two labels, and the difference decides whether they count toward anything.

“Independent” is the part that does the work. Five outlets restating the same original report are one source, not five — if a publication credits someone else, the credit is what counts. These are the source types the registry recognises:

Primary

The affected party, an investigator with direct access, or an official body: post-mortems, exchange statements, indictments, court filings, regulator notices.

On-chain

Our own verification of a transaction, address or balance against the chain. Counts as an independent source because we derive the figure ourselves.

Secondary

Original reporting by a publication or research firm that adds information beyond restating someone else.

Aggregator

A third-party tracker listing the incident. Recorded for completeness only — never counted toward verification and never used as a source of figures.

On-chain confirmation counts as an independent source because it is not a restatement: the transaction is read directly and the figure is recalculated. For individual phishing losses, where post-mortems and official filings do not exist, this is usually the second source that makes verification possible at all.

How losses are valued

Losses are recorded in US dollars at the price prevailing when the incident happened, not at today's price. A token that was worth $10m at the time of the theft and $2m a year later is recorded at $10m, with the basis stated on the entry. Where a source used a different basis and we could not recompute it, the entry says so.

Amounts recovered — returned by the attacker, frozen by an exchange, or clawed back through legal action — are recorded separately and never netted off silently. The headline figure is what was taken.

When sources disagree

Published loss figures for the same incident routinely differ, sometimes by a wide margin. Rather than pick one and present it as settled, the registry records the lowest and highest credible published figures alongside our best single estimate, and the entry shows the range.

The single estimate favours, in order: the affected party's own accounting, a figure we could confirm on-chain, and then the most detailed independent analysis. Where nothing separates the estimates, the lower one is used.

Naming people and groups

Saying who did it is the part of this work most likely to cause harm, so attribution is recorded with an explicit confidence level and never stated flatly:

Confirmed

Established by conviction, admission, or formal government attribution.

Alleged

Asserted by a named investigator, prosecutor or regulator, but not proven.

Suspected

Reported by credible researchers on the basis of on-chain or tooling overlap.

Unknown

No public attribution exists.

No entry naming a person or company is ever published automatically. Insider theft and fraud are recorded only where charges have been brought, an admission exists, or a named investigator has said so on the record — and the entry states which.

Individual victims

Where the victim is a private individual, the registry records the incident but not the person: no name, no handle, no wallet address. Attacker addresses are always published, because they are what makes a claim checkable and they are already public knowledge. Anyone who believes an entry identifies them can write to [email protected] and it will be reviewed.

Attack vector definitions

Classification is a judgement call, so the definitions used are published here rather than left implicit. Incidents involving several steps are filed under the one that made the theft possible.

Private key compromise

The attacker obtained a signing key or seed phrase. Covers stolen keys, leaked backups and brute-forced wallets, but not cases where a key was handed over after social engineering — those are classified separately.

Access control flaw

A privileged function was callable by an address that should not have had permission, including missing owner checks and uninitialised proxies.

Oracle or price manipulation

The attacker moved a price feed the protocol trusted, then traded against the distorted value.

Reentrancy

A callback re-entered the contract before its state was updated, letting one balance be spent more than once.

Contract logic error

The contract behaved as written but the written behaviour was wrong: accounting mistakes, bad rounding, broken invariants, infinite mints.

Signature verification flaw

Signature or proof checking could be bypassed or forged, including malformed merkle proofs and unchecked validator sets.

Flash loan attack

Uncollateralised borrowed capital was used to reach a state the attacker could not otherwise afford. Recorded when the flash loan was essential, not merely present.

Governance attack

Voting power was acquired or borrowed to pass a malicious proposal.

Supply chain or frontend compromise

The contracts held, but the path to them was poisoned: hijacked frontend, malicious dependency, compromised build or DNS.

Social engineering

A person with access was manipulated into approving a transaction or handing over credentials. Includes fake job interviews and impersonated colleagues.

Phishing signature

A holder signed a malicious approval, Permit or transaction on a spoofed interface. This is the dominant vector for individual victims.

Insider action

Funds were taken by someone with legitimate access. Only recorded when charged, admitted, or asserted by a named investigator — never inferred.

Rug pull or exit scam

The operators themselves removed user funds or abandoned the project holding them.

Infrastructure compromise

Hosting, DNS, BGP, cloud accounts or internal tooling were breached rather than any on-chain component.

Other or undisclosed

No credible public account of the mechanism exists. Used sparingly — an unexplained incident is still worth recording.

Corrections and updates

When a published figure changes, the entry records what changed, when, and why, and the record of the change stays on the page. Nothing is edited silently. Entries are re-checked as investigations progress, and each one shows when it was last verified.

Corrections are welcome and are the fastest way to improve the registry. Send them to [email protected] with the source you are relying on.

Reuse and citation

The dataset is published under CC BY 4.0. You may republish, adapt and build on it, including commercially, provided you credit iTokenly and link to the registry. CSV and JSON exports are linked from the registry page and need no key or account.

Every row and every entry has a permanent address. Slugs do not change; if an entry is renamed, the previous address continues to resolve.

Known limits

• Coverage is better for large, well-documented incidents than for small ones. Losses near the threshold are undercounted, and the registry does not claim to be complete.
• Individual phishing losses only enter the registry when someone reports them publicly. Most never are.
• Where a loss spans several assets and chains, the dollar figure depends on price sources that themselves disagree at the margins.
• Attribution reflects what is publicly known at the time of writing, which frequently changes years later.

Independence

No entry in this registry is sponsored, and no company can pay to be included, removed, reworded or reclassified. Entries are added and amended on the evidence alone.