How Ozone decides

In short

1. Lists — official sanctions (OFAC, UK, EU, and the on-chain sanctions oracle on Ethereum, Arbitrum, Optimism, Polygon, Avalanche and Base), law-enforcement attributions (FBI), stablecoin issuer freezes (Tether on Ethereum, TRON and Avalanche, USDT0 on Arbitrum and Polygon, Circle on Ethereum, Base, Avalanche, Arbitrum, Optimism and Polygon), hack/exploit and phishing lists, and maintainer flags for freshly announced hacks. Every entry keeps its source, a reference link, when the source listed it, when Ozone first saw it and — if it happened — when it was removed.
2. Addresses on every THORChain chain — THOR, BTC, ETH, BSC, BASE, AVAX, GAIA, LTC, BCH, DOGE, TRON, XRP, SOL (plus ZEC, XMR, DASH, BSV, BTG, ETC, ARB, BNB Beacon for listed addresses) are validated with their checksums and reduced to one canonical form.
3. THORChain tracing — value that leaves a listed address through THORChain is followed to its recipients (swaps incl. streaming and L1→L1, sends, LP withdrawals, THORNames), which are flagged with the transaction as evidence.
4. Verdicts — each address gets a risk level and human-readable reasons. The default policy flags at risk high; relayer nodes can choose their own threshold.
5. Snapshots — everything above is published as a signed, versioned snapshot. Nodes verify it and screen locally, without asking Ozone at request time.

Sources

Public sources only; none needs an API key. A download that is too small or would remove too many entries at once is refused, so a truncated file can never mass-delist sanctioned addresses.

Hack incidents. Only addresses that a public source names as the attacker's are admitted, each with the page that names it. Confidence high (published as risk severe): law enforcement, sanctions designations, or the victim itself. Confidence medium (published as risk high): established investigators' public posts (ZachXBT, SlowMist/MistTrack, Elliptic, TRM Labs, Chainalysis, PeckShield, CertiK, BlockSec, Cyvers, Beosin, Hacken, Halborn, Merkle Science, Match Systems, BitOK, QuillAudits, rekt.news), also when quoted by news media. Every address was checked in September 2026: valid for its chain (checksums, EIP-55) and present verbatim on the cited page. Service addresses (exchanges, bridges, routers, THORChain vaults, mixers) and the victims' own wallets are excluded. Incidents whose funds were returned are kept as history (delisted), never flagged. Sites whose terms forbid automated access (Etherscan, Arkham, X) were not fetched; their posts are cited only through pages that quote them. The previous hard-coded hack list was dropped in September 2026: of its 21 addresses only 4 could be confirmed.

Researched without a usable address list: Harmony Horizon bridge hack (2022-06-24); AFX Trade bridge hack (2026-07-23); CoinsPaid hack (2023-07-22); Genesis-creditor social-engineering theft ($243M) (2024-08-19); $330M BTC theft from an elderly holder (2025-04-28); CrediX Finance exploit (2025-08-04); Crypto.com hack (2022-01-17); Deribit hot-wallet hack (2022-11-01); BitKeep hack (2022-12-26); Harvest Finance exploit (2020-10-26); Mango Markets exploit (2022-10-11); Upbit hot-wallet theft (2019-11-27); Upbit Solana hot-wallet hack (2025-11-27); Mixin Network hack (2023-09-23); PlayDapp exploit (2024-02-09); BtcTurk hot-wallet hack (2024-06-22); Bunni V2 exploit (2025-09-02); Shibarium bridge hack (2025-09-12); UXLINK hack (2025-09-22); Hyperdrive exploit (2025-09-27); Nemo Protocol exploit (2025-09-08); CoinDCX hack (2025-07-19); Step Finance hack (2026-01-31); SwapNet / Aperture Finance exploit (2026-01-25); Resolv Labs USR hack (2026-03-22); Ostium exploit (2026-07-15); Ronin bridge: three further OFAC addresses (2022-04-22). Each entry says why in the dataset.

Not used: Israel's NBCTF seizure lists (the site blocks automated access), commercial APIs that need keys, and OpenSanctions' processed data (non-commercial licence) — Ozone reads the primary lists directly. (Only when the EU's own endpoint fails does Ozone fetch OpenSanctions' unmodified copy of the same official EU XML file.)

