Coldcard Mk3 and the Limits of Single-Signature Security

What predictable key generation teaches us about hardware wallets, multisig and time-delayed Bitcoin security

Updated July 31, 2026. The investigation remains ongoing, and some technical details may change as further analyses are published.

A hardware wallet can remain air-gapped, never expose its recovery phrase to an online device and still fail.

That is the uncomfortable lesson emerging from the incident involving seeds generated by affected Coldcard firmware.

On July 30, approximately 594.5 BTC were swept from 500 single-signature addresses in a coordinated operation spanning four consecutive Bitcoin blocks. The transactions emptied 1,324 UTXOs in roughly fifteen minutes. According to Atlas21’s on-chain reconstruction, the analysed funds were held in single-signature addresses rather than multisig wallets. (atlas21.com)

This article does not repeat the complete transaction chronology. Instead, it examines the architectural lesson: what happens when a hardware wallet generates a secret weaker than it appears, and how multisignature and time-delayed security can limit the consequences.

What has been confirmed

Coinkite has warned users whose seeds were generated on affected Coldcard firmware that their funds may be at risk. Updating the firmware does not repair a seed that has already been created. (blog.coinkite.com)

Separately, Block’s Bitcoin Engineering and Security team identified an RNG integration error in the Coldcard firmware. According to its analysis, affected code paths could rely on a deterministic software generator instead of receiving the expected cryptographically secure randomness from the hardware RNG. (engineering.block.xyz)

The result is a key that may appear random to its owner while coming from a much smaller and more predictable set of possibilities.

An attacker would not necessarily need to steal the device, access the recovery phrase or compromise the owner’s computer. Candidate secrets could be generated offline and checked against known public wallet data until a match was found.

This is not a failure of Bitcoin’s cryptography. It is a failure in the process used to generate the secret controlling the bitcoin.

Why the air gap was not enough

An air gap protects a secret from communicating with the outside world.

It cannot improve the quality of the secret itself.

If a private key was predictable when generated, keeping it offline afterwards does not restore the missing entropy. Moving the same recovery phrase to a new hardware wallet does not solve the problem either: the new device protects the same potentially weak secret.

The deeper weakness is therefore not simply that one hardware-wallet implementation may fail.

It is that, in a single-signature wallet, one key has complete and immediate authority.

One compromised private key equals complete spending authority.

Once that key is reconstructed, the attacker normally faces no second approval, no independent signer and no intervention window.

How multisig changes the outcome

A multisignature policy distributes authority across multiple keys.

In a 2-of-3 wallet, compromising one signer is not normally sufficient to move the funds. The attacker must obtain another valid signature.

However, the signers must be genuinely independent. Multiple devices do not provide meaningful protection when enough of them rely on the same vulnerable generation process. Block’s researchers therefore warn that a multisig wallet composed entirely of affected devices may remain exposed. (engineering.block.xyz)

The correct lesson is not simply “use multisig.”

It is:

Use multisig without reproducing the same single point of failure inside every signer.

How BitVault changes the failure model

BitVault is built around the assumption that a device, key or service may eventually fail.

Its architecture combines three elements:

• distributed signing authority;
• time-delayed transactions;
• encrypted secret notifications.

Two keys remain under the user’s control, while the normal spending path requires one user key together with the BitVault Convenience Service. A separate long-term recovery path allows the two user-controlled keys to recover independently of BitVault after a longer on-chain delay has matured.

If one user key becomes predictable or compromised, that key alone is not sufficient to complete the normal spending path.

BitVault then adds a second protection: time.

Transactions in the protected normal flow include a predefined delay, validated by the Convenience Service. Instead of turning a valid signing attempt immediately into irreversible settlement, the system creates a waiting period.

That delay becomes a meaningful response window when combined with secret notifications. Encrypted alerts sent to a separately designated monitoring wallet can make suspicious activity visible even when the primary signing environment is no longer trustworthy.

The objective is not to make compromised keys harmless. It is to prevent one compromised signer from automatically becoming an immediate and irreversible loss — and to give the user time and awareness to react.

Put time on your side

The Coldcard incident shows why Bitcoin security cannot depend exclusively on keeping a private key offline.

When a signer is compromised, the ability to detect suspicious activity and react before an irreversible transaction settles can be decisive.

BitVault combines multisignature authority, time-delayed transactions and secret notifications to create that response window.

The official BitVault app launch will be announced shortly. Join our announcement list to receive the launch news and access an exclusive launch promotion, designed to help early users put BitVault’s security model into practice from day one.

Launch updates and promotion details only. Unsubscribe at any time.

What BitVault does not replace

BitVault does not replace secure key generation or the protection provided by the hardware wallets on which it relies. A weak or compromised key remains a security problem and must be replaced.

Its purpose is to limit the consequences: distributed authority, enforced delays and secret notifications can provide the awareness and response window needed to act before suspicious activity becomes an irreversible loss.

This keeps the disclaimer while avoiding another full explanation of the architecture.

What potentially affected Coldcard users should do

The relevant question is not only which device currently stores the seed.

It is where, when and under which firmware the seed was originally generated.

Installing fixed firmware does not retroactively repair an existing seed. Restoring the same seed on another device also leaves the original weakness unchanged.

Coinkite recommends identifying the device and firmware originally used to generate the seed, creating a replacement seed through a fixed and verified process, securely verifying its backup and receiving address, and first sending a small test transaction. The remaining funds should be moved only after the test has been confirmed, while the old backup should be retained until the migration is complete.

For Mk4 and Mk5, Coinkite recommends installing version 5.6.0 or later before generating the replacement seed. For Coldcard Q, it recommends version 1.5.0Q or later. Its advisory also describes an advanced dice-only procedure for Mk3 users who cannot immediately migrate to another suitable device.

A strong and unique BIP39 passphrase may provide an additional independent barrier, but Coinkite still advises affected users to migrate. A short, common, reused or patterned passphrase should not be assumed to provide sufficient protection.

Users of multisig wallets should verify that enough independently secure keys remain to satisfy their signing threshold. Three devices do not provide meaningful resilience when the attacker can reconstruct two of the required keys through the same vulnerability.

Security should survive the failure of a security product

Coldcard has long been recognised as a serious Bitcoin security device. The significance of this incident is not that hardware wallets are useless or that users should abandon self-custody.

The lesson is that no individual device should be treated as an infallible root of trust.

Hardware wallets remain valuable components. But a component is not the same thing as a complete security architecture.

The known theft cluster illustrates what can happen when weak key generation meets single-signature finality: once the attacker reconstructs the secret, there is nothing else left to defeat and no time left to react.

BitVault changes that model by separating one compromised key from complete authority and by introducing time between a spending attempt and irreversible settlement.

It cannot make a weak key strong.

It can prevent the failure of one key from automatically becoming an immediate and irreversible loss.

And in Bitcoin security, that difference can be decisive.

Sources and further reading

• Coinkite — Mk3 Security Advisory: official affected-device guidance, firmware information and migration recommendations.
• Block Bitcoin Engineering and Security — Predictable RNG Fallback and 32-Bit Reseed in Coldcard Firmware: technical source-code analysis and multisig implications.
• Atlas21 — 594 bitcoin swept in fifteen minutes: on-chain reconstruction of the coordinated transaction cluster.
• BIP 112 — CHECKSEQUENCEVERIFY: technical specification for Bitcoin consensus-enforced relative timelocks.
• BitVault Security Paths: normal delayed-spending flow and provider-independent recovery architecture.