The multi-vendor multisig standard

Three signing devices from different vendors linked in one multisig

On July 30, 2026, an attacker drained 1,196 addresses belonging to Coldcard users, stealing more than 1,000 BTC. Further waves followed until August 6. The toll varies from one report to the next, but the order of magnitude seems to be around 1,700 BTC stolen in roughly a week according to Galaxy, up to 2,400 counting suspect addresses, or more than 100 million dollars. The cause was neither malware nor user error, but a simple random number generation (RNG) bug in the firmware that went undetected for more than 5 years. We already told the story of what happened on August 1, then published the technical autopsy of the bug on August 11.

Since then, 2 pieces of advice have been making the rounds on Twitter: “you should have generated your seed with dice” and “you should have used a passphrase”. These 2 practices did save some of the Coldcard users. However, turning them into a general rule is flawed reasoning, and I will try to show why in this article.

The question to ask is not “what would have stopped this particular flaw?”, but “which security model still holds when the next bug, the one nobody has found yet, hits the device you trust?”.

My answer: the multi-vendor multisig with timelocked recovery paths.

In this article, I explain why it beats dice and passphrases, what the real drawbacks of this type of setup are, and I also give you concrete configurations to set up in Liana, depending on your budget.

TL;DR

• The Coldcard flaw (an RNG bug) revived 2 pieces of advice on Twitter: generate your seed with dice and add a passphrase. Both saved users this time, but turning them into a rule is a hasty generalization compounded by survivorship bias: they counter the last bug, not the next one.
• A multi-vendor multisig is a multisig in which no open spending path can be satisfied with the keys of a single vendor. It is aviation’s dissimilar redundancy applied to Bitcoin: a firmware, entropy, signature, or supply chain flaw exposes only one key, below the primary path’s threshold.
• Combined with Liana’s timelocked recovery paths, it is the one model within any user’s reach that reduces both the risk of theft and the risk of loss without trading one for the other.
• A dice seed done entirely by hand does not exist in practice: nobody computes the SHA-256 checksum manually, so the seed ends up on a machine it was never supposed to touch. Entered into a hardware wallet that enforces a minimum number of rolls, dice settle a single question, trust in the vendor’s RNG, and nothing else.
• The passphrase has no checksum, is sensitive to case, is hard to generate in a truly random way offline, is painful to type for every spend, and creates a second single point of failure against loss. It goes through the same firmware as the seed, so it does not protect against a signature bug, malicious firmware, or a compromised supply chain.
• Tesler’s law: multisig is harder to understand but simpler to use, because the complexity lives in the software, not with the user.
• The only drawbacks of multisig with a recovery path: a more recognizable on-chain footprint and a periodic refresh of the timelocks.
• The backup comes down to the seeds and the descriptor; the encrypted .bed descriptor (BIP-138) can be copied anywhere without risk.
• There is no amount threshold: if the loss would put you in real difficulty, you deserve the best system. And for tight budgets, there are multi-vendor multisig setups that require buying only one hardware wallet.

What is a multi-vendor multisig?

A multisig wallet is a wallet whose bitcoins can only be spent with multiple signatures, produced by multiple distinct keys. This is what we call an “M-of-N” scheme: out of N keys, at least M are needed to sign. In a 2-of-3 for example, you have 3 keys, and any 2 of them are enough to spend.

The word “multi-vendor” adds a constraint on how those keys are stored: each key must live on a signing device from a different brand. A Ledger, a BitBox02, and a Jade, for example, rather than 3 Ledgers. The principle is that no spending path usable today should be satisfiable with keys from a single vendor alone. We will see later how timelocked recovery paths, which stay closed as long as you remain active, fit into this rule.

This constraint has a name in critical systems engineering: dissimilar redundancy.

To tolerate a hardware failure, duplicating a component is enough. However, to tolerate a design error, duplication is not enough, because if the 2 copies share the same defect, they both fall to the same bug. The redundant components must therefore be designed by different teams, with different parts and different software. This is why the fly-by-wire controls of a modern airliner rely on multiple computers built on distinct processors and separately developed software, so that a single bug cannot strike them all at once.

