first wave: from Jul 30 01:10 to Jul 30 01:51 UTC (block time), blocks 960,183-960,191

liberlume-content-v3 lang: en title: The numbers of the Coldcard incident, verified at home summary: Between July 30 and August 1, 2026, thousands of addresses created with Coldcard Mk2 and Mk3 wallets, whose seeds came from a faulty generator, were drained. The incident's numbers recomputed at home with a Bitcoin node and nodsig's open artifacts: 1,366 BTC from 4,560 addresses, the rules that isolate the groups, the comparison with Perera and Galaxy, where the funds are. btc-anchor: 969003,000000000000000000015856107d8546d2821369235a47f97ca073da7d33ae60 prev: genesis --- body --- Between the end of July and the beginning of August 2026 thousands of Bitcoin addresses created, according to the reports, with Coldcard Mk2 and Mk3 hardware wallets were drained. The cause lies upstream of the chain: from firmware 4.0.0 of March 17, 2021 until the fix of July 31, 2026 the seeds of those models came from a faulty random number generator, which left a few dozen bits of uncertainty instead of 128: few enough to try them all. Anyone who reconstructed a seed could spend its coins. According to Galaxy Research, the losses come to about $115 million. The generator side of the story, including the newer models, which had a milder flaw, is covered in [«How big is "practically impossible"?»](/en/seed-entropy/). This piece looks at the other side: what is left written on the ledger. The incident's numbers in circulation come from a few analysts, above all Praveen Perera for the first wave and Galaxy Research, the research arm of Galaxy Digital, for the overall count. On a public ledger there is no need to take them on trust: **they can be recomputed, and that can be done at home**, with one's own node and open tools, in hours rather than weeks. Recomputed, the numbers hold where the reports are precise, diverge where the criteria differ, and stop where the chain stops saying who acted. The dates and the starting windows come from the public reports; the measurement is independent. This holds for any public and complete ledger: anyone with the data can redo the count without relying on whoever did it first. To avoid having to trust anyone, or just as an exercise. ## What it takes A Bitcoin node keeps blocks in time order, and in that order it answers well and efficiently: what is in such a block, what such a transaction spent. The questions about an incident ask for the data in another order. When did this address first receive funds, and how many times? Had its key already appeared on the chain before the theft? Were its coins ever spent together with those of other addresses? These are questions by address, by key, by spend, and for the node each of them costs a reread of the whole history.

The questions about an incident and the order they need. The node keeps blocks in time order and answers well what a block contains or what a transaction spends. Questions by address (first arrival, receipts, spends), by key (had it already appeared?) and by spend (with which other coins?) need indexes built once: the history of the coins, the archive of revealed keys, the co-spends, with the nodsig 3.4.0 commands beside them. For the recent weeks the node is enough, because the blocks can be reread.

