Published migration guidance

The common ground in published guidance R1

Coinkite's advisory told owners of affected seeds to migrate to a new wallet, and presented its fixed firmware as suitable for generating new seeds. The source-level fix and release record have been checked here, but this project has not reproduced, rebuilt or disassembled the signed firmware images. U2 Updating firmware changes future generation; the published explanations do not describe it as altering words that already exist.

Other vendors and custody providers published the same replacement line for anyone whose keys came from an affected device, and one of them revised how it said it. Trezor, a competing hardware-wallet vendor, published an article dated 5 August 2026 stating that its own devices are not affected and that restoring a COLDCARD-generated backup onto a Trezor does not repair the weak randomness used when the wallet was created: a new wallet has to be generated and the funds moved to it. In this archive's first capture of that page, at 08:09 UTC on 6 August, the migration sentence told affected readers to follow Coinkite's official guidance and linked Coinkite's Mk3 advisory. In the 16:38 UTC capture the same day it reads "follow these instructions" and links Trezor's own guide to moving to a Trezor from another wallet; "wallet backup" was shortened to "wallet" in the same edit. V3 Trezor's own reason for the change is not published in the article, and this archive does not infer one.

Casa, which sells collaborative multi-key custody and supports the COLDCARD as a key in its vaults, added a security advisory banner to its COLDCARD troubleshooting page: funds generated on affected firmware may be at risk, and "we do recommend replacing this device as soon as you are able". The banner carries the date "Updated August 1, 2026", but the page was unchanged in this archive's 16:27 UTC poll on 6 August and carried the banner at the 22:57 UTC poll the same day; the page's own date moved from 4 March 2026 to 6 August 2026 in the same change. V4 A vendor's stated update date and the date a change becomes visible to a collector are different things, and both are recorded here.

Adam Back told owners on 5 August to move coins to a different hardware wallet, naming Blockstream Jade first and then Trezor and Ledger. He is Blockstream's chief executive and Blockstream sells Jade, a competing signing device, which is stated because the post is in part a product recommendation. Coinkite's own 2 August update had already named other devices and collaborative-custody providers for owners who wanted an alternative or needed a device sooner than it could supply. R5

The published guidance also addressed what to do with the old device. Coinkite's 2 August update asked owners of an affected device not to dispose of it, saying it may become essential if funds are recovered and that its legal team would coordinate as warranted with law enforcement across multiple jurisdictions. Adam Back made a narrower version of the same point in the post above, for owners who had already been swept: do not smash the device or throw it away, because it may weakly prove ownership to a whitehat sweeper, while telling readers not to get their hopes up. The advice circulated in the community too, in an r/coldcard thread titled "Do not dispose of affected device" that cited Coinkite's post. R6 Commenters in that thread asked how possession of a device would establish original ownership at all, given that a recovered seed can be loaded onto any device afterwards, and suggested it would have to be combined with exchange records. No source held here sets out a procedure by which a retained device would be accepted as proof, and no recovery process that uses one is recorded in this archive. U7

Alongside the vendor guidance, a large body of community guidance published from 5 August turns on sourcing the randomness for the replacement keys by hand, with physical dice, rather than from any device. On Stacker News, BitcoinHandsOn2 published a printable dice-to-seed-phrase worksheet on 7 August, saying the motivation was that they would no longer trust entropy from hardware wallets, and asking readers whether the logic had holes. On r/coldcard, fanatic75 published a dice-to-BIP39 tool and a network-less Pi Zero image, with test vectors and an explicit warning that it is a personal project and not audited. In r/Bitcoin, AdEuphoric5133 wrote a long-form entropy explainer giving 2.585 bits per roll, 50 rolls for 128 bits and 99 for 256, arguing that a badly balanced die costs about one bit over 99 rolls, and warning that rolling several same-coloured dice together and recording them in sorted order costs entropy. R16

The published roll counts do not agree. In a thread on Ian Coleman's converter, the commenter orbag wrote on 6 August that it depends on the algorithm, that Coleman's yields only 2 bits per roll, and that a 24-word seed therefore needs at least 160 rolls. The author of the Pi Zero tool draws a related distinction, describing his own conversion as compatible with Coleman's Hex and Base 10 modes but not its Dice [1-6] mode. Separately, a poster describing years of casino work pushed back on the video guidance appearing at the same time: the number of shakes in the hand is irrelevant, the throwing surface matters more, and retail "casino dice" are not guaranteed balanced because casinos machine-test each die before it reaches a table and replace them regularly. R17

The tooling that grew around this guidance drew a named objection. On 7 August slush called it an over-reaction and "absolutely terrible advice - using custom, vibe-coded software on a standard computer to generate recovery seeds", quoting a post that showed a single-file offline page converting 60 dice rolls into a 12-word phrase. He is a co-founder of SatoshiLabs, which makes Trezor, a competing hardware-wallet vendor, and the objection is to seed-generation software rather than to any COLDCARD finding. R18 This archive records the objection as a published position alongside the guidance it criticises. The dice arithmetic itself, and what each figure assumes, is worked through on the technical conditions record.

