Coldcard Key Exposure
mempool-research-key-exposure
Latest reviewed change
source content difference between and
The guide grew from a short read to a long explainer adding a What happened section, a per-model firmware scope table, affected-key risk tables, migration route guidance and a root-cause summary.
An analysis of the ongoing Coldcard key exposure with details for how to manage migration, and when to use private broadcast.
orangesurf
05 Aug 2026
-• 7 min read
+• 18 min read
There is an ongoing exploit of an error in the firmware of Coldcard devices that resulted in highly insecure wallets being generated by default. If you have used a Coldcard, you must carefully evaluate whether your bitcoin is at risk and act accordingly. If you are at risk, or are unsure, you should migrate your funds immediately following the guidance below.
+What happened?
+For roughly five years, affected Coldcard firmware generated some wallet secrets through a predictable software PRNG path instead of the intended STM32 hardware RNG path. Attackers can enumerate candidate secrets offline, derive public addresses, compare them with the blockchain, and sweep matches. The attack does not require the victim's device, phishing, or malware on the device. This was a firmware defect, not ordinary user error (Coinkite security advisory, Coinkite technical deep dive).
First lines only. The complete diff is in the timeline below.
- Organisation
- mempool.space Research
- Evidence role
- Independent primary analysis
- Published
- 2026-08-04
- Source changes
- 2
- Detected differences
- 2
- Unreviewed
- 0
- Copies held
- 3
mempool.space Research's incident guide, published after the first four drain waves. It separates affected firmware and seed-generation cases, recommends migration steps and links its technical and funds-accounting claims to primary material. The risk assessments and recommendations belong to the authors; registration here does not independently verify them.
Every check is recorded, including checks that found no text change. A detected edit is therefore bounded between two checks. The publisher's exact save time is not observable from this record. Last checked .
Also held inside a captured conversation
This post is held twice: here, with this project's own note on why it matters, and again as part of the conversation captured at , which is polled for changes. Both copies are the same post; neither is a separate event.
Public privacy boundary
Snapshot and diff bodies for this chain monitor are held in the local evidence archive but withheld from the public site because they can contain the addresses of people who published nothing themselves. Capture times and reviewed change summaries remain available below.
Held captures
-
The guide grew from a short read to a long explainer adding a What happened section, a per-model firmware scope table, affected-key risk tables, migration route guidance and a root-cause summary.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 67 lines
An analysis of the ongoing Coldcard key exposure with details for how to manage migration, and when to use private broadcast. orangesurf 05 Aug 2026 -• 7 min read +• 18 min read There is an ongoing exploit of an error in the firmware of Coldcard devices that resulted in highly insecure wallets being generated by default. If you have used a Coldcard, you must carefully evaluate whether your bitcoin is at risk and act accordingly. If you are at risk, or are unsure, you should migrate your funds immediately following the guidance below. +What happened? +For roughly five years, affected Coldcard firmware generated some wallet secrets through a predictable software PRNG path instead of the intended STM32 hardware RNG path. Attackers can enumerate candidate secrets offline, derive public addresses, compare them with the blockchain, and sweep matches. The attack does not require the victim's device, phishing, or malware on the device. This was a firmware defect, not ordinary user error (Coinkite security advisory, Coinkite technical deep dive). +The first large observed wave of thefts began July 30, approximately 01:10–01:51 UTC (Galaxy Research, CoinDesk). Losses so far: TRM's August 5 tally is 1,816 BTC across 5,200+ addresses; Galaxy is confident in 1,596 BTC across about 7,300 addresses and tentatively counts 2,055 BTC across 7,700+ (Alex Thorn). Galaxy's promoted set had a reported median coin dormancy of about 3.8 years, and the vast majority of implicated addresses had only received funds before being drained (TFTC). +A firmware update prevents future bad generation but it does not repair an existing affected seed. +The remedy is a completely new seed plus migration. Imported copies of the old seed remain weak. Which wallets are insecure / have exposed keys? Wallets derived from a seed generated on a Coldcard running firmware version 4.0.1 or later (excluding the emergency patch released on 2026/07/30) which were setup using the default initialisation steps are insecure wallets. An exposed key is defined as one which is associated with these insecure wallets. Whether the device was updated following the insecure wallet generation is irrelevant. Updating does not repair an existing seed. Furthermore, users are reporting that their devices have been bricked by applying the latest 2026/07/30 firmware updates. If at all possible do not update the firmware on the device and simply sweep the funds and put the device into storage. +Also treat as insecure: +BIP85 children of a weak parent including +derived mnemonics +WIF/XPRV material +Nostr keys +Passwords +Duress wallets. +Any seed of unknown origin which may plausibly have been generated by a Coldcard. +Firmware Scope +Device Seed-generation firmware status +Mk1 Outside this regression. +Mk2/Mk3 through v3.2.2 Direct hardware-RNG path; outside this regression. +Mk2/Mk3 v4.0.1–v4.1.9 Officially affected. Block also identifies the regression in v4.0.0 code, but Coinkite's public scope starts at v4.0.1. +Mk3-specific v5.0.1-mk3 / v5.0.3-mk3 Independent source review identifies these as affected; Coinkite's current public advisory does not expressly reconcile them. Treat them as affected pending an official clarification. +Mk4/Mk5 before standard v5.6.0 Affected. +Q before standard v1.5.0Q Affected. +Mk4/Mk5 Edge before v6.6.0X Affected. +Q Edge before v6.6.0QX Affected. +Fixed releases: Mk2/Mk3 v4.2.0+; Mk4/Mk5 standard v5.6.0+; Q standard v1.5.0Q+; Mk4/Mk5 Edge v6.6.0X+; Q Edge v6.6.0QX+. Note that Standard and Edge are separate tracks (Coinkite security advisory). +Not exposed by the wallet-seed-generation bug alone +A seed imported from a genuinely independent non-Coldcard source +A dedicated dice-only seed generated through the documented fixed-firmware workflow with at least 99 independent rolls. +Direct-PRNG features: a good main seed does not automatically save them +Feature Refined impact statement +Paper-wallet generation The normal path uses the weak stream directly as the standalone private key, making candidate validation possible from the public address. The paper-wallet Use Dice option bypasses that path. +Clone-to-device The clone operation uses weak ephemeral ECDH keys. Someone who captures the clone file/public-key material may enumerate the ephemeral key, derive the session key and potentially decrypt the cloned backup, even if the underlying seed was good. The file does not simply contain the seed in cleartext by itself. +USB session encryption A captured transcript exposes public keys that can validate candidate ephemeral keys, threatening that session's confidentiality. This does not directly disclose the wallet signing seed. +Ordinary Key Teleport Temporary ECDH keys and a five-byte secondary password draw from the weak stream. Severity depends on capture of the exchange and protocol details; do not compress this to “40-bit password + 28-bit index” for every mode. +Secure Notes / generated passwords / HSM material Generated secrets and some HSM local-code material inherit the weak stream. Manually entered secrets and BIP85-derived values instead depend on the security of the underlying seed. +Seed XOR random-split mode For a two-part random split, A is the weak random mask and B = seed XOR A. Possession of B can permit enumeration of candidate masks and recovery of the original seed; A alone does not reveal it. The default deterministic split mode is separate from this bug. +Sources for the table above: Block Engineering, Wizardsardine. Protection via a passphrase -A secure BIP39 passphrase is unique and generated using genuine randomness rather than chosen by a person. For example, 12 independently and randomly selected words would be extremely difficult to guess. Common phrases, quotations, personal information, reused passwords, predictable word combinations are not secure passphrases. You should not enter your passphrase anywhere online to evaluate it's security, because such sites could harvest your passphrase in order to steal your funds. -If your passphrase is not truly randomly selected, you should treat your wallet as insecure and migrate your finds. +A secure BIP39 passphrase is unique and generated using genuine randomness rather than chosen by a person. For example, 12 independently and randomly selected words would be extremely difficult to guess. Common phrases, quotations, personal information, reused passwords, predictable word combinations are not secure passphrases. You should not enter your passphrase anywhere online to evaluate its security, because such sites could harvest your passphrase in order to steal your funds. +If your passphrase is not truly randomly selected, you should treat your wallet as insecure and migrate your funds. +A weak passphrase may be cheap to test once the weak mnemonic is recovered, because BIP39 uses PBKDF2-HMAC-SHA512 with only 2,048 iterations. A reported Mk3 wallet protected by a two-word passphrase was drained on August 2 (Casa). A weaker passphrase may buy time but should be assumed to eventually be cracked. A strong random passphrase still calls for migration; it is an additional barrier, not a repair. Protection via dice rolls If you entered 50+ dice rolls when creating the wallet then you did not follow the default setup, and you have a more secure wallet than the insecure wallets which used the default setup procedure - your key is not exposed by this bug. If you can't remember how many dice rolls you performed you should treat your wallet as insecure and migrate your funds. Migration If you have an insecure wallet / exposed keys you should migrate to a new wallet urgently. +Affected keys Policy visibility Funds at risk Submission route Action +Below signing threshold Irrelevant No immediate theft using only the identified affected keys. Public broadcast OK Migrate to restore the intended security margin. +Signing threshold reached, but at least one cosigner is unaffected The witness script, descriptor and equivalent wallet metadata have not been disclosed.1 No practical theft using this flaw until sufficient policy and public-key information is disclosed. Private preferred Migrate urgently using a direct-to-miner or private-relay service (e.g. Slipstream). +Signing threshold reached, but at least one cosigner is unaffected The witness script, descriptor or equivalent wallet metadata is already known. UTXOs governed by the disclosed policy may be stolen at any time. Judgement Call Migrate urgently — secrecy is already lost, so a high-fee public broadcast is likely better (see below). +All required cosigner keys are affected No witness script, descriptor or equivalent wallet metadata disclosure has been identified.1 Funds not safe, but not trivially stolen. Private strongly preferred Migrate urgently without publicly revealing the spending policy. +All required cosigner keys are affected A previous spend or metadata leak has disclosed sufficient wallet information. Potentially all UTXOs belonging to the same standard descriptor wallet. Judgement Call Migrate immediately — treat the wallet as already public; a high-fee public broadcast is likely better (see below). +¹ "Policy not disclosed" assumes that the complete witness script, descriptor, cosigner xpubs, coordinator data, PSBT records and equivalent wallet metadata have not leaked through another channel. Single Sig If you have a single sig Coldcard wallet with an exposed key your funds may have been stolen already - check your wallet to confirm. If they have not they should be migrated to a new wallet immediately. Broadcasting the transaction publicly at a sufficiently high fee rate for next block confirmation is likely the best option to minimise the chance of theft. You can check the current fee rates at mempool.space MultiSig If you have a multisig wallet in which exposed keys reach the signing threshold (2-of-3 or M-of-N where M are coldcards) your funds are at high risk and should be migrated urgently. There is nuance with how to proceed: -¹ “Policy not disclosed” assumes that the complete witness script, descriptor, cosigner xpubs, coordinator data, PSBT records and equivalent wallet metadata have not leaked through another channel. +Situation Usually favored route Why / caveat +Affected single-signature wallet Public broadcast with a fee intended for prompt confirmation The public address already validates candidate keys; direct network propagation is usually fastest. There is no guaranteed fee or confirmation time. +Multisig whose complete policy is already public or leaked Often a high-fee public broadcast; private submission may still reduce passive observation but no longer restores secrecy Public propagation may be faster. An attacker who already knows the policy need not wait for your migration transaction. +Never-spent multisig, policy genuinely undisclosed¹, and affected keys meet threshold Consider private direct-to-miner submission It can avoid pre-confirmation disclosure to the public mempool, but you must trust the service/miner not to leak, confirmation can be slow, the service sees your IP, and there is no guarantee. +Affected Coldcard keys below every threshold Orderly key rotation and full wallet migration This bug alone should not authorize a spend, but the affected key should still be retired. Submission-route notes Public broadcast: Propagates quickly across the Bitcoin network but exposes the transaction to public-mempool monitoring. An attacker able to spend the same inputs may submit a higher-fee conflicting transaction. Private submission: Can avoid revealing a previously concealed witness script through the public mempool, but requires trusting the submission service and participating miners not to leak or relay the transaction. Confirmation may take longer and is not guaranteed. You should do your own research - there are a number of good signing hardware options available. When used in a multi-vendor multi-sig a very robust setup can be achieved, provided sound operational and backup practices are followed. Users may consider a self-managed wallet using multiple independently implemented signing devices, or a collaborative custody provider. Multisignature and timelocked recovery policies introduce additional backup, descriptor and operational requirements, so users should understand and test the complete recovery process before transferring substantial funds. Examples of such tools include Sparrow Wallet, Liana Wallet, Anchor Watch & Unchained. Do your own research and ensure you are on the legitimate websites. +Prepare the destination wallet +Generate the replacement seed on a trusted device, or for larger amounts preferably using multi-vendor multi-sig. +Generate a completely new seed. Do not reuse or "upgrade" the old mnemonic. +Record and verify the backup, wallet fingerprint and receive address on the hardware-device screen. +Power-cycle and re-check the fingerprint/address. For high-value setups, complete a recovery rehearsal before retiring the old setup. +Keep the old backup until the migration has fully confirmed and the destination has been verified. +Test-transaction +Coinkite's official guidance recommends a small test transaction before moving the remainder. That is sensible destination-error protection for many single-signature migrations. In a previously concealed multisig, however, a test spend from the old wallet can reveal the policy and create the same pre-confirmation attack window as the final migration. A safer pattern there is to test the new receiving setup using unrelated safe funds, verify recovery/fingerprint/address thoroughly, then make one carefully reviewed private migration. +Root cause: what actually went wrong +The old path reached the board-local STM32 hardware RNG. The hardware RNG implementation remained present and was still used by callers of ckcc.rng_bytes; the principal wallet-seed path and several other ngu.random consumers no longer reached it. Do not say seed generation was the only affected function. +There are excellent writeups on this by Block Engineering & Wizardsardine. Plausible Attack Progression and Reported Incidents One plausible attacker progression is to prioritize candidates that combine low search cost, easily identifiable funded outputs and high expected value. They may then progress to the harder to steal coins (requiring more cost and more complex tooling) only once they have exhausted their search or detect that they have competition within a search space.Extracted text as captured
Coldcard Key Exposure An analysis of the ongoing Coldcard key exposure with details for how to manage migration, and when to use private broadcast. orangesurf 05 Aug 2026 • 18 min read There is an ongoing exploit of an error in the firmware of Coldcard devices that resulted in highly insecure wallets being generated by default. If you have used a Coldcard, you must carefully evaluate whether your bitcoin is at risk and act accordingly. If you are at risk, or are unsure, you should migrate your funds immediately following the guidance below. What happened? For roughly five years, affected Coldcard firmware generated some wallet secrets through a predictable software PRNG path instead of the intended STM32 hardware RNG path. Attackers can enumerate candidate secrets offline, derive public addresses, compare them with the blockchain, and sweep matches. The attack does not require the victim's device, phishing, or malware on the device. This was a firmware defect, not ordinary user error (Coinkite security advisory, Coinkite technical deep dive). The first large observed wave of thefts began July 30, approximately 01:10–01:51 UTC (Galaxy Research, CoinDesk). Losses so far: TRM's August 5 tally is 1,816 BTC across 5,200+ addresses; Galaxy is confident in 1,596 BTC across about 7,300 addresses and tentatively counts 2,055 BTC across 7,700+ (Alex Thorn). Galaxy's promoted set had a reported median coin dormancy of about 3.8 years, and the vast majority of implicated addresses had only received funds before being drained (TFTC). A firmware update prevents future bad generation but it does not repair an existing affected seed. The remedy is a completely new seed plus migration. Imported copies of the old seed remain weak. Which wallets are insecure / have exposed keys? Wallets derived from a seed generated on a Coldcard running firmware version 4.0.1 or later (excluding the emergency patch released on 2026/07/30) which were setup using the default initialisation steps are insecure wallets. An exposed key is defined as one which is associated with these insecure wallets. Whether the device was updated following the insecure wallet generation is irrelevant. Updating does not repair an existing seed. Furthermore, users are reporting that their devices have been bricked by applying the latest 2026/07/30 firmware updates. If at all possible do not update the firmware on the device and simply sweep the funds and put the device into storage. Also treat as insecure: BIP85 children of a weak parent including derived mnemonics WIF/XPRV material Nostr keys Passwords Duress wallets. Any seed of unknown origin which may plausibly have been generated by a Coldcard. Firmware Scope Device Seed-generation firmware status Mk1 Outside this regression. Mk2/Mk3 through v3.2.2 Direct hardware-RNG path; outside this regression. Mk2/Mk3 v4.0.1–v4.1.9 Officially affected. Block also identifies the regression in v4.0.0 code, but Coinkite's public scope starts at v4.0.1. Mk3-specific v5.0.1-mk3 / v5.0.3-mk3 Independent source review identifies these as affected; Coinkite's current public advisory does not expressly reconcile them. Treat them as affected pending an official clarification. Mk4/Mk5 before standard v5.6.0 Affected. Q before standard v1.5.0Q Affected. Mk4/Mk5 Edge before v6.6.0X Affected. Q Edge before v6.6.0QX Affected. Fixed releases: Mk2/Mk3 v4.2.0+; Mk4/Mk5 standard v5.6.0+; Q standard v1.5.0Q+; Mk4/Mk5 Edge v6.6.0X+; Q Edge v6.6.0QX+. Note that Standard and Edge are separate tracks (Coinkite security advisory). Not exposed by the wallet-seed-generation bug alone A seed imported from a genuinely independent non-Coldcard source A dedicated dice-only seed generated through the documented fixed-firmware workflow with at least 99 independent rolls. Direct-PRNG features: a good main seed does not automatically save them Feature Refined impact statement Paper-wallet generation The normal path uses the weak stream directly as the standalone private key, making candidate validation possible from the public address. The paper-wallet Use Dice option bypasses that path.Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
The incident guide revised its opening description and changed the date of its reported single-signature Mk4 theft example from 1 August to 4 August 2026.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 3 lines
Coldcard Key Exposure +An analysis of the ongoing Coldcard key exposure with details for how to manage migration, and when to use private broadcast. orangesurf 05 Aug 2026 • 7 min read 1.4 - single sig Mk4 / Mk5 / Q with weak passphrase or small number of dice rolls Real world data: July 30, ~01:10 UTC: The first wave of thefts from single sig Mk3 no passphrase [source] -Aug 1, 2026. A reported theft from a single-signature Mk4 with no passphrase [source] Aug 2, 2026, ~04:00 UTC A reported theft from a single-signature Mk3 with a weak two-word passphrase. [source] +Aug 4, 2026. A reported theft from a single-signature Mk4 with no passphrase [source] Phase 2 - Multisig via address/key reuse Description: The attacker scans for unspent outputs which are known multisigs which have addresses that have previously been spent from. They then search the redeem script / witness script for matches against indexed weak public keys. For each output they find where the threshold can be met by the compromised keys, they construct a transaction stealing the funds.Extracted text as captured
Coldcard Key Exposure An analysis of the ongoing Coldcard key exposure with details for how to manage migration, and when to use private broadcast. orangesurf 05 Aug 2026 • 7 min read There is an ongoing exploit of an error in the firmware of Coldcard devices that resulted in highly insecure wallets being generated by default. If you have used a Coldcard, you must carefully evaluate whether your bitcoin is at risk and act accordingly. If you are at risk, or are unsure, you should migrate your funds immediately following the guidance below. Which wallets are insecure / have exposed keys? Wallets derived from a seed generated on a Coldcard running firmware version 4.0.1 or later (excluding the emergency patch released on 2026/07/30) which were setup using the default initialisation steps are insecure wallets. An exposed key is defined as one which is associated with these insecure wallets. Whether the device was updated following the insecure wallet generation is irrelevant. Updating does not repair an existing seed. Furthermore, users are reporting that their devices have been bricked by applying the latest 2026/07/30 firmware updates. If at all possible do not update the firmware on the device and simply sweep the funds and put the device into storage. Protection via a passphrase A secure BIP39 passphrase is unique and generated using genuine randomness rather than chosen by a person. For example, 12 independently and randomly selected words would be extremely difficult to guess. Common phrases, quotations, personal information, reused passwords, predictable word combinations are not secure passphrases. You should not enter your passphrase anywhere online to evaluate it's security, because such sites could harvest your passphrase in order to steal your funds. If your passphrase is not truly randomly selected, you should treat your wallet as insecure and migrate your finds. Protection via dice rolls If you entered 50+ dice rolls when creating the wallet then you did not follow the default setup, and you have a more secure wallet than the insecure wallets which used the default setup procedure - your key is not exposed by this bug. If you can't remember how many dice rolls you performed you should treat your wallet as insecure and migrate your funds. Migration If you have an insecure wallet / exposed keys you should migrate to a new wallet urgently. Single Sig If you have a single sig Coldcard wallet with an exposed key your funds may have been stolen already - check your wallet to confirm. If they have not they should be migrated to a new wallet immediately. Broadcasting the transaction publicly at a sufficiently high fee rate for next block confirmation is likely the best option to minimise the chance of theft. You can check the current fee rates at mempool.space MultiSig If you have a multisig wallet in which exposed keys reach the signing threshold (2-of-3 or M-of-N where M are coldcards) your funds are at high risk and should be migrated urgently. There is nuance with how to proceed: ¹ “Policy not disclosed” assumes that the complete witness script, descriptor, cosigner xpubs, coordinator data, PSBT records and equivalent wallet metadata have not leaked through another channel. Submission-route notes Public broadcast: Propagates quickly across the Bitcoin network but exposes the transaction to public-mempool monitoring. An attacker able to spend the same inputs may submit a higher-fee conflicting transaction. Private submission: Can avoid revealing a previously concealed witness script through the public mempool, but requires trusting the submission service and participating miners not to leak or relay the transaction. Confirmation may take longer and is not guaranteed. Judgement Call: The spending information is already available to an attacker, so private submission no longer provides secrecy. A high fee public broadcast will give faster confirmation, but exposes you to attackers who are only monitoring the public mempool. Private mempools You can directly submit to a miner running a private mempool. MARA Slipstream is a popular option that does not require registration. Any private mempool provider must be trusted not to leak or relay the transaction before confirmation, and none guarantees confirmation. Confirmation may take hours because the transaction must wait for MARA, which controls approximately 5% of the network hashrate, to find a block. Note that there is a privacy tradeoff when submitting a private transaction, you reveal your IP address to the recipient server. Given the sensitive nature of this data in combination with potentially high value bitcoin transactions we have suggested to Mara to setup a tor hidden service to allow broadcasts which don't reveal this information. Slipstream | MARA Holdings, Inc. MARA Holdings, Inc. Official Slipstream Frontend Outofband: direct-to-miner broadcast Submit signed PSBTs and raw transactions straight to MARA Slipstream, so they are mined without ever entering the public mempool. Everything runs in your browser. Outofband Alternate Frontend for Slipstream If the UTXO’s witness script or equivalent wallet-policy information is already known (for example, because its descriptor, cosigner xpubs, coordinator data or an earlier spend has revealed it) an attacker can steal those funds without waiting for you to broadcast anything.Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 0 lines
Extracted text as captured
Coldcard Key Exposure orangesurf 05 Aug 2026 • 7 min read There is an ongoing exploit of an error in the firmware of Coldcard devices that resulted in highly insecure wallets being generated by default. If you have used a Coldcard, you must carefully evaluate whether your bitcoin is at risk and act accordingly. If you are at risk, or are unsure, you should migrate your funds immediately following the guidance below. Which wallets are insecure / have exposed keys? Wallets derived from a seed generated on a Coldcard running firmware version 4.0.1 or later (excluding the emergency patch released on 2026/07/30) which were setup using the default initialisation steps are insecure wallets. An exposed key is defined as one which is associated with these insecure wallets. Whether the device was updated following the insecure wallet generation is irrelevant. Updating does not repair an existing seed. Furthermore, users are reporting that their devices have been bricked by applying the latest 2026/07/30 firmware updates. If at all possible do not update the firmware on the device and simply sweep the funds and put the device into storage. Protection via a passphrase A secure BIP39 passphrase is unique and generated using genuine randomness rather than chosen by a person. For example, 12 independently and randomly selected words would be extremely difficult to guess. Common phrases, quotations, personal information, reused passwords, predictable word combinations are not secure passphrases. You should not enter your passphrase anywhere online to evaluate it's security, because such sites could harvest your passphrase in order to steal your funds. If your passphrase is not truly randomly selected, you should treat your wallet as insecure and migrate your finds. Protection via dice rolls If you entered 50+ dice rolls when creating the wallet then you did not follow the default setup, and you have a more secure wallet than the insecure wallets which used the default setup procedure - your key is not exposed by this bug. If you can't remember how many dice rolls you performed you should treat your wallet as insecure and migrate your funds. Migration If you have an insecure wallet / exposed keys you should migrate to a new wallet urgently. Single Sig If you have a single sig Coldcard wallet with an exposed key your funds may have been stolen already - check your wallet to confirm. If they have not they should be migrated to a new wallet immediately. Broadcasting the transaction publicly at a sufficiently high fee rate for next block confirmation is likely the best option to minimise the chance of theft. You can check the current fee rates at mempool.space MultiSig If you have a multisig wallet in which exposed keys reach the signing threshold (2-of-3 or M-of-N where M are coldcards) your funds are at high risk and should be migrated urgently. There is nuance with how to proceed: ¹ “Policy not disclosed” assumes that the complete witness script, descriptor, cosigner xpubs, coordinator data, PSBT records and equivalent wallet metadata have not leaked through another channel. Submission-route notes Public broadcast: Propagates quickly across the Bitcoin network but exposes the transaction to public-mempool monitoring. An attacker able to spend the same inputs may submit a higher-fee conflicting transaction. Private submission: Can avoid revealing a previously concealed witness script through the public mempool, but requires trusting the submission service and participating miners not to leak or relay the transaction. Confirmation may take longer and is not guaranteed. Judgement Call: The spending information is already available to an attacker, so private submission no longer provides secrecy. A high fee public broadcast will give faster confirmation, but exposes you to attackers who are only monitoring the public mempool. Private mempools You can directly submit to a miner running a private mempool. MARA Slipstream is a popular option that does not require registration. Any private mempool provider must be trusted not to leak or relay the transaction before confirmation, and none guarantees confirmation. Confirmation may take hours because the transaction must wait for MARA, which controls approximately 5% of the network hashrate, to find a block. Note that there is a privacy tradeoff when submitting a private transaction, you reveal your IP address to the recipient server. Given the sensitive nature of this data in combination with potentially high value bitcoin transactions we have suggested to Mara to setup a tor hidden service to allow broadcasts which don't reveal this information. Slipstream | MARA Holdings, Inc. MARA Holdings, Inc. Official Slipstream Frontend Outofband: direct-to-miner broadcast Submit signed PSBTs and raw transactions straight to MARA Slipstream, so they are mined without ever entering the public mempool. Everything runs in your browser. Outofband Alternate Frontend for Slipstream If the UTXO’s witness script or equivalent wallet-policy information is already known (for example, because its descriptor, cosigner xpubs, coordinator data or an earlier spend has revealed it) an attacker can steal those funds without waiting for you to broadcast anything. There are currently no reported instances of attackers having stolen funds by replacing unconfirmed multisignature spends. For these UTXOs, it may therefore be preferable to broadcast publicly using a fee rate targeting confirmation in the next block rather than leave them exposed for hours.Excerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
0 presentation-noise differences. Sidebar, ticker and other page chrome churn that our review classified as not being changes to what the source says.
How to check this yourself
The excerpts and plain unified diffs above show the text this project held and how it changed. To verify a quotation, compare it against the page itself or against the Internet Archive's copies, which are independent of this project.
Complete captures are held offline rather than mirrored here, so this page shows diffs and excerpts. If a quotation is ever disputed, the full copy can be produced. Ask.
How to check this yourself
Compare the screenshot or a quotation against the original while it is available.