You can apply the same principle to protect your sats. A 3-of-3 built on 3 Coldcards is a multisig, but it is not dissimilar: the July 2026 flaw affected all 3 keys at once, and the threshold would have allowed the funds to be stolen. The same 3-of-3 built on 3 devices from different vendors keeps the funds safe from this flaw, because only 1 key out of 3 is exposed, and a single key on its own is worth nothing to an attacker.

The security margin still shrinks: with 1 key presumed compromised, the wallet now offers only the theft resistance of a 2-of-2 on the 2 sound devices, even though spending still requires all 3 signatures. So you replace the affected device at your own pace, with no attacker racing you.

These devices share, in principle, no hardware, no firmware, no random number generator, no supply chain, no development team… For an attack to succeed, you would need as many independent flaws as there are vendors in the threshold, 3 for this 3-of-3, 2 for a 2-of-3, and you would need to exploit them at the same time on the same wallet, which is obviously far less likely than a flaw at a single vendor.

No hardware wallet vendor is spared

Obviously, with what just happened, all eyes are on Coinkite. The Coldcard flaw is indeed the most serious in its consequences, but it is not an isolated case:

• In 2018, Saleem Rashid bypassed the firmware verification of the Ledger Nano S, which in theory made it possible to ship a device with a predetermined seed;
• The same year, he reconstructed the keys of a BitBox01 hidden wallet;
• In late 2018, Thomas Roth, Dmitry Nedospasov, and Josh Datko (wallet.fail), then in 2019 Ledger’s Donjon, extracted the seed of a Trezor One through fault injection.
• In late 2019 on the KeepKey, then in early 2020 on the Trezor One and Model T, Kraken did the same in about 15 minutes, with a tool estimated to cost under $100.
• In 2020, Shift Crypto showed that a Coldcard could validate a testnet transaction and sign it for mainnet, then, a few months later, that it did not detect the substitution of a cosigner’s xpub in a multisig.
• In 2023, our CEO, Kévin Loaec, found a flaw in the Miniscript encoding of Ledger’s Bitcoin application.
• The same year, Ledger’s connect-kit npm package was compromised through a phished former employee.
• In 2024, the Donjon read and modified the firmware of a Trezor Safe 3 through fault injection.
• In 2025, Blockstream fixed a stack overflow in the Jade.
• And in August 2026, BitBox disclosed and fixed 3 flaws in the BitBox02, one of which would have let an attacker, after a successful phishing attack, trick the user into installing malicious firmware on an authentic device.

This list is only a sample. There are dozens more disclosed vulnerabilities across the ecosystem, and the goal here is not to catalog them all. Also keep in mind that a vendor with fewer entries is not necessarily safer, since the count mostly reflects who gets audited and who publishes.

None of these incidents makes the vendors involved bad vendors, and the conclusion is not to go looking for the perfect vendor, because it does not exist. What the Coldcard incident and all these other vulnerabilities should teach us is simply to accept the fact that hardware wallets, and more broadly any system, can have flaws. There is no such thing as zero risk, in any system.

However, protecting bitcoins is not like protecting just any data. A stolen password can be changed, fraudulent card charges get refunded, a deleted file can be restored from a backup… A Bitcoin transaction, on the other hand, cannot be canceled. And bitcoin is money, meaning years of work, a family’s safety net, freedom, a project, a retirement… A loss like that is not easily recovered from. That is why a level of risk we would tolerate in other computer systems becomes unacceptable here. The goal for Bitcoin users is therefore to build a wallet that survives a flaw in any one of the devices used to store or handle private keys.

Note also that dissimilarity is never total. For example, the Trezor One and the KeepKey shared the same STM32 microcontroller. Coldcard and BitBox02 also use the same secure element, Microchip’s ATECC608. Coldcards long used a cryptographic library derived from Trezor’s (before the vulnerability was introduced). All devices implement BIP-32, and all receive their transactions from the same computer. You can go lower still, since they all sign on the secp256k1 curve, most of them with the same libsecp256k1 library from Bitcoin Core or one of its forks.

