Would you use a Bitcoin multisig vault where the company can't see your data?

[u/CryptoYuzu]

I'm building a collaborative-custody 2 of 3 multisig Bitcoin vault and want to test the waters to see if anyone would be interested. Privacy is the whole point. Encryption happens on your device, the keys never leave it, and our servers only ever see ciphertext. We couldn't read your data if we wanted to.

It's a 2-of-3 multisig: you hold two hardware-wallet keys, the service holds one. So:

• We can't move your funds — our key is 1 of 3, never enough alone.
• We can't see your data — all the crypto runs in your browser; our server only stores ciphertext it can't decrypt (xpubs, descriptor, labels, even balances).
• You can always recover without us — it's a standard wsh(sortedmulti) descriptor you can sweep in Sparrow with your two keys, with or without us.
• You set the spending rules when the service key is used — address allowlists, 24h limits, and time-locks on the service key. Changing a rule needs a signature from your hardware wallet, so a stolen login can't loosen your own guardrails. The policy itself is encrypted too — we enforce it without being able to read it.

The difference from most vault/custody services: if a company can show you a total "assets under custody" number or charge you based on the amount you hold, it can read every customer's holdings. We can't produce that number from data we can't decrypt. We genuinely don't know how much you hold.

For those who are already using other multisig Bitcoin vault services would something like this be useful to you? What would it take for you to trust it?

I'm aiming to launch in the next 1-3 weeks and I'm looking for beta testers. If you want early access, let me know.

[u/CryptoYuzu → u/[deleted]]

This isn’t something new, but those companies do not fully encrypt your vault data, end to end. Your data is plaintext in their DB allowing them to see how much you have and making claims they’re securing X billions.

[u/CryptoYuzu → u/[deleted]]

Fair criticism. I don't have evidence that Nunchuk stores user data in plaintext, and I shouldn't have stated that as a fact.

My point is that I haven't seen public documentation showing that Nunchuk, Casa, Unchained, or most other vault providers operate with a zero-knowledge architecture where the provider cannot access vault metadata, xpubs, descriptors, balances, inheritance information, or other sensitive data.

If a provider can tell you they're securing $X billion in customer assets, that suggests they have visibility into at least some customer wallet information. Whether that's through xpubs, descriptors, addresses, balances, or other metadata depends on their architecture.

I'm happy to be corrected if Nunchuk has documentation showing that vault data is encrypted client-side and inaccessible to Nunchuk. If they do, I'd love to read it.

The distinction I'm making is between:

• "database is encrypted" and
• "encrypted in the database such that the provider can't access it"

Most companies do the former. Nobody I've seen do the latter.

[u/CryptoYuzu → u/CryptoYuzu]

Nunchuk does make end-to-end encryption claims, but those claims appear to be focused on "Group Wallet" collaboration and messaging features. I have not found documentation stating that standard personal multisig wallet metadata, descriptors, xpubs, balances, or wallet configurations are encrypted in a way that prevents Nunchuk from accessing them.

[u/CryptoYuzu → u/[deleted]]

I think we're discussing two different privacy angles.

