If your Coldcard was integrated with BitVault
If your Coldcard was integrated with BitVault, reconstructing its defective private key would not, by itself, have given the attacker immediate control over your bitcoin.
More importantly, this remains true even in the stronger failure scenario: suppose the user created both BitVault user keys using two affected Coldcards, and the same randomness defect allowed an attacker to reconstruct both keys.
In BitVault, those keys are:
- A: the user’s primary hardware-wallet key;
- B: the user’s secondary hardware-wallet key;
- C: an independently generated co-signing key operated by the BitVault Convenience Service.
The relevant spending policy separates ordinary protected spending from sovereign fallback recovery:
Protected spending path:
(A or B) + C
Available through the configured short-delay process
Independent recovery path:
A + B
Available only after the one-year fallback delay
In BitVault’s managed configuration, C is generated and protected independently from the user’s hardware wallets, inside AWS KMS HSM infrastructure. It does not inherit the entropy-generation process used by either Coldcard. The compromise of A and B therefore does not automatically compromise C.
What happens if both Coldcard keys are reconstructed?
Assume the attacker has reconstructed both A and B.
The attacker now possesses the complete signing quorum for the long-term fallback branch:
A + B
But possession of those keys does not make that branch immediately valid.
Before the one-year threshold is reached, a transaction attempting to use the fallback path is invalid under the vault’s Bitcoin-enforced spending conditions. The attacker may be able to construct and sign the transaction in advance, but Bitcoin nodes cannot confirm it before the fallback branch becomes available.
The attacker also cannot unilaterally use the normal protected path:
(A or B) + C
That path still requires C, which exists in a separate signing and entropy domain. Possession of A or B does not reveal, reconstruct or replace C. Any request for C’s signature remains subject to the Convenience Service’s authorization rules, configured delay and notification process.
The attacker is therefore placed in a fundamentally different position from the attacker in a single-signature wallet.
In a single-signature wallet:
Compromised key = immediate spending authority
In the two-Coldcard BitVault scenario:
Compromised A + compromised B = future fallback authority, but not immediate authority
That distinction creates the time required to invalidate the attacker’s future spending opportunity.
Yes, the attacker could spend after one year if nothing were done
The one-year A + B branch is a genuine sovereign recovery path. It is not a simulated recovery feature and BitVault cannot arbitrarily disable it.
That is intentional.
The purpose of the fallback is to ensure that the user can recover the bitcoin without BitVault if:
- the Convenience Service disappears;
- C becomes unavailable;
- BitVault stops operating;
- the user chooses to leave the service;
- or another external dependency fails.
The recovery branch therefore cannot distinguish between the rightful user holding A and B and an attacker who has reconstructed A and B. Bitcoin validates signatures and spending conditions. It does not determine who morally owns the keys.
Consequently, if all of the following happened, the attacker could eventually spend:
- Both A and B were generated with vulnerable Coldcards.
- The attacker reconstructed both private keys.
- The vault’s one-year fallback became valid.
- The user did not refresh or migrate the vault before that point.
- The funds remained in the original vault output.
BitVault’s protection depends on preventing the fifth condition from remaining true.
The vault is refreshed before the fallback matures
BitVault users refresh their protected vault outputs before the one-year fallback becomes available.
A refresh spends the existing vault output through the protected path:
(A or B) + C
and sends the bitcoin into a new BitVault output with a new long-term fallback horizon.
Conceptually:
Old vault V₀
Fallback becomes available at T₀ + 1 year
Before maturity:
V₀ –[(A or B) + C]–> New vault V₁
New vault V₁
New fallback horizon begins
Once the refresh transaction confirms, the old vault output has been spent.
This has an important technical consequence: any transaction prepared by the attacker using A and B against the old output becomes permanently invalid. It references a Bitcoin UTXO that no longer exists as an unspent output.
The attacker cannot preserve the old one-year countdown and apply it to the new vault. The new output has its own spending policy and its own lock horizon.
This is why merely possessing both compromised keys is not enough. The attacker must also wait until the fallback becomes valid while the corresponding vault output remains unspent.
The legitimate user, by contrast, does not need to wait for the one-year fallback. The user can move first through the shorter protected path using one user key together with C.
A concrete example
Suppose bitcoin is deposited into BitVault on January 1.
The vault provides:
Protected path:
(A or B) + C
Fallback path:
A + B after January 1 of the following year
In March, an attacker discovers that both Coldcards used to generate A and B suffered from predictable randomness. The attacker reconstructs both private keys.
At this point:
- the attacker cannot spend through A + B, because that path has not matured;
- the attacker does not control C;
- the user can still spend or refresh through (A or B) + C;
- the existing fallback transaction remains unusable under Bitcoin’s consensus rules.
In October, safely before the one-year threshold, the user refreshes the vault:
V₀ –[(A or B) + C]–> V₁
After the refresh confirms:
- V₀ is spent;
- any attacker transaction spending V₀ is invalid;
- V₁ has a new fallback horizon;
- the user has another protected response window.
If the Coldcard vulnerability is already known, the correct migration is not merely to recreate V₁ with the same compromised seeds. The user should generate new keys through a fixed and independently verified process and create the new vault using replacement keys:
Old compromised policy:
A + B + C
New policy:
A′ + B′ + C
Once the bitcoin reaches the new vault, reconstructed A and B no longer satisfy any spending branch controlling the funds.
Refreshing and rotating keys are not the same thing
This distinction matters.
A routine refresh resets the fallback horizon. It prevents the existing vault from reaching the point at which A and B become independently spendable.
A key rotation removes the compromised keys from the security policy entirely.
If no vulnerability is known, periodic refreshes prevent a silent attacker holding A and B from reaching a mature fallback output, provided the refreshes continue before each deadline.
Once a vulnerability is discovered, however, the recommended response is:
1. Generate secure replacement keys A′ and B′.
2. Verify the new wallet policy and receiving output.
3. Test the replacement setup.
4. Spend the old vault through the protected A-or-B-plus-C path.
5. Confirm the transaction before the old fallback matures.
6. Retire the compromised seeds only after migration is verified.
Resetting the timer buys time. Replacing the keys removes the underlying compromise.
Why confirmation before the deadline matters
The refresh must be confirmed safely before the fallback threshold, not merely prepared at the last moment.
Before the threshold, the attacker’s A + B branch is invalid, so the user has an exclusive consensus-level opportunity to move through the protected path.
After the threshold, both paths may be valid:
User:
(A or B) + C
Attacker:
A + B
At that point, the situation may become a transaction race. BitVault therefore does warn the user and initiate the refresh with a sufficient safety margin for:
- the configured protected-spending delay;
- transaction construction and signing;
- changing fee conditions;
- mempool congestion;
- and block confirmation.
The user has all of the time to easily refresh the UTXOs in-app , anytime in between 6 months to 11months and a half. (12 months – 15 days )
The security guarantee comes from confirming the refresh while the attacker’s fallback branch is still cryptographically unavailable.
Secret notifications solve a different part of the problem
Secret notifications are useful when an attacker attempts to initiate a transaction through a monitored BitVault flow. They can reveal suspicious activity during the configured delay and give the owner time to respond.
However, an attacker holding A and B could silently prepare a fallback transaction without broadcasting it. An unbroadcast transaction is not visible on-chain and cannot generate an on-chain alert.
The defence against that silent attacker is therefore not notification alone.
It is the combination of:
Independent key C
+
one-year restriction on A + B
+
mandatory refresh before maturity
+
key replacement after a known compromise
Why the Coldcard sweep could not have happened in the same way
The known Coldcard theft affected single-signature addresses. Once the vulnerable private keys were reconstructed, the attackers had complete and immediate spending authority. There was no independent signer, no immature recovery branch and no required intervention window.
If those Coldcards had instead been integrated as A and B in a properly operated BitVault:
- Reconstructing A and B would not have provided immediate spending authority.
- The attacker could not independently satisfy the protected (A or B) + C branch.
- The A + B fallback branch would remain unusable until its long delay matured.
- The user could move the bitcoin first through the shorter protected path.
- Refreshing the vault would spend the old UTXO and invalidate any attacker transaction targeting it.
- Rotating to new keys would permanently remove the compromised Coldcard keys from the vault policy.
The precise claim is therefore:
If your Coldcard was integrated with BitVault, reconstructing its private key would not have been sufficient to steal your bitcoin immediately.
And even if both user keys had been generated by affected Coldcards:
Provided the BitVault Convenience Service remained secure and the prescribed refresh occurred before the one-year fallback matured, the coordinated sweep seen in the Coldcard incident would not have happened against that vault output.
BitVault does not make defective randomness harmless. It cannot make a compromised key secret again, and it cannot protect a user who allows a compromised fallback quorum to mature without acting.
What BitVault changes is the failure sequence.
With ordinary single-signature custody:
Key compromise
→ immediate authority
→ irreversible loss
With BitVault:
Compromise of both user keys
→ normal path still requires independent C
→ fallback remains time-locked
→ user refreshes or rotates the vault
→ old attacker transaction becomes invalid
→ funds remain protected
The goal is not to claim that hardware wallets cannot fail.
It is to ensure that even the failure of two hardware wallets does not automatically become an immediate loss of bitcoin.
Check https://www.bitvault.sv/ out , and take advantage of the limited time ongoing offer !