Choosing different vendors therefore does not guarantee perfectly independent failure modes. There are always components, however low-level, shared by two devices from different brands. But choosing multi-vendor multisig gets you as close to dissimilarity as you can get today, and every shared layer removed is one less common failure mode, and therefore a smaller attack surface. The advantage of multi-vendor multisig is that one simple decision knocks out a large number of your wallet’s single points of failure (SPOFs).

What does multi-vendor multisig protect against?

To judge a security model, you have to test it against the 2 ways of losing your bitcoins: theft and loss. Theft is someone else spending your funds. Loss is when nobody can spend them anymore, including you.

Almost every solution offered to individuals reduces one risk at the expense of the other. The passphrase reduces theft and worsens loss. Keeping 3 copies of the seed reduces loss and worsens theft. Multisig alone, at full threshold (N-of-N), reduces theft but worsens loss, since you now have to keep multiple seeds and losing a single one dooms the funds.

Against theft, the multi-vendor multisig covers a much wider class of risks than a single device:

• An RNG flaw like Coldcard’s: only 1 key out of N is predictable, which falls short of the threshold.
• Buggy or malicious firmware that signs incorrectly or exfiltrates the seed inside a signature: each device provides only one of the required signatures and knows only its own key.
• A device tampered with in the supply chain, for the same reason.
• A lying screen: a compromised device can display a fake address, but each signing device checks the destination address and the change address against the registered policy, and you can display a receive address on any of your devices. The attacker would have to fool every device you check with the same fake address.
• Physical theft of a device or a seed: one key on its own is useless.
• A flaw in a chip or secure element specific to one vendor: the other devices use different chips.
• A reused or biased signature nonce, which reveals the private key of the faulty device: it reveals only that one.
• A compromised firmware update or a firmware signing key stolen from a vendor: it only affects the devices of that brand.
• And so on.

In all these cases, the reasoning is the same: the attacker has to succeed against multiple independent targets at the same time.

Loss is where timelocked recovery paths come in. A Liana wallet can do much more than a fixed M-of-N scheme thanks to Miniscript. It defines a primary path, spendable at any time, and one or more recovery paths, locked behind a delay expressed in blocks, which only become usable if the bitcoins have not moved for that long. In practice, a 3-of-3 for everyday use can be set up so that after 6 months of inactivity, 2 keys are enough, and after 12 months, a single one is. Lost a device? No rush: you wait out the delay, then you move the funds with the remaining keys. Lost 2? Same thing, a bit later. These conditions are written into the Bitcoin script itself, via Miniscript, and enforced by consensus. Nobody can open a recovery path ahead of time.

This combination is what makes the model interesting. The multi-vendor multisig reduces the risk of theft, the timelocked recovery path reduces the risk of loss, and neither worsens the other, since the recovery paths are not immediately accessible. Theft protection stays at full threshold day to day, and loss is covered by the passage of time rather than by extra keys to protect. No other trustless solution reduces both risks at once without trading one off against the other.

Now let’s look at the alternatives and why I think they fall short of multi-vendor multisig for Bitcoin users.

The seemingly good answers to the flaw

Let’s come back to the other 2 pieces of advice that have flooded Twitter since July 30.

“Roll your own dice”

The first reaction to the flaw was to say that the problem came from trusting the vendor’s random number generator, and that the solution was to produce your own entropy, with dice. The reasoning is not wrong, but it is incomplete. There are only 2 ways to turn dice rolls into a seed.

The first is to do everything by hand on paper. Converting the rolls into words is easy but the checksum is not. The last word of a BIP-39 phrase contains a checksum (4 bits for 12 words, 8 bits for 24) computed from a SHA-256 hash of the entropy. Computing it by hand is possible in theory, but nobody will. It takes far too long and the slightest error forces you to start over.

So in practice, a dice seed done entirely by hand does not exist. Either a hardware wallet finishes the job, and you are in the second method below, or you end up typing your rolls into a computer, at best on Tails OS and offline to limit exposure during generation, but it is still a computer, with its enormous attack surface. And you are putting on that computer the very seed that, by the definition of a hardware wallet, was never supposed to leave the device. That makes it a very bad practice.