For the weeks of the incident the node is enough: they are eleven thousand blocks and they can be reread. For the past it is more useful to have indexes built once, which answer in the order of the questions. Here they are those of [nodsig](https://github.com/amenano/nodsig), an open tool that builds from the chain, reproducibly, the index of the coins, their history and the archive of revealed keys. | layer | blocks (heights) | how it is verified | |---|---|---| | sealed base, that is, closed with public fingerprints: index, history, archive of revealed keys, headers | 1-957,301 (up to July 9, 2026) | fingerprints (at the end); in addition 1.87 million fees and 3.74 million locks compared with the node, all equal | | recent layer, read from the node | 957,302-968,533 (July 9-September 25, 2026) | for every block: hash, link to the previous one, the two fingerprints that bind the transactions to the block (Merkle root and witness commitment), fees recomputed from the spent coins | Building the indexes has a cost, to be weighed against what they save. The base is built once: about 129 machine hours and 960 GB. After that, the questions become queries: | question | with the node alone | with the indexes | |---|---|---| | reread 282,351 blocks (2021-2026), with fees and heights of the spent coins | about 50 hours and 500 GB read (estimate from the measured pace, 0.64 seconds per block) | 3 h 41 | | reread the incident's 1,251 blocks, with the spent coins | 12 minutes measured, with three processes (0.57 seconds per block) | not needed | | profile of 1,891 addresses: first arrival, receipts, spends | a pass over the history, or an external indexer | about 90 seconds | | had the key of 265,869 addresses already appeared? | cannot be asked without rereading all the unlocking data | about an hour | The reading pace was measured twice, with two independent readings of the blocks, at 0.64 and at 0.54-0.57 seconds per block: with the node alone the five years would cost between 42 and 50 hours. The fair comparison, though, is not just with a bare node: an address indexer would cover the profile and the co-spends, not the archive of revealed keys. One limit holds for the whole piece: taproot addresses and bare-key ones (p2pk) cannot be reconstructed from the unlocking data, and they are left out of the five-year reread; in the recent period they are 16.4% of the drains. None of them is in the incident's groups. The address types, and what each one shows when it spends, are in [«Bitcoin's locks»](/en/bitcoin-locks/). ## The first wave The first wave can be recomputed to the satoshi, the hundred-millionth of a bitcoin, from the blocks' bytes alone, and the number known from the public reports holds: | measure | Perera | redone from the bytes | |---|---|---| | drains (transactions) | 1,195 | 1,195 | | inputs (coins spent) | 2,350 | 2,350 | | value | 1,082.65318922 BTC | 1,082.65318922 BTC | | blocks (heights) | 960,183, consolidation in 960,191 | 960,183-960,191 | | when (block time, UTC) | July 30, 01:10-01:51 | July 30, 01:10-01:51 | The reconstruction does not use a list of transactions or addresses. It starts from the description Perera gives of the first wave (the blocks, one transaction per drained address with a single output, the same values of version, locktime and sequence, a fee equal to 30 times a fixed estimate), turns it into rules and applies them to the blocks. Out come the same numbers as the report, to the satoshi. Perera had found them by tracing back from the four destination addresses published by Galaxy; here no address is given up front. Of the 1,195 addresses Perera publishes 153, those he did not trace to a seed: they are all among those reconstructed here, with the same block, the same number of inputs and the same value. It was redone twice, with two independent readings of the blocks; the second, from the wave's nine blocks alone and in twenty seconds, uses even poorer rules, without the fee formula, and finds the same set again. The terms used from here on come from this case. Each transaction is a **drain**: a single output and no change (the output that returns the difference to the sender), towards a different address. A drain is **simple** when the inputs all come from one address, as here: one address per transaction. The destinations are four **collectors**, addresses that receive drains from many different addresses, new ones. Within seven blocks, three transactions sweep up almost everything they received; the 32.45 BTC that arrived in the same block as the consolidation stayed on the collector. Galaxy counts 1,196 addresses for the same amount to the satoshi; the chain shows 1,195 transactions from 1,195 addresses, and no other transaction pays the four collectors in those blocks. The one-address difference remains unexplained. 1,195 addresses are not 1,195 people. Perera, who rebuilt the faulty generator, reconstructed 328 seeds, that is, 328 wallets: behind those seeds are 1,042 of the 1,195 addresses and 949.70 of the 1,082.65 bitcoins, 87.72 per cent. The chain alone counts addresses; to count wallets one has to rebuild the faulty generator. One step of the analysis is to find data that characterise individual transactions and the way they are written to the ledger. What the 1,195 transactions have in common is the **mark** of a program, where program means any software that builds and signs transactions: a user's wallet is one, and so is the tool used for the attack. The protocol leaves many details open, and each program settles them its own way. The first is the **construction**: version 2, locktime 0 (valid immediately), sequence at the maximum value on all inputs (cannot be replaced). These are fields every transaction carries, and together they point to a family of programs, not a single one. The second is the fee. The protocol does not say how to compute it. Every program derives it from a rate and a size of the transaction, and since the fee is decided before signing, the size is always an estimate. The program of these transactions, as Perera described, uses a fixed estimate, always the same for the same number of inputs: 42 virtual bytes plus 68 for each input from p2wpkh addresses (91 for p2sh, 148 for p2pkh). The virtual byte is the unit in which space in the block is measured. The estimate is multiplied by an integer rate: 30 satoshis per virtual byte, 30 sat/vB. The result is a fee that is always an exact multiple of that estimate, in all 1,195. Many programs reach the fee in other ways, with non-integer rates or different estimates, and their fees do not fall on that grid: this is what narrows the field. The third detail is the signature. The length of an ECDSA signature, the scheme used by these addresses, depends on one of its internal numbers, r: about half the time it needs one extra byte, so signatures split roughly evenly between 72 and 71 bytes. Bitcoin Core, since 2018, repeats the computation until the short version comes out. In the first wave, of 2,350 signatures, 48% are 72 bytes long; in the 279,492 transactions built like Core or Sparrow between July and September, 4%. The fee narrows the family down to one program, the signatures help tell apart different programs that use the same formula. The last trait concerns the drained addresses, and it was measured on these: all funds arrived after March 17, 2021, the date of the faulty firmware; almost always a single receipt; key never revealed, that is, never shown on the chain in a spend; mostly coins that had not moved for years. It is the **profile** of the drained addresses. It is also the profile of cold deposits (one receipt, never a spend): on its own it does not separate an attack from a service, and it does not say with which device the address was born. Of these traits only the first comes from the flaw itself: a seed born with the faulty firmware exists only from that date. The others describe those who use a Coldcard as a deposit. Taken together, these details work as a filter that gets tighter at each level: | level | what it looks at | how common it is | what it says | |---|---|---|---| | construction | version 2, locktime 0, sequence at the maximum | from September 1 to 25, outside the incident: drains from 310,784 addresses | a family of programs | | mark | the construction, plus a fee that is an exact multiple of the fixed estimate | in the same period: 109,059 drains from 65,554 addresses, at 1-3 sat/vB | one program, or a few | | episode | the mark at 10 sat/vB or more, in a peak in time | in the five years before the incident: 709, almost all small | a repeated activity of that program | | the first wave | the episode, plus shared collectors and the profile of the drained addresses | 1,195 addresses in 41 minutes, at 30 sat/vB | an episode of the incident | The filter serves to find the first wave's transactions among millions of others, and to look for the same mark in earlier years. It does not serve to attribute. **The mark says which program, not who uses it**: since September 1 the same mark, at lower rates, is used by a very widespread program. That is why, in this piece's rules, construction and mark alone are never enough to make a group. ## How a group is recognised and characterised On the chain an incident has no labels. It can be identified when some rules isolate transactions that resemble each other more than chance allows, and rules are worth something only if they were fixed where the answer was known and then applied where it was not. The work has three phases: **calibrate** the rules on the first wave, **search** for the groups in the incident's window, **verify** where the answer is unknown. What the rules isolate is called a **group**. A group that Perera or Galaxy also attribute to the attack is called a **wave**: the first, and the two-step one. The rules are eight, written for this investigation; the scripts that apply them are not public. From outside the analysis comes Perera's description of the first wave (he rebuilt a tool similar to the one the attacker presumably used): it served to calibrate the rules, and that is why some of them bear its trace. The thresholds are those used; the logic matters more. The rules do not all play the same role: two, the peak and the collector, run over all transactions and find the candidates; the others examine the candidates or describe them. | | rule | what it looks at | when it fires | origin | |---|---|---|---|---| | R1 | form | a transaction | it is a drain. The simple form is sought over the whole history; the multi-address one only in targeted analyses, because it is also the form of someone gathering their own addresses | this investigation; the simple form is the one Perera describes for the first wave | | R2 | peak | drains with the same construction, or the same mark, in six blocks (about an hour) | when they exceed twice the 99th percentile, that is, the value that only one window in a hundred exceeds, in the two weeks before and after, leaving out the surrounding day; with a minimum of 30, or 10 for the mark | this investigation, calibrated on the first wave | | R3 | collector | the destinations of the drains | when many addresses converge on a few: at least 20 towards one, and no more than one different destination every ten drains. That the collector was new was checked afterwards, collector by collector | this investigation, calibrated on the first wave's four collectors | | R4 | mark | fee and construction | the first wave's construction and a fee that is an exact multiple of the fixed estimate, at 10 sat/vB or more. Signature length does not filter: it tells apart programs with the same formula | the fee formula is in Perera's report; here it was measured, extended to every integer rate from 10 up and to the other address types, and completed with the signatures | | R5 | profile | the drained addresses | on all candidates, almost no coin older than the firmware (at most 1%); on the groups the piece names, the full profile: first arrival, receipts, spends, key | this investigation, measured on the first wave | | R6 | follow-up | what happens to the funds afterwards | the destinations are spent together, or drained together; and where the funds arrive: coinjoin, THORChain, services, memos. Recognising the arrivals is itself a rule, and it got it wrong once: on September 21, a recovery mistaken for a coinjoin, then corrected | this investigation | | R7 | union | groups or destinations | the destinations of one are the sources of the other, or they are spent together | this investigation | | R8 | second step | one-to-one drains | a peak of one-to-one drains with the family's construction and an integer rate, from addresses funded no more than three days earlier but not forwarded at once (median age of at least 24 blocks, about four hours): it is the rule that looks for two-step waves | this investigation, born from the second step of the two-step wave and used on the earlier years | A coinjoin is a transaction that mixes coins of many owners to blur where they come from; THORChain is a service that swaps bitcoin for other coins on other chains; a memo is a short text written in the transaction itself.

The investigation's flow in three phases. Calibrate, where the answer is known: Perera's description gives the first wave, 1,195 addresses, on which the mark and the profile are measured and peak and collector are calibrated. Search, from July 30 to August 7: peaks and collectors (R2, R3) find the 5:48 and 7:34 groups of July 31; a peak by construction (R2; then the same fixed estimate, R4, and the second-step rule, R8) finds the second step of the two-step wave, 288 p2wsh addresses, and following the funds backward (R6) leads to the first step, 1,891 addresses; the union (R7) links the two steps. Verify, where the answer is unknown: the same rules over the 2021-2026 history find 709 episodes, none like the first wave; a reading that uses nothing from the reports finds July 31 on its own, and in its revised version the first wave too. For every group the profile (R5) and the follow-up of the funds (R6) describe, they do not decide.

The three phases, and what each one checks: 1. **calibrate**, where the answer is known. Perera's description gives the first wave; on it the mark (R4) and the profile (R5) are measured, and peak and collector (R2, R3) are calibrated. The rules were tried there and corrected before reading the rest. The peak, by construction, is always measured against the nearby weeks, not against a chosen value; 2. **search**, from July 30 to August 7. Peak and collector (R2, R3) run over all transactions of the recent layer, from July 9 to September 25, and produce a list of candidates; profile, follow-up of the funds and union (R5, R6, R7) examine them one by one, and discard services and migrations. Outside the window the collector finds another 48 candidates, almost all coins just arrived, forwarded by services: the profile discards them. Inside the window what remains are the 5:48 and 7:34 groups and a peak on August 1: 283 one-to-one drains, with the same fee, towards new p2wsh addresses. That fee turns out to be the first wave's fixed estimate, adapted to the output (R4); tracing back from there to the transactions that had funded those addresses (R6 backward) leads to the first step. From the second step the rule R8 is born, used then to look for others in the earlier years; 3. **verify**, where the answer is unknown. The same rules reread the history since 2021: if the attack has similar precedents, they must show up. A reading that uses nothing from the reports must find the anomalous period on its own. These are the two cross-checks, further on. The groups emerge from the list of candidates; they are not sought explicitly. The exception is the first wave, which comes from Perera's description. The table that says which rule decided each group, further on, is a reconstruction made afterwards. Calibration comes at a price, and it should be stated: rules derived from transactions chosen with Perera's description look, by construction, for things like those already described. Within the incident's window the price is low, and it can be measured on the blocks: in the windows of the first wave and of the 5:48 and 7:34 groups, the collector rule alone also finds the collectors of services that gather deposits, and to separate them the age of the coins is enough, without Perera's formula. The attack's coins had been unmoved for a median of 148,000-210,000 blocks, three or four years; those of the services for 1-1,838 blocks, two weeks at most. In the reread of the earlier years the price is high, because there the program's mark is what is sought: the cross-checks say so. ## Beyond the first wave: groups, not actors After the first wave the rules isolate three more groups, all by the morning of August 1. Two take their name from the time of their first block, on July 31: the 5:48 group and the 7:34 group. They pay 10 and 50 sat/vB on the actual transaction size, not on the fixed estimate: they do not have the first wave's mark, and they were built by programs other than the first wave's. | group | blocks (heights) | when (block time, UTC) | addresses | BTC drained | in the sources | |---|---|---|---|---|---| | first wave | 960,183-960,191 | 07/30 01:10-01:51 | 1,195 | 1,082.65 | Perera; Galaxy, Wave 1 | | 5:48 group | 960,352-960,356 | 07/31 05:48-05:58 | 352 | 30.19 | Galaxy, Wave 2 (352 addresses) | | 7:34 group | 960,363-960,369 | 07/31 07:34-08:36 | 1,122 | 45.93 | not named | | two-step wave | 960,396-960,471, then 960,519-960,520 | 07/31 12:23 → 08/01 06:27 | 1,891 | 207.73 | Galaxy, Wave 3 | | **total** | | | **4,560** | **1,366.49** | | The address total is a plain sum: overlaps between groups were not checked. Galaxy counts the 5:48 group as Wave 2, but the same group ends up in a recovery transaction (see below): that is why here it stays a group and not a wave.

The incident's 48 hours, from July 30 to August 1, 2026, block time in UTC. First wave: July 30, 01:10-01:51, 1,195 addresses, 30 sat/vB. The 5:48 group: July 31, 05:48-05:58, 352 addresses, 10 sat/vB. The 7:34 group: July 31, 07:34-08:36, 50 sat/vB, 1,122 addresses. Two-step wave: the first step on July 31, 12:23-22:25, 1,891 addresses, mostly at about 200 sat/vB; the second on August 1, 05:48-06:27, 288 p2wsh addresses, 10 sat/vB. July 31 is the day of the firmware fix (4.2.0). In the 2,145 blocks from July 14 to 29 the median fee rate of the blocks was 1.02 sat/vB. Data: blocks read from the node.

The two-step wave is the one Galaxy calls «Wave 3». The drained addresses are 1,891, all in the first step: on July 31, 296 transactions drain them, up to ten per transaction, and send their funds to 288 new transit addresses, not to a collector. That is why R3 does not see it. In the second step, on August 1, each of the 288 transit addresses is drained in turn towards a new p2wsh address, that is, one protected by a script that stays hidden until the address spends. The transfers are almost all in the same block and pay the same fee: a batch sent by a single program. Of the 11 addresses that spent by September 25, all 11 reveal a 2-of-2 multisig script, with 22 keys all different; the 22 signatures are all short, a habit of the signing software. For the 277 unmoved ones the script remains hidden. Galaxy describes them all as two-signature vaults: for the 11 the form matches, for the others it cannot be said.

The two-step wave, in BTC. On July 31, 296 transactions drain 1,891 addresses, up to ten per transaction, to 288 new transit addresses (207.73 BTC). On August 1 the 288 are drained one by one to 288 new p2wsh addresses, with the same fee in 283 transactions (207.09 BTC arrived). At September 25: 20.50 BTC to THORChain on September 2, 70.26 BTC into coinjoins on the 5th and 7th, 116.33 BTC unmoved in 277 p2wsh addresses. Data: blocks read from the node up to 968,533.

In the 2,145 blocks between July 14 and 29 the market's median fee rate, weighted by transaction size, was 1.02 sat/vB: the incident's groups pay 10 to 200 times as much, as the summary of the groups further on shows. The table below shows, column by column, which rules each group comes from: the first wave is the only one where peak, collectors and mark all fire together; the two minor groups come from the collectors, without the mark; the two-step wave escapes the collectors in both steps, and the first step emerges only by following the funds backward from the second (✓ applied and satisfied; ✗ applied and not satisfied; the dash marks a rule not applied). In the cells, transactions are the drains, addresses are the drained ones, destinations are the addresses that receive: | rule | first wave | 5:48 group | 7:34 group | two steps: first step | two steps: second step | |---|---|---|---|---|---| | **deciding rule** | Perera's description; among this piece's rules R3 and R4 find it again, but they are calibrated on it | R3 | R3 | R6, backward from the second step | R2 and R4 | | R1 form: what drains they are | ✓ simple: 1,195 transactions, one per address | ✓ simple, the 31 transactions of the peak; of the 93 in all, 52 drain several addresses together | ✓ simple: 1,214 transactions from 1,122 addresses | ✓ multi-address: 296 transactions from 1,891 addresses, up to 10 per transaction | ✓ simple, one to one: 289 transactions from 288 transit addresses | | R2 peak: drains in a six-block window, against the threshold | ✓ 627 and 416 transactions in two windows, threshold 52 (about 24 and 16 times the maximum of the comparison weeks) | ✓ barely: 31 transactions, threshold 30 | ✓ 953 and 248 transactions in two windows, threshold 30 (at least 63 and 16 times) | — | ✓ 283 transactions in one window, threshold 30 (at least 19 times) | | R3 collector: where the funds go | ✓ 4 collectors, receiving from 500, 491, 104 and 100 addresses | ✓ 1 collector; 352 addresses in all | ✓ 1 collector, receiving from 1,122 addresses | ✗ no collector: 288 different destinations, transit addresses | ✗ no collector: 288 different destinations, p2wsh addresses | | R4 mark: the fee | ✓ 30 times the fixed estimate, in 1,195 transactions out of 1,195 | ✗ 10 sat/vB on the transaction size, not on the estimate | ✗ 50 sat/vB on the transaction size, not on the estimate | ✗ as a rule, except a peak of 12 addresses; the formula at 200 times the estimate holds in 77 transactions out of 296 | ✓ variant for p2wsh output: 10 times the estimate in 288 transactions out of 289 (the 289th rounded by one byte) | | R6 follow-up, backward | — | — | — | ✓ tracing back from the 288 transit addresses to the 296 transactions that funded them | — | | R7 union | ✓ the 4 collectors are a single group: same blocks, two consolidated in the same transaction | — | — | ✓ with the second step: its 288 destinations are the sources of the second | ✓ with the first step | | R8 second step | — | — | — | — | ✓ the rule was born here | The R2 values in the table come from a first version of the rule, which compared each window with the maximum of two fixed weeks, one before and one after the incident: hence the «times the maximum». The version in the rules table, with the 99th percentile of two moving weeks around each window, is the one applied to the five earlier years; on the recent period it finds the same groups again. The profile does not decide anything, but it separates drained addresses from those of a service, and it looks the same across the groups: | profile (R5) | first wave (1,195 addresses) | 5:48 group (the 31 of the peak) | 7:34 group (1,201 transactions at the exact rate) | two steps (1,891 addresses) | |---|---|---|---|---| | with coins older than the firmware | none | none | none | none | | a single receipt | 86% | 29 of 31 | 89% | 93% | | key never revealed | 97% | 29 of 31 | 98% | 99% | | coins unmoved for 3 years or more | 56% | 20 of 31 | 69% | 61% | The other 321 addresses of the 5:48 group were not profiled; those of the second step are transit addresses, without history. The same forms, however, are left by different parties. The 5:48 group shows it: consolidated on August 7, on September 21 its funds enter a transaction whose memo declares a recovery trust, a Wyoming entity set up to return the funds to those who lost them. Galaxy counts it among the recoveries by white hats, that is, people who used the same flaw to move the still-reachable funds first, and return them. **A recovery and a theft have the same form** until the funds reach a destination that declares itself. That is why the piece says «group» for what the rules isolate, and of the funds it says only what can be seen: unmoved, sent to THORChain, in a coinjoin, in a transaction with a memo. ## The drained addresses The drained addresses tell a story of five years of deposits. For each, the oldest coin among those drained says at least since when the address held funds. In the four groups, 4,560 addresses, the coins cover every quarter since March 2021, densest between late 2021 and mid-2022, and none predates the firmware:

When the drained coins were born: for each address, the quarter of the oldest coin among those drained, from March 17, 2021 (firmware 4.0.0) to July 2026. First wave (1,195 addresses) and, together, the other three groups (3,365). The addresses cover every quarter, densest between late 2021 and 2022; no coin predates the firmware. Data: blocks read from the node.

It is the measure of the drained coin, not of the first arrival of funds, which needs the base; with almost always a single receipt, the two almost coincide. Value is distributed differently across the groups: | value drained per address | first wave | two-step wave | 7:34 group | 5:48 group | |---|---|---|---|---| | addresses | 1,195 | 1,891 | 1,122 | 352 | | median | 0.27 BTC | 0.014 BTC | 0.010 BTC | 0.010 BTC | | the largest | 51.07 BTC | 13.34 BTC | 4.97 BTC | 8.00 BTC | | half the value is in | 58 addresses | 42 addresses | 85 addresses | 3 addresses | | the richest 10% of addresses holds | 64% of the value | 80% of the value | 56% of the value | 77% of the value | | address types | 1,182 p2wpkh, 7 p2sh, 6 p2pkh | all p2wpkh | 1,112 p2wpkh, 10 p2pkh | all p2wpkh | The first wave drained addresses with balances twenty times higher than the other groups: as if its author had started with the richest ones. This is a reading; the chain shows the balances, not the choices. A detail concerns the amounts. The first payment received by each drained address, compared with the first payments received by new addresses in the same blocks and with those of addresses never spent (cold deposits, the closest baseline): | first payment | drained addresses (%) | new addresses (%) | cold deposits (%) | |---|---|---|---| | less than 0.001 BTC | 10.4% | 33.8% | 51.5% | | 0.001-0.01 BTC | 23.3% | 36.9% | 22.8% | | 0.01-0.1 BTC | 35.2% | 19.0% | 16.1% | | 0.1-1 BTC | 25.3% | 7.1% | 7.9% | | 1-10 BTC | 5.4% | 2.5% | 1.4% | | 10 BTC or more | 0.4% | 0.6% | 0.2% | | exact multiple of 0.01 BTC | 11.4% | 1.7% | 2.6% | | exact multiple of 0.001 BTC | 17.2% | 3.2% | 4.3% | | number of addresses | 4,206 | 20,637 | 2,101 | The addresses counted are those of the four groups with a first payment in the base, before July 9: the 20 funded later are not included, nor are the addresses of the 5:48 group outside the peak, which were not profiled. The drained addresses had received medium and round amounts more often: this is consistent with purchases or withdrawals sent once to a cold deposit. It is a form, not an identity; and half of the comparison cold deposits are small change. ## Where the funds are At September 25, more than nine in ten bitcoins had not moved: | group | BTC drained | where they are, at September 25 (BTC arrived) | |---|---|---| | first wave | 1,082.65 | unmoved: 1,050.12 on three consolidated outputs, 32.45 on the collector, never consolidated | | 7:34 group | 45.93 | unmoved, after one consolidation | | 5:48 group | 30.19 | 30.18 in the recovery trust's transaction, on September 21 | | two-step wave | 207.73 | 116.33 unmoved in 277 p2wsh addresses; 70.26 into coinjoins on September 5 and 7; 20.50 towards THORChain on September 2 | | **total** | **1,366.49** | | In the third column the figures are those that arrived: the difference from the second is the fees paid along the way, less than one bitcoin in all. Unmoved does not mean lost or returned: it means that nobody has spent those coins yet. Of what has moved, 120.94 BTC, less than a tenth, the chain shows the path up to the coinjoin, THORChain or the trust's memo; beyond that it loses track. ## Two measurements, one comparison This piece's total, 1,366 BTC from 4,560 addresses, does not match Galaxy's, and that is not a disagreement. The three sources count different things: | | Perera | Galaxy | this piece | |---|---|---|---| | what it counts | the first wave, transaction by transaction | the waves and groups it attributes to the incident | the groups this investigation's rules isolate from July 30 to August 7 | | with what | the chain, starting from the four collectors published by Galaxy, and the rebuilt generator: 328 seeds reconstructed | the chain, with unpublished criteria | the chain alone: node and nodsig's artifacts | | date | August 12 | up to August 24 | snapshot at September 25 | | total | 1,082.65 BTC | 1,789.28 BTC | 1,366.49 BTC | Each difference is traced to a criterion; where that is not possible, it is left openly unresolved: | comparison | here | Galaxy | where the difference comes from | |---|---|---|---| | total | 1,366.49 BTC, 4,560 addresses | 1,789.28 BTC at August 24 | 422.79 BTC: partly batches with a construction these rules do not look at (below); the rest is open | | two-step wave / Wave 3 | 1,891 drained addresses, 288 p2wsh arrival addresses, 207.73 BTC | 1,912 drained addresses, 293 p2wsh arrival addresses, 208.24 BTC | criterion: here the send of August 1; Galaxy also joins the addresses spent together later, among them one created on August 3 from 58 addresses and spent on September 6 with nine of the 288 | | 5:48 group / Wave 2 | 352 addresses, 30.19 BTC | 352 addresses, 30.19 BTC | none: it is the same group, with the same numbers | | Footprint E, one of the largest minor groups | no group | 2,148 addresses, 209.94 BTC | different construction, outside these rules | A comparison holds only with the date beside it. Galaxy's counts grew with the investigation: 1,367 BTC at August 1, 1,596 at the 4th, 1,778 at the 14th, 1,789.28 at August 24, the last published, which is the one used here. The first is almost identical to this piece's total; whether the two sums contain the same groups cannot be said from outside. The address totals are not compared: for the same amount the sources report different counts (over 5,200 in one, 8,680 in another), a sign of perimeters that are not declared. Galaxy, moreover, has not published the list of its addresses: it shared it with exchanges and authorities. The address-by-address comparison, which would close much of the difference, cannot be made from outside. Galaxy calls «Waves» the waves it attributes to the incident, and «footprints», with a letter, the minor groups it recognises by traits their transactions share: by mid-August it counted a few dozen. Footprint E uses the construction of Bitcoin Core, the reference program, and of Sparrow, another widely used wallet: both write the current height in the locktime and signal that the fee can be raised. It is not the first wave's construction. To see what is there with Core and Sparrow's construction, the window from July 30 to August 8 was reread with a criterion written before counting, in four steps: 1. batches: multi-address drains (R1) of at least 50 addresses; 2. profile (R5): coins all later than the firmware and unmoved for at least 30 days, and at least 80% of the addresses with the profile of the drained addresses; 3. follow-up (R6): for each destination, whether by September 25 it is spent together with others; two destinations are linked if the same transaction spends both; 4. discarding services: a link does not count if it comes from a transaction with 50 or more inputs almost all unrelated, the form of a service gathering the deposits of many customers. The results: | measure | value | |---|---| | batches found | 292 transactions, 37,500 addresses, 1,365.54 BTC (a sum close to the groups' total only by chance) | | destinations | 290 different addresses | | destinations with no links to others | 259 addresses | | groups linked by co-spends, with no service in between | 7 groups: 26 destinations, 63.74 BTC | | the batch of 795 addresses of August 2, which Galaxy puts in Footprint E | isolated | | the series of small-change batches between August 1 and 3, with the identical change of 0.0004 BTC | a single owner, according to the co-spends: about 8,570 addresses, 4.64 BTC | Nine destinations in ten stay isolated: it is the form of many independent owners moving the funds of their own dormant addresses to new addresses, often with round amounts. With these rules Footprint E does not separate from the migrations, and it is not forced into shape. If it is part of Galaxy's total, it would explain almost half of the difference. The series of small change, instead, reads clearly: thousands of addresses of a few cents gathered, according to the co-spends, by a single owner. Whether it is someone draining even the low-value keys or a service consolidating, the chain does not say. Co-spending, too, has its limit: it is a hint of common ownership, not a proof. Behind the difference there is also a more general reason: **there are two ways of knowing**. From the keys: one rebuilds the faulty generator, lists the possible seeds, derives their addresses and looks at which were drained. It is the path Perera followed for 1,042 of the 1,195 addresses, and it gives the true answer, regardless of how the drainers behaved. From the behaviour: one reads how the funds move, and always depends on an assumption about who acts. This piece follows only the second path, and on purpose: listing the weak seeds would mean holding the keys of those who still have funds. Where Galaxy attributes and these rules do not, as for Footprint E, the difference probably lies there, although Galaxy has not published its method. ## The cross-checks The flaw goes back to March 2021, and the obvious question is: was it exploited before July 2026? Two cross-checks answer as far as the rules allow. The first rereads the 282,351 blocks written since the firmware's release, with the same rules, in three steps: 1. it counts the **episodes**: consecutive six-block windows in a peak (R2) of drains with the first wave's mark (R4), at 10 sat/vB or more. The threshold keeps out September's widespread program, which pays 1-3 sat/vB. The episodes are 709, 565 small ones (fewer than 30 drains and less than 1 BTC) and 144 larger; 116 of the 144 also have signatures like the first wave's. It is the background noise of a family of programs; 2. it picks the candidates with the collectors (R3) and coherence with the firmware (R5). **None resembles the first wave**: none reaches hundreds of addresses towards a few collectors, and the largest, 45 BTC, goes to 12 different destinations; 3. it profiles one by one the five closest (full R5): only one has the profile of the drained addresses, and it is small, in April 2025, 12 addresses and 5.75 BTC, with the funds ending up at a service. The second-step rule (R8), applied to the same five years, finds 27 one-to-one peaks, none of comparable scale: the largest is worth 3.72 BTC.

Episodes with the first wave's mark (a fee that is an exact multiple of the fixed estimate, at 10 sat/vB or more), by quarter, from the second quarter of 2021 to July 9, 2026: 709 in all, 565 small (fewer than 30 drains and less than 1 BTC) and 144 large; the busiest quarter is the second of 2024, with 172. None resembles the first wave, which alone counts 1,195 drains in one episode and is off the scale. The chart says that with these rules there are no similar episodes, not that there were no attacks. Data: blocks 674,951-957,301 reread with nodsig's artifacts.

This cross-check has a wide blind spot, and it should be stated in full: the rules see only attackers who behave like whoever was behind the first wave. Among others, these stay out: - anyone draining at less than 10 sat/vB, for example with small tests, because the threshold that removes September's program removes them too; - multi-address drains, because in the history only the simple form is sought; - anyone draining a few keys at a time, which produces no peak; - anyone sending the funds to many new addresses instead of a collector, like the first step of the two-step wave; - taproot and p2pk addresses, which the reread does not reconstruct. An attack done differently, before 2026, would not show up here. The second cross-check uses nothing from the reports: neither the construction, nor the profile, nor the dates. It counts, in six-hour windows, the addresses with coins unmoved for over a year that end up in new collectors, and flags the windows above the 99th percentile of two and a half months of blocks. The most anomalous day emerges on its own: July 31 (blocks 960,336-960,479, three consecutive windows), and among the collectors the 7:34 group and the 5:48 group reappear. It does not see the first wave: 1,195 addresses in one window stay below the threshold, which is 5,455. Among the windows above it there are dust consolidations, thousands of addresses of a few satoshis gathered at once: counting addresses, they weigh as much as an attack. It also counts the owners consolidating their own addresses. A revised version removes the dust and takes the threshold from a thousand windows drawn at random over the five years, with rules fixed before looking at the data. For each window of 36 blocks, about six hours, it counts the addresses that send to the same destination, along with at least 19 others, more than 10,000 satoshis of coins unmoved for at least a year. It reads the same tables over the five years and the recent period, and so it sees only drains from a single address: | window | addresses towards shared destinations (number) | rank out of 8,155 windows | same, in BTC | rank | |---|---|---|---|---| | threshold (99th percentile of the drawn windows) | 555 | — | 21.97 | — | | first wave | 1,008 | 53 | 544.68 | 5 | | 7:34 group | 1,040 | 51 | 43.52 | 34 | | 5:48 group | 38 | 914 | 0.63 | 580 | | second step | 0 | — | 0 | — | The first wave and the 7:34 group exceed the threshold; the 5:48 group does not, and the second step, one to one, by construction does not either. The count alone, however, is not specific: over the five years 83 windows exceed the threshold, almost all consolidations of small amounts towards a single destination, with a median of 5 BTC. And counting only coins unmoved for a year loses 187 of the first wave's 1,195 addresses, 181 because their coins were younger. If the value is also considered, the windows anomalous in both measures are three in five years: the first wave, the 7:34 group and one on June 12, 2022. The latter has nothing to do with the incident, and the firmware says so: they are multisig coins born almost all before it (6,466 rows out of 6,496), consolidated at 3 sat/vB. What its destination receives afterwards confirms it, about 15,600 drains in the following 400 blocks: a continuous collection, that is, a service. A rule that looks only at the past, however, would not have discarded it: before that window the destination had received nothing. The combination was chosen after seeing the results, and it remains an indication, not a proof. It says, though, that with nothing from the reports the first wave could have been found, along with a single false alarm in five years. ## The reaction The chain also records the reaction. Here an address is at risk if it has coins created after the firmware, unmoved for at least 30 days, and the key never revealed. In the week from July 31 to August 6 (blocks 960,326-961,333) the at-risk addresses moved were four times the average of the three previous weeks. Looking only at transactions built like Bitcoin Core or Sparrow, that is, with programs other than the one used in the attack, the ratio rises to eight. The control says how much of this is specific: coins created before the firmware, which were not at risk, rise by 2.5 times in the same week.

Addresses with the at-risk profile moved per week, from July 9 to September 24, 2026, divided by the average of the three weeks before the incident (normal = 1), and the same count for coins created before firmware 4.0.0, which were not at risk. In the week from July 31 to August 6 the former rise to 4.07 times normal, the control to 2.50. Counts on a sample of one block in ten; the last, partial week is excluded. Data: blocks read from the node.

The count is made on a sample of one block in ten. Scaled up to the whole chain, it says that in that week between 200,000 and 390,000 at-risk addresses more than normal moved: the upper bound multiplies the sample's excess by ten, the lower bound also removes the general rise measured by the control. The bitcoins are not estimated from the sample, because a few large coins dominate. And how many of those moves were by Coldcard owners, the chain does not say. The second rise, between August 20 and 27, does not come from the incident: at least half of it is dust consolidations, fixed batches of 400 coins towards a few addresses, at rates of about 2 sat/vB. The measure counts addresses, not bitcoins, and so dust weighs as much as a real coin. ## Why the forms change What follows is a reading: the chain shows the forms, not who acts nor why. Side by side, the groups look nothing alike: | | first wave | 5:48 group | 7:34 group | first step | second step | |---|---|---|---|---|---| | when (block time, UTC) | 07/30 01:10 | 07/31 05:48 | 07/31 07:34 | 07/31 12:23 | 08/01 05:48 | | construction | no replacement possible | replacement possible | replacement possible | no replacement possible | no replacement possible | | fee (sat/vB), and times the market median | 30 on the fixed estimate, 29 times | 10 on the transaction size, 10 times | 50 on the transaction size, 49 times | about 200 in 210 transactions out of 296, about 200 times | 10 on the fixed estimate, 10 times | | form | one transaction per address, 4 collectors | many transactions from several addresses, 1 collector | one transaction per address, 1 collector | up to 10 addresses per transaction, no collector | one to one towards p2wsh addresses | | short signatures sought | no (48% at 72 bytes) | not measured | no (about half at 72 bytes) | not measured | no (52% at 72 bytes); yes in September's spends | | median drained per address | 0.27 BTC | 0.010 BTC | 0.010 BTC | 0.014 BTC | — | | where the funds are, at September 25 | unmoved | recovery trust | unmoved | to the second step | coinjoin, THORChain, unmoved | Three explanations, which do not exclude each other. 1. **Several actors, once the flaw becomes known.** The first wave falls on July 30, before the firmware fix: its author probably knew in advance. From the 31st the groups have different constructions, fees and destinations, and one declares itself a recovery. Galaxy, too, counts dozens of footprints; 2. **the same actor changing strategy**, from the first wave to the two steps. What they share is the fixed estimate with integer rates, the construction and signatures without the search for short ones. After four very visible collectors come scattered funds, 2-of-2 addresses and coinjoins, that is, funds harder to follow. But the mark is also used by a widespread program: the same tool does not mean the same hand; 3. **targets running out, and a race.** The first wave takes balances twenty times higher than the other groups; from July 31 the owners move their funds, and the pool shrinks. Paying 200 times the market makes sense only if someone is racing for the same addresses: other attackers, those who wanted to give back, the owners themselves. A single method, repeated for as long as funded addresses were left, would have been plausible as long as only one party knew the flaw. From the moment it is public, arriving first is what counts, and the haste, the changes of program and the race-level fees are consistent with this. Which explanation weighs more, the chain alone does not say. ## Redoing the numbers Every number on this page can be recomputed. The artifacts depend only on the chain: the same blocks yield the same files, byte for byte, and anyone who builds them up to block 957,301 gets the same fingerprints. | artifact | fingerprint | |---|---| | coin index (outpoint-index-v3) | `c5ab330944162f2a70df92d2163210742fa8bb11c66e6211b017cf4058471f70` | | history, fees and co-spends (outpoint-derived-v3) | `4650474c729ce9f011484e50f7f4f3cc8f2fe5e89bb2efeb7abe59686499413e` | | archive of revealed keys (reveal-archive-v4) | `a4b678c52089cbb4a86bf54583947bbc565aab16e855b1ab2e53d7e312b404f7` | | headers (headers-v2) | `6af1fed6c48f59461efefbb0868a2e002fcfb68cb7fd578a10fca2b538cbe5d4` | The queries are nodsig 3.4.0 commands. Where no command is enough, a script of one's own is needed; this investigation's scripts are not public, but the rules that drive them are the ones written above, and they are enough to rewrite them. Rewritten from scratch as a check, on a second reading of the blocks, the same rules bring the first wave back to the satoshi and the second step of the two-step wave to 288 p2wsh arrival addresses and 207.09 BTC. | step | nodsig 3.4.0 command | or | |---|---|---| | profile of an address: first arrival, receipts, spends | `derived history`; for a list `check --file` | for the aggregates, the example `examples/address-set-profile/` | | had the key already appeared before a height? | `check --key`, `archive lookup` | | | co-spends | `derived cospends` | | | fee of a transaction | `derived fee` | | | height of the spent coins | `index lookup` | | | memo of a transaction (data in an OP_RETURN output) | `graph show`, up to July 9 | after that, reading the blocks | | cost of the artifacts | `nodsig report` | | | recent blocks, drains and peaks, follow-up of the funds after July 9, weeks and the reading without the reports | | scripts on the node, with this piece's rules | | fees, ages and types of the drained coins, for the incident's blocks | | the blocks' JSON from the node, which carries fee, size and the spent coins | Run times depend mostly on how the data are read. The table of the five years' drains, 96.8 million rows and 10.9 GB, takes the revised blind reading 4-6 minutes from the USB disk, measured with two programs written independently, if it reads in 16 MB blocks and splits the fields itself. With the generic CSV reader and the default small reads, through a virtual machine's mount, it takes 36 minutes: same numbers, byte for byte. Three precautions are enough: large, sequential reads, in a single pass; a simple reader when the format allows it; a cap on memory. Keeping one window at a time in memory, the reading does not exceed 53 MB. This piece's base stops at July 9, 2026, before the incident, and the following weeks were read from the node. With the base extended to the end of September the profile of the most recently drained addresses, the follow-up of the funds and the memos would also become commands. The recognition of the groups and the transactions' internal details (version, locktime, sequence, signatures), which the artifacts do not keep, would remain block reading. Those details can be taken from any source, even a block explorer, and verified against one's own artifacts: the transaction identifier for its fields, the block header for the signatures. nodsig has the pieces to do it, not yet a command. ## What the chain says What the rules do not reach stays open: where the remaining part of the difference with Galaxy lies, whether before 2026 there were attacks with a different behaviour, how many of that week's moves were by those who had a Coldcard. The chain says what happened to the coins, not who moved them nor why. But it says it to anyone who rereads it, with the same bytes for everyone. It is the difference between a number received and a number verified: the first asks for trust in whoever counted it, the second asks only for a node, some indexes and the time to redo the count. ## References - Praveen Perera, [«Inside Wave 1: Tracing the Attacker's Steps Through the 1,082 BTC Coldcard Drain»](https://praveenperera.com/blog/coldcard-mk3-weak-rng-wave1/), August 12, 2026: the first wave, transaction by transaction. - Galaxy Research, [update thread on the incident](https://x.com/glxyresearch/status/2088252639767085417) and [on Wave 3](https://x.com/glxyresearch/status/2096785347929608296), on X. - Decrypt, [«Coldcard Bitcoin Thefts Slow, But Losses Could Top $150 Million: Galaxy»](https://decrypt.co/375656/coldcard-bitcoin-thefts-slow-losses-top-150-million), August 14, 2026: Galaxy's counts by waves and footprints. - The Crypto Times, [«Galaxy Finds $115M Lost in Coldcard Exploit Across 8,865 Addresses»](https://www.cryptotimes.io/2026/08/24/galaxy-finds-115m-lost-in-coldcard-exploit-across-8865-addresses/), August 24, 2026: Galaxy's count used for the comparison. - CoinDesk, [«Bitcoin cold-wallet attack spreads to 4,500 addresses as losses near $89 million»](https://www.coindesk.com/tech/2026/08/02/bitcoin-cold-wallet-attack-spreads-to-4-500-addresses-as-losses-near-usd89-million), August 1, 2026: Galaxy's first count over three waves. - The Crypto Times, [«52.37 BTC From Coldcard Exploit Moved Into Wyoming Recovery Trust for Victim Return»](https://www.cryptotimes.io/2026/09/22/52-37-btc-from-coldcard-exploit-moved-into-wyoming-recovery-trust-for-victim-return/), September 22, 2026. - TRM Labs, [«The Largest Hardware Wallet Exploit of 2026: Inside the USD 116 Million Coldcard Hack»](https://www.trmlabs.com/resources/blog/the-largest-hardware-wallet-exploit-of-2026-inside-the-usd-116-million-coldcard-hack). - Coinkite, [security advisory on seed generation](https://blog.coinkite.com/coldcard-mk3-seed-generation-warning/) and [Mk3 firmware release history](https://github.com/Coldcard/firmware/blob/master/releases/History-Mk3.md): 4.0.0 of March 17, 2021, 4.2.0 of July 31, 2026. - [nodsig](https://github.com/amenano/nodsig), release `v3.4.0`, and the example [`examples/address-set-profile/`](https://github.com/amenano/nodsig/tree/db08314/examples/address-set-profile) at commit `db08314`.