Whether the replacement should add a passphrase or add keys was argued rather than settled. In one r/Bitcoin thread, bullett007 set out a case for a 2-of-2 multisig over single-sig with a passphrase: two secrets each carrying at least 128 bits with checksums, and no long passphrase typed on a small device screen, weighed against higher fees and a descriptor to back up. In an r/coldcard thread, a commenter called the push to multisig an overreaction, warned that a 2-of-3 also needs all three public keys to spend, and argued a dice-generated key with a strong passphrase is enough. R19 A first-hand worked example is held from the cohort whose multisig absorbed the compromise: blackjackn described rebuilding a 2-of-3 after one COLDCARD Q key was compromised while the coins stayed safe, using the same device on the fixed firmware with a seed from 150 physical dice rolls, one six-word dice-generated passphrase applied to all three keys, and trusted contacts holding keys and passphrase backups. An earlier example of the same kind, posted on 2 August, describes a mixed-vendor rebuild of an Unchained collaborative-custody setup. Both are the posters' accounts of their own setups; this archive records them as published examples and does not assess whether either is sound. R20

One published warning concerns migration that is not finished. On 6 August an r/Bitcoin poster raised owners who buy on a schedule at an exchange and have automatic withdrawals to a COLDCARD address, naming River as a service that offers it: unless those settings are changed, funds keep arriving at addresses derived from affected keys for as long as the owner does not look. The poster said they had not seen the point discussed and suggested exchanges screen withdrawal destinations against the published address lists. R21 No source held here records an exchange screening withdrawal destinations against the incident address lists, or an instance of funds arriving at a drained address this way. U22

Threshold wallets: the first spend can publish the script

only if a spending path has at least as many affected keys as its threshold, and the script is still hidden

This applies to a narrow case: a threshold wallet has at least as many affected keys as a spending-path threshold, and its relevant script, descriptor and child public keys have not already been disclosed. In that case the first spend can make individual weak-key tests possible before the transaction confirms. Whether the case applies is a technical condition rather than a matter of address reuse, and it is worked through on the technical conditions record.

Submission options and limitations

Migration transaction routes

Option	Published or unresolved limitations
Public relay with a competitive fee	A next-block fee is a target, not a confirmation guarantee. Block intervals are variable, policy differs across miners, and a conflicting transaction may pay a higher fee.
Direct submission to a miner	Confirmation depends on the service accepting the transaction and a participating miner finding a suitable block. The public material held here does not settle confidentiality, retention, replacement behaviour or what happens after non-confirmation.

Charles Guillemet described the complete-script condition, the possibility that copies already exist in provider systems or backups, and the public-mempool conflict window, recommending a trusted private relay and naming Slipstream as one example.

What is known about Slipstream

MARA describes Slipstream as a direct transaction-submission service backed by MARA Pool. At the 1 August 2026 check, its portal required a client code and applied a minimum submission feerate. On 3 August 2026 MARA announced Slipstream as a permissionless public good with no client-code requirement, and the portal text captured on 6 August 2026 no longer carries the requirement: it presents the submission form, a minimum submission feerate and the current mineable rate. MARA's public material supports describing it as direct submission, but the portal terms do not establish a confidentiality or confirmation guarantee. R23 V24 The separately published OpenAPI document describes transaction handling as best effort and says admission does not guarantee mining. Its request schema marked client_code as optional in every capture held here, which differed from the portal's client-code requirement at the 1 August 2026 check; that difference closed when the portal dropped the requirement after the 3 August announcement. V25 This archive did not submit a transaction to test which condition the service enforced at the 1 August 2026 check.

A dated pool-share observation gives scale to that limitation. In a held copy of mempool.space's rolling one-month pool dataset, retrieved at 05:56 UTC on 1 August, MARA Pool had found 197 of 4,343 blocks in the response, or 4.54%. The total includes 44 blocks in the endpoint's Unknown category. D26 Pool share and block intervals vary, and acceptance, fee policy, conflicts and service behaviour remain separate conditions.

A time-stamped risk assessment

LLFOURN assessed the immediate risk of moving Mk4 multisig as low on 1 August, while warning that the same assessment might not hold a few days later. R27 The post describes Unchained's cautious, one-size process as sensible for a KYC provider that knows its customer base, and notes that waiting means trusting the provider's eventual solution. The date is part of the claim.

Provenance of the recommendation

Rob Hamilton, an AnchorWatch co-founder, published the migration warning. Peter Todd subsequently endorsed direct miner submission as a possible way to reduce the public-mempool interval. PortlandHODL, who has described involvement in building Slipstream and lists an AnchorWatch affiliation, offered access codes during the incident. Charles Guillemet later published a similar recommendation while serving as Ledger's CTO, and Ledger sells competing signing devices. R28 These relationships are disclosed because they connect the advice either to the service or to a competing hardware-wallet vendor. They do not establish that the technical mechanism is incorrect.

A reported migration outcome

PortlandHODL later reported that a transaction submitted through Slipstream and included in the block current when he posted had saved approximately 158.6 BTC from a 2-of-3 multisig wallet whose COLDCARD keys were likely exposed. R29 The held post does not identify the transaction, wallet policy, competing-spend evidence or counterfactual outcome. This archive therefore records the statement as a reported service outcome and does not independently classify the funds as saved by Slipstream.

Two later posts describe a much larger migration volume. Unchained reported helping owners move thousands of BTC through MARA Slipstream, while Orange Surf reported more than 3,650 BTC in multisig-wallet transactions broadcast through the same route. R30 These figures may overlap and are not independently totalled here. They describe broadcast migration traffic, not an independently verified amount saved from a competing spend.