BitBox offers an option to get around the checksum: roll your first 23 words with dice, and the BitBox computes the valid 24th word for you. This softens my first argument, since a hardware wallet finishes the job instead of a computer. But it has to be a BitBox02, even if that is not the wallet you planned to use, and the human risks around the rolls, which we will get to, remain the same.

The second is to enter the dice results directly into a hardware wallet that offers this option, like Coldcard or SeedSigner. This is much better, because the conversion of the rolls and the checksum computation happen inside the device, and this is the mode that did protect the affected Coldcard users. But there is still an important condition: the device must enforce a minimum number of rolls of a 6-sided die: 50 for 128 bits, and 99 for 256 bits. If it does not enforce it, the user can create a very weak seed without knowing it.

And even inside the device, the quality of the seed still depends on what the human provides, because the device builds it by hashing your rolls, but does not add any entropy. The problem doesn’t come from the die itself. An ordinary die is fine: the largest study on the subject, 4.38 million recorded throws, found precision casino dice indistinguishable from perfect, and only a tiny bias in cheap dice with drilled pips. The dangers are human, because a digit typed from memory instead of a real roll carries almost no entropy, skipped rolls shrink the total, and a series of rolls that has been observed or photographed is no longer a secret. Coinkite sums it up in 3 adjectives in its documentation: fair, independent, and private rolls. But each of the 3 is an opportunity to get it wrong with no warning light ever coming on.

You also need proof that the device actually turned your rolls into the seed, and that the keys come from that seed. Checking it directly, without trusting the vendor, means redoing the computation on a second device from another brand (same rolls in, same words out if both use the same derivation method, then import the words and compare the xpubs). At this point you already own 2 devices from 2 different vendors, the first step of a multi-vendor multisig, except that here both hold the same seed, so a flaw in either one exposes it. There is a lighter, indirect check: run throwaway rolls through the device, reproduce the expected result with a program on a computer, and if they match, start over with real rolls, this time without ever exposing them. This catches a bug, not a firmware that misbehaves selectively. And these checks alone are more complex than setting up a multisig.

And even done well, this mode settles a single question: trust in the vendor’s random number generator. It does not protect against firmware that signs incorrectly, a lying screen, a compromised supply chain, seed exfiltration inside a signature, or anything else that can happen to a single-sig on a single device.

Add to this the fact that generating a seed with dice is complex and nearly impossible to do properly outside a device, and that we are not going to ask every beginner to do it. When people object that multi-vendor multisig is complicated, I answer that the dice seed is far more so.

“Add a passphrase”

The second piece of advice is even more widespread: use a single-sig with a passphrase.

The BIP-39 passphrase is free-form text that the wallet adds as a salt in the function that turns the mnemonic phrase into the binary seed used for key derivation, so that knowing the mnemonic phrase alone is not enough to derive the private keys, and therefore to spend the wallet’s bitcoins. You need both the mnemonic phrase and the passphrase to derive the keys.

This construction has 3 direct consequences:

• First, there is no checksum. Every passphrase generates a valid seed, and therefore a valid (and empty) wallet, with no error message at all.
• Second, the passphrase is sensitive to case and spaces.
• Third, the passphrase is a full second secret: backing it up is no easier than backing up a second key.

The specification also requires Unicode normalization (NFKD) that not every implementation applies: bitcoinj, for example, derives the seed with the raw passphrase, unlike other wallets such as Sparrow that follow BIP-39. A passphrase containing an “é” can therefore open 2 different wallets depending on the software.

None of this is necessarily obvious to a beginner, which is why, if you want to use a passphrase, I believe you first need a solid understanding of HD wallet architecture and its implications, otherwise you are headed for disaster.

But beyond how the passphrase works, generating it is the really hard part. A passphrase is only as strong as its entropy, and humans are terrible sources of randomness. For it to be a real protection if the mnemonic phrase is ever compromised, it must be generated randomly and offline. That is not something you do naturally, on instinct, by picking a password that means something to you. It takes dice and a proven method, and the passphrase must never be typed into or generated on a computer. Judging by what people have been posting on social media since the Coldcard flaw, I think most passphrase users did not follow this kind of method, and that their passphrase is much weaker than they believe.

