With the recent Coldcard emergency, I have seen a few people publicly mention they were in situations like this:
They were either away their seed / device and were put under pressure in the race against the clock to move funds off vulnerable seeds.
Now that many people are rethinking first principles towards entropy, security practices, and trust after the Coldcard bullshit, I wanted to share an idea I had earlier in the year.
Full disclosure, I emailed this idea to Jameson Lopp for his input, summarising his feedback under "Caveats".
Sharing as I wrote it below, but I think this situation applies not just to a hardware wallet failure mode, but also to the situation many Coldcard users were in.
Using unbroadcast Bitcoin transactions as a complimentary mode of securityUsing unbroadcast Bitcoin transactions as a complimentary mode of security
Originally written in January 2026
The premise of Bitcoin ownership is "the ability to spend funds = owning the Bitcoin". In practice this means many people use a hardware signing device, with a backup of the seed phrase on steel etc (with various levels of redundancy).
In the situation when someone is a plane flight or long drive away from their seed for whatever reason, they may go to spend Bitcoin and find that their hardware signing device has had some kind of failure (screen, USB port, etc) meaning they cannot spend funds without immediately going and finding the seed.
Conceptually, that person is down to "no layers of redundancy" for their ability to spend. It may take days or weeks to then return to a safe place of redundancy. What if upon trying to find their seed they discover something has happened to it?
Once a year we are encouraged to undertake "proof of keys" to confirm that we in fact have access to the seed and can sign transactions. A lot can happen in a year. With a simple 1 seed plate + 1 signing device setup, this means that there are many moments when we are possibly in a state of not fully knowing if we have redundancy in our ability to spend, or not (Schrödinger's Bitcoin).
Having backup signing devices or copies of the seed is one way of ameliorating this somewhat, but can come with its own costs and logistical and security challenges (Theft of the seed).
Multi-sig is not a solution for this failure mode, it only makes it more complex as you have to go and find all the seeds etc in an emergency.
My idea is whether there is another mode of "peace of mind" available here, something like having a finalized and signed Bitcoin transaction that spends some / all of the UTXOs from the wallet into a second wallet that we also have access to. The transaction can be signed and saved to an SD card etc and broadcast in an emergency.
To me, this "backup" has a slightly different security profile to a seed and could perhaps even be stored on computer or on your persons in a way that a seed cannot.
In the case that our user finds their signing device has failed, they are not instantly down to a single point of failure with a seed that may not be immediately accessible, but instead they can calmly assess the situation knowing they can always broadcast the saved transaction and receive the funds to the second wallet, if they need to.
The are some additional benefits such as:
- Being able to invalidate the unbroadcast transaction by simply consolidating the UTXOs.
- Can simply drag and drop the file into mempool.space etc to be broadcast if on the road or in less-than-ideal situation.
- Is a powerful counter-measure in an actual attempt to sweep the funds into a malicious wallet if you have watch notifications setup, could have a high fee RBF version of the transaction saved and ready to deploy.
- When spending from the original wallet, this process encourages the user to follow the hygiene of regenerating the unbroadcast transactions and saving to SD again immediately in the same session, reducing the chance that a silent failure etc will impact the signing device while it sits unused.
- Avoids needing to use a company or "service" at all, the solution lasts indefinitely.
Of course there are various peace of mind services, including Casa that exist in this space, but what do you think about it from the perspective of what an individual is able to do with the various open source tools available?
Caveats (summarised) from discussion with Jameson LoppCaveats (summarised) from discussion with Jameson Lopp
- Every time your wallet changes UTXOs, via either a deposit or a withdrawal, you need to recreate the pre-signed transaction.
BUT being able to save some of the UTXOs rather than none seems reasonable. Also, how often are cold storage UTXOs moving?
- The second "destination" wallet also has to be maintained.
AGAIN, something is better than nothing, and having a tested and secure redundant setup here seems like common sense to me for substantial holdings.
- Need to be somewhat careful with the presigned transactions so that it is not broadcast accidentally or made public.
Fair point.
So what does SN think about this approach to the challenge of an alternative failsafe mode?
My general feeling about presigbed but not broadcasting them creates more liability than redundancy/flexibility.
Lopp's points are great and I don't know that I can add to them, but I will saw an unbroadcasted tx quickly gets out of date, unless you truly aren't touching the wallet.
There have been a number of signed but not broadcasted transaction schemes (can't think of their name right now), but mostly they don't catch on because it adds so much complexity.
This seems like a good solution though for someone in this example? Say you are going on vacation and won't be touching your wallets the whole time. You could bring these pre-signed transactions with you and then just delete them when you get home.
What is an alternative that would work in this case to provide a failsafe?
Forgot to mention that in our corresponce, Lopp reminded me that what I describe above is currently the only feasible way to create any sort of "covenant" functionality in Bitcoin. Somewhat related article on covenants from his company: https://blog.casa.io/why-bitcoin-needs-covenants/
I was going to say, you're basically talking about what vaulting/covenants would add, but with an inferior mechanism.
I personally am not opposed to it in principle as long as recursion is cut out (i.e. you can restrict what your utxo spends to, but not influence the utxo after that through the prior one.) You can still prefabricate a chain of course.
Unfortunately, people burn out on getting this functionality to a point of activation, which also means that it is hard to get the story - as they're burned out - as to what the difficulties truly are.
Note that key loss and even insufficient entropy on a seed can still cause all sorts of trouble so it doesn't solve any of the real problems we have today on its own. You still need good entropy. You still need good key retention and secrecy. You still need to roll keys. You still need to be mindful, actively manage your stack, have watch-only alerts, and hedge everything. So this isn't a silver bullet and it will cause new ways to lose your hard earned stack.
Sorry you mean, my idea is inferior to covenants or vice versa (lol)?
The approach I describe does not have the range of functions etc of a full covenant setup, but we may never get consensus on covenants, and it will take even longer for it to get integrated into wallets.
As of today - It seems for the simple use case of having an emergency failsafe, what I describe works but has not been given much thought or discussion AFAIK.
I don't think it is that much work for someone to presign cold storage UTXOs in Wallet A to Wallet B and keep the file in a safe place "just in case".
Yours is inferior. I can destroy it for you step by step but it is a waste of time, and probably better to look at the superior non-interactive proposal that is already there.
I don't understand, covenants don't even exist. What I suggest works today on the protocol and would have helped the guy in the screenshot at the top of the article. Can you clarify your position please?
Like I said, it's a bit of a waste of people's time, but let me be nice and waste my time.
Let's say everyone does this. Attack happens. Everyone now publishes their tx. The first thing that happens is congestion. You don't know what the fee in the future will be especially during congestion. So now you're going to have to do p2a and sign a child tx too in the same go, with the right fee. This means that you have to have at least the anchor device on you, and that needs to be not vulnerable to whatever is going on.
Now, if you're going to have a presigned tx to a place that you carry on you, and a means to trigger said presigned tx, then you still have everything on you and your entire stack is hot. If you presign p2a to a third device with only the anchor on you (see how complicated this is getting?) then now you:
This is why, I think that sure you can do this, but it is not in your interest to standardize it, because it doesn't scale.
PS: it's a bit rich to within 24h complain about LARP and then do it yourself and ask for more LARP.
I think it's a great idea particularily for when quantum resistant addresses become available.
It adds some complexity to ones cold storage setup, but once set up you'd probably only need to deal with it once a year.
I might add one thing. If this is for an emergency, broadcasting the TX fees needs to be set high as we have no idea what fees will be at any given time in the future.
The idea I am trying to work out is: Without literally duplicating a seed / HWW and stashing them - what other "failsafe modes" do we have to retrieve our Bitcoin just in case we lose access to either the seed or device.
The risk with having extra copies of a seed hidden in different places is that they all become theft risks and each seed give "full permission to spend" (unless you have a passphrase, which can be brute forced or forgotten, and introduces its own management complexity etc). Whereas, by using a pre-signed unbroadcast transaction to a fallback address you have something at least, that you can can use in an emergency to move the funds if all else fails.
Even with a passphrase in place, if your HWW screen fails, and it just so happens that the place you thought your seed was stashed has been compromised, suddenly you have no Bitcoin anymore. In most people's setups I imagine their whole setup could silently fail and they might not even notice for months.
Some of the comments in this thread don't seem to grasp the value of this, which makes me wonder if I have overlooked something.