How these addresses were identified

A flaw in Coldcard wallet firmware made some recovery seeds predictable, and in late July 2026 a thief began recreating those keys and emptying the wallets they controlled. This page sets out how the drained addresses on this site were identified, and where the method can be wrong.

This is not a blocklist

Every address here is published in full so the work can be checked. That is the point of the page. It also means this list can be copied into a screening or compliance system, and if that happens an address stops being a research finding and becomes a problem for whoever holds it, usually without them ever knowing why.

Stated plainly: this is not a screening feed and it has no measured false-positive rate. None can be measured. Nobody has tested whether any of these addresses was in fact generated with weak entropy, and the vendor's own advisory told every affected owner to move their coins in a way that produces the same shape a theft does. The reasoning below is set out so it can be argued with, not so it can be automated against people.

If an address here is yours, it comes off. No proof of identity is needed and nothing secret should ever be sent: the address and the transaction are enough to check it against the chain, and if the listing does not hold up the totals move with it. Report it here. That request is handled before anything else on this project.

Telling a victim apart from a thief

Each theft is one transaction with one input and one output. The input address is the victim, because that is where the money leaves. The output is the attacker, because that is where it arrives. Nothing is inferred from the addresses themselves. Direction does the work. A transaction like this, one that empties an address completely, is called a sweep below.

Those output addresses collect a batch of sweeps and then forward everything to a second address that holds the funds. So each cluster has a collector, which fills and empties, and a vault, which fills once and then goes quiet. The dashboard watches the vaults, because that is where the money sits.

Telling a theft apart from someone moving to safety

This is the part that cannot be proven from the chain alone, so here is the actual reasoning. Four things appear in every sweep and rarely together otherwise:

• One input, one output, and no change output. The address is emptied exactly; a normal payment sends leftover change back to the payer.
• Every input is a single-signature native segwit key (an address starting bc1q), the default path of the affected wallet.
• Every transaction in a batch pays an identical hardcoded fee rate, unrelated to what the network was charging.
• The proceeds consolidate once and then never move.

No single mark settles it on its own. An owner rescuing coins one at a time, moving each coin in its own transaction to keep their histories separate, produces the same shape the tool does. What an owner cannot produce is convergence with hundreds of strangers, and there are two kinds of it in this incident. An address is listed on this site only when its sweep shows one of them, and never on shape alone.

Convergence of destination. Hundreds of sweeps land inside one window, every one paying the same fee rate regardless of what the network was charging, and every one paying into the same address. A rescue goes to the owner's own wallet, and a thousand separate owners cannot share one destination. The first, second and fifth clusters are listed on this test.

Convergence of fee. Wave 3 removed the shared destination deliberately, giving each drained wallet its own fresh address and then its own fresh vault of a different address type (P2WSH), 214 of them sharing nothing, which is why this site missed the wave for two days. What it did not remove is the fee. Its 215 sweeps all paid within a hair of 201 sat/vB (satoshis per unit of transaction size, which is how Bitcoin fees are priced) while the network was charging under 3, and a rate that constant across transactions sharing no address is a number hardcoded in a script rather than 215 strangers independently choosing the same urgent fee. Sixteen further chains matched the shape but paid scattered rates, and they were left off rather than published on shape alone.

Three further marks hold across that wave, and are set out here because the fee should not carry it alone. The oldest coin anywhere in the set was created in block 677,217, about two weeks after the vulnerable firmware shipped: nothing in the set predates the flaw, which is what a population of addresses generated by that firmware would look like. All 214 vaults are still unspent, where an owner who moves coins to safety goes on to use the wallet they moved to. And Galaxy Research reported a wave of this size in this window from their own separate analysis, which is harder to account for if these sweeps were owners rescuing their own coins.

What each cluster rests on

Three different hardcoded fee rates, and only the second batch signals replace-by-fee. That is either one operator changing their tooling or more than one operator working the same flaw. There is no way to tell from the chain, and this page does not claim to know.

How new clusters are found

Every block since the first drain is read and tested against the pattern above, and the scan keeps running forward as new blocks are mined. A cluster nobody has reported still surfaces here, because the search is over the chain itself rather than over a list of addresses somebody supplied.

Blocks come from a Bitcoin Core node directly, so the scan does not depend on a third party's API or rate limit. When a group of sweeps in a single block pays into one address at one identical fee rate, that address becomes a candidate. Each candidate is then checked for freshness, because an exchange processing withdrawals produces a similar-looking burst: one rejected candidate had 476,464 prior deposits, which no collector in this incident has.

Anything that survives both tests raises an alert for a person to examine. A false accusation against an exchange or an uninvolved wallet would be worse than a slow addition, so a human confirms every cluster before it appears.

Reports from the people who were robbed

The block scan starts from the chain and works outward, so it can only find a cluster that matches the pattern above. A theft that used a different tool, or that nobody has connected to the known operators, can stay invisible to it. The people who were actually robbed are the other source, and several of them have posted their own drained address in public.

So the reports are watched too. An agent reads the replies and quotes on the threads about this incident, the posts that link here, and a standing search for people describing a Coldcard theft, and it pulls any bitcoin address out of them. A tweet is only a lead. Every address it surfaces is checked against the chain before anything happens, because a post can name the wrong address, quote the thief's address rather than the victim's, or be mistaken.

That check decides what follows, on two levels:

• When the drained funds land in a known attacker address, directly or through one hop that the attacker signs alongside an address already known to be theirs, ownership is proven by the transaction itself. Those are added and the totals updated.
• When the sweep matches the theft pattern but connects to nothing already known, it is held for a person to review rather than published on a match alone.
• When the address looks like a collector, receiving batched sweeps rather than losing funds, it is never treated as a victim. It is flagged as a possible new operator address instead.

This runs on an always-on server that stays watching around the clock, so a report posted in the middle of the night is checked within the hour. What it cannot reach: a private or deleted account, a report that shows the loss only in a screenshot with no address in the text, and any claim the chain does not support; none of those appear here, which is the same standard the rest of the page holds to.

What this cannot see

The detector now looks for two shapes rather than one, but both are still shapes. A thief who uses an address type other than single-signature native segwit, varies the fee from one sweep to the next, or spreads a theft thinly enough that no block holds a group would still not match it. Wave 3 is the worked example: removing the shared collector made every detector on this site blind to it until the fee constant was used instead. The freshness test is also a judgement, not a proof: it sorts by how much unrelated history an address carries, and an unusual case can land on the wrong side of that line.

An address can therefore be missing from this set for two different reasons: it was never drained, or the pattern failed to catch the theft. Because the checker cannot tell those apart, a result of not in the verified set leaves the question open rather than settling it.

What the checker actually does

The list of drained addresses is turned into one-way fingerprints (hashes) and shipped with the page. When an address is entered, the browser fingerprints it the same way and looks for a match locally. Nothing is transmitted and nothing is logged. If the list fails to load, the tool disables itself rather than reporting everything as clean.

Sources and how to check the work

Block data for the scanning comes from a Bitcoin Core node. Address balances and histories come from Blockstream's Esplora, with blockchain.info used to read many addresses in one request and mempool.space as the fallback and the source of the exchange rate. Figures that appeared in more than one source were compared before being published, and the totals here match the independently published ones to the satoshi.

Every address on this site links to a block explorer, so any claim can be checked without trusting the page. Vendor detail comes from the Coinkite advisory and Block's engineering analysis.

If you know of a drained address or a collection address that is missing here, it belongs in the set. A report from someone who was there still beats a pattern match.