Also, the passphrase is not meant to be memorized. The lengths required for it to be truly effective make it nearly impossible to keep in your head. So beyond the fact that keeping it only in your head is extremely risky, if you know yours by heart, it is most likely either not long enough or not truly random.

Still, let’s assume you generated, offline, a passphrase that is long enough and truly random. Now you have to live with it. Day to day, the passphrase is not stored on the device by default; you retype it every session (unless you use an option some devices offer to store it, like a Ledger with the passphrase attached to a secondary PIN).

Typing it in is no easy task on small 2-button devices. You have to select each character from a long list, one by one, without a single mistake, or you start over. Anyone who has ever tried to enter a passphrase on a Coldcard Mk or a Nano S, for example, knows how long and tedious it is.

The argument that day-to-day spending would be simpler with a passphrase single-sig than with a multisig is, in my view, wrong. A multisig admittedly takes longer to set up initially, but once configured, it is much simpler to plug in 2 or 3 devices and sign with them than to manually type a 40-character passphrase you do not know by heart on a 2-button device for every single transaction.

Then you have to back up this passphrase. It is a second critical backup element, to be engraved on a durable medium and stored in a different place from the mnemonic phrase, with no reset or recovery mechanism. In other words, the passphrase does not reduce single points of failure; it creates a second one. Lose the mnemonic phrase, everything is lost. Lose the passphrase, everything is lost too. The passphrase reduces the risk of physical theft of the mnemonic phrase, true. But it doubles the risk of loss, whereas the multisig with a recovery path reduces both at once, while simplifying the backup even further if you go seedless (more on that below).

That leaves the question of what it protects against, and what it does not (provided it is long and random enough). It protects against physical theft of the mnemonic phrase, against extraction of the mnemonic phrase from a device at rest, and, in the specific Coldcard case, against enumeration of a reduced mnemonic space. Every other type of flaw goes right through it, for a simple reason: the passphrase goes into the same firmware, on the same device, as the mnemonic phrase. Firmware that signs with bad nonces, or that deliberately exfiltrates the mnemonic phrase in the nonces of a few signatures, can just as easily exfiltrate the master key already derived with the passphrase. A device compromised in the supply chain, a screen displaying a fake address, a derivation flaw, an attacker forcing you to type your passphrase in front of them: in all these cases, there is still only one key to compromise.

A multi-vendor multisig, by contrast, puts each signature on a different device, so that a compromised device leaks only a fraction of what is needed to spend, each signing device checks the destination against the registered policy, and an attacker has to gather multiple signatures in multiple places.

The last-bug fallacy

What bothers me most about the 2 previous pieces of advice is not that they are useless; it is the reasoning behind them: “dice and passphrases saved Coldcard users, therefore dice and passphrases will save you”. That is a hasty generalization, drawing a rule from an isolated case, compounded by survivorship bias. We look at the Mk3s that were saved; we ignore the forgotten passphrases, the weak ones that got cracked, and the bugs that have nothing to do with entropy.

This is what strategists call “fighting the last war”. The textbook example is the Maginot Line: after 1918, France drew the lessons of trench warfare and spent the 1930s building a line of fortifications along its border with Germany, ready to hold the front of the previous war. In May 1940, the Wehrmacht simply went around it through the Ardennes and Belgium, and France fell in 6 weeks. The July 2026 flaw was an RNG flaw, and dice counter exactly that class of flaw. Building your whole defense around it is building your own Maginot Line: the next flaw may be a signature, display, derivation, or supply chain flaw, and neither dice nor a passphrase will make any difference.

A security model is not judged by its ability to counter the last known bug, but by its ability to survive the next one, whose nature nobody knows yet. That is precisely what dissimilar redundancy does: it assumes nothing about the nature of the flaw, only that it is unlikely to hit several independent vendors at the same time.

The 2 drawbacks worth conceding

To be entirely honest, the model I am defending has 2 real drawbacks to take into account.

On-chain privacy