Address normalization

• EVM (ETH, BSC, BASE, AVAX, ARB, …): lower-cased; one key for all EVM chains — an account is the same key holder everywhere.
• Bitcoin, Litecoin, Dogecoin: base58check (case-sensitive, checksum verified) or bech32/bech32m (segwit v0 and taproot, lower-cased).
• Bitcoin Cash: cashaddr without the bitcoincash: prefix — the form THORChain uses; legacy 1…/3… BCH addresses are converted.
• TRON: base58check T…; the hex form TronGrid returns is converted (the previous worker stored it as 0x…, so TRON inputs never matched).
• XRP (classic r…, XRP alphabet checksum), Solana (32-byte base58), THOR / Cosmos (bech32).
• Same-key twins: a TRON address and the EVM address with the same 20-byte key hash, and a pay-to-pubkey-hash address across BTC/BCH/LTC/DOGE, are controlled by the same private key. For sanctions, law-enforcement attributions, issuer freezes and maintainer flags (an identified holder), the twin carries the listing one risk level lower; hack-cluster and phishing addresses are single-use and are not twinned.
• Lists sometimes mislabel formats (e.g. a TRON address published under the XBT ticker, USDT on Omni as bitcoin addresses); Ozone trusts the checksum-verified format and notes the mismatch. Identifiers that are not valid addresses are rejected and reported, never imported.

THORChain flow tracing

Laundering through THORChain rarely touches a thor1 account: the Bybit funds (Feb–Mar 2025) went ETH → BTC directly. Ozone therefore follows flows, not accounts:

• Followed: swaps (including streaming, limit swaps and L1→L1), native sends, secured-asset deposits and withdrawals (SECURE+ / SECURE−: an L1 address into a thor1 account, a thor1 account out to an L1 address), trade-account deposits and withdrawals (TRADE+ / TRADE−), LP withdrawals (to the member's payout addresses), LP pairing (asset and RUNE side of one deposit co-own the position) and THORNames (owner ↔ alias). Their reasons say which: TRACE_SWAP, TRACE_SECURE, TRACE_TRADE, TRACE_SEND, TRACE_CONTRACT, …
• Through Rujira contracts: Midgard shows a contract call without its coins, so the chain's own transaction events (THORNode) are read too. Value a flagged account puts into a contract call and the contract pays on to another account in that call — a FIN swap with a recipient, a payout to a third party, a position funded for another owner, a swap the contract starts toward another address — flags that account (TRACE_CONTRACT). Only what the signer's own value moved counts: a call that puts nothing in and touches none of its own positions, a fee-sized side payment (under 5 % of the largest one), payments to contracts and module accounts, and amounts with no known price on either side do not. Not traced: the maker of a FIN limit order that a flagged account's swap fills — the maker is credited inside the contract and no event names it.
• Linked accounts: a thor1 account that signed a payment to a listed address (a swap to it, a secured-asset withdrawal to it) is linked to it, found from the listed side whoever the account is. A link counts one risk level below the listing, because a payment to an address is not proof of common control: a link to an official listing flags the account, a link to a hack or exploit listing is published as a reason below the flag level.
• Hops: at most 3. A traced address propagates only flows that happen after it received the tainted value; likewise a hack-cluster member only from the start of its incident (earlier activity cannot be the proceeds).
• Decay: traced risk is capped at high and drops one level per extra hop (hop 1 high, hop 2 medium, hop 3 low).
• Amounts: value from the same listed origin to the same recipient at the same hop is added up — each THORChain transaction once, however often it is re-read. A total under $50 flags nothing (dusting resistance); hop-1 totals under $1,000 and deeper totals under $5,000 lose one more level. Swap values use the price at the time from Midgard; other flows use current pool prices (approximation, only used against the thresholds).
• Many small transfers: a recipient built entirely from transfers under $50 each is traced once they add up to $50 — with the risk one transfer of that total would get, tainted from the transfer that reached it, and followed onward like any traced address. Its reason (TRACE_SMALL_TRANSFERS) names the total, the number of transfers and the origin. Only transfers a flagged address signed itself count; anyone else's transfers never do. At most 100 such recipients per listed origin and hop are followed further; beyond that they are still flagged, but not traced onward.
• Never flagged by a flow: affiliate fee outputs, THORChain module accounts (asgard, reserve, bond, affiliate collector, …), CosmWasm contracts, and services (addresses with more than 2,000 THORChain actions).
• Coverage: history is backfilled per flagged address — oldest first and to the end, over several passes for long histories — and a real-time follower processes every new THORChain action in chain order; after an outage it catches up from where it stopped instead of skipping ahead. The backfill reads incident keys first (see below), then by risk; within one risk level it reads traced addresses first (they are proven THORChain users), then attributions (sanctions, law enforcement, hacks, maintainer flags), then bulk lists (issuer freezes, phishing lists), then same-key twins. (Midgard's address filter is case-sensitive: senders are stored as observed on chain — lower-case for EVM — which is the form the backfill queries; memo destinations keep the user's spelling, which is why normalization happens on Ozone's side.)
• Freshly announced hacks: no public list carries a new hacker's addresses on day one. A maintainer pastes them, with the public source (post-mortem, law-enforcement release, investigator thread), as maintainer flags marked urgent. The worker notices within seconds, lists them, reads their THORChain history — and that of every recipient it finds, hop after hop — before anything else, and publishes a signed snapshot right away, typically within minutes. The urgency lasts 48 hours; the flags stay until a maintainer removes them.

Hack clusters. Attribution lists name the first addresses of a heist; the THORChain swaps are made from the next layer. For every incident Ozone follows native-coin transfers out of its attacker addresses on their own chain (Ethereum and the EVM chains, Bitcoin, Litecoin), inside the laundering window (by default the theft date plus 180 days), above a value threshold and up to a hop limit. It stops at services (addresses with many transactions: exchanges, THORChain vaults), contract calls (router and bridge deposits, DEX swaps), contracts (bridges, routers, mixers, smart wallets — checked on chain), CoinJoins and THORChain deposits. Members are listed with the incident's name (depth ≤ 2 high risk, 3 medium) and traced through THORChain from the start of their incident. Each run has a request budget; a run cut short records where it stopped and the next run resumes there, so no cap is silent. Pasted maintainer incidents are expanded right away; the rest weekly while their window is open. Explorer data: Powered by Routescan.io APIs (Ethereum, Avalanche), Blockscout (other EVM chains) and the Esplora APIs of mempool.space, blockstream.info and litecoinspace.org (Bitcoin, Litecoin); contract checks through PublicNode.

• ETH: transfers ≥ 0.5 (native units), depth ≤ 2, ≤ 400 explorer requests per cluster and run
• ARB: transfers ≥ 0.5 (native units), depth ≤ 2, ≤ 150 explorer requests per cluster and run
• OP: transfers ≥ 0.5 (native units), depth ≤ 2, ≤ 150 explorer requests per cluster and run
• BASE: transfers ≥ 0.5 (native units), depth ≤ 2, ≤ 150 explorer requests per cluster and run
• POL: transfers ≥ 5000 (native units), depth ≤ 2, ≤ 150 explorer requests per cluster and run
• GNOSIS: transfers ≥ 2000 (native units), depth ≤ 2, ≤ 150 explorer requests per cluster and run
• AVAX: transfers ≥ 60 (native units), depth ≤ 2, ≤ 200 explorer requests per cluster and run
• BSC: transfers ≥ 3 (native units), depth ≤ 2, ≤ 200 explorer requests per cluster and run
• BTC: transfers ≥ 0.02 (native units), depth ≤ 3, ≤ 300 explorer requests per cluster and run
• LTC: transfers ≥ 20 (native units), depth ≤ 3, ≤ 150 explorer requests per cluster and run
• Bybit hack (TraderTraitor / DPRK), 2025-02-21 (ETH) — window 2025-02-21 → 2025-06-30, transfers ≥ 1, depth ≤ 3, seeded from the FBI list and exploiter labels.

New hack money arriving at THORChain. Launderers rarely deposit straight from an attributed address. For every new THORChain inbound of $25,000 or more from an L1 address that no list or trace covers, Ozone looks back one and two hops at who funded the sender on its own chain (the last 30 days; for Bitcoin and Litecoin the inputs of the deposit and of the transactions that funded them). If a funder is listed or traced, the depositor is traced with the reason "funded by … one hop before THORChain" (code TRACE_L1_FUNDING, two hops: TRACE_L1_FUNDING2, one risk level lower) and its THORChain outputs are traced from its deposit on. Look-backs run in a queue beside the real-time follower (never inside it), at most 3 funders per hop, cached per address; exchanges, contracts and CoinJoins are skipped.

Verdicts and risk levels

A verdict is flagged when any active reason reaches the policy threshold (default high). Every reason carries its source, category, provenance link and dates; traced reasons carry the hop, the THORChain transaction, the amount and the listed origin.

The numbers on the home page have one meaning each, and each links to its list:

• Flagged addresses (all chains) — every address in the newest signed snapshot whose active reasons reach risk high or above: listed, traced through THORChain, linked, or controlled by the same key as a listing. Each address (key) counts once, however many reasons it has; an EVM key counts once for all EVM chains. List · JSON
• Flagged THORChain (thor1) addresses — the thor1 addresses among them. List · JSON
• Listed addresses — distinct addresses on at least one list at any risk (medium-risk phishing entries are listed, not flagged). List
• Monitored thor1 accounts · flagged — thor1 accounts Ozone watches (Rujira League, LPs, live transactions), and how many of them are flagged themselves or linked to a listed L1 address (formerly "Flagged THORChain users"; see below). List

The two flagged lists show only what the signed snapshot publishes: address, chain, risk, reason codes, sources and the incident or entity behind it.

Monitored thor1 accounts flagged (formerly "Flagged THORChain users") are monitored thor1 accounts whose own address is flagged, or which are linked (by their own signed actions in their Midgard history) to a listed L1 address — a link counts one level lower, because a linked address can be a counterparty. Links through affiliate outputs and hub accounts are ignored: the previous screener flagged exactly two accounts, and both were fee collectors (THORChain's affiliate-collector module and an interface's affiliate address) linked to tens of thousands of unrelated swappers. A flagged monitored account also appears in the thor1 list (from the next snapshot on, which publishes its links); the thor1 list is larger because it also covers addresses Ozone does not monitor.

Signed snapshots and node-local screening

• The worker checks every 10 minutes and publishes a new snapshot when anything changed (and at least every 6 hours): a small manifest (version, build time, SHA-256 of the payload) signed with Ed25519, and the gzip payload with every listed and traced address and its reasons.
• Nodes pin Ozone's public key, verify the signature and the payload hash, refuse older versions (anti-rollback) and screen locally — Ozone never learns which address a node screened.
• If Ozone is unreachable, nodes keep screening against the last verified snapshot; every verdict reports the snapshot version and age.
• Online answers (/api/v1/screen) and certificates are signed too. Keys: /api/v1/keys. Format and client: INTEGRATION.md.

Privacy

• No IP addresses are logged or stored — not for API calls, not for reports, not for admin sessions.
• The screening API is stateless: screened addresses are neither stored nor logged. (Hosting providers may keep their own access logs; nodes that want zero exposure screen locally from the snapshot.)
• Stored on request only: certificates (address + verdict, by design shareable) and reports/appeals (what you type; the contact field is optional).

Limitations — what Ozone cannot see

• Transfers outside THORChain are traced only by the hack clusters (from attributed addresses forward) and the inbound watcher (from large THORChain deposits one or two hops back). A launderer who inserts more L1 hops, or deposits less than the watcher's threshold, is only caught if an intermediate address is listed.
• Hack clusters follow native-coin transfers only (no token transfers or contract-internal transfers), inside the incident window and within a request budget. Keyless explorers limit which chains are covered: Ethereum and Avalanche through routescan, Bitcoin and Litecoin through public Esplora servers; other EVM chains only at a trickle (a keyless Blockscout instance allows about 10 requests an hour) unless an Etherscan or Blockscout key is configured.
• Lists lag reality: community lists publish with delays, sanctions add addresses weeks after the fact, Tether and Circle only freeze what they are asked to. Freshly announced hacks reach Ozone only when a maintainer lists them (see freshly announced hacks).
• Traces are evidence of a flow, not of intent: a hop-1 recipient may be an exchange deposit address or a victim of deliberate "dusting" (hence the amount thresholds and decay: dusting an address costs at least $50 in total). Read the reason before acting on it.
• Current pool prices approximate the value of non-swap flows.
• Midgard is the source of THORChain history; if it misses an action, so does Ozone.