Primary-analysis register
Original analyses are listed with what each source states, what has been independently checked, and what remains an assumption.
No code. Written to be actionable.
This page distinguishes original analysis from reporting that restates it. Inclusion records provenance and does not endorse a source's assumptions or conclusions.
The source list includes both categories. The entries below identify the original source for a technical, chain or attribution claim and state its evidentiary limit.
An entry is listed here when it introduced something to the public record that no earlier source had: a reading of the firmware or a binary, a chain derivation, a candidate-space model, a reproduction, or an attribution finding. Restatement of another source's work belongs on the source list instead, however widely it was read. Each entry carries the publication date recorded for it in the source registry, which for a mutable repository README is when the work was first published rather than when the held copy was taken.
The candidate-space numbers in this register differ.
Coinkite gives approximately 72 bits for Mk4-class devices and LLFOURN
2^72.3, while Talip reports roughly 52 to 63 bits if RTC
behaviour is problematic and roughly 75 to 88 bits if it is not, and Block
publishes a ≤2^32 scenario conditional on the attacker
knowing the device identifier and timing terms. The estimates apply
different assumptions about what a remote attacker knows at the moment of
generation. None is presented here as a measured population-wide search
cost. Each assumption is written out beside its number on the
attack-cost page, and the estimates
should not be combined without carrying those assumptions with them.
Block engineering, with anonymous collaborators
evidence →The technical disclosure
30 Jul 2026
Identified the migration commit, showed that the Mk4-class reseed carries at most 32 bits into one libngu state word, and published lower candidate-space scenarios. Bitcoin Optech reports that anonymous researchers participated and that disclosure was coordinated with Coinkite.
Verified against the report and source repositories.
The candidate-space figures are scenarios with stated attacker-knowledge assumptions, not per-device measurements.
3z
evidence →Mk3 binary reversal and bounded synthetic proof of concept
31 Jul 2026
Reports reproducible builds of Mk3 4.1.9 and 4.2.0, compares the resolved RNG symbols in both binaries, and models the vulnerable path with fixed synthetic register inputs. The repository says it contains no enumeration, wallet-recovery or fund-targeting capability.
Reported independent binary analysis; the README is captured for revision tracking.
This archive has not independently reproduced the builds or endorsed the author's candidate-state calculation. The synthetic proof establishes determinism for its inputs, not a measured remote-search cost for a wallet population.
Kelbie
evidence →A chain-derived and rapidly updated postmortem
31 Jul 2026
Publishes frozen chain data, explicit rules for deriving collectors and waves, source recovery notes and reconciliation checks. The project distinguishes victim-named evidence, publisher attribution and its own pattern matches.
Reported independent chain analysis; its mutable README is captured for revision tracking.
The chain can verify transactions and amounts. Wave grouping, common-control attribution, tool fingerprints and counterfactual claims remain the author's derivations and may change as new reports appear.
Álvaro P.
evidence →Reproducible firmware and chain investigation
31 Jul 2026
Reports independent checks of the fix commits, a chain reconstruction from a public consolidation point, and compiled vulnerable and patched firmware symbol comparisons. The repository separates completed evidence from planned synthetic and regtest demonstrations.
Reported independent reproduction; the public README is captured for revision tracking.
The repository has not been audited in full by this archive. Deeper files contain public transaction identifiers, so only the address-free README is mirrored publicly here.
Rob Hamilton, AnchorWatch
evidence →On-chain forensics, and the front-running warning
30 Jul 2026, 18:30 UTC
Reported 1,324 UTXOs across 500 transactions, approximately 594.48 BTC and a later 562 BTC consolidation. The transactions occupy four block heights, not the "3 block window" in the post. Hamilton separately described the first-spend script-reveal risk for threshold wallets in a captured migration PSA.
Reported primary analysis, with transaction counts and block span independently checked.
The post labels the entropy attribution preliminary. The chain establishes movements, not the COLDCARD cause by itself.
Clay Garrett and Block engineering
evidence →The preliminary earlier-wave scan
31 Jul 2026, 00:03 UTC
Reported 695 earlier transactions with the same stated fingerprint as the known wave: 204 sweeps in block 960,183 and 491 in block 960,185, with 488.10957948 BTC reaching three first collectors. The thread describes a scan of 888,661 transactions and lists the matching properties.
Reported primary chain analysis; counts and amounts reconciled against the pinned chain-derived dataset.
Block explicitly said it had not confirmed that the earlier waves were related to the drain. The shared fingerprint and arithmetic do not establish common control or cause by themselves.
LLFOURN
evidence →The attack-cost model
31 Jul 2026, 00:41 UTC
Published a model using about 2^20 MCU identifiers, 80,000 timing states and 16 button-press variants. This gives about 2^40.3 for Mk3 and 2^72.3 for Mk4-class devices. The source does not decompose the 16 variants further. A follow-up said clock assumptions might reduce the latter by 10 to 14 bits, and another reply described a 2^32 lower scenario when UID, button-press variation and clock behaviour are known.
Reported model; arithmetic checked against the stated inputs.
The 2^20 UID range and practical timing distribution have not been independently measured here.
Kevin Loaec
evidence →An early hypothesis from the observed sweep pattern
30 Jul 2026, 20:28 UTC
Before the full technical account was public, Loaec proposed a low-entropy generator as the cause and pointed to BIP84-only searching, limited derivation depth and partial sweeps. The post presented AI-assisted script generation and the operator's limited Bitcoin knowledge as a hypothesis, not a demonstrated attribution.
Reported early analysis; the low-entropy direction was later confirmed.
The derivation-pattern observations do not establish that the operator used AI or identify who discovered the defect.
Gregory Sanders (instagibbs)
evidence →Independent public confirmation
30 Jul 2026, 22:37 UTC
Published the statement: "Confirmed. Mk2/3 vuln, I don't think mk4 is but can't be certain." A later captured post says it took about one hour and 50 minutes from deciding to investigate to an on-device proof on Mk3.
Reported confirmation.
The follow-up identifies Mk3 and the full investigation-to-proof interval. Neither post identifies firmware, method, candidate inputs, brute-force runtime or scripts. The elapsed interval is not an attack benchmark.
Praveen Perera
evidence →Independent recovery against the known stolen set
31 Jul 2026, 01:01 UTC
Reported scanning index-zero addresses against the known first-wave address set and recovering two private keys associated with approximately 34 BTC. Perera reported that the run took about five minutes and less than US$5 of GPU time.
Reported independent reproduction.
The code, candidate inputs and recovered keys are not public. The run targeted known stolen addresses and does not measure discovery of unknown still-funded wallets.
Galaxy Research
evidence →The wider flow-of-funds mapping
31 Jul 2026, 13:23 UTC
Published a wider attributed set from 01:10:20 to 01:51:26 UTC across blocks 960,183 to 960,191, a 1,082.65 BTC gross total and four consolidation holdings. This is the set the funds page reconciles transaction by transaction. Galaxy has since revised the total upward over a wider scope, recorded as a separate entry below.
Reported attribution; transaction stages and totals independently reconciled.
Galaxy does not publish its address-counting method. The chain does not establish common control or cause by itself.
Galaxy Research
evidence →The third-wave revision, and the method limit stated with it
1 Aug 2026, 18:38 UTC
Identified a third sweep wave of 207.7294 BTC and revised the estimated observed size of the incident to 1,367.05 BTC, given as approximately US$88.6m, across 4,585 addresses. The same thread reports 1,366.3865 BTC under attacker control with every endpoint attacker address fully unspent, and states that the vulnerable firmware shipped on 17 March 2021 around block 674,951 with no identified coin created before it. What that boundary means for published version ranges is kept on the firmware page. Galaxy sets out its own method limit in the same thread, which bounds every figure in it.
Reported attributed estimate; not reconciled transaction by transaction here.
Galaxy states that the work derives solely from Bitcoin block data and the unspent-output set, that it has not used compute to test whether the addresses it identifies as possible victims were generated with low entropy, and that the analysis should not be treated as complete or definitive. Its scope is wider than the 30 and 31 July sets reconciled on the funds page, and includes a third wave that is not in the pinned dataset held here. The revised total and this site's reconciliation are not alternative measurements of one set and should not be merged.
Clay Garrett, Block
evidence →The attribution finding
31 Jul 2026, 17:42 UTC
Reported that the operator queried the source addresses through a paid account at a blockchain-services provider during the sweeps, and that the provider's logs matched the suspected workflow "with extraordinary specificity, including the number, timing and sequence of requests".
Reported by Block; not independently verifiable from public data.
The provider remains unnamed at its request. Block says it found no evidence that the provider knowingly participated.
Talip (@otaliptus)
evidence →Independent technical analysis
1 Aug 2026, 01:32 UTC
Published a separate, deliberately tentative Mk4 model. It assumes a remote attacker does not know the UID, estimates about 20 to 21 bits from the wafer-coordinate word, narrows the practical SysTick positions, and makes the unresolved RTC term visible. The post reports roughly 52 to 63 bits if RTC behaviour is problematic and roughly 75 to 88 bits if it is not. The author labels the work brainstorming and lists assumptions that may be wrong. Profile.
Unverified working hypothesis.
The author calls it brainstorming, says details may be wrong and credits GPT-5.6 Pro with document checking. It is retained as commentary, not a settled estimate.
Kevin Loaec, Wizardsardine
evidence →The post-mortem and the derived-material argument
1 Aug 2026
Reconstructs the flaw at length and argues its reach goes past seed generation: on affected devices, features that draw on the same generator are reported broken even where the seed itself was imported or created with dice. The post opens with configuration-specific guidance for Liana, Miniscript and multisig users before turning to the incident. A companion post enumerates the features in an attached graphic that did not render in the held capture.
Reported independent analysis; the mutable post is captured for revision tracking.
Wizardsardine sells Liana, a competing wallet product, and the first section is written as guidance to its own users. The authors describe the post as written quickly under stress and invite corrections. The feature-exposure claims are their reading until checked against source, and nothing in the post has been reproduced here.
Dustin Dettmer
evidence →The commit-history reading of how the defect entered
1 Aug 2026
Traces the firmware commit history behind the disabled hardware generator: a commit whose entire message is "runs" sets MICROPY_HW_ENABLE_RNG to zero next to a duplicate symbol definition that would not otherwise have compiled, and the overridden functions turn out not to be the ones seed generation reaches. Published on bitcoin++ Insider Edition and announced there.
Reported independent source reading; the commit-level claims are checkable against the pinned repository clones held here.
The account of what the original author intended, and of the frustration inferred from it, is the writer's reading of commit messages and diffs rather than established fact. This archive has not rechecked every commit cited.
Milk Sad researchers
evidence →Contextual weak-key precedent
publication date not established here
A separate weak-key incident with a public disclosure and an attempt to account for affected funds. It is included as context on the precedent page, not as evidence about COLDCARD.
Verified contextual source.
Different generator, affected population and disclosure process.
The first held capture records a short confirmation for Mk2/Mk3 and uncertainty about Mk4. The follow-up identifies an on-device Mk3 proof and says the path from deciding to investigate to that proof took about one hour and 50 minutes. It does not split that interval into analysis, implementation and search time.
The two statements still do not publish enough detail to reconstruct the test conditions or method, and do not establish a blind remote-search cost. The attack-cost page keeps those assumptions separate.
Community trackers
Two community trackers publish views of the attributed transaction set. They are independent of this archive. Their figures and methodology can change, and entering an address into any third-party site discloses that query to the operator and network intermediaries.
- COLDCARD funds flow monitor · https://coldcard-watch.vercel.app/
The tracker expanded on 1 Aug from the first 1,195-address episode to two episodes totalling 2,321 addresses and 1,128.4717 BTC. It includes a browser-local address checker and follows spends from the consolidation addresses hop by hop. It labels the first episode 29 July without stating a timezone; the corresponding on-chain window begins 30 July at 01:10 UTC. Operator anonymous; figures cross-check against Galaxy's published map for the first episode. - COLDCARD hack tracker · https://coldcard-hack-tracker.vercel.app/
Second, independent tracker of the same four holding addresses. States the accounting precision the reporting rounded: 1,082.65 BTC drained, 1,082.57 BTC arrived, the difference paid to miners as fees. Cites Galaxy, Coinkite and Block. The page is client-rendered. The empty shell from the first capture is preserved as a capture correction, followed by complete rendered captures. The operator rebuilt the page on 2 August 2026 around a five-wave model, which renamed the section heading this capture previously keyed on. The guard string moved from that heading to "Watched holdings"; "Holding 1" and "Movement feed" are retained because they appear only after the client-side data resolves, so an unrendered shell still fails the check rather than entering the record.
Registered posts
Registered social posts include original findings, recommendations and commentary. Their registry descriptions state why each is retained and do not convert a reported claim into a verified one.
| Author | Posted | Why it is registered |
|---|---|---|
| @nvk | 2026-07-31T15:42:23Z | Vendor apology, hotfix summary, postmortem commitment and support offered to affected users. |
| @TrustWallet | 2023-04-22T08:59:28Z | Trust Wallet's primary incident thread states the affected browser-extension creation window, that the issue was fixed, and that affected users should follow its remediation guidance. The held capture covers the first post of the ten-post thread. |
| @LLFOURN | 2026-07-31T00:41:30Z | LLFOURN's stated attack-cost model: approximately 2^40.3 for Mk3 and 2^72.3 for Mk4-class devices under its listed UID, timing and interaction assumptions. |
| @LLFOURN | 2026-07-31T20:58:52Z | LLFOURN's follow-up lowering the Mk4-class estimate by 10 to 14 bits, giving approximately 2^58.3 to 2^62.3 under the revised assumptions. |
| @KLoaec | 2026-07-31T21:18:10Z | Dated guidance on configurations where affected COLDCARD keys meet a multisig or miniscript threshold, with qualified Taproot and private-submission advice. |
| @clay_garrett | 2026-07-31T17:42:45Z | Block's report that the operator used a paid blockchain-services account; the complete thread says the provider's logs matched the workflow and that Block saw no evidence of knowing participation. |
| @clay_garrett | 2026-07-31T00:03:31Z | Block's seven-post preliminary accounting thread for the reported 695 earlier transactions, including the two block-level counts, amounts, scan method and explicit warning that the common-incident attribution was not confirmed. |
| @unchained | 2026-07-31T03:44:44Z | Unchained's client guidance to rotate COLDCARD-generated keys, with specific treatment of one versus two affected keys in a 2-of-3 vault. |
| @otaliptus | 2026-08-01T01:32:55Z | A deliberately tentative independent Mk4 model. Assuming a remote attacker does not know the UID, otaliptus estimates about 20 to 21 bits from the wafer-coordinate word, narrows practical SysTick positions, and isolates the unresolved RTC term. The post reports roughly 52 to 63 bits if Mk4 RTC behaviour is problematic and roughly 75 to 88 bits if it is not. The author labels this brainstorming and lists assumptions that may be wrong, so it is preserved as reported analysis rather than a measured bound. |
| @BEN0WHERE | 2026-08-01T00:37Z | Part of the Slipstream advice chain. Reply to "why do multisig holders need Slipstream?", explaining the mechanism: a thief holding some keys of a multisig may still lack the wallet setup data, but the owner's own broadcast reveals enough of it to let the thief build a competing transaction; private miner submission avoids that race. Author's profile: Product Lead at Bitkey (Block's wallet), which bears on the conflict disclosure already on the Slipstream page. |
| @glxyresearch | 2026-07-31T13:23:11Z | Galaxy's own flow-of-funds post, the primary source behind the 1,082.65 BTC / 1,196-address figure quoted by The Block. Adds what the reporting dropped: the 30.0 sat/vB hardcoded fee signature with no change outputs, the BIP-84/49/44 derivation mix, blocks 960,183-960,191, and the four consolidation addresses with per-address balances (562.02 + 398.48 + 89.62 + 32.45 BTC). The first rendered screenshot was taken before the attached chart hydrated. The timestamped 07:49:51 UTC recapture includes the complete post and flow map. |
| @KevinKelbie | 2026-08-01T01:43:39Z | Reports a later 31 July cluster of 1,216 transactions and 45.9 BTC, outside Block's published scan window. The post says seven of Block's eight markers match while replace-by-fee behaviour differs. Captured as a reported lead, not treated as verified until the underlying transaction set is independently checked. |
| @Rob1Ham | 2026-07-30T18:30:25Z | Primary source for Hamilton's preliminary accounting: 1,324 UTXOs, 500 transactions, a three-block window, 594.48 BTC, and a later 562 BTC consolidation. The post itself says the activity occurred over 15 minutes and labels the analysis preliminary. |
| @LLFOURN | 2026-07-31T22:01:41Z | Reports a pessimistic Mk4 scenario of 32 bits of work per target if the UID is known and the button-press count and clock behaviour are more predictable. This is an attributed attack model, not a measurement of shipped devices. |
| @LLFOURN | 2026-08-01T02:13:02Z | A time-stamped risk assessment rather than a durable guarantee: LLFOURN reports little immediate risk in moving Mk4 multisig on 1 Aug, warns that could change within days, and describes Unchained's one-size process as sensible for a KYC provider that knows its customer base. |
| @LLFOURN | 2026-07-31T21:05:38Z | An explicit correction of LLFOURN's earlier multisig guidance: Mk4, Mk5 and Q setups in which affected devices meet the signing threshold, without a mitigating factor such as dice rolls, need to move. |
| @darosior | 2026-07-31T16:30:43Z | Antoine Poinsot's high-urgency public warning covering Mk3, Mk4, Mk5 and Q, with a 50-roll pure-dice exception. The scope and urgency are attributed guidance; the post does not itself provide evidence that every named model was already being drained. |
| @theinstagibbs | 2026-07-30T22:37:02Z | Gregory Sanders's concise public result from an independent hardware reproduction: Mk2/Mk3 confirmed, with Mk4 explicitly left uncertain. The owned device inputs and unpublished scripts limit what this establishes about a blind remote search. |
| @KLoaec | 2026-07-30T20:28:24Z | Kevin Loaec's early low-entropy hypothesis, based on BIP84-only scanning, limited derivation depth and partial sweeps. The post labels the account a current hypothesis; its claim that the operator used AI remains unverified. |
| @dhruvbansal | 2026-07-31T18:43:08Z | Dhruv Bansal's broader security response, arguing for layered protections, redundancy and human involvement as Bitcoin, AI and computer security overlap. Its reference to an attacker using an LLM is commentary, not new attribution evidence. |
| @PraveenPerera | 2026-07-30T23:46:52Z | Praveen Perera's first public report that an independent scan recovered two private keys belonging to the known stolen-address set. The result is preserved as reported because the reproduction code and candidate data are not published. |
| @PraveenPerera | 2026-07-31T01:01:29Z | Adds scope and cost to Perera's earlier report: index-zero addresses against a known stolen set, two recovered keys associated with about 34 BTC, roughly five minutes and less than US$5 of GPU time. The post also gives urgent dice and passphrase advice, which remains an attributed recommendation. |
| @Rob1Ham | 2026-07-31T15:37:51Z | Origin of the public multisig migration warning and Slipstream recommendation. Hamilton describes the first-broadcast race for wallets whose affected COLDCARD keys alone meet the threshold. The service recommendation is attributed, not independently guaranteed. |
| @peterktodd | 2026-07-31T15:54:21Z | Peter Todd expands Hamilton's multisig scenario, endorses private miner submission, and adds the caveat that an already revealed script does not gain the same protection. The recommendation and service assumptions remain attributed. |
| @PortlandHODL | 2026-07-31T16:59:29Z | PortlandHODL publicly offered Slipstream access codes by direct message during the incident. This records the access channel and its authentication risk; it does not establish service confidentiality or confirmation guarantees. |
| @COLDCARDwallet | 2026-07-31T11:37:18Z | Official COLDCARD update expanding the affected scope beyond the initial Mk3 advisory and directing users to model-specific remediation. |
| @COLDCARDwallet | 2026-07-31T13:43:05Z | Official COLDCARD announcement of the Mk3 v4.2.0 hotfix, useful for bounding the public remediation timeline. |
| @COLDCARDwallet | 2026-07-31T16:54:38Z | Official COLDCARD announcement naming the Edge hotfix releases 6.6.0X and 6.6.0QX. |
| @theinstagibbs | 2026-07-31T13:48:54Z | Gregory Sanders states the elapsed time from deciding to investigate to an on-device Mk3 proof, while leaving method and brute-force runtime unstated. |
| @_benma_ | 2026-08-01T02:14:13Z | Independent warning that BIP85 child wallets inherit exposure from an affected COLDCARD master seed and require separate migration consideration. |
| @KLoaec | 2026-07-31T10:31:26Z | Kevin Loaec warns that BIP85-derived wallets from an affected COLDCARD master seed fall within the migration scope. |
| @PortlandHODL | 2026-08-01T03:18:41Z | PortlandHODL reports a specific amount moved through Slipstream for a 2-of-3 multisig case; the result is retained as attributed and unverified. |
| @P3b7_ | 2026-07-31T21:20:04Z | Charles Guillemet explains how script visibility changes a threshold-wallet migration race and recommends private transaction submission; Ledger affiliation requires disclosure. |
| @Ledger | 2026-07-31T16:16:25Z | Ledger states that its devices are not affected and describes the architecture and entropy source it says distinguish them. |
| @CasaHODL | 2026-07-31T16:04:26Z | Casa publishes incident-specific guidance for customers using COLDCARD keys in Casa vault policies. |
| @Nneuman | 2026-07-31T18:20:12Z | Casa CEO Nick Neuman publishes migration guidance and a threshold-risk claim whose applicability depends on the stated wallet policy and key-provenance assumptions. |
| @dhruvbansal | 2026-07-31T18:43:07Z | First post in Dhruv Bansal thread, preserving the setup and argument that precede the already registered concluding post. |
| @dhruvbansal | 2026-07-31T18:43:08Z | Second post in Dhruv Bansal thread, preserving the middle argument that precedes the already registered concluding post. |
| @zherbert | 2026-08-01T03:47:40Z | Foundation Devices co-founder and CEO Zach Herbert reports a physical OPENDIME entropy test and provides device-specific evidence bearing on the not-affected claim. Foundation sells competing hardware-wallet products, so that affiliation is relevant to the report's provenance. |
| @Rob1Ham | 2026-08-01T04:04:59Z | Rob Hamilton responds to the OPENDIME test, distinguishes its observed entropy incorporation from the harder-to-verify closed-source TAPSIGNER claim. |
| @jamesob | 2026-07-31T14:17:32Z | James O'Beirne recommends migration for affected COLDCARD seeds generated with fewer than 99 dice rolls, documenting stricter public guidance than the vendor's 50-roll threshold. |
| @alwaysaimbig | 2026-08-01T02:04:10Z | Zach's post includes a slide headed "An Unchained vault with 2 Coldcard-generated keys: Group A" and describes it as webinar guidance. The post, complete attached image and attachment transcript are held. The archive has not independently authenticated the slide's authorship, webinar context or the complete presentation. The unversioned PNG and text capture are preserved as an incomplete first attempt; the timestamped PNG, JPG attachment and text capture supersede them for reading the post and slide. |
| @COLDCARDwallet | 2026-08-01T11:21:43Z | Coinkite's 1 August escalation post asks users to treat migration as urgent and to spread the word to less-online owners. It quotes the vendor's 31 July urgent update, whose wording states the Mk3 affected boundary as 4.0.1+ and carves out seeds generated with at least 50 private, independent dice rolls. Both details bear directly on the affected-range boundary and the mixed-dice classification recorded elsewhere in this archive. |
| @KLoaec | 2026-08-01T12:29:01Z | Kevin Loaec of Wizardsardine states on 1 August that Mk4, Mk5 and Q wallets are now being actively drained, quoting Tomer Strolight's account of an intentionally seeded Mk4 honeypot swept overnight to a named bc1q address. If corroborated on chain this is the first reported Mk4-class sweep, extending observed exploitation beyond the roughly 40-bit Mk3 space; the claim itself remains a reported third-party account. |
| @KLoaec | 2026-08-01T15:45:04Z | Kevin Loaec announces Wizardsardine's long-form post-mortem of the COLDCARD flaw, summarising it as worse than commonly understood because users with safe mnemonics, including dice-generated ones, still face broken features on affected devices. The linked blog post is captured separately as a web source; this post records the framing and the author's request for corrections. |
| @KLoaec | 2026-08-01T15:47:25Z | Kevin Loaec stresses that even users who imported a seed or generated one with dice are exposed if they used certain COLDCARD features, with an attached graphic enumerating them. This extends the incident's blast radius beyond seed generation into derived-material features and aligns with the Wizardsardine post-mortem's broken-features section; the specific feature list is the vendor-independent claim to check against source. |
| @clay_garrett | 2026-08-01T16:09:40Z | Block hardware lead Clay Garrett shares initial findings on a separately reported Bitkey vulnerability disclosed by 1440000bytes, stating it requires exceptional circumstances during inheritance setup, yields insufficient key material even if exploited, and that a mobile-app patch ships same day. Recorded because Block is a primary party in the COLDCARD incident record and this statement shows its concurrent security posture; the Bitkey issue itself is distinct from the COLDCARD RNG flaw. |
| @btcinsider__ | 2026-08-01T16:35:37Z | bitcoin++ Insider Edition announces Dustin Dettmer's commit-history walkthrough of how the COLDCARD entropy bug was introduced, titled 'When random.bytes() runs but doesn't work'. The linked article is captured separately as a web source; this post records the publication and its framing. |
| @glxyresearch | 2026-08-01T18:38:48Z | Galaxy Research's 1 August revision identifying a third sweep wave of 207.7294 BTC and raising its estimated observed total to 1,367.05 BTC across 4,585 addresses, superseding the roughly 1,083 BTC figure quoted earlier in this archive. The thread also states that no coin drained in waves 1 to 3 was created before block 674,951 on 17 March 2021, which bears independently on the affected-range lower bound, and carries Galaxy's own disclaimer that the work derives solely from block data and the unspent-output set without testing whether the identified addresses were in fact generated with low entropy. |
| @glxyresearch | 2026-08-01T18:38:49Z | Galaxy Research's own scope disclaimer for its wave analysis: the work derives solely from Bitcoin block data and the unspent-output set, and Galaxy has not used compute to test whether the addresses it identifies as possible victims were in fact generated with low entropy. This bounds every Galaxy figure quoted in this archive and is the reason those totals are recorded as attributed observations rather than established causation. |
| @glxyresearch | 2026-08-01T18:38:58Z | Galaxy Research states that the vulnerable COLDCARD firmware shipped on 17 March 2021 around block 674,951, and that no coin identified in waves 1 to 3 was created before that block. This bears independently on the affected-range lower bound: 17 March 2021 is the v4.0.0 release date recorded here, not the 29 March 2021 v4.0.1 date that the vendor advisory uses as its stated boundary. |
| @glxyresearch | 2026-08-01T18:38:55Z | Galaxy Research reports 1,366.3865 BTC under attacker control with all endpoint attacker addresses fully unspent on chain as of 1 August 2026. Recorded alongside the funds accounting because it is the outcome question a reader asks after the sweep totals, and because an unspent endpoint set is the condition under which any later movement becomes newsworthy. |
| @glxyresearch | 2026-08-01T18:38:51Z | Galaxy Research states the basis for treating the sweep waves as one operator: waves 1 and 2 share funnel topology into a handful of collectors, the same P2WPKH destinations and the same mix of derivation paths, 27 hours apart, and that treating them as one operator is reasonable but rests on resemblance rather than proof. This is the attribution qualifier behind every same-operator total quoted in this archive. |
| @lopp | 2026-08-01T18:02:16Z | Jameson Lopp posts a screenshot of a Telegram account impersonating COLDCARD WALLET that messaged a user on 1 August, opening with rapport rather than an immediate credential request: the sender claims database records showing the recipient was an early user and asks whether they moved their funds safely. The capture also shows Telegram's own contact panel marking the account Not an official account, registered March 2026, and the blue mark identified in-app as a Premium subscriber badge rather than verification. Quoted above his 31 July warning that phishing mail posing as Coinkite security notices would follow. First-hand documentary evidence of an impersonation channel exploiting this incident's migration guidance. |
| @lopp | 2026-07-31T14:59:43Z | Jameson Lopp predicts on 31 July that phishing mail posing as Coinkite security notices will follow the disclosure and will try to get readers to type recovery words into a malicious site. Held because his 1 August impersonation screenshot quote-tweets this post: together they are a dated prediction and a dated artefact, and the pairing is what distinguishes a documented scam from an anticipated one. |
This page was corrected after timestamps showed that private-submission advice had been attributed to the wrong person. The corrections process accepts attributable evidence and records substantive changes.