Methodology

The sum of each account's at-freeze balance, counted once per freeze episode. A freeze episode starts when an issuer blocklists an address and ends only when the address is unblocklisted. Within one episode, only the first blocklisting event is summed: issuers occasionally re-mark an already-frozen address (two blocklist events with no removal between them - a verified on-chain behavior), and summing those would count the same trapped balance twice. A fresh freeze after an unblocklisting is a genuinely new episode and counts again. Destroys do not end an episode, because a destroy does not lift the blocklist.

Because balances are captured at the moment of each freeze, this total reflects what was frozen then, not what those accounts hold now - for that, see the current value below.

The sum of the live on-chain balance of every address that is currently blocklisted. Our worker maintains a per-address balance snapshot: a new blocklisting adds the address within seconds, an unblocklisting removes it, and a full daily sweep re-reads every balance to capture drift (deposits into or seizures from frozen accounts). The headline updates immediately on new events; the "as of" stamp shows when the full sweep last completed.

Event values shown across the site (the ledger, event pages, largest-freeze rankings) are the balance held by the address at the moment the event executed, not its current balance. How we obtain that varies by chain capability: on chains with archival RPC access we read the balance at the exact block of the freeze; destroy events carry the seized amount in the event itself, which is used directly; on chains without archival reads we reconstruct the at-event balance from transfer history, or - as a stamped, repairable fallback - use the closest available read. Deny-list chains are always read at the freeze block so deposits made after the freeze are excluded from the at-freeze figure.

Ever blocklisted counts distinct (chain, address) pairs with at least one blocklisting or destroy - an address counts once no matter how many times it was frozen, and still counts after being unblocklisted. Currently blocklisted is derived from each address's most recent executed event: a destroy does not lift the blocklist, so destroyed addresses remain counted as blocklisted; currently unblocklisted counts addresses whose latest event is an unblocklisting.

Some freezes (chiefly Tether's, executed through a multisig) are visible on-chain as a proposal before the confirming signature executes them. The escape outflow of a freeze is the value that moved out of the targeted address in that window - funds that saw the freeze coming and left before it landed. We compute it from the address's outgoing transfers between the proposal transaction and the execution transaction. Only freezes with an observable proposal step have an escape outflow; instant freezes (e.g. USDC's single-transaction blacklist) cannot have one.

For multisig freezes, the time between the on-chain proposal and its execution - the window in which the target can still move funds (see escape outflows). Stats-page aggregates (mean, largest) are computed over all recorded proposal-to-execution pairs.

For addresses that were unblocklisted, the elapsed time from their blocklisting to the unblocklisting - how long the freeze actually lasted. Addresses still frozen have no duration yet and are excluded from duration aggregates rather than counted as zero.

Issuers can permanently seize (burn) the balance of a blocklisted address. The destroyed amount is taken from the on-chain destroy event itself, which reflects the full frozen balance seized at that moment. A destroy leaves the address blocklisted; it is counted in the destroyed total and deducted from the current value (the live balance drops to zero), but its original at-freeze value remains in the all-time total.

Where a freeze is visible as a multisig proposal before execution, we show it as pending the moment the proposal lands, with the address's balance at that time. A pending event either becomes an executed blocklisting (and is folded into the same record, preserving its URL) or expires if never confirmed. Only executed events count in the headline totals; pending events are shown for early warning, not summed.

Events are ingested continuously from each chain's canonical source (contract event logs, or the issuer's on-chain deny list where events don't exist), with high-frequency fast lanes on the busiest chains (TRON and Ethereum USDT are scanned every ~3 seconds at the chain tip). Every feed is idempotent - re-scanning can never duplicate an event - which lets us layer healing passes on top: trailing re-scans behind the live cursor, weekly trailing and monthly full-history reconciliation sweeps.

Independently of ingestion, every feed is cross-checked against a source that does not share its failure modes: external indexer counts (Dune, Blockscout), on-chain enumerable deny-set reconciliation where contracts expose one, and monthly contract-state sweeps that verify each recorded address's status directly on-chain. A watchdog alerts on any feed running without a registered cross-check, on stale feeds, and on events whose transactions cannot be verified on-chain.

Intel notes (who an address belongs to, why it was frozen) are community submissions. Every note is hidden until a moderator verifies it against its cited evidence; verified notes show the contributor's public username, never their email. Notes are attached to addresses, not events, so context follows an address across its freezes. Intel is presented as community-submitted context - it is never the issuer's official reasoning.

Ask-the-data answers are generated by a language model that can only call the same aggregate queries that power this site - it cannot free-read the database, and every figure in an answer comes from a query result, not the model's memory. Charts under answers are computed server-side from those same queries. Answers are capped to a small number of example rows, so the feature cannot be used to bulk-export the dataset.