Your money should not hang on a single key

One key can spend everything

Most people start self-custody with a single-sig wallet. One seed phrase, one private key, one device. That is simple, and simple is good. But it also means that one matching key is enough to spend everything the wallet protects.

It is a bit like cash. Whoever holds the bills can spend them. Nobody asks if it is really you. With a seed phrase it is the same, only that the bills can be copied without you noticing, and the copy is worth exactly as much as the original.

That is why I wrote on X that multisig, ideally across different manufacturers, has to become the standard for self-custody. Not because one device is bad. Because one stolen seed should not mean total loss.

Losing a device is not the same as losing a key

If only the device breaks, a usable backup can restore access. If only the paper with the seed phrase gets lost, the bitcoin are not automatically gone, as long as a usable key still exists somewhere.

Losing the device, losing the backup and having a key stolen are three different problems. People mix them up all the time, and then they protect against the wrong one. A second device in the drawer helps against the first problem. Against the third it does nothing.

A stolen seed does not need your device

It is a different story when someone gets the full seed phrase and no additional unknown passphrase is required. The attacker can then restore the keys on another device. They do not have to unlock your hardware wallet or get past its security chip.

All the effort that went into the device, the secure element, the PIN, the seal on the box, does not count anymore at that moment. The seed is the wallet. The device is only one place where it was used.

This is the point where I stop thinking about better devices and start thinking about more than one key.

Copies are not independent keys

A simple 2-of-3 multisig has three different keys, and two of them have to approve the same transaction. One stolen key is not enough. If one key fails, the other two can still sign. The security does not come from a key being harder to steal. It comes from the first successful attack not being enough yet.

That is different from several copies of the same seed. Three devices with the same key may help with availability, but they are not three independent signers. Whoever controls one copy still has the full signing power of that single-sig wallet.

I think this is the most common misunderstanding. People make three copies and feel three times as safe. Against loss, maybe. Against theft, every copy is one more place where the whole wallet can be stolen.

Independent signers must not share one failure

Under my post, someone objected: if hardware wallets might have backdoors, why would you just buy more hardware? The question is fair. More devices alone do not solve the problem.

If several signers run the same faulty firmware or the same compromised dependency, one attack can hit several keys at once. Different manufacturers can reduce that shared risk, but different brands can also share components or software. Two logos are not proof. What matters is whether the failure that hits the first signer also reaches the second.

That this is not only theory shows a case Ledger confirmed itself, an unauthorized hardware implant in an affected device, with a reseller named in its statement. An implant does not automatically mean a key was read out, but a device arriving at your door unchanged is an assumption, not a fact.

So I trust different kinds of signers more than more of the same. A hardware wallet, a phone, a server that signs under its own rules, a key kept in a different place.

Several signatures can confirm the same mistake

Multisig does not automatically protect against a wrong payment that all required signers approve. A manipulated wallet interface could, for example, write a different destination address into the transaction. If every signer just takes over the same misleading display, several valid signatures can end up authorizing the wrong payment.

The answer is not more signatures. The answer is signers that look for themselves. A hardware wallet that shows the address on its own screen. A co-signer that checks limits or unusual patterns instead of signing whatever the client sends. A person who reads the amount and the recipient before confirming.

That last look stays with the user, and no design takes it away. If you confirm a false recipient, your confirmation is still real. No single point of failure is a requirement for the whole system, including that last look.

Theft protection and availability are two different jobs

A 2-of-2 model can make a single stolen key useless. Both keys are needed. But that exact rule also means: if one is missing, there is no payment for now.

A provider that cannot steal on its own could still block the normal payment path by no longer co-signing. That can be on purpose, but it can also be a server outage or the end of the company.

So a self-custodial wallet has to answer two questions. Why can the provider not move my money on its own? And how do I move it when the provider is gone? The second one needs a spending path that was set in advance and never asks the provider for permission. Further down I come back to how a timelock can do that.

Muun shows how everyday use and emergencies can be kept apart

In my posts I pointed to Muun and Blockstream Green as sources of ideas. Muun describes its model very clearly: in everyday use, the phone and the Muun server sign together. The phone does not hold both unencrypted keys.

For emergencies there is an Emergency Kit with encrypted keys and the information needed for recovery. The matching recovery code is stored separately. The normal payment path is convenient, while the emergency path is meant to work without the provider's day-to-day cooperation.

That shows multisig does not have to mean several manual device confirmations per payment. It can feel like one app. The real work is in the emergency path. Nuri shares the same everyday idea of user plus server, but the user key sits behind a passkey instead of a kit and a code. A shared idea does not make two products the same.

A passkey is not just a hidden seed phrase

An ordinary passkey is first of all for signing in. It proves cryptographically to a website that you hold the matching credential. Because it is bound to that website, a fake login page cannot simply collect it the way it could collect a typed-in password.

A seed phrase is a secret you have to write down, store and never type into the wrong place. A passkey is held by an authenticator, a phone, a password manager or a hardware key, and it can sync to a new device through the provider you picked. With the WebAuthn PRF extension, the same passkey can also return a fixed secret. The same input always gives the same 32 bytes, and a wallet can derive a key from them locally.

