Five years passed between the first faulty commit and the first sweep.
The long fuse10 events · 1 key
2018-05-22Code
MicroPython gains a software PRNG fallback
+−
The Yasmarang generator lands upstream in MicroPython as a fallback for boards without a hardware RNG. Harmless on its own — it only becomes dangerous once something links against it by accident.
nvk regrets the GPL, two days after Passport is announced
+−
Foundation Devices announces Passport — a competing wallet built on COLDCARD's GPL-licensed code — and two days later nvk publicly regrets having shipped under the GPL. In November the licence changes to MIT plus a Commons Clause, shipping that month in v3.2.0, though the top-level GPL LICENSE file and per-file headers survive until March 2021. Coinkite says the licence change was already planned, and that the rewrite which followed was made to adopt libsecp256k1 rather than to shed the GPL. The record here establishes sequence, not motive.
2021-01-28Code
The guard that checks the wrong thing is written
+−
libngu adds a build-time check intended to make a missing hardware RNG a compile error. It tests #ifndef MICROPY_HW_ENABLE_RNG — whether the macro is defined — instead of what it is defined to. The board config defines it as zero, so the guard is satisfied and the build succeeds.
2021-03-01Code
Wallet generation migrates to libngu
“First pass w/ libNgU” moves crypto onto libngu — built on libsecp256k1, the library Bitcoin Core uses — removing the GPL-licensed libraries and rewriting seed generation. From this commit forward, rng_get() resolves to the software fallback rather than the STM32 hardware RNG.
Every Mk3 seed generated from here until 4.2.0 comes out of a PRNG seeded by an unchanging MCU serial number and timer state. Effective entropy: roughly 40 bits against the 128-bit BIP-39 minimum. Coinkite's own advisories scope the exposure to 4.0.1 and later rather than 4.0.0; 4.0.1 superseded 4.0.0 within weeks.
2021-05Loss report
A Roth IRA buys a Mk3 direct from Coinkite
+−
u/s1ammage purchases a COLDCARD Mk3 from store.coinkite.com for a self-directed Roth IRA held through Solera National Bank, funded via Swan Bitcoin. No BIP-39 passphrase is set. The seed generated that month is already predictable; nobody will know for five years.
2021-07-2713:08:31ZPublic
Coinkite says the hardware RNG is in use
+−
Asked which RNG the device uses four months after v4.0.0, nvk says the STM32 hardware RNG is used and its entropy was tested. The vulnerable build was already using MicroPython's software fallback.
Alex Waltz@raw_avocado·02:27 · 27 Jul 21
@nvk Did you guys ever tested the TRNG on the ATECC608A, if so what did you use?
Newer models begin mixing secure-element entropy at boot. Forty bytes are hashed, but only four digest bytes reach reseed(), replacing a single 32-bit state word. Mk4, Q and Mk5 land at ~2^32 distinguishable streams.
2022-06-06Public
An independent reviewer reads the driver and finds it correct
+−
@PortlandHODL publicly inspects the Mk4's STM32 RNG driver and concludes the implementation is right. It was — the driver was never the bug. The defect sat in the build-time guard that should have failed the build when the board config left that driver unused.
Portland.HODL@PortlandHODL·6 Jun 2022
Hardware isn't the whole story. Software drivers are needed to utilize the true random number generator peripheral. Looking through the source of the COLDCARD MK4 their driver implementation for the STM32 rng is correct.
https://github.com/Coldcard/firmware/blob/master/stm32/COLDCARD_MK4/rng.c
Predates the incident by four years · the file he linked is the driver, which was correct; the defect was in the build-time guard deciding whether it was linked · Open on X ↗
2026-01Loss report
The 2021 seed is restored onto a Mk4
+−
u/s1ammage digs out the paper seed from 2021 and types it into a newer Mk4. The device is fine; the seed was already compromised. They will later, incorrectly, blame this moment as the point of failure.
First-night sweeps7 events · 2 key
2026-07-3001:10:20ZOn-chain
Wave 960183 begins
One sweep delivered less than it paid: a 4,500-sat balance moved for a 3,300-sat fee. A Block engineer later identified the block and holding addresses without attributing them.
2026-07-3001:32:48ZOn-chain
Wave 960185 moves 398.49 BTC
+−
The operation's densest block. It filters out smaller balances and uses a different holding address and vault at the same fee rate.
2026-07-3001:36:08ZOn-chain
Wave 960188 begins
+−
Three and a half minutes later, the largest wave starts with the richest addresses and works downward. The operation's largest individual loss was already in wave 960185.
2026-07-3001:37:21ZOn-chain
Block 960189 — 116.36 BTC across 110 transactions
+−
Among them, tx 2fe075cf…f736 takes five UTXOs totalling 0.78962661 BTC from a Roth IRA wallet.
2026-07-3001:43:00ZOn-chain
Block 960190 — 67.85 BTC across 168 transactions
+−
Wave 960188's queue is working downward: nothing in this block held more than 0.89 BTC.
2026-07-3001:51:26ZOn-chain
Block 960191 — the last sweeps, and the consolidation
+−
The last sweeps confirm with wave 960188's consolidation, leaving some funds at the holding address. The first episode ends 41 minutes after wave 960183 began.
2026-07-3009:15:14ZLoss report
The first loss report of the incident is filed to an abuse database, not a forum
Seven and a half hours after the sweep and four hours before anyone posts on Reddit, an anonymous filer reports approximately 19.96 BTC in five unauthorised transactions from an “air-gapped hardware signing device”. The report never says COLDCARD, which is why no search for the product finds it.
It publishes five amounts totalling 19.95981068 BTC without saying which transaction is which. Each named sweep has exactly one source address, and those five inputs carry those five amounts to the satoshi. The filer reads the destination as a service deposit address on its lifetime volume — 594 BTC across 501 transactions — where this record reads the same volume as the theft itself.
From 01:10:20Z to 01:51:26Z, 1,195 sweeps moved 2,350 UTXOs. Waves 960183 and 960185 began before wave 960188. Total span: 41m 6s.
02The earlier waves match Block's published totals
Waves 960183 and 960185 contain 695 sweeps totalling 488.10957948 BTC, matching Block's earlier-tranche figure. This checks the totals, not the attribution; Block described the link as unconfirmed.
03Minimum swept value varied by wave
Wave 960183 reached 1,200 satoshis; wave 960185 stopped at 0.1082 BTC and wave 960188 at 0.1499 BTC. Waves 960183 and 960185 consolidated in block 960190.
04Observed consolidation fee rates differed by 10.00×
The 1,195 sweeps paid 30.05–30.32 sat/vB, totalling 0.0664 BTC in fees. Consolidations ranged from 3.039 sat/vB in wave 960183 to 30.388 sat/vB elsewhere.
05Every first-episode sweep has the same input-output shape
All 1,195 sweeps move every UTXO from one address to one output, with no change output. The record therefore contains 2,350 UTXOs from 1,195 addresses; neither is a person count.
06Wave 960183 split swept inputs at a value boundary
One collection address received the 104 smallest sweeps, up to 0.02121610 BTC. The other received the 100 largest, from 0.02152167 BTC.
Discovery and response32 events · 5 key
2026-07-3013:19:35ZLoss report
First public loss report on Reddit
A Roth IRA holder reports that the wallet was emptied and links the sweep transaction. The holder later reports that the remaining 0.01 BTC moved.
1.5k
r/Bitcoin· Posted by u/s1ammage
Full panic - one of my wallets was drained
I haven't done anything since creation except sending into the wallet.
Image post — Blue Wallet transaction screen showing the sweep itself: Sent −0.78962661 BTC, July 29 9:37 PM, txid 2fe075cf…f736
2026-07-3015:23:51ZPublic
A Reddit comment names the holding address and vault
+−
A commenter identifies wave 960188's holding address and vault, measures the 0.15 BTC floor, and proposes predictable seeds three hours before the first analysis on X. The archive was captured near posting time; a later edit cannot be ruled out.
1
r/Bitcoin· Posted by u/Hoax__
Comment on “Full panic - one of my wallets was drained”
It doesn't appear to be an isolated theft. The receiving address 'bc1qnk4zh9qcnap2mycp56qjrgza3cc8ylrh8fecp0' has received about 594 BTC (approx $37.8M) from 500 different addresses in a 15 min window (between 01:31-01:56 UTC 30/07/26). Many of the other sending addresses have been dormant for years, similar to your address. All the affected addresses contained more that 0.15 BTC at the time of the transactions.
… Or it could be a cryptographic flaw within the hardware device where the device generates users seed phrases in such a way that an attacker could predict them…
Theft address has consolidated most of the funds in bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r.
Excerpt · the elision drops an alternative supply-chain hypothesis the commenter also offered
2026-07-3017:35:25ZPublic
Kevin Loaec asks his followers to check their balances
+−
Four hours after the Reddit post, the first call for corroboration on X, scoped to the population at risk.
Kevin Loaec 🧙♂️🐟@KLoaec·17:35 · 30 Jul 26
I'm hearing a potential issue with some Coldcard wallets being drained.
I will not FUD, but would like to get at least reports of trusted people.
Can my followers, who own a CC, generated the mnemonic on the CC, and use it as a single sig check their balance and report if it's gone.
Hopefully a nothing burger, but gonna do my job here.
The first response calls it FUD — and links the victim's transaction
+−
Twenty-four minutes after Loaec's call, and eleven minutes before the better-known 18:10 post, nvk gives the same explanation in blunter terms: the reports are FUD, the user loaded a seed from another wallet, and someone is harvesting pre-generated seeds. The transaction he links is the same one — mempool.space/tx/2fe075cf0ec… — and it is the sweep that emptied the victim's wallet, not the attacker's consolidation. Both posts were deleted. This one was recoverable because the Internet Archive captured X's own API response for it in the second it was published.
Kevin Loaec 🧙♂️🐟@KLoaec·17:35 · 30 Jul 26
I'm hearing a potential issue with some Coldcard wallets being drained.
I will not FUD, but would like to get at least reports of trusted people.
Can my followers, who own a CC, generated the mnemonic on the CC, and use it as a single sig check their balance and report if it's
It is FUD, the guy loaded from a different wallet. Mess of a history of events.
someone is collecting the seeds they pre-generated mempool.space/tx/2fe075cf0ec…
DELETED BY AUTHOR · ID 2082888798820532410 · text recovered verbatim from the capture below, which holds X's own API response rather than a rendered page · engagement counts were all zero at capture, taken in the second of posting · the t.co shortlink resolves, via the capture's own entities, to tx 2fe075cf0ec799f3529ed6a28e0a08b45fe1fc9bd93c3f33bdbc42d5bff4f736
Scale disputed eight minutes before the user is blamed
+−
Replying to Loaec, nvk argues the reports cannot be what they look like, on the grounds that a firmware-wide fault would produce far more victims than were being reported. Eight minutes later he posts the seed-error explanation — and accepts a figure of 500 keys while doing so.
Kevin Loaec 🧙♂️🐟@KLoaec·18:00 · 30 Jul 26
@nvk Could be, will keep digging until we figure it out. It's super weird, but also not just one user.
Coinkite's founder attributes the loss to user error
The deleted post attributes the reports to a bad or leaked seed. Its link points to the transaction that emptied the reporting user's address, not a later consolidation. The post survives only in a screenshot; the source note records that limitation.
NVK@nvk·18:10 · 30 Jul 26
There is no need to panic, someone loaded a bad seed into a COLDCARD and/or leaked their seed.
It's part of a wider attack affecting 500 private keys from different wallets.
The attacker is consolidating here:
mempool.space/tx/2fe075cf0ec…
Deleted post · text recovered from a screenshot · linked URL resolves to the reporting user's sweep transaction
2026-07-3018:30:25ZPublic
Rob Hamilton reads the chain and says the word 'entropy'
+−
Twenty minutes after the denial, AnchorWatch's CEO publishes the on-chain shape of the attack. He is the first to name the vault on X; a pseudonymous Reddit commenter had named the holding address and vault three hours earlier.
Rob Hamilton@Rob1Ham·18:30 · 30 Jul 26
I've conducted some preliminary analysis of the ~600 BTC which have moved in a 15 minute period this morning.
What we know:
- 1,324 UTXOs were swept across 500 transactions all within a 3 block window (594.48 BTC).
- From there, 562 BTC was swept again to a new address which has not moved since to: bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r
- The UTXOs that were swept span from 2021 to 2026
100% of the addresses swept were single sig, NONE of the addresses stolen from were taproot.
At a glance, this looks like there was flawed entropy in wallet generation somewhere along the way.
Forty-three minutes after the seed-error post, nvk sets the bar at Coinkite's own inbox: nothing has come in through support or security, so what is circulating is hearsay and Reddit noise. The victim thread he is discounting had already published a txid that resolves on-chain.
ZE
zender ⚔️@zndtoshi·18:49 · 30 Jul 26
@lopp @KLoaec @nvk Any patterns until now? Is it naked single sig only?
An hour and forty-eight minutes after Loaec asked his followers to check their balances, grubles becomes the first person on X to confirm a loss first-hand. Four words, no detail — the detail comes three hours later.
Quoting
Kevin Loaec 🧙♂️🐟@KLoaec·17:35 · 30 Jul 26
I'm hearing a potential issue with some Coldcard wallets being drained.
I will not FUD, but would like to get at least reports of trusted people.
Can my followers, who own a CC, generated the mnemonic on the CC, and use it as a single sig check their balance and report if it's
A post calling loss reports 'internet panhandling' is amplified
+−
An hour and eighteen minutes after the seed-error post, and while victims were still publishing transactions, nvk reposts someone else's dismissal of the reports as attention-seeking. The words are not his — a repost is weaker evidence than anything he wrote himself. It was later deleted.
NVK@nvk·19:28 · 30 Jul 26
RT @SnarkyAlien: Every few months we get a crier claiming he lost Bitcoin in hopes of plebs feeling sorry and donating some for their loss. Internet panhandling.
DELETED BY AUTHOR · ID 2082911187071619195 · the repost itself is recovered from the capture below; the quoted text is @SnarkyAlien's original, live with 6 likes as of the 2 Aug 2026 snapshot
Loaec publishes a hypothesis, and lists what would disprove it
+−
He calls the RNG defect correctly two and a half hours before the advisory. His reasoning about an AI-written script and BIP84 does not survive the chain — legacy and P2SH-wrapped addresses were hit too, just far fewer — but he sets out his own falsifiers, and his warning that partially drained wallets stayed at risk was right.
Kevin Loaec 🧙♂️🐟@KLoaec·20:28 · 30 Jul 26
My current hypothesis for the Coldcard theft.
1- The issue:
- Low entropy RNG, either in a library or secure element/chip itself. Could be a limited batch or a specific firmware.
- Probably affecting the mnemonic, even if the theft is weird/confusing.
- Thief knows about the RNG bug, but not about Bitcoin.
2- The attack
- Attacker asked an AI to craft a script to bruteforce and prepare a sweep.
- AI ONLY TRIED bip84 derivation paths
- AI ONLY TRIED A LIMITED NUMBER OF DEPTH
This is why we only see Segwit being stolen, and sometimes partial wallets instead of full wallets.
If i am correct:
- The funds of partially affected wallets ARE AT RISK or further drain
- The funds of other type of addresses ARE AT RISK when the scan looks for them too.
If I am wrong:
- WHY only bip 84?
- WHY partial sweeps?
Could be some very rare bug happening in very specific cases, but looking at the chain it's hard to guess what it could be. Some weird derivation bug happening only in CC, at bip 84 paths?
32
42
274
52.7K
Show 1 more post
Kevin Loaec 🧙♂️🐟@KLoaec·20:35 · 30 Jul 26
CONCLUSION:
We will see another wave of this exact same attack, for deeper paths and other key types.
DO NOT PANIC as you will have more chance losing your coins that way, but PREPARE TO MOVE to multisig this weekend or when you aren't stressed.
Wicked hosts the first live discussion — 459 posts in the conversation, roughly two hours before any official advisory. No recording or participant list is retrievable through any public endpoint; only the Space ID and the hosting post survive.
Wicked@w_s_bitcoin·20:59 · 30 Jul 26
x.com/i/spaces/1DGLddPgRoQGmSpace card — the post carries no text body. 174 likes · 459 posts in conversation.
The victim posts a full timeline, with the transaction
+−
s1ammage publishes device provenance, dates, the sweeping txid and the drained address — the first victim account anyone could independently verify against the chain. It checks out: address 258 of 1,195 by size.
572
r/Bitcoin· Posted by u/s1ammage
Wallet Drained Timeline
Little background: The setup was IRA custodian is Solera National Bank, exchange at Swan Bitcoin was used as an Investment Trust, purchase 2 dedicated hardware wallets: coldcard mk3 from https://store.coinkite.com May 2021. One for personal stacking (DCA into since 2021), one for this ROTH IRA.
I never setup a 25th Passphrase… REST of the BTC stayed in Swan Exchange.
Coming to January 2026 now, I decided to use these new cards. I dug out the wallet seed (from 2021) phrase paper. Dusted off one of the mk4 … typed in the seed written down from 2021 … Restored my 2021 onto one of the new wallet 2025.
This was the transaction. https://mempool.space/tx/2fe075cf0ec799f3529ed6a28e0a08b45fe1fc9bd93c3f33bdbc42d5bff4f736 My wallet address is (with all transactions, since it's gone now…): bc1qldkfrrlylk4s9sdyns9jkaajuzugl0dv5m8fxj
My key takeaway now never enter the seed phrase into anything. EVER. Even to restore. Always will generate new and use a 25th passphrase.
The widest-reach warning lands an hour before the advisory
+−
James O'Beirne reaches 423,000 views — more than any other actionable warning that night, and 63 minutes ahead of anything official. His scoping is tighter than the eventual advisory in one direction and looser in another: the exposed population turned out to be defined by firmware version rather than purchase year, and Mk4, Q and Mk5 were added the following day.
James O'Beirne@jamesob·21:46 · 30 Jul 26
If you have bitcoin residing under a single key that was generated on a Coldcard Mk3 between 2021-2023, and you
- did not incorporate dice rolls
- do not use a passphrase
- do not use multi-sig
I would advise moving funds as soon as possible.
@Pledditor posts a screenshot, which is the only reason the wording exists at all — the Wayback CDX API has no capture of the post itself, nor of any mirror carrying it. The screenshot also preserves the Kevin Loaec post nvk was replying to, in which Loaec had already put “RNG weakness” and “entropy that isn't fully broken, but just too weak” on the table. Twenty-five minutes later nvk quote-tweeted this post to say “That post is wrong.”
Pledditor@Pledditor·22:03 · 30 Jul 26
Screenshot exhibit — the image below is the recovered evidence. Reproduced because it is the sole surviving record of the deleted post.
Quoted by nvk 25 minutes later as “That post is wrong” — that post is below · Open on X ↗
2026-07-3022:27:16ZLoss report
grubles reports 2.476 BTC lost and posts a return address
+−
The post supplies a claimed loss amount and a return address, not a swept source address or txid. This record cannot independently match the claim to the ledger.
grubles@notgrubles·22:27 · 30 Jul 26
Replying to @VandelayBTC
If the thief has a conscience, they can return my family’s 2.476 BTC to this address:
3M2DTZW9WaXMVYztuJ9s37iQwCzeZTLB27
61
78
514
26K
Return address supplied by the claimant; not a swept source identifier. · Open on X ↗
2026-07-3022:27:35ZPublic
The seed-error post is retracted as wrong
+−
Four hours and seventeen minutes after posting it, nvk disowns his own explanation outright. The post he calls wrong is the 18:10 one, which he had already deleted; this is the first time he says plainly that it was incorrect rather than merely superseded.
Pledditor@Pledditor·22:03 · 30 Jul 26
deleted
One word, quoting the 18:10 post — the screenshot that preserved its text · 368 likes
I don't wrong info now that i have more clarity, i don't want people to be at risk. Blog incoming. That post is wrong.
5
0
68
5K
Verbatim — the sentence is missing a word as posted · Open on X ↗
2026-07-3022:28:53ZPublic
NVK says the deleted post is wrong before the advisory
+−
NVK quote-posts the screenshot, says its content is wrong, and promises a blog update. Coinkite publishes its advisory 21 minutes later.
NVK@nvk·22:28 · 30 Jul 26
I don't want wrong information out now that i have more updates, i don't want people to be at risk. Blog incoming.
That post is wrong.
20
6
104
41.4K
Quote-tweets @Pledditor's screenshot of nvk's own deleted post · Open on X ↗
2026-07-3022:37:02ZPublic
Greg Sanders confirms it independently — thirteen minutes before the advisory
+−
The proof was in the attached image: a recovery run against his own disposable Mk3 on v4.1.3, reporting xpub_match=true and recovery_verified=true. He recovered the device's private root on an ordinary computer without the Coldcard ever revealing its mnemonic, by modelling the fallback generator against an 80,000-state timer range and the keypad shuffle call trace. That trace is where the “he predicted his own seed from button presses” story comes from. Note the caution on Mk4 — the opposite of what Coinkite was about to publish.
instagibbs@theinstagibbs·22:37 · 30 Jul 26
Confirmed. Mk2/3 vuln, I don't think mk4 is but can't be certain
39
90
490
300.2K
Attached image: “Coldcard Mk3 v4.1.3 owned-device RNG recovery proof” · Open on X ↗
2026-07-3022:50:13ZAdvisory
Coinkite publishes the Mk3 advisory
The advisory warns Mk3 users but says Mk4, Q and Mk5 are unaffected. Coinkite retracts that claim the next day.
COLDCARD@COLDCARDwallet·22:50 · 30 Jul 26
COLDCARD Mk3 Security Advisory
If you generated a seed on a Mk3 after firmware 4.0.1, your funds may be at risk.
Mk4, Q and Mk5 are not affected based on our early analysis.
Read the advisory and migrate carefully:
https://blog.coinkite.com/coldcard-mk3-seed-generation-warning/
The initial Mk3-only scope is challenged within minutes
+−
Two minutes after Coinkite's initial advisory excludes Mk4, Q and Mk5, James O'Beirne updates his warning to say Mk2 and Mk4 may also be affected. This records the contemporaneous uncertainty; the post is an urgent analyst warning, not proof of either model's exposure.
James O'Beirne@jamesob·21:46 · 30 Jul 26
If you have bitcoin residing under a single key that was generated on a Coldcard Mk3 between 2021-2023, and you
- did not incorporate dice rolls
- do not use a passphrase
- do not use multi-sig
I would advise moving funds as soon as possible.
This is confirmed, and may also affect mk2/mk4.
I'm updating my advice: if you have coins living under a single key generated by a Coinkite (Coldcard, Q) device with no passphrase, no dice rolls that you bought during or after 2021, I would move funds immediately.
Not a drill.
26
101
470
61.4K
Contemporaneous analyst warning · model scope was not established by this post · Open on X ↗
2026-07-3022:55:04ZLoss report
r/Bitcoin opens a drain megathread
+−
r/Bitcoin opens a megathread for affected and unaffected users to report device model, firmware, dice-roll use, passphrase use and loss details. Reports without checkable identifiers remain unverified.
—
r/Bitcoin· Posted by u/ShortCircuitDisco
Wallet Drain Megathread (Check Your Balances)
Use this thread to report drained wallets, and to report unaffected devices — device model, firmware, dice rolls, passphrase — so the affected population can be narrowed down.
Paraphrased header — the megathread's value is the report collection, quoted claims are cited individually where used
2026-07-3100:03:31ZAdvisory
Block reports an earlier tranche
Block reports 695 additional transactions and 488.10957948 BTC matching its structural fingerprint. The thread later names the addresses tracked here as waves 960183 and 960185, while leaving attribution open.
Clay Garrett@clay_garrett·00:03 · 31 Jul 26
1/ Block's engineering and security team found another set of transactions that could be a part of the Coldcard drain. We're still working to vet these completely, but given the situation, we feel it's important to share early.
6
56
213
27.9K
Show 6 more posts
Clay Garrett@clay_garrett·00:03 · 31 Jul 26
2/ There are 695 earlier transactions with the same full fingerprint that transactions in the known set had. These transactions moved another 488.10957948 BTC. If this is part of the same attack, it’d bring the total to 1,082.58680432 BTC.
6/ Method: We scanned all 888,661 transactions in blocks 960050–960230. Each match in the original wave had these shared properties: version 2, locktime 0, final sequence on every input, one output and inputs from one source address, a P2WPKH destination, one homogeneous supported input type and a 30 sat/vB pre-signing fee estimate.
1
0
23
3.3K
Clay Garrett@clay_garrett·00:03 · 31 Jul 26
7/ Again, the patterns here are strong, but we have not confirmed that these indeed are related to drain. Please reach out if you spot anything that supports/refutes this.
Post 6 describes the seven-property transaction filter. Post 7 says the matches are strong patterns, not a confirmed link to the drain. The addresses reconcile to the satoshi; the attribution remains open.
Clay Garrett@clay_garrett·00:03 · 31 Jul 26
6/ Method: We scanned all 888,661 transactions in blocks 960050–960230. Each match in the original wave had these shared properties: version 2, locktime 0, final sequence on every input, one output and inputs from one source address, a P2WPKH destination, one homogeneous supported input type and a 30 sat/vB pre-signing fee estimate.
7/ Again, the patterns here are strong, but we have not confirmed that these indeed are related to drain. Please reach out if you spot anything that supports/refutes this.
A competitor links the bug to the GPL-dependency removal
+−
Foundation Devices CTO Zach Herbert — a competitor — says the entropy bug was introduced inside the same 120-file commit that removed the old GPL dependencies. The guard itself was written in libngu two months earlier; that commit is where COLDCARD began resolving against it. Coinkite says the change was made to adopt libsecp256k1 and that licensing was irrelevant.
Zach Herbert@zherbert·00:54 · 31 Jul 26
the entropy bug was introduced inside the same 120-file commit that removed the old GPL code dependencies.
648
154.4K
Excerpt from a longer thread quote-tweeting nvk's July 2020 post on regretting the GPL · Open on X ↗
2026-07-3101:49:46ZAdvisory
Block publishes the root cause
Block identifies a preprocessor guard testing definedness instead of value, which exposed MicroPython's Yasmarang PRNG fallback. Its analysis extends the affected range to Mk4, Q and Mk5 through the truncated reseed.
Max Guise@max_guise·01:49 · 31 Jul 26
1/ Earlier today, our Bitcoin engineering and security teams at Block began investigating reports of non-Bitkey wallets being drained. To proactively protect our customers, we began investigating immediately. Here's what we found 🧵
57
393
1,430
722.6K
Show 9 more posts
Max Guise@max_guise·01:50 · 31 Jul 26
2/ First, no Block products including @Bitkey are affected. But we want to protect everyone who has bitcoin in self-custody, so we continued to investigate.
4
10
328
72.1K
Max Guise@max_guise·01:52 · 31 Jul 26
@Bitkey 3/ Initially, only single sig wallets were affected, in a remote drain over an hour. The attack is likely ongoing and more wallets will be drained – including those with 25th word passphrases that are too weak, and multisig setups with weak key generation for more than one key.
6
18
237
75.5K
Max Guise@max_guise·01:52 · 31 Jul 26
@Bitkey 4/ We discovered two vulnerabilities, affecting non-Block products including Coldcard Mk2, Mk3, Mk4, Q, and Mk5 at varying levels described below and in the document linked at the end of this thread.
3
41
289
94.4K
Max Guise@max_guise·01:52 · 31 Jul 26
@Bitkey 5/ The Mk2 and Mk3 firmware intends to use the hardware random number generator to generate keys. A mistake in a macro defined in the firmware leads to using only a known UID, timer state and call history - wallet generation is deterministic, not random.
12
28
311
85.1K
Max Guise@max_guise·01:52 · 31 Jul 26
@Bitkey 6/ Mk4, Q, and Mk5 attempt to compensate at boot with secure-element input, but the reseed truncates it to 32 bits, sharply limiting the secret entropy it contributes – far below what wallets should have.
10
35
293
93.2K
Max Guise@max_guise·01:52 · 31 Jul 26
@Bitkey 7/ If you exported a seed generated in a vulnerable Coldcard and later moved it to another wallet, then that same insecure seed is still affected.
3
22
246
63.6K
Max Guise@max_guise·01:53 · 31 Jul 26
@Bitkey 8/ We disclosed these findings to Coinkite as soon as we could, and their team acknowledged. We are disclosing now to protect people who self-custody their bitcoin – we don’t want anyone to lose their money.
@Bitkey@clay_garrett@BEN0WHERE@obnauticus@jm 10/ P.S. personally I recommend that anyone affected move funds as soon as they can safely do so - to a new wallet that does not use affected hardware. If you can, talk to a knowledgeable friend through your plan, and then execute it asap. Move deliberately, but don’t wait.
The third post predicts continued draining, weak-passphrase exposure, and multisig setups where more than one key was generated on an affected device.
Max Guise@max_guise·01:52 · 31 Jul 26
3/ Initially, only single sig wallets were affected, in a remote drain over an hour. The attack is likely ongoing and more wallets will be drained – including those with 25th word passphrases that are too weak, and multisig setups with weak key generation for more than one key.
A researcher says an AI model found the bug from the public repository
+−
An outside researcher says an AI model located the defect in the public repository. The post follows Block's root-cause thread by 33 minutes and does not state how long the search took.
Stephen DeLorme@StephenDeLorme·02:22 · 31 Jul 26
I was able to use Opus 5 to sniff out the ColdCard vulnerability after cloning the firmware repo. All our software is insecure, and we're painfully figuring that out in realtime with AI agents.
A second self-identified victim opens a thread about legal options. They explain they deliberately skipped a passphrase because forgetting it was the risk they were guarding against.
49
r/Bitcoin· Posted by u/whatusernaym
Has anyone reached out to lawyers/authorities? Let's organize
I've also been affected by the Coldcard mk3 fiasco (fml). I know it's early still but has anyone reached out to the authorities or lawyers, particularly for a class action? I'm pretty certain Coinkite will not make things right…
— and in a comment 77 minutes later: There are no solutions, only tradeoffs. The benefit of the passphrase is increased security but the downside is that if you ever forget it, you're shit outta luck. That's why I intentionally didn't use it. But jokes on me because I'm now still shit outta luck.
No address or txid provided — loss not independently verifiable
2026-07-3104:09:48ZPublic
The community contradicts the advisory on Mk4
+−
The first widely-shared post arguing that Mk4, Q and Mk5 are also exposed — that cracking them is merely expensive rather than impossible. Coinkite's guidance still said they were unaffected.
Quit@0xQuit·04:09 · 31 Jul 26
…there's evidence that Mk4, Q, and Mk5 could also be affected, though would require much more compute.
Rising replace-by-fee activity is read as multiple attackers arriving. Nobody produces an address to back it, and the reading is contested within hours — including by Kevin Loaec, who posts an all-caps warning about multiple attackers and then describes it as one escalating attack an hour later.
Marty Bent@MartyBent·04:43 · 31 Jul 26
RBF'd transactions are on the rise. Assume the Coldcard attack has been widely discovered by many attackers.
1,182 native SegWit, 7 P2SH-wrapped and 6 legacy addresses appear in the first episode.
Later sweeps and response69 events · 15 key
2026-07-3104:54:28ZOn-chain
Later sweeps begin in block 960345
The wave moves 45.9 BTC from 1,126 addresses into one holding address. Earlier scans ended before these blocks and filtered for a different fee rate. This record found the wave from its fee arithmetic; a later public report supplied the source claim.
2026-07-3105:20:23ZPublic
An early summary preserves superseded figures
+−
Onchain Lens repeats a 25-minute, 594 BTC, Mk3-only summary. The first-night chain window was 41 minutes, Block had already reported an earlier 488 BTC tranche, and Coinkite later expanded its affected-model guidance.
Onchain Lens@OnchainLens·05:20 · 31 Jul 26
⚠️ $38M stolen from Coldcard wallets.
An attacker exploited a flaw in Coldcard's key generation to steal 594 $BTC (~$38M) from around 500 single-signature wallets in a 25-minute sweep.
The vulnerability affected wallet seeds generated on Coldcard Mk3 devices running firmware 4.0.1 or later. Coinkite says Mk4, Q, and Mk5 are not affected based on its early analysis.
The attacker consolidated 562 $BTC into a single address, which has not moved.
A rival CTO calls 73 bits survivable — and predicts a second wave anyway
+−
Ledger's chief technology officer does not dispute the Mk4/Q/Mk5 figure; he says brute-forcing that space is not economically worthwhile. His warning is about what sits underneath it: room for optimisation, and device IDs that are not random. He also predicts a larger second wave now that the defect is public.
Charles Guillemet@P3b7_·06:38 · 31 Jul 26
If you generated your seed on a Coldcard, just move your funds elsewhere, asap.
Considering how the funds are swept, it's unlikely to be DPRK. We'll probably see a second, bigger wave of drains, especially now that everything is public.
And the 73 bits of "security" (on mk4+) look good enough. Brute forcing the full space is not economically relevant.
However, there is a large room for optimization. And I don't even talk about the device IDs that are anything but random.
Coinkite puts numbers on it — roughly 40 bits for Mk3, roughly 72 for Mk4, Q and Mk5 — credits Block and LLFOURN, and concedes the review failure directly: “A few weeks ago, we used one of the best available AI models to review our code for security issues, and it did not find this bug or anything serious.”
COLDCARD@COLDCARDwallet·06:46 · 31 Jul 26
The first post was the advisory and what users should do.
This second post has the technical details: what actually went wrong, why our reviews missed it, the impact across Mk3/Mk4/Q/Mk5, and what we changed.
https://blog.coinkite.com/entropy-technical-backgrounder/
( current evaluating Mk3 firmware release )
Rival vendors say they are unaffected, and explain why
+−
Rival vendors publish “not affected” notices giving the same reason: they mix several independent sources of randomness, so one weak input cannot collapse the result. BitBox puts it plainly — “If you combine good randomness with bad randomness, the result is still good randomness.” Trezor is the one that spells out the part affected users most need to hear, and it is the opposite of reassuring: moving a COLDCARD-generated seed onto a different vendor's device does not make that seed any less guessable.
Trezor@Trezor·07:16 · 31 Jul 26
Trezor users: your funds are safe.
The recent Coldcard issue is limited to their own custom firmware and how some of their devices generated randomness. Trezor does not share that code.
We have always mixed multiple independent sources of randomness together (device hardware + host + secure elements on newer models).
We are truly sorry for everyone who has lost bitcoin.
Stay safe.
92
224
1,549
164.1K
Excerpt · a closing line linking Trezor's entropy guide is omitted · Open on X ↗
2026-07-3108:20:19ZPublic
A second Twitter Space
+−
A second Space, 114 posts in the conversation. As with the first, the audio is gone.
genXbtc@without_rulers·08:20 · 31 Jul 26
x.com/i/spaces/1nxnRRMDRyVxOSpace card — no text body. 13 likes · 114 posts in conversation.
'The ColdCard attack is ongoing' — a victim watching it happen
+−
Seven minutes after the last of wave 960345 confirms, a holder tries to move old coins he was keeping for a friend. His own transaction is still unconfirmed; the friend's seeds, when he restores them, are empty. The only first-hand account of the drain witnessed in progress rather than discovered afterwards.
Chad Wick@iSchmiegle·08:43 · 31 Jul 26
The ColdCard attack is ongoing.
I just pulled up some Uncle Tom coins I was holding for my buddy from a long time ago. TXN UNCONFIRMED!
I raced around trying to restore his seeds but they too are gone. :-(
A Bitcointalk claimant names the pooled vault, not their transaction
+−
ColdcardVictim says almost 1.8 BTC was lost and publishes bc1qq85v…fcu9r. The chain identifies it as an already-tracked vault funded by a single 562.01962301 BTC consolidation; third-party dust sent since brings its balance to 562.02023175 BTC. The post does not identify which source transaction or address, if any, belonged to the claimant, and no signed proof followed.
Re: Large-scale Coldcard compromise (600 BTC stolen so far)#36
The address I'm writing about is bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r.
It was almost 1.8 BTC that I had spent years putting aside, little by little.
2026-07-3109:22:57ZOn-chain
Wave 960345 consolidates in block 960377
+−
The holding address consolidates 1,212 outputs into one vault. Twenty-five of the wave's sweeps moved outputs worth less than the fee that moved them; the smallest moved 305 sats at a 5,500-sat fee.
2026-07-3109:40:47ZLoss report
A claimant report anchors wave 960345
+−
An hour later, the poster supplies the address where he says the funds went. The report anchors the wave independently of fee-pattern inference; the reported 03:34 time is 07:34 UTC, when 964 of 1,216 sweeps confirmed in block 960363.
Chad Wick@iSchmiegle·09:40 · 31 Jul 26
Replying to @iSchmiegle
bc1qsjrf5ze5tmulz7y2x4pc7qaex2a35sanp3rqlx
Here's the address. Date: 2026-07-31 03:34
Small payments begin arriving at two publicly named attacker addresses — wave 960188's holding address and its vault. Five confirm on 31 July; three carry OP_RETURN messages.
2026-07-3109:53:02ZAdvisory
Coinkite reverses course on an Mk3 patch
+−
After the changelog said no Mk3 update was planned, COLDCARD says it is working on one and evaluating whether it can be released without bricking devices. The public reply precedes the changelog deletion by three hours and the signed 4.2.0 build by almost four.
KI
kiawtzin@kiawtzin·07:52 · 31 Jul 26
hey @nvk am I wrong to believe this is the shittiest thing @coinkite can do? Besides pushing your customers to buy you another newer overprized gadget. What could be the reason to purposefully leave thousands of mk3s vulnerable? Why dont they deserve to be fixed?
@kiawtzin @nvk @Coinkite Sorry, that's incorrect. We are working on a mk3 and evaluating if safe to release without bricking https://blog.coinkite.com/entropy-technical-backgrounder/
Coinkite expands its guidance after the first advisory said Mk4, Q and Mk5 were not affected.
COLDCARD@COLDCARDwallet·11:37 · 31 Jul 26
🚨URGENT COLDCARD SECURITY UPDATE
Read carefully before acting.
👉Mk3 seed generated on 4.0.1+ without ≥50 private, independent dice rolls: begin a careful migration now.
👉Mk4/Mk5 <5.6.0 or Q <1.5.0Q: update first, generate a new seed, then migrate.
https://blog.coinkite.com/entropy-technical-backgrounder/
No amount, address or txid provided — not independently verifiable · Open on X ↗
2026-07-3113:03:55ZFix
A line disappears from the changelog: 'We are not planning to update Mk3 firmware'
+−
Coinkite's second reversal in 36 hours, and the one recorded in git rather than on X. Having said the deprecated Mk3 would not be patched, the sentence is deleted from the ChangeLog — 23 minutes before a signed Mk3 build exists.
2026-07-3113:19:43ZPublic
'More attackers are currently draining wallets'
+−
Loaec provides no address or transaction. Wave 960345 had ended four hours earlier, moving 45.9 BTC into an unmonitored holding address; a victim had named it that morning.
Kevin Loaec 🧙♂️🐟@KLoaec·13:19 · 31 Jul 26
PSA: I AM GETTING REPORTS OF NEW SWEEPS. MORE ATTACKERS ARE CURRENTLY DRAINING WALLETS.
GET YOUR COINS OFF COLDCARD NOW (if MK3) OR SOON (if Mk4, 5, Q)
Galaxy Research maps the flow independently — and the numbers agree
+−
The first institutional analysis, mapping the same fingerprint Block published. Their figures agree with this page's derivation: the same 41-minute window and blocks, the same balances for three vaults and one holding address to the published precision, the same conclusion from the 30 sat/vB overpay — “an automated tool spending keys it already held, not owners moving funds.” Their gross total, 1,082.65 BTC, matches what the victims here lost including fees, again at the published precision. The one divergence is an address count of 1,196 against 1,195 here — a counting-basis difference, not a missing victim.
Galaxy Research@glxyresearch·13:23 · 31 Jul 26
We mapped the flow of funds for the Coldcard vulnerability based on the pattern identified by engineers at Block and shared by @clay_garrett
1,196 addresses drained in full for 1,082.65 BTC (~$70.2M) between 01:10:20 and 01:51:26 UTC on Jul 30 — a 41-minute window, blocks 960,183-960,191. That preceded the hardware-wallet vendor's public advisory by ~30 hours.
Signature: every sweep paid an identical hardcoded 30.0 sat/vB — a 30-75x overpay vs the 0.4-1.0 sat/vB median that week — and left no change output. That looks like an automated tool spending keys it already held, not owners moving funds. Victims: 1,183 native segwit (BIP-84), 7 BIP-49, 6 BIP-44 — consistent with multi-path key scanning.
Proceeds consolidated within minutes and have NOT moved since:
- bc1qq85v2c9...cu9r — 562.02 BTC
- bc1qx76cae2...fhe3 — 398.48 BTC
- bc1q8jy96fe...tp3q — 89.62 BTC
- bc1qnk4zh9q...fecp0 — 32.45 BTC (unmoved)
A Wizardsardine engineer argues the priority is reaching exposed users before further sweeps, not attribution.
darosior@darosior·13:37 · 31 Jul 26
In all likelihood, there is still a ton of funds left to drain, and many unaware users.
The absolute priority should be to reach as many users as possible with a clear set of instructions to move funds in urgency, to minimize the number of persons losing their life savings in the coming week.
Lopp says Coinkite purges customer records after 120 days
+−
A later COLDCARD reply supplies a Coinkite Store notice that qualifies this wording: it says old personal-record fields are blanked while the recipient's email address is preserved “for now” so they can log in. The screenshot does not state a 120-day trigger, and Coinkite's later outreach post says only that it contacted every address it could reach.
Jameson Lopp@lopp·13:46 · 31 Jul 26
Fun double-edged sword: Coinkite purges all their customer records after 120 days to protect against data breaches.
Which means they are unable to reach out to customers who bought vulnerable coldcards over the past 5 years to warn them of this vulnerability. 🫠
0.175 BTC, and a request for a mental-health response
+−
The poster reports 0.175 BTC lost from an Mk3 but supplies no address or txid, so this record cannot independently match the claim.
Sᴀᴛs & Sɪʟᴠᴇʀ⚡@SatsAndSilver·14:28 · 31 Jul 26
Replying to @hodlonaut
@hodlonaut Unbelievable! I haven't even seen an apology!
They should be hiring a mental health crisis team to reach out to affected users before someone who lost it all does something terrible & irreversible.🙏
Prayers to all affected, they even got me too .175 on mk3 GONE!
DMs open 2all
4
43
1.6K
Amount only; no independently checkable identifier. · Open on X ↗
2026-07-3114:57:07ZPublic
'Devastated'
+−
Twenty hours and forty-six minutes after telling people not to panic, and an hour after shipping the Mk3 patch, the tone has changed completely.
NVK@nvk·14:57 · 31 Jul 26
Replying to @BTC_Elementary
devastated, but my focus right now is on helping ppl rotate keys.
About 90 minutes after the Mk3 patch shipped, s1ammage says the wallet's remaining 0.01 BTC was swept. No source address or transaction is supplied, so the report remains unmatched and is not counted in the ledger.
—
r/Bitcoin· Posted by u/s1ammage
Comment on “Wallet Drained Timeline”
WARNING: They are still running sweeps… just lost the last 0.01 just now.
I was too deflated to care about it.
I did make sure to move another wallet away from the affected cold card though (which is the rest of my stack).
First-hand but not chain-verifiable — no tracked sweep took from the reported address on 31 July
2026-07-3115:37:51ZPublic
A new risk surface: rescue transactions can be hijacked in flight
+−
Hamilton warns that multisig setups signable by compromised COLDCARDs alone face a second trap: broadcasting a rescue reveals the script, and an attacker holding the weak keys can replace-by-fee the transaction to an address of their own. Peter Todd endorsed the out-of-band mitigation sixteen minutes later, adding that address reuse forfeits it. The MARA Foundation's own post about its Slipstream service, three minutes after Hamilton's, was later deleted — the second documented deletion in this record.
Rob Hamilton@Rob1Ham·15:37 · 31 Jul 26
PSA for those who used Cold Card MK3/MK4/MK5/Q in a multi signature wallet where the compromised Cold Cards alone can sign to move funds:
If you did not roll dice/use a passphrase, your funds may be at risk!
An attacker may be able to take your transaction(s) once broadcasted, and use the compromised private keys to bump the fee and pay the attackers address.
In order to avoid this, you can use a service like @MARA Slipstream supported by the @MARAFoundation_ to do an out of band bitcoin transaction.
This mitigates the risk as the funds should be confirmed on chain before an attack can see your publicly broadcasted transaction.
Link below.
NVK accepts responsibility and repeats the seed-migration warning
+−
NVK says Coinkite “fell short” and takes full responsibility for the firmware bug. He says the hotfix protects only newly generated seeds, tells users with an older affected seed to create a new one and move funds, and promises a technical postmortem plus cooperation with affected users, investigators and law enforcement. The article also says Coinkite does not store customer information; later first-party posts qualify that wording by describing store and newsletter email outreach.
NVK@nvk·15:42 · 31 Jul 26
To all Coinkite users and the entire Bitcoin community,
First-party X Article · claims and commitments are scoped to NVK's statement · Open on X ↗
2026-07-3116:54:38ZFix
Edge-channel hotfixes ship
+−
COLDCARD publishes separate Edge-channel fixes: 6.6.0X for Mk4/Mk5 and 6.6.0QX for Q. The migration instruction stays the same: updating prevents new weak seeds but does not repair an old one, so users must generate a new seed and move funds.
COLDCARD@COLDCARDwallet·16:54 · 31 Jul 26
Replying to @COLDCARDwallet
COLDCARD EDGE UPDATE
Edge hotfixes are now public:
• Mk4/Mk5: 6.6.0X
• Q: 6.6.0QX
Seed generated on older Edge firmware without ≥50 private, independent dice rolls? Update first, create a new seed, then migrate. Updating alone does not repair it.
https://blog.coinkite.com/entropy-technical-backgrounder/
Jonathan Goodman — a fitness-business author with a large following — reports $1.6 million drained, and dates it 29 July: the sweep ran late on the 29th in North American time, which is how victim-local dates and block-UTC dates ended up a day apart across the coverage. He has published no transaction or address, so the loss cannot be matched against the ledger. A later Reddit post gives the amount as 18.25 BTC and an eight-minute window. Counted here as a claim, not a verified loss.
Jonathan Goodman 🇨🇦@itscoachgoodman·17:32 · 31 Jul 26
I just got robbed.
$1.6 million dollars in Bitcoin was drained from my account on July 29th in the @COLDCARDwallet hack.
How's your day going?
44
13
211
24.5K
No transaction or address published — loss not independently verifiable against the chain · Open on X ↗
2026-07-3117:42:45ZPublic
The investigation moves off-chain
Block reports that the source-address queries used a paid account at a blockchain-data provider. It says the provider supplied matching logs and relevant records were shared with authorities. This page cannot verify those off-chain claims.
Clay Garrett@clay_garrett·17:42 · 31 Jul 26
1/ During our investigation of the Coldcard drain yesterday, we identified an unusual pattern in the sweeps. That pattern led us to a hypothesis that has since been confirmed: the operator used a paid account at a well-known blockchain-services provider to query the source addresses and perform other related activity during the sweeps.
2/ We contacted the provider directly. Their internal logs matched the suspected workflow with extraordinary specificity, including the number, timing and sequence of requests. The provider was supplying its standard services in response to requests that did not reveal their broader purpose. We have seen no evidence that the provider knowingly participated in or facilitated the suspected theft.
3
7
370
24.7K
Clay Garrett@clay_garrett·17:42 · 31 Jul 26
3/ We are sharing the relevant information with the appropriate authorities. We will provide further updates when doing so will not interfere with the investigation.
12
8
501
21.3K
Opening post of a three-post thread · later posts recovered through ThreadReader and checked against X · Open on X ↗
2026-07-3117:52:34ZPublic
The faulty generator is attributed upstream
+−
Asked about the RNG, nvk places it with MicroPython rather than Coinkite. The Yasmarang fallback is indeed upstream code, landed in 2018; what is Coinkite's is the firmware that linked against it.
A wallet emptied to zero, reported with a photograph
+−
A holder on vacation, whose father had been shown how to access the COLDCARD, posts that everything is gone — with a photograph of the wallet's history showing thirteen debits emptying it in two batches that morning. The photograph is the evidence: its two timestamps are blocks 960359 and 960367 at UTC-4. Of its thirteen amounts, the seven non-round ones each match exactly one transaction; the other six are round numbers with nineteen look-alikes in the same block, so the report sits unresolved until he posts the thirteen destination addresses himself seven hours later.
I instructed my father how to access my ColdCard wallet while I'm on vacation.
Everything is gone.
If you want to contribute to my anti-suicide fund, the address is bc1qk3e5x9fxwzkgycajh04p890pnxhvl6szjel2k3
Fuck you @COLDCARDwallet @nvk
The plainest statement of the position nvk had argued against a day earlier: a firmware fault, and affected users must generate a new seed and move their funds.
NVK@nvk·21:27 · 31 Jul 26
Replying to @JimAndrews77
Correct, firmware bug. But you must generate a new seed and move the funds
An Mk3 owner reports a loss but supplies no amount, address or transaction.
Ted@PMonkeyBTC·22:36 · 31 Jul 26
I had a mk3. All my kids Bitcoin is gone.
58
17
274
27K
No amount, address or txid provided — not independently verifiable · Open on X ↗
2026-08-0101:37:11ZLoss report
“There is one layer of trust you cannot audit”
+−
The poster reports a material loss and distinguishes it from a Bitcoin protocol or self-custody failure. No amount, address or transaction is supplied.
Oliver L. Velez ⚡️ Bitcoin Intelligence@olvelez007·01:37 · 1 Aug 26
I followed every accepted rule of Bitcoin self-custody.
I still lost a material amount of Bitcoin.
The protocol didn't fail. Self-custody didn't fail.
There is one layer of trust you cannot audit.
https://x.com/i/article/2083364449499410432
42
27
206
29.6K
No amount, address or txid provided — not independently verifiable · Open on X ↗
2026-08-0102:15:57ZLoss report
The thirteen-transaction claimant narrows later wallet activity
+−
In an earlier reply, Bill Fowler identifies the drained device as an Mk3. He then explains that three later deposits into the address published with his loss post were his own migration of remaining funds from one of his two COLDCARD wallets, where he says he used a passphrase, not a recovery from the attacker. No source transaction is identified, so this is claimant scope and device provenance rather than a new chain seed.
OC
Ocean’s Lawyer #BlIP-110@stack_toshi·02:03 · 1 Aug 26
@teslafanboi_67 @Bill_Fowler_ @COLDCARDwallet @nvk He’s already got 3 deposits to that address almost totaling what he claims was lost. Could be from his txs, but if he lost it and is now getting it back, that would be cool
The seven-figure claimant gives an amount and an eight-minute window
+−
Jonathan Goodman's Reddit follow-up specifies 18.25 BTC across three Mk3 devices and an eight-minute window on 29 July. No transaction or address is published. The local sweep record has no exact one-to-three-movement match, gross or net, even when restricted to one wave and an eight-minute span, so the claim remains untraced.
r/Bitcoin· Posted by u/itsgood-man
(Coldcard) Lost 18.25 BTC
Had all my BTC on 3 devices. All MK3’s. All got drained over 8 minutes on July 29th.
Provisional · claimant report only · no published transaction or address and no exact chain match
2026-08-0104:06:57ZLoss report
A claimant publishes 13 wave 960359 destination addresses
+−
@Bill_Fowler_ publishes 13 destination addresses matching the 13 debits in the earlier screenshot. The 13 output amounts plus 13 fees reconcile to 0.32631901 BTC. The addresses enter this record on the claimant's report; shared transaction traits do not identify an operator.
Mallard Beakman ₿⚡🥕@Bill_Fowler_·04:06 · 1 Aug 26
Replying to @KevinKelbie
I think there might be multiple attackers. My non-passphrase ColdCard was drained into multiple addresses not involved with any other transactions.
bc1q53dfk923tp8vjfzsu9ktufsmpf79xwl9pxn9rn bc1q8g94gg3kdy0epkrhgy9sxjpfwpcf2m3mr7wscz bc1q8lz69a2zzkh9z6jrk2g600nec682nq7u80x7v6 bc1q9uktsu2ujvhz7k469mwk35u5wmqsunnyztmchy bc1qdk4md3wd8mp82wfyhlzv3qhlgv70vv8yvukj70 bc1qk7wx4dcng7u0e4rwv9dmcvuea3ywpc5y4tp7da bc1qn7vtzkcc2m2pm60q096ex26j5v30dytrhfj4gy bc1qnan6mss4s2nhsrdeauyrt5pke8fmszw6kuc8py bc1qnc3hygnhvxf5qdfvqm35rzvmm7shdsfan6lg4t bc1qnu9pfldt7w405p258yvxqglrvlha463kdjn6qg bc1qrn94chxyf069em794qhxgryuu9rmwr3vc5jgnz bc1qt388s2eg2k2298pmtwcda86khlm25r2ayyjzr8 bc1qwl67v2zn95yy364pgxnw9r6jrhxpdskktuhq6c
Asked whether both funding transactions into the published holding address were his, @sanjuanhodl says the second was not. The correction is negative scope: it does not identify his source transaction, but it prevents the two funding paths from being attributed to one claimant.
KE
Kevin Kelbie@KevinKelbie·04:25 · 1 Aug 26
@sanjuanhodl @sanjuanhodl do you know if all of these are yours? did they do two separate transactions? or is that a different victim.
Negative attribution only · no claimant source input or transaction is supplied · Open on X ↗
2026-08-0112:11:05ZLoss report
Wave 960518 includes a second-hand Mk4 seed claim
A poster relays an acquaintance's Mk4 duress-wallet claim. Sixteen sweeps moved 0.33203236 BTC and share several transaction traits with earlier waves; the seed provenance is not independently verified.
Tomer Strolight@TomerStrolight·12:11 · 1 Aug 26
An acquaintance of mine intentionally left a small amount of bitcoin in a ColdCard MK4 RNG created seed phrase (that was originally a "duress" wallet) to see when it might get swept. Last night it got swept to bc1qzm5pauxyv7t7vqstzpumqcn066wfjsmev34mf3.
So at this point any RNG generated seedphrase on any ColdCard product is under active attack. Move quickly if you're exposed.
38
73
351
43.7K
Second-hand · no original address or transaction supplied · Open on X ↗
2026-08-0112:39:17ZLoss report
A Mk3 owner names all three of their swept addresses
+−
“All three UTXOs (0.06327422 BTC) were swept in one unauthorised transaction”, and the transaction named debits exactly that from exactly three addresses. Reported to Police Scotland.
The filer reasons from the fee — 201 sat/vB against the first night's 30 — to a second actor brute-forcing the keyspace after disclosure. The arithmetic is right. The inference is theirs: a fee rate is a setting rather than a build trait, and this record separates the two precisely because an operator who turns the fee down is still the same operator.
The post lists seven lines but five unique addresses. Four were already tracked; the fifth anchors wave 960352: 93 sweeps and 30.18 BTC. The printed addresses held 1,069.03 BTC, 89.62 BTC below Galaxy's stated total, roughly the omitted wave 960183 vault.
Galaxy Research@glxyresearch·14:30 · 1 Aug 26
Total under attacker control: 1,158.6571 BTC (~$75.1M). We are monitoring all 7 addresses on every block.
We will post if we see any funds flow out of these 7 addresses:
bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r
bc1qx76cae2706qd5q576feh7xq8rfcsjpf2htfhe3
bc1qx76cae2706qd5q576feh7xq8rfcsjpf2htfhe3
bc1qtfrwa4j6rmj9rsgspv6a0yjumkg39js2numu75
bc1qnk4zh9qcnap2mycp56qjrgza3cc8ylrh8fecp0
bc1qmd5m5ktv7m5ffujxv4248fxv36myvdx79n8jp6
bc1qmd5m5ktv7m5ffujxv4248fxv36myvdx79n8jp6
1
0
0
31
Seven lines, five distinct addresses — two are duplicated, and the stated total needs one the post does not list · Open on X ↗
2026-08-0116:31:35ZLoss report
The first claim anyone makes on wave 960185
A German filer reports a Mk3 wallet emptied at “approximately 03:32 local German time” and gives a police case number, 3229-0706-4949. Both transactions named are single-input; the two addresses hold 0.82727392 BTC between them.
Until this filing, wave 960185 — 491 sweeps — rested entirely on an address Block published while saying in the same post that it had not confirmed the link to the drain. Nobody had said the coins were theirs.
The post shows a holding address after its balance moved onward. Its sweep fee matches the witness-count size table used elsewhere in the record.
The next transaction matches 292 other holding addresses moving into separate P2WSH vaults in the same four blocks. Those matches expand the tracked wave to 207.73 BTC, swept from 1,918 victim addresses into 294 holding addresses, without implying a common owner.
Image post · explorer view of the holding address and onward transaction
2026-08-0119:38:00ZPublic
Galaxy independently maps wave 960395
+−
Galaxy reports 207.7294 BTC and 293 holding addresses, matching the topology derived from a victim screenshot — and their BTC is this record’s vault total to the satoshi. The boundary differs by one transaction each way: this record includes an earlier seven-address sweep their window opens too late to see, and they include a one-input sweep this record never reached. Excluding both, the two agree on 299 sweeps, 1,911 victim addresses and 2,349 UTXOs. Theirs is unidentified — their total being equal to the vaults says its coins never reached one, which leaves nothing to search on. Galaxy publishes no addresses for this wave, so the post corroborates its scale and shape, not the exact set.
Galaxy Research@glxyresearch·19:38 · 1 Aug 26
🚨 A 3rd wave in what we suspect are hacks of Coldcard-generated addresses has been identified in which 207.7294 BTC has been drained.
Our estimated observed size of the Coldcard hack is now 1,367.05 BTC (~$88.6m) across 4,585 addresses.
…Even if we can assume Waves 1 and 2 are the same attacker, Wave 3 should not be assumed to be the same operator. It differs from both earlier waves on every behavioural axis we can measure: it abandons the shared collector for one destination per victim, it holds in P2WSH rather than P2WPKH, it batches an average of 6.37 victims into each sweep where wave 1 took exactly one, and it scans only the default derivation path.
It may be the same actor with rebuilt tooling — the anti-clustering design is exactly the evolution one would predict after waves 1 and 2 were enumerated — or it may be a second actor working the same vulnerable key space independently, which the published disclosures make entirely feasible. The chain does not distinguish these, nor can we.
5K
Excerpt · the thread also carries a disclaimer that the analysis is derived solely from block data, with no compute used to test whether the identified addresses were in fact low-entropy · Open on X ↗
2026-08-0121:19:17ZLoss report
The first claim on wave 960352, and it describes the address the fee arithmetic found
A filer reports a seed generated on a Mk3 with no BIP-39 passphrase, found already empty when imported into BlueWallet, and one transaction taking twelve outputs from four addresses — 0.10435085 BTC, the figure they state. Complaint filed with IC3.
Their description of where it went — about 30.18 BTC across 93 unspent outputs — is the address this page had derived from the fee arithmetic before Galaxy listed it, and before any person named it.
The reported transaction is a five-input, one-output sweep in block 960469. It took 19,421,249 sats including its fee; the holding address received 19,344,649 sats and later moved into a P2WSH vault in wave 960395's 10 sat/vB co-batch. The report establishes a new root claim for that path without changing the wave's population.
u/rkavanau· commented in r/Bitcoin
Transaction: 2d616a0d18e7185690dd5dedcc754807ad723724def0662c7e216346a6e94143
All 5 of my addresses were emptied yesterday.
Accepted · claimant-published txid verified in local block 960469 · parent submission was moderator-removed
2026-08-0200:03:40ZPublic
Galaxy says about 600 suspected holding addresses went to investigators
+−
Galaxy says victim reports helped it derive further patterns and that it sent roughly 600 suspected holding addresses to federal, compliance and cyber investigators. The post does not publish the address set, so the number records Galaxy's report rather than an independently reproducible population.
Galaxy Research@glxyresearch·00:03 · 2 Aug 26
The Coldcard exploit is ONGOING. Move Coldcard single-sig funds to safe locations immediately!
We have reported ~600 addresses we believe to be hackers holding funds stolen from Coldcard-generated weak entropy addresses to federal investigators, industry compliance firms, and cross-industry cyber investigators.
Thank you to all the victims with the courage to share their addresses or relevant txids. Your act of sharing has helped us immensely to develop onchain patterns and thereby identify new victims and attacker addresses to report to authorities.
If you continue to share with us in replies or DM @intangiblecoins, we will continue to add your addresses to our investigation.
20
87
408
71.4K
Galaxy's unpublished investigation set · not substituted for this project's claimant-rooted ledger · Open on X ↗
2026-08-0202:29:22ZAdvisory
Coinkite says every reachable address has been emailed
+−
Coinkite says messages have gone out in batches since Friday to every address it could reach through its store and newsletter systems. This is a statement about reachable email addresses, not proof that every affected owner was identified or contacted.
COLDCARD@COLDCARDwallet·02:29 · 2 Aug 26
It’s been challenging, but we have now emailed every address we could reach through our store and newsletter systems.
The emails have been going out in batches since Friday. If you received one, we want to confirm that it is legitimately from Coinkite.
A claimant publishes 2 addresses already in the tracked cluster
+−
@ShariaHODL publishes a holding address and its onward P2WSH address. Both were already included by pattern, and the reported timestamps match the corresponding chain transactions. The report links the addresses to a claimant; it does not independently prove ownership.
Shariabitcoin@ShariaHODL·04:05 · 2 Aug 26
Replying to @KevinKelbie
@KevinKelbie my MK3 was swiped clean during my transfer to another wallet.
Date: 2026-07-31 13:05:24
Funds drained to wallet address: bc1qm6vmrr5xngp3ct6gqfarvvdtlr7gewwqxgteqh
Later to: bc1qn3uy9j26m79vghed2uddr89l344xa5efnn4d0rxhz4q3xxlyxryqq595ld
Date: 2026-08-01 02:27:01
2
2
31
Both addresses were previously included by pattern; this report supplies claimant-published identifiers. · Open on X ↗
2026-08-0204:12:28ZPublic
A pre-sweep targeting theory is corrected to an inscription airdrop
+−
Four 294-sat transfers in April and May really did reach addresses later swept in waves 960185 and 960188. Eighteen minutes after attributing them to the thief as advance target marking, however, LightningSats withdrew that explanation and said further research pointed to an Ordinals airdrop. Each transfer descends from a reveal inscription carrying the sameX@agiBRC-20 payload. That supports the correction; it does not identify the sender or link the transfers to the July sweeper.
Correcting
LightningSats@LightningSats·03:53 · 2 Aug 26
I just noticed that the Coldcard thief started dusting the largest wallets they were going to attack back in late April / early May.
Alex Thorn corrects his earlier statement that every post-March-2021 COLDCARD address would eventually be drained, narrowing the warning to single-signature setups with no dice rolls, no passphrase and firmware from 17 March 2021 onward. The revised wording is still his risk assessment, not proof that every wallet matching it will be drained.
Alex Thorn@intangiblecoins·05:03 · 2 Aug 26
Replying to @intangiblecoins
i should have said "every coldcard single-sig setup with no dice rolls and no passphrase and firmware from march 17, 2021 or later, will be drained" but i recommend moving off coldcard completely unless you imported a high entropy seed from elsewhere, or used many dice rolls
4
1
16
2K
Analyst correction · revised exposure warning, not a measured affected-wallet population · Open on X ↗
2026-08-0206:52:02ZLoss report
An anonymous abuse report names 23 inputs of the wave 960668 sweep
Filed 2h48m after the sweep, and the first public account of it. The report names the transaction, the block, the destination and 23 input addresses with an amount for each. All 23 are inputs to that transaction for the exact satoshi claimed, totalling 5.13591373 BTC — 7.9% of what the sweep took. They say the seed was generated on an Mk3.
The filer is anonymous, so unlike the named reports this carries no one's reputation; what it carries is arithmetic that can be checked against the block, and does check out. It is the only public report naming any address in this wave, and the 23 are the only addresses of the 795 that anyone has claimed.
Marius says a friend's Mk2 was drained into the already-tracked transaction d72e2d8e…c89a4. The chain has 902 total inputs from 795 source addresses. Because the friend's input set is not identified, the post's “890 other inputs” breakdown cannot be verified. This records a device-scope lead without creating a new victim seed or changing the wave total.
Marius@mariusoffchain·07:15 · 2 Aug 26
ColdCard attack continues
Without access to his wallet, a friend got his Mk2 drained this morning
His funds were consolidated with 890 other inputs of 64 BTC (< $ 4 million) to this address:
bc1q0rvn88w08j75k4h48lf9fvhan7unjp7vjf5q6m
63
69
415
94K
Second-hand · exact claimant input, seed provenance and firmware are not supplied · Open on X ↗
2026-08-0209:15:21ZLoss report
A report that establishes a sweep and claims none of it
+−
The filer labels the holding address and the vault as the scammer's first and second addresses and names the sweep, but says only that BTC was stolen via the vulnerability. The sweep draws on four addresses and nothing in the report says which was theirs, so it reaches all four as a report and claims none of them.
Its causal claim — that the defect struck during transaction signing — is not what the advisories describe. The seed was predictable at generation.
COLDCARD says the change was required to move to libsecp256k1, the library Bitcoin Core uses, and that licensing was irrelevant. The record here is sequence only: the guard was written in libngu in January 2021, and the March 2021 commit that adopted libngu also removed the GPL-licensed libraries. Sequence does not establish motive.
Asked to comment on
GE
ge gels@gegelsmr4·00:48 · 2 Aug 26
NVK used open-source code from Trezor to build Coldcard.
Then Foundation forked Coldcard’s code to create Passport.
NVK got mad and switched Coldcard to a Commons Clause license so competitors could no longer use their code.
But because he couldn’t simply relicense the GPL code he took from Trezor, he had to remove and replace it.
And during that rewrite, he introduced the RNG flaw.
That flaw stayed unnoticed for 5 years because nobody had an economic incentive to spend weeks auditing code they were no longer allowed to build on.
His greed caused his downfall.
Do I get this right?
The immediate parent only asks COLDCARD to comment on this post.
@PsiloX @gegelsmr4 @nvk COLDCARD had to make this change to move to libsec256k1, the license change is irrelevant this. libsec256k1 is the standard library used by bitcoin core.
1
0
159
Vendor position · the misspelling of libsecp256k1 is preserved from the post · Open on X ↗
2026-08-0211:00:30ZPublic
An engineer lists the failures beyond the guard
+−
Responding to Dustin Dettmer's commit-history article, Ryan Dale reads the defect as compounding failures: the existence check masked the fallback; the fallback shared the hardware function's signature, so the authors could not tell which symbol was resolving; no test exercised the hardware RNG; nothing at runtime verified the good RNG was in use or failed closed if it was not; and a security-critical swap warranted a far smaller, more targeted change than the one it shipped in — 120 files. He also cautions against reading terse commit messages as a smoking gun.
bitcoin++ Insider Edition@btcinsider__·16:35 · 1 Aug 26
JUST IN: Dustin Dettmer (@dusty_daemon) digs into the COLDCARD firmware commit history to uncover what actually happened in the code to introduce one of the worst bugs for self-custody in recent bitcoin history
https://open.substack.com/pub/btcpp/p/when-randombytes-runs-but-doesnt?r=2jfs7&utm_campaign=post&utm_medium=web
This was an important bit not in the article:
‘’’
#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif
‘’’
That ifndef is a defined check not a truth check. Made people think the rng was enabled. This was a big factor.
commit msg length is not a metric anyone tracks. Multi-line commit messages are fairly recent. I would encourage readers to not get too wrapped up in “works” being too short being some smoking gun (seeing it in some comments). Its very common for example to have multiple commits in a single pr that has a bigger pr message or comes with a bigger message out of band.
The bigger misses here: an existence check instead of a truth check masked the fallback, a software fallback was available at all and with the same function signature meaning that the authors didnt know which symbol was being resolved, there should have been tests that the hardware was being lit up. lack of assertions or checks at runtime that the good rng was used or code to fail closed if it wasnt (iow the code should have failed to produce a value if the trng wasnt being used). And then yeah there should have been a much smaller and more targetted change to swap out the rng invocation since its security critical.
9
2
71
26.7K
Independent engineer commentary · responds to the Dettmer commit-history article · Open on X ↗
2026-08-0211:21:42ZLoss report
A victim links the 902-input wave 960668 sweep
Erik links the transaction that opened wave 960668. It took 64.90947964 BTC including its fee from 795 source addresses and paid 64.90373764 BTC to one P2WPKH holding address. The report establishes the sweep; it does not reveal which source address belonged to Erik.
Erik@eriklocalhost·11:21 · 2 Aug 26
just had a testing device swept this morning. it's a coldcard mk3 i used for misc testing. 9k sats on it. native segwit. gone.
https://mempool.space/tx/d72e2d8e3096440c48fdd4ed0cc56a7e784d215970413210e0b2af38528c89a4
Accepted · claimant-linked txid verified in local block 960668 · exact claimant input not published · Open on X ↗
2026-08-0211:53:16ZPublic
An investigator reports one depositor identity obtained
+−
Galaxy research lead Alex Thorn says a casino operator identified the depositor for one traced flow, but the funds had already left and police-report information was still needed. Neither the identity nor the transaction path is published in this post, so the report is not public attribution.
Alex Thorn@intangiblecoins·11:53 · 2 Aug 26
Replying to @intangiblecoins
thanks to @korraflow for working with me and identifying their depositor’s identity. it looks like funds left their platform before they were able to freeze them but they do have ID of the depositor. when the victim’s police report info arrives, they should be able to ID this one
2
6
118
9.8K
Investigator report · no name or public transaction path is supplied · Open on X ↗
2026-08-0217:24:04ZPublic
Galaxy explains how reports generated its later wave patterns
+−
Galaxy credits Block engineers with the first-wave pattern and says victim-supplied addresses and transaction IDs enabled its second- and third-wave patterns. This is useful provenance for Galaxy's method, but the organisation does not publish the full input or address set needed to reproduce those classifications.
Galaxy Research@glxyresearch·17:24 · 2 Aug 26
We are still monitoring and expanding our investigation into the Coldcard weak-entropy hacks.
The pattern that identified Wave 1 was identified by engineers at @blocks, but we identified the patterns of Waves 2 and 3 thanks specifically to victims coming forward. While we know it’s hard, sharing your story, addresses, and TXIDs helps everyone, not just you.
Please keep sharing your victim addresses and TXIDs with @intangiblecoins. We do not need your personal identifying information to assist you.
We continue to share our findings with US authorities, SEAL, crypto exchanges, and cyber investigators.
We will publish a substantive update about the state of our investigation in a few hours.
15
41
285
44.8K
First-party account of Galaxy's methodology · underlying address set remains unpublished · Open on X ↗
2026-08-0218:04:24ZAdvisory
Coinkite says shipments halted and affected inventory was destroyed
+−
COLDCARD says shipments stopped when the vulnerability was confirmed, all remaining units at its facilities with affected firmware were destroyed, and customers whose orders had already shipped were emailed migration steps. It also says SATSCARD, OPENDIME and TAPSIGNER use different codebases and are unaffected. These are first-party claims; the post does not publish shipment, contact or inventory records.
COLDCARD@COLDCARDwallet·18:04 · 2 Aug 26
🚨 UPDATE: We halted COLDCARD shipments as soon as we confirmed the vulnerability. All remaining units at our facilities with affected firmware installed were destroyed.
Some orders had already shipped. We contacted those customers directly by email with the advisory and migration steps.
SATSCARD, OPENDIME and TAPSIGNER use different codebases and are not affected.
Right now, our full focus is helping affected users migrate safely.
354
97
580
132.3K
First-party response statement · underlying shipment, contact and inventory records are not published · Open on X ↗
2026-08-0220:44:30ZPublic
NVK steps down from the OpenSats board
+−
OpenSats says the resignation is effective immediately and the organisation will operate with eight board members until a replacement is made. The statement gives no reason, so the timing is recorded without asserting that the RNG incident caused the resignation.
OpenSats@OpenSats·20:44 · 2 Aug 26
NVK is stepping down from the OpenSats board, effective immediately. OpenSats will continue to operate with an 8 person board until a replacement is made.
40
79
604
21.7K
Primary organisational statement · no cause is stated · Open on X ↗
2026-08-0221:13:10ZLoss report
An unmatched two-word-passphrase loss is relayed
+−
BTC Sessions relays an unnamed report of an Mk3 seed with a two-word passphrase being drained. It supplies no claimant, transaction, source address, firmware, seed date, passphrase construction or precise timezone. The scope lead remains unmatched and does not enter the victim ledger.
BTC Sessions 😎@BTCsessions·21:13 · 2 Aug 26
IMPORTANT UPDATE: We just had our first confirmed loss of a Mk3 + 2 Word Passphrase.
Drained at 2pm Aug 2nd Australia Time - Roughly 17hrs ago.
135
208
1,035
124.2K
Second-hand and unmatched · 'Australia Time' is not a precise timezone · Open on X ↗
2026-08-0223:00:19ZAdvisory
Coinkite tells affected users to preserve their devices
+−
In its Sunday update, Coinkite says an affected device may become important if funds are recovered and asks users not to dispose of it. The article repeats that patched firmware protects new seeds but cannot repair an old vulnerable seed, says legal counsel will coordinate with law enforcement where warranted, restates the shipment and inventory response, and promises a later technical postmortem.
COLDCARD@COLDCARDwallet·23:00 · 2 Aug 26
Update, Sunday.
First-party X Article · summary separates response claims from independently verified facts · Open on X ↗
2026-08-0302:15:47ZLoss report
The first claim on wave 960345, five days after it was swept
Three single-input sweeps in block 960363, debiting 0.32531190 BTC — the figure the filing states, fee included. The filer dates the seed to about December 2021 and gives an affected firmware range of 4.0.1 to 4.1.9.
@iSchmiegle had named this wave's holding address on the day. Nobody had attributed a swept address to themselves until now.
The most detailed device provenance anyone publishes
A Mk3 bought new from Coinkite on 2 February 2022, order KT72AW4D-CDTM6YDL, running firmware 4.1.3, with the seed attributed to the MicroPython Yasmarang generator. The filer names their own address and one sweep, 0.68172885 BTC.
The report opens by saying the write-up was produced by an LLM from the filer's transaction id, so its aggregate figures are the filer's and not this record's. What is checkable checks out: the address, the amount, and the 491 deposits totalling 398.48587857 BTC into the collector.
A report opens a wave nobody had seen, paying to Taproot
Three transactions and one destination, filed as “my transactions from the cold card hack”. The destination is P2TR — no other wave in this record pays to Taproot — and it sits in blocks past the last one any other wave touches.
Everything paying into it is changeless and single-output, and the fee is priced from the same invented per-input constants as the tool waves — 68, 91 and 148 vbytes by script type — on a base of 53 vbytes instead of 42. A 43-byte Taproot output is what re-deriving that table would give, but the base does not follow the destination: scanning for it finds the same 53 paying ordinary P2WPKH addresses, where 42 would have been exact. It is a constant of this build, and the agreement with a Taproot output size is a coincidence. Against that: every sweep signals RBF, and not one signature carries the 33-byte R the tool waves leave in about half of theirs. Whether that is different software or the same software with signature grinding turned on is not something this settles.
A filing whose own total counts thirty-three other people's coins
+−
The filer names one swept address and asks for the vault to be tagged. Two of the three addresses in the body are mistyped, a digit 1 for a lowercase l, and are corrected here against the transactions themselves.
Its third transaction is left out of the record. That one is a wave 960395 sweep co-spending 34 inputs from 34 distinct addresses, and the 0.54969966 BTC the filing totals is the sum of all three transactions' outputs — so it counts 33 other people's coins as this filer's loss. The two wave 960185 transactions stand on their own.
The only claim that accounts for a whole sweep's input side
The filer lists their victim addresses, the intermediary and “the final and actual address of my funds” under those headings. The sweep they name has exactly two inputs, from exactly those two addresses: 4.53915589 BTC.
Every other claim in the record either names a subset of a sweep's inputs or claims the whole input side without listing it. This one closes a sweep completely. The same account had filed the same event the day before with only the attacker's side, so it is entered once.
08At the snapshot, no tracked onward spend was found
1,432.45888972 BTC remained across 316 of 613 tracked destination addresses. After the last tracked consolidation, 64 further sweeps and 26 dust payments arrived.
09This episode contains a first-episode match and a single-trait divergence
1,322 tracked sweeps confirmed in this episode. Waves 960345 and 960359 agree with the first-episode group on every mutually observable grouping trait. Shared traits do not identify software or a person. Wave 960352 differs from the first-episode group on size table: two tables (first episode: primary only). The same fingerprint group also includes 960518. Separating-trait sample count: 38.
10Wave 960395 has a different transaction fingerprint
300 tracked sweeps confirmed in this episode. Wave 960395 differs from the first-episode group on nLockTime: 0 and a block height (first episode: always 0); size table: two tables (first episode: primary only). No other wave here shares the full observed trait combination.
11Wave 960518 differs from the first-episode group on one observed trait
16 tracked sweeps confirmed in this episode. Wave 960518 differs from the first-episode group on size table: two tables (first episode: primary only). The same fingerprint group also includes 960352. Separating-trait sample count: 1.
12Wave 960668 has a different transaction fingerprint
1 tracked sweeps confirmed in this episode. Wave 960668 differs from the first-episode group on nLockTime: a block height (first episode: always 0); input types per sweep: mixed within a sweep (first episode: one type throughout); fee priced from: no size table (first episode: an exact size table); signature R: ground — no 33-byte R (first episode: not ground). No other wave here shares the full observed trait combination.
13Wave 960737 has a different transaction fingerprint
62 tracked sweeps confirmed in this episode. Wave 960737 differs from the first-episode group on destination type: P2TR (first episode: P2WPKH); signature R: ground — no 33-byte R (first episode: not ground). No other wave here shares the full observed trait combination.