The main objective disadvantage of multisig versus single-sig, with or without a passphrase, lies in its on-chain footprint. When you spend from a P2WPKH single-sig, the transaction reveals one signature and one public key, like tens of millions of others. When you spend from a P2WSH multisig, however, the transaction has to reveal the full script so that nodes can verify it: the number of keys, the threshold, all the public keys including those that did not sign, and, in Liana’s case, the recovery paths and their timelocks. This footprint is very distinctive. Across the whole UTXO set in April 2025, according to the mempool.space report, P2WSH outputs made up barely 1% of the total by count, versus 26.5% for P2WPKH. You are in a much smaller anonymity set, and even within that set, your wallet has distinguishing features the others do not.

Taproot mitigates the problem without making it disappear. Liana has supported Taproot since version 5. If the primary path is a single key, that key becomes the internal key, everyday spending goes through the key path, and nothing distinguishes your wallet from a Taproot single-sig as long as you do not use a recovery path. But if the primary path is a multisig, key-path spending is not possible yet: it requires signature aggregation, which will come with MuSig2 support in Liana, currently under development. For now, the multisig lives in a script leaf, and spending reveals that leaf (the keys of the path used and the threshold), even though the other paths and their timelocks stay hidden. That is better than P2WSH, but the footprint remains distinctive, inside a small global anonymity set.

There are 2 things to say to put this drawback in perspective, in my view:

• The first is that this is a trade-off, and most people are right to settle it in favor of security: a more recognizable on-chain footprint costs you no bitcoin; a firmware flaw on a single device costs you all of them.
• The second is that this does not make a multisig unmanageable privacy-wise, and you can always keep a hot spending wallet on the side with small amounts, where maintaining privacy is much simpler. Staying private simply takes a bit more care, because the starting point is more recognizable.

Refreshing your coins

The second drawback comes with the recovery paths. A recovery path opens when the bitcoins have not moved for a certain number of blocks. So before the deadline, you have to move them: that is the refresh, a transaction from the wallet to itself, signed by the primary path, which resets each UTXO’s counter to zero. It costs an ordinary transaction fee, and you have to remember to do it. Note that this delay has a ceiling, and it does not come from Liana. The relative timelock is encoded in 16 bits of the nSequence field, which caps the wait at 65,535 blocks, or about 15 months. That is a consensus rule, the same for all software, independent of Liana’s implementation choices.

This drawback has an upside I find interesting. With a classic savings wallet, you put the seed away, touch nothing for 5 years, and the day you need it, you no longer quite remember how everything works. The refresh forces you to open the wallet, plug in your devices, and sign a transaction every 6, 12, or 15 months. It is a forced check-up: the opportunity to verify that the devices boot and that you still know how to use them. Seen that way, the refresh is the maintenance cost of your custody: one transaction fee every 6 to 15 months, likely less than the annual fees of any bank account or insurance policy. A wallet you never check is a wallet whose condition you discover on the day you need it most.

Harder to understand, simpler to use

Next comes an argument I often hear: multisig with recovery paths is more complicated. That is true. Understanding a 3-of-3 that becomes a 2-of-3 after 6 months takes more effort than understanding “a seed plus a password”. However, you have to distinguish the complexity of understanding it from the complexity of using it, and on that second point, the situation flips completely.

Larry Tesler, a pioneer of human-computer interaction, formulated in the mid-1980s what has since been known as Tesler’s law, or the law of conservation of complexity: every application contains an irreducible amount of complexity, which can be neither removed nor hidden. The only question is who carries it: the software, or the user.

Let’s apply this lens to the 2 models:

• The passphrase is trivial in code: it is just a salt added to a derivation function. All the complexity is pushed onto the human: generating enough randomness offline, retyping the passphrase for every spend, backing up a second secret with no checksum on a durable medium in a separate location, writing down the wallet’s master fingerprint to detect a typo…
• Multisig with recovery paths is complex in code: Miniscript, descriptors, relative timelocks, path management, all of that lives in Liana and in the devices’ firmware. What the user sees, meanwhile, is very simple: ordinary 12- or 24-word seeds, each with its checksum, a descriptor file to copy everywhere, and a transaction that asks you to plug in a device and confirm.

Multisig is not complicated to back up

The complexity of a multisig backup was real as recently as 5 or 6 years ago: setting up a multisig yourself meant understanding that the seeds are not enough, that you also need to keep the xpubs of all cosigners and the derivation paths. Otherwise you risked ending up with 2 valid seeds out of 3 and inaccessible funds for lack of a piece of public data. And on top of that, there was no standardization across software.