That has limits. Protection against fake login pages does not make every transaction shown afterwards correct. A compromised real website or a compromised device are separate problems. PRF has to be supported by the specific browser and authenticator. And a compromised passkey account stays a real risk. A passkey makes a key easier to keep. It does not turn it into a second key.

MuSig2 makes shared control less visible

Several signers do not have to look like several signatures on the blockchain. MuSig2 lets them produce one valid Schnorr signature together. Their keys aggregate into a single Taproot key, and a normal key-path spend looks like the signature of one signer.

That is useful for size and privacy. The security still comes from the participants working together, not from the number of signatures visible onchain.

One technical distinction matters here: under BIP 327, MuSig2 needs every signer in a given key aggregation. On its own it is not a 2-of-3 system and it is no recovery path. Alternative paths have to come from the wallet construction, for example additional Taproot script paths. That is where the next part comes in.

Co-signers that expire on a schedule

In my posts I described co-signers that become unnecessary over time. Technically, their keys do not disappear. A predefined second spending path becomes usable. Bitcoin can do this with a relative timelock, CHECKSEQUENCEVERIFY from BIP 112. The clock starts when the output confirms.

The shape is simple. In everyday use, everyone signs together. Next to that there is a path where, after a fixed number of blocks, the user key alone is enough. You can also build several steps, where one signer after another drops out. What matters is the direction. Thresholds only shrink toward the user, never away from them.

This changes the security assumption, and I want to say that plainly. Once the user key alone is enough, an attacker with that key can use the path too. While the co-signer is in the script, it protects. After the delay, its protection is gone. Deadlines, key loss and maturing outputs have to be looked at together.

Recovery needs more than one secret

With more complex Bitcoin wallets, the recovery software also has to know which keys and spending rules belong together. Output descriptors describe constructions like these, including public keys, derivation paths and the structure of the spending conditions.

Restoring only your private key does not give you everything needed to spend the right multisig or Taproot output. The Nuri recovery project names exactly this limit and separates key derivation, public recovery data, searching for outputs and sending a transaction.

A descriptor can expose private financial information. So it belongs in an encrypted backup, not in plain text somewhere. But it has to be backed up, and in a way you can read again without the provider. A backup that only the provider can open is no backup for the day the provider is gone.

The test with a provider that is gone

I like one simple test. Imagine the company behind your wallet is gone tomorrow. Servers off, domain gone, app removed from the store. What do you do now?

If the answer is that you should have exported your key before, that is not really an answer. You do not always get a warning. If the answer needs a server the company runs, it is the same problem in another place. The exit has to be set in advance, in the coins themselves, and the tool for it has to be open and run on your own computer.

This test is not against providers. A provider can do a lot of good work, co-signing, checking limits, watching for strange payments. It only must not be the one thing everything hangs on.

Why this matters for Nuri

In Nuri, the user sees one thing: a passkey, confirmed with Face ID, Touch ID or a PIN. No seed phrase, no list of signers, no juggling of devices for every payment.

Behind that one prompt, two things happen. The PRF extension returns a fixed secret on the device. As documented in the public local-nuri-prf-passkey-recovery-tool repository, the user's Bitcoin key is derived from it locally with domain-separated HKDF-SHA256 and the Taproot path m/86'/0'/0'/0/0. At the same time, the WebAuthn assertion goes to a separate co-signer as proof that the user approved this specific action. The co-signer asks for a fresh passkey ceremony with user verification every time, not a session cookie or an API key. It receives the approval, never the PRF output.

On Bitcoin L1, an output has a key path, the 2-of-2 MuSig2 aggregate of user and co-signer, and a script path with the user key behind a CSV delay: and_v(v:pk(user), older(csv_blocks)). The Arkade layer for fast off-chain payments adds the Arkade server as a third signer, with three leaves per VTXO. First all three together, after the first delay user and co-signer, after both delays the user alone. Which outputs and contracts belong to the wallet is kept in an encrypted backup on Nostr, not in a Nuri database.

If Nuri is gone, the open recovery tool rebuilds the nuri.com web context on the user's own computer. A hosts entry points nuri.com at the local machine, a locally trusted certificate makes it a secure origin, and a local server runs the reviewed code. The passkey evaluates PRF as usual, and the keys are derived offline. This is no WebAuthn bypass. It still needs the passkey and its user verification.

The limits belong to the design. The tool does not replace a lost passkey, it needs an authenticator that supports PRF, it does not restore the co-signer's private key, and it does not skip a timelock that is still running. For L1 coins, the CSV path is the unconditional exit. Leaving Arkade without its operator also needs the pre-signed exit transactions, so that exit depends on the exit data being in the user's backup. After the decay, the co-signer no longer protects. And the user still has to check amount and recipient. A documented tool is also not proof that every wallet configuration has been tested end to end.

The measure is what still works after a failure

I want multisig as the standard because losing a single device or key should not decide what happens to all the money. For that, the additional signers have to create a real hurdle, and recovery must not quietly remove it again.

For users, it has to stay simple. One thing to confirm, and a clear answer to each failure. Lost phone. Stolen key. Wrong screen. Provider gone. For each of these, the answer should not be the same single thing.

A broken or manipulated device is a reason to ask these questions, and the answer should be more than the next manufacturer's name. I judge a wallet by which single failure stays manageable, who has to work together for a payment, and how users act on their own again in an emergency. That is the measure for Nuri too.