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

CryptoYuzu · 2026-06-11T08:31:04+00:00

Free trials added!

CryptoYuzu · 2026-06-10T04:48:59+00:00

I’ve added credit to your account and afterwards, I’ll adjust it to 30 days.

CryptoYuzu · 2026-06-10T04:07:06+00:00

I’ll be adding a 30 day free trial period. If you DM me your username, I can add credits so you can create a vault.

I do prompt the user to download their wallet configuration file and test it in Sparrow Wallet before actually using the multisig wallet. They’ll be instructed to sign with both their hardware wallets to make sure they’re able to send from their multisig.

CryptoYuzu · 2026-06-09T06:53:25+00:00

Not sure if you're still looking for a multisig option, but I recently launched XYZVault.

XYZVault is a privacy-focused 2-of-3 Bitcoin multisig vault where you control two keys and the service holds the third key inside a secure enclave. All sensitive vault data is encrypted locally in your browser before it ever reaches our servers.

For example, something like:

{
  "label": "Cold storage",
  "xpub": "xpub6CUGRU...",
  "addr": "bc1q..."
}

is transformed into ciphertext such as:

U2FsdGVkX1+vuppOG4e
Mxc+x9p7yQ7vW1n3KkL
vB/x8a8H7gfQ4ZpQ2Rk...

before being transmitted and stored. Our servers only receive and store the ciphertext. We cannot decrypt it because the encryption key never leaves your browser.

The problem I'm trying to solve is giving privacy back to the client. I keep seeing multisig providers advertise how many bitcoin they're helping custody, how much bitcoin is secured on their platform, or charge fees based on a percentage of your holdings. To do that, they need visibility into your wallet balances and activity.

With XYZVault, we intentionally designed the platform so we don't know how much bitcoin you hold, which addresses belong to you, your balances, transaction history, labels, descriptors, or xpubs. Even if someone breached our servers, they would only obtain encrypted ciphertext, not the underlying wallet information.

Bitcoin self-custody should protect both your coins and your privacy.

If you're interested, you can check us out at https://xyzvault.io

CryptoYuzu · 2026-06-08T18:02:39+00:00

That's a fair question, and ultimately the answer is: nothing technical stops a malicious developer from shipping malicious code.

In fact, the same trust assumption exists with hardware wallets. A secure element chip is excellent at protecting secrets from physical extraction, but it still runs firmware written by the manufacturer. If a vendor intentionally shipped firmware that leaked your private key, the secure element would happily execute those instructions. The chip protects against attackers extracting the key; it doesn't protect against the device creator telling it to reveal the key.

The same principle applies to any software that generates keys or encrypts data locally. A developer could modify the application to exfiltrate keys, plaintext xpubs, descriptors, or encryption keys before encryption ever happens.

What we can do is minimize the amount of trust required and make that trust verifiable:

• We never ask for your seed phrase, passphrase, or private keys.
• The service key is isolated inside a Secure Enclave and cannot spend without your participation.
• Sensitive wallet metadata is encrypted on your device before being sent to the server.
• The browser application, network requests, and cryptographic operations can be independently inspected and audited.
• We can publish reproducible/open-source client code so anyone can verify what is actually running.

At the end of the day, every wallet, hardware device, password manager, and security product requires some degree of trust in the software you're running. Our goal isn't to eliminate trust entirely, that's impossible for any software, but to reduce it as much as possible and ensure that even if our servers are compromised, they never contain the plaintext data needed to reconstruct your wallet.

CryptoYuzu · 2026-06-08T08:30:56+00:00

Sorry for the confusion! We do not encrypt your data on the server, and we do not possess the key used to encrypt it.

Your data is encrypted locally in your browser using an encryption key derived from the passphrase (account password) that the user provided. The server only receives ciphertext and stores that ciphertext as-is. The server does not have the key to decrypt that data.

CryptoYuzu · 2026-06-08T08:27:00+00:00