Since then, descriptors have changed everything. A descriptor is a standardized text string that fully describes the wallet: the script type, each cosigner’s extended public keys with their origin, the thresholds, the recovery paths and their timelocks if any. A Liana wallet thus comes down to 2 things to back up: the seeds (one per key, unless you choose not to back up those of the primary path, as I will show below) and the descriptor.

Now these 2 things do not belong in the same risk category. The seed is secret: whoever finds it can sign on your behalf, so you want as few copies as possible. The descriptor is merely private: whoever finds it cannot spend a single satoshi; they can only read your balance and your history. The right strategy is therefore few copies of the seed, many copies of the descriptor. The only thing holding back that multiplication was privacy, since a cleartext descriptor on an online service exposes your holdings.

That is what the encrypted descriptor solves. Since version 13, Liana produces by default, at wallet creation, a .bed file (Bitcoin Encrypted Descriptor), whose scheme has since evolved into a draft standard, BIP-138, written by Pythcoiner from an idea by Salvatore Ingala. The principle is this: instead of inventing an encryption key that would in turn need backing up, the descriptor is encrypted with the public keys it already contains, its own xpubs. Any one of those xpubs is then enough to decrypt it, and you already hold them, since they can be re-derived from your seeds or read from your devices. No new secret is created. The result is a file unreadable by anyone who holds none of the wallet’s xpubs, which you can therefore copy anywhere without any precautions at all: to Google Drive, to your email, to a USB stick, on your computer, at a relative’s… Backing up the descriptor stops being a matter of complexity and becomes a matter of redundancy, and redundancy no longer costs anything.

Multisig is not too expensive for individuals

Finally comes the price argument. Buying 2 or 3 hardware wallets from different brands is an investment, and some conclude that multisig is only for those holding more than a certain amount. I do not believe there is a threshold above which multisig becomes necessary. The only boundary is at the bottom: if the price of a hardware wallet is out of proportion to what you hold, no setup is justified, and a mobile wallet will do. Beyond that case, the right question is not “how much do I have” but “what would losing it do to me”. If losing that sum would put you in real difficulty (financial, psychological, or family-related), then it deserves the best security system you can reasonably set up, and that best system today is the multi-vendor multisig with a timelocked recovery path.

Especially since multi-vendor does not necessarily mean buying several devices. The first configuration I describe below requires only one, complemented by a key on your computer, and it already beats a single-sig, with or without a passphrase, on both theft and loss.

Concrete configurations in Liana, depending on your budget

Everything above remains theory until we get concrete about what to install. So here are 5 configurations, from the most accessible to the most complete. All of them are built in the Liana installer with the “Build your own” mode, which lets you freely define each path, its threshold, and its delay.

Liana supports any hardware wallet that implements Miniscript, and we add new ones as soon as support for them lands. The full list as of today (August 17, 2026):

• Ledger: Nano S Plus, Nano X, Stax, Flex, and Nano Gen 5.
• BitBox: BitBox02 and BitBox Nova.
• Jade: Jade, Jade Plus, and Jade Core (note that the Jades only support Miniscript in native SegWit, not in Taproot).
• Specter DIY.
• Krux.

Whichever ones you pick, the rule is always the same: no open spending path should be satisfiable with keys from a single vendor alone. For the primary path, this holds at all times. For recovery paths that need a single key, it holds as long as you refresh your UTXOs before the deadline.

1. A single hardware wallet and a hot key

This is the entry-level configuration, and it requires buying only one hardware wallet. The primary path is a 2-of-2 between this hardware wallet and a hot key, that is, a key stored on your computer, which Liana can generate directly in the installer. The recovery path is a 1-of-2 on those same 2 keys, which opens after 12 months of inactivity, or about 52,600 blocks.

The hot key lives on a connected computer, and its 12-word mnemonic is stored in cleartext on the disk. Taken alone, it is far less secure than the hardware wallet’s key. But it is never used alone, and that is precisely what makes it acceptable here. To steal your funds before the recovery path opens, an attacker must compromise both your computer and your hardware wallet, and there is very little chance that a single bug hits a mainstream operating system and the firmware of a dedicated device at the same time. It is multi-vendor in the broad sense: the 2 share neither the same code nor the same attackers.

If tomorrow your hardware wallet suffers a flaw the size of Coldcard’s, an attacker who recovers its seed can do nothing without your computer’s key as long as the recovery path stays closed, whereas a single-sig on that same device, with or without a passphrase, could be drained.

On the loss side, the recovery path does the work: if the computer dies and you no longer have the hot key’s mnemonic, the hardware wallet alone recovers the funds after 12 months, and if the hardware wallet disappears, the hot key alone does the same (with the descriptor, of course).

Day to day, this kind of wallet is very simple to manage, since a spend requires one signature from the hardware wallet and one from the hot key, which Liana adds itself. You plug in the device, you confirm, and that’s it, like a classic single-sig.

2. The decaying multisig

If you can get hold of multiple devices, the most general configuration is the decaying multisig. The primary path is a 3-of-3 on 3 hardware wallets from 3 different vendors. A first recovery path turns it into a 2-of-3 after, say, 6 months of inactivity, and a second into a 1-of-3 after 12 months.

The everyday 3-of-3 is the maximum level of theft protection: 3 devices from 3 different brands would have to be compromised. The 2-of-3 after 6 months covers the loss or failure of one device, with no need to rush. The 1-of-3 after 12 months covers the loss of 2 devices. You can even add an inheritance path with a timelocked fourth key belonging to a relative.

A single flaw at one vendor, like the July 2026 one, defeats neither the 3-of-3 nor the 2-of-3.

3. The expanding multisig

The expanding multisig does the opposite: instead of lowering the threshold over time, it adds keys. The primary path is a 3-of-3 on your devices. After n months of inactivity, a recovery path becomes a 3-of-4 by adding a key, for example a backup key kept elsewhere or a key entrusted to a relative; after n more months, a 3-of-5 by adding yet another key, which can be a service provider’s if you wish.

The point is to never concentrate spending power in fewer keys than at the start. The threshold stays at 3 while keys are added, which suits cases where the added keys are held by other people: none of them can act alone, nor can any 2 of them together, and yet the loss of one of your devices is covered as soon as the first path opens, and the loss of 2 as soon as the second does.

4. A multisig with a separate recovery key

Nothing requires you to reuse the primary path’s keys in the recovery paths. A 2-of-2 or a 3-of-3 for everyday use can, after 12 months of inactivity, hand recovery to an entirely different key. That key can be yours, stored somewhere else, which protects you from a disaster that would take out every device on the primary path; or an heir’s, who has no power whatsoever as long as you are active and refreshing your UTXOs, and who, if you pass away, can then recover the funds without you and without any third party.

5. Going seedless on multisig

This last configuration is less a setup of its own than an add-on to configurations 1, 2, and 4, and it directly answers those who find multisig “overkill” for an individual because it multiplies the number of seeds to protect.

With timelocked recovery paths, the primary path needs no seed backup. In practice, you configure your hardware wallets, you never write down their 12 or 24 words (or you destroy the backup afterwards), and you back up only the recovery key’s seed, plus the descriptor. This is what we call “seedless”: the primary path’s keys exist only inside the devices.

What you gain is a physical attack surface cut to the bare minimum. There is no longer a metal plate at home that gives anyone who reads it access to the funds. A burglar who walks away with your devices walks away with boxes protected by a PIN code and, on models with a secure element, with no known way of extracting the seed (still, do not store all the primary path devices in the same place!).

You, meanwhile, wait for the recovery path to open, then move the funds to a new wallet.

What you lose is the ability to restore a primary device exactly as it was: if a device breaks, if you forget its PIN, or if an update wipes it, you go through the recovery path, after waiting out the delay you chose.

Resources

• Download Liana: lianawallet.com
• Our first analysis of the Coldcard flaw: Critical Coldcard flaw: what happened, who is affected, and what to do
• The technical autopsy of the bug: Coldcard: the technical autopsy of an entropy failure
• Understanding recovery keys: What is a Bitcoin recovery key?
• Managing recovery paths and the refresh: Managing recovery paths in Liana