I'm currently working on coding for a 30 day free trial. If anyone wants to test right now, let me know.

https://m.stacker.news/144257

For those who are curious on what the platform looks like, here you go! I'm always open to feedback on improving the UX, as well as, the security of the platform.

That's a fair point, and I wouldn't argue that XYZVault is strictly more secure than a well executed 3 key geographically distributed setup. If your threat model is maximizing security and you're comfortable managing three separate locations, that's already a strong solution.

The advantage we're trying to provide is convenience without giving up self-custody.

With XYZVault, you still control two keys, so we can never move your funds on our own. The service key simply acts as a backup key when you have access to one of your keys but not the other. For many people, maintaining three hardware wallets in three separate locations is operationally difficult, expensive, and increases the chances of losing track of devices, descriptors, backups, or recovery information.

The other aspect is privacy. Many collaborative custody providers require KYC or collect enough information to know exactly who you are and how much Bitcoin you hold. Even when databases are encrypted at rest, that data is typically stored in plaintext within the application and can be exposed if the platform is compromised.

XYZVault takes a different approach. Your descriptor, xpubs, labels, vault configuration, and other sensitive metadata are encrypted locally in your browser before they ever leave your device. The server stores ciphertext, not plaintext, and does not possess the key needed to decrypt it. As a result, a database breach doesn't reveal your balances, transaction history, wallet structure, or other vault data because we don't have access to it ourselves.

So the value proposition isn't "replace perfect OPSEC with trust in us." It's reducing the operational burden of managing a multisig setup while minimizing the amount of information the service operator can learn about you.

Currently, there is no account recovery path. Your encryption key is derived from your passphrase, and neither is ever transmitted to or stored by the platform. If you lose your passphrase, we cannot recover your account or decrypt your vault data.

That said, you've raised a good idea. This could be an opt-in feature which will allow the user to enroll their hardware devices as recovery keys.

Some additional information:

Vaults on XYZVault use our private Bitcoin node, address and transaction lookups are routed through a blind proxy.

Your browser derives addresses locally, then sends lookup requests to the proxy. The proxy forwards those requests to XYZVault’s private Bitcoin node, but it does not log request data, and the node does not receive account context. That means XYZVault may transiently handle address or transaction queries, but we are not able to tie those queries back to a specific user or vault.

This is different from storing wallet data. XYZVault does not store your addresses, balances, or transaction history. Those are derived and computed client-side each time the vault loads. The proxy only exists so users can query chain data without relying on third-party public APIs.

Good question. No, the platform key alone cannot reveal your transactions.

To track a wallet, you need the descriptor/xpubs that identify which addresses belong to it. In XYZVault, those are encrypted in your browser before upload. We use Argon2id to derive a master key from your passphrase, then HKDF to derive an authKey and encKey. The authKey is hashed and stored for authentication, while the encKey never leaves your browser.

Your descriptor, xpubs, labels, policies, and vault configuration are encrypted with AES-256-GCM before reaching our servers. Every encrypted blob is also bound with AAD, preventing ciphertext from being transplanted between accounts.

The service key itself lives inside an AWS Nitro Enclave. While we cannot extract the key from the enclave, it's important to understand the trust model: the enclave protects secrets from attackers, not from the code running inside it.

The same assumption exists with hardware wallets. A secure element chip protects a private key from extraction, but it still executes firmware written by the manufacturer. If a vendor intentionally shipped firmware that leaked keys, the secure element would do exactly that. The chip protects against extraction, not against the device creator instructing it to reveal secrets.

Likewise, the Nitro Enclave protects the service key from theft, but the reason we cannot see your balances or transactions is because the wallet metadata needed to identify your addresses is encrypted with an encKey that never leaves your browser.

Even in the hypothetical scenario where someone could extract information from the enclave, they would only obtain the platform's service key. They still would not have access to your encrypted vault data because the encKey required to decrypt it never leaves your browser and is never stored on our servers or in the enclave.