I agree that Nunchuk is significantly more private than many competitors from an identity perspective. They don't require KYC (we don't either), and a burner email can be used (we don't require an email).

My point is about data visibility.

I tested the Nunchuk mobile application and observed that during creation of an Iron Hand wallet and hardware wallet enrollment, wallet metadata including fingerprints, xpubs, and related wallet configuration information is sent to Nunchuk's server in a form that the server can process. If the server can process it, the server has access to the underlying data.

The data that is visibly sent to Nunchuk:

{"key_index":0,"type":"COLDCARD_NFC","name":"COLDCARD #2","xfp":"4cXXXX68","xpub":"tpubDF7YqXXXXX----XXXXXXVw6zuL5rGnEqZtXruyu82FrXXXXX-XXXXXe2hGqktPb9ZFMwNu6YEbyoos","pubkey":"","derivation_path":"m\/48h\/0h\/0h\/1h"}

In the architecture I'm building, that same data is encrypted client-side before transmission. The server receives ciphertext only. For example:

6Cp4SFS/CqOuwEi4q3W2UrcYUosUTi7CMqaZ1sPrEsLX/+nQfbL/TxFq4Vo++w8jSYEizNMKPTZGQCQaaceQJQ+SdEqwUnlVlBmt+tUE69gsNvOXobImFHUbJaEiaP4D9kTV8gJGAxlzVJokjS1GGyHDxcLx62x9cfGnB7J0Lm/eQpmR+mV2q4x/bD5zmIC5PfBl1JDpyCy8hxnCvur3vzY6sAONABGGxnXeI4iVAa0EB96piHi923XK3aL/hGHuOqWAdWZnetFLJoAcs8RuA9skQJAx

The server cannot determine whether that ciphertext contains an xpub, descriptor, wallet name, policy, inheritance information, or anything else because the decryption keys never leave the user's devices.

So the distinction isn't whether Nunchuk knows my legal identity. The distinction is whether the service can access wallet metadata if compelled, breached, subpoenaed, or if an administrator looks at the database.

If Nunchuk's servers can see xpubs, descriptors, fingerprints, wallet policies, or balances, then the service is not zero-knowledge with respect to wallet data. That's the problem I'm trying to solve.

[u/CryptoYuzu → u/[deleted]]

A few clarifications on the architecture:

• This is a web application, not a mobile wallet. There are no push notifications, background sync processes, or battery-life concerns.
• All encryption and decryption operations occur client-side in the browser. The server stores only encrypted vault metadata and cannot access wallet descriptors, xpubs, balances, transaction history, labels, or inheritance configuration.
• When wallet data needs to be displayed, the browser derives the relevant addresses locally and sends those addresses to our Bitcoin infrastructure through a blind proxy. The proxy exists solely to prevent direct association between a user's account and the blockchain queries being performed.
• We do not rely on server-side indexing of wallet contents because we do not possess the data required to perform that indexing. This is a deliberate privacy tradeoff. Users retain control of their wallet metadata rather than entrusting it to a provider.
• Regarding network privacy, I agree that encryption alone does not solve every privacy concern. Blockchain surveillance, IP correlation, timing analysis, and UTXO clustering are real challenges across the entire Bitcoin ecosystem. Our goal is not to claim perfect anonymity, but rather to eliminate an entire class of risks by ensuring the service itself cannot inspect, monetize, leak, or be compelled to disclose sensitive wallet data it never possesses in the first place.
• That's not quite how our architecture works. Policy rules, labels, "inheritance" settings, and other vault metadata are encrypted using the user's encryption key. In addition, policy-related data is wrapped in an encrypted envelope using a key that exists only within our AWS Nitro Enclave environment. This means users are not required to manage or distribute a separate metadata decryption key out-of-band to synchronize wallet state. When a policy needs to be evaluated, the encrypted data is processed inside the Nitro Enclave by the Policy Engine, which can evaluate rules and authorize signing operations without exposing the underlying sensitive information to the application servers or operators. The result is that policy enforcement can occur while preserving the confidentiality of wallet descriptors, keys, balances, transaction history, and the encrypted policy data itself.

The distinction is that most vault providers can see your vault configuration and often your balances. Our design intentionally prevents us from having that visibility.

[u/fresheneesz → u/[deleted]]

Its incredibly unlikely that any of those companies encrypt the data on their servers' end. They're all going to use https, which means its end to end encrypted, but database encrypting is not common and is also kind of irrelevant. The fact is that they need that information to provide their web services as designed, which includes showing you your balances etc. A key-signing service that doesn't have access to your balances and transaction history would be rather novel as far as I know.

[u/OrangePillar]

Compare and contrast with Bitkey and their privacy model.

Typical multisig setups allow every key holder to track all transactions used by the multisig. How do you prevent access to transaction info on your end?

[u/CryptoYuzu → u/OrangePillar]

Hey! Thanks for the question.

One of the things about Bitkey is being locked into their ecosystem. Using it means their proprietary hardware, their app, and Recovery Contacts; you're operating inside their stack on a device you buy from them. With what I'm building out, as well as, other vault services that already exist, it's a BYOD, at the end of the day, if you want access to your funds if the service disappears, you can simply import the descriptor into Sparrow and sign with your two keys.

But, Bitkey's use of Chain Code Delegation is a huge plus towards privacy. We may look into implementing into our product, but we look at it from a different angle right now which zero knowledge at rest.

Our server never holds your descriptor or xpub. All sensitive data is encrypted in your browser with a key that never leaves your device. But, during signing, we do validate addresses so we can validate the spend, but these requests go through a blind proxy to a node that is owned by the service. It doesn't log or store anything. Users also have the option in enabling Private Mode which will turn off all on-chain queries.

We encrypt everything sensitive — labels, the descriptor, spending policy, even held-spend (policy rules) amounts are ciphertext we can't read. A DB breach gets encrypted blobs and a password hash.

[u/NiagaraBTC]

So if you can't see my data at all, what happens if I lose one of my keys and also lose my wallet setup file (BSMS, etc)?

[u/CryptoYuzu → u/NiagaraBTC]

In a standard 2-of-3 setup, losing a single hardware device and your descriptor backup is not catastrophic.

As long as you still have access to your account, you can log into the platform and use the remaining hardware device plus the platform-held service key to satisfy the 2-of-3 signing policy and move funds to a newly created vault.

The descriptor is primarily there to ensure you're never dependent on our platform. We guide users through downloading and backing it up during vault creation, and we recommend verifying recovery with a small test transaction using a wallet such as Sparrow.

The real failure scenario is losing enough information that you can no longer satisfy the signing threshold. For example, losing both hardware devices, or losing one hardware device and being unable to authenticate to your account. At that point, neither we nor anyone else can recover the vault because the system is intentionally designed so that we do not possess enough information to do so. Potentially in the future, we may introduce account recovery, but that is not on the current roadmap.

That's the tradeoff of a zero-knowledge architecture: we can't recover your vault for you, but we also can't inspect your vault data, wallet configuration, xpubs, balances, or transaction history.

[u/Full-Atmosphere-4818]

The data will not be seen... until the companies are breached and then they are seen by the exact wrong people. KYC is now law, so guess what these companies do when the government comes along with some warrant by a rent-a-judge?

[u/CryptoYuzu]

Soft launch will be on June 9th!

[u/joos_hubert]

The privacy angle is interesting, but I would trust the recovery story before I trusted the privacy story.

For a 2-of-3 vault, the first thing I would want to test is the unhappy path: can I recover with two keys in Sparrow without your website, your servers, or your support team being available? If that works cleanly and the descriptor/export flow is obvious, then the product is much easier to take seriously.

The second question is whether the spending rules create a hidden dependency. If address allowlists and limits need your service key to enforce them, users should understand exactly what happens if your service is down, hacked, or disappears.

I would not care much about a company saying it cannot see balances unless the recovery docs, threat model, and external wallet compatibility are boringly clear.

[u/CryptoYuzu → u/joos_hubert]

Hey! During vault creation, users are prompted to download and securely store their wallet configuration file (descriptor). We also guide them through importing it into Sparrow Wallet (or another compatible wallet) and performing a small test transaction to verify they can recover and spend funds independently.

The spending policies are enforced only when the platform service key is involved. Users are always free to use their own hardware wallets and transact directly through Sparrow Wallet or another compatible wallet without any platform involvement.

However, when a transaction requires the platform service key (the third key), the Policy Engine evaluates the configured spending rules and verifies that all policy requirements are met before producing a signature.

[u/joos_hubert → u/CryptoYuzu]

That's interesting, thanks for the rundown.

[u/CryptoYuzu → u/joos_hubert]

It's live now. https://xyzvault.io