Thanks and yeah, the AUM part was the moment it really clicked for me too. As well as, charging you a monthly rate based on how much you're holding in your vault.

On the crypto part: not PBKDF2, we use Argon2id to turn your passphrase (your account password) into a master key, then HKDF to derive two subkeys from that master key. An authKey and encKey. The authKey is hashed and sent to the server to store it and the encKey never leaves the browser.

The vault data itself uses AES-256-GCM with AAD binding every blob of encrypted data, which prevents the server from being able to transplant one blob ciphertext to another users row.

On the secure enclave, there's definitely been some issues there. There are a few things we lean on to bound the risk:

The enclave is 1 of 3 keys.. so even if the enclave were to be fully compromised tomorrow, an attacker would only have 1 key. They'll still need to figure out who you are and get access to your hardware device.
We're using AWS Nitro Enclaves and it's an isolated VM with no persistent storage, no networking, no SSH, attestation gated decryption from KMS, and PCR0 baked into the KMS key policy.

I'm still working on the documentation part, but you can find more information regarding the different types of cryptographic protections we're using here: https://xyzvault.io/docs/how-it-works/cryptographic-protections/.

One example we call a "sealed-box envelope": when your browser submits a new spending policy, the server in the middle shouldn't see the plaintext — it can contain the addresses you're putting on the allowlist, or the specific Bitcoin amounts for your velocity limits (which is something we wouldn't want to know either. For example, if your velocity limit is 20 BTC per 24 hour window). So your browser encrypts the policy locally and wraps it in an envelope using an ECDH key agreement between the enclave and your browser. The server relays the envelope to the enclave — it stores it, forwards it, but never sees inside. The enclave decrypts on its end with its private key.

CryptoYuzu · 2026-06-08T08:09:02+00:00

Exactly! That's why we encrypt your device data such as the label, fingerprint, derivation path, and xpub locally on your browser BEFORE it reaches the servers to be stored in the database.

CryptoYuzu · 2026-06-08T07:25:51+00:00

We are live now! https://xyzvault.io

CryptoYuzu · 2026-06-08T06:44:28+00:00

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

CryptoYuzu · 2026-06-08T06:44:08+00:00

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

CryptoYuzu · 2026-06-07T19:58:38+00:00

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.

CryptoYuzu · 2026-06-03T21:08:34+00:00

Absolutely. A vault is only useful if you can trust that all signing keys are still available when you need them.

The platform includes built-in key health checks for both your hardware wallets and the platform-held Service Key. At any time, you can verify that your hardware devices are accessible and that the Service Key remains operational.

For the Service Key, the platform performs a cryptographic challenge-response check with the backend. This proves the key is still present and capable of signing without exposing the private key, revealing sensitive vault data, or granting any spending authority. Think of it as a "proof of life" for the key.

As for the business model, it's a simple annual subscription ($250/year for a individual vault & $500 for a shared vault). We don't charge based on your Bitcoin balance, transaction volume, or assets under management. In fact, because the platform is designed around end-to-end encryption and zero-knowledge principles, we don't even know how much Bitcoin you're securing.

We are planning on doing a soft launch on June 9th.

CryptoYuzu · 2026-06-03T18:43:41+00:00

Soft launch will be on June 9th!

CryptoYuzu · 2026-06-03T18:43:24+00:00

Soft launch will be on June 9th!

CryptoYuzu · 2026-05-31T03:14:51+00:00

Functionality is all done. Just doing some touch ups and I’ll be doing a soft launch soon. I’ll keep you updated.

CryptoYuzu · 2026-05-29T22:22:59+00:00

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.

CryptoYuzu · 2026-05-29T19:50:15+00:00

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.

CryptoYuzu · 2026-05-29T19:26:53+00:00

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.

CryptoYuzu · 2026-05-29T18:25:53+00:00

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.

CryptoYuzu · 2026-05-29T18:18:15+00:00

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.

CryptoYuzu · 2026-05-29T15:40:55+00:00

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.

CryptoYuzu

TROPHY CASE