Z-Vault: Local-First Encrypted Recovery Toolkit for Zcash Users

Community Grants
1

Hi Zcash community,

I submitted a ZCG grant application for Z-Vault, a local-first, client-side encrypted recovery toolkit for Zcash users.

Z-Vault is designed to help users manage wallet-adjacent sensitive metadata such as address labels, memo templates, recovery instructions, encrypted notes, backup references, and recovery packets without relying on centralized servers.

The project does not store plaintext secrets on-chain and does not act as a wallet. Instead, it uses Zcash as an optional privacy-preserving anchoring layer for encrypted backup commitments and recovery references through shielded memo payloads.

The main goal is to improve the recovery, organization, and privacy UX around Zcash wallet usage without introducing custody, private key management, or transaction signing into the MVP.

GitHub grant application:

I welcome feedback from the Zcash community, especially around:

  • whether this solves a real Zcash user problem
  • the security assumptions of the local-first encrypted vault model
  • the usefulness of optional shielded memo anchoring
  • what should be explicitly out of scope for the MVP
  • whether this should be positioned under Wallets, Developer Tools, or Privacy UX
3 Likes
Zcash Community Grants Meeting Minutes 6/22/2026
2

Hi, how does your system offer on top of storing seed phrases / keys / etc in a password manager like 1password?

1 Like
3

That is a fair question.

Z-Vault is not intended to replace 1Password, Bitwarden, or other password managers for storing seed phrases, private keys, or login credentials. In fact, for raw seed phrase/key storage, a mature password manager or hardware-backed storage is usually the better tool.

The gap Z-Vault is trying to address is different: wallet-adjacent Zcash metadata and recovery context.

Examples include:

  • local labels for shielded, unified, and transparent addresses
  • memo templates and payment context
  • notes about which wallet/address is used for which purpose
  • recovery checklists and backup references
  • encrypted export/import of that Zcash-specific metadata
  • optional backup integrity commitments that can be anchored through shielded memo payloads

The goal is not “store secrets on-chain” and not “build a password manager on Zcash.” The goal is to provide a Zcash-specific, local-first tool for organizing and protecting the sensitive context around wallet usage without relying on a centralized server.

A password manager stores secrets well, but it does not understand Zcash concepts like shielded addresses, transparent-address privacy warnings, memo workflows, or backup commitment anchoring. Z-Vault would sit beside existing wallets and password managers, not replace them.

This is also why the MVP explicitly avoids private key custody, transaction signing, and broadcasting. The first version focuses on encrypted metadata, recovery organization, and optional Zcash-specific anchoring rather than raw secret storage.

4

Thank you for the clarification.

@hanh raised this question because, during ZCG’s discussion, I initially considered whether this could be understood as something broader, closer to a password or access-management layer connected to Zcash. Your reply makes it clearer that this is not the intended scope.

My remaining difficulty is practical UX. Without seeing the MVP flow, it is hard for me to understand where this fits. If this were part of a wallet, I could more easily imagine it preserving user-specific wallet metadata such as an address book, labels, notes, backup references, or recovery context. As a standalone application, without a clear connection to an existing wallet or user workflow, I still find it difficult to evaluate who would use it and what the first useful MVP actually looks like.

5

Thank you, that is helpful feedback.

I agree that the practical UX needs to be clearer. The MVP should not feel like an abstract standalone vault with no obvious workflow. The intended first useful flow is a companion workflow around an existing Zcash wallet, not a replacement for the wallet itself.

A concrete MVP flow would look like this:

  1. A user already has a Zcash wallet and one or more Zcash addresses.
  2. They open Z-Vault locally in the browser.
  3. They create an encrypted local vault.
  4. They add wallet-adjacent metadata manually, such as:
    • address label
    • address type: shielded / transparent / unified
    • what the address is used for
    • memo templates or payment notes
    • backup location reference
    • recovery checklist items
  5. Z-Vault encrypts this metadata locally.
  6. The user exports an encrypted backup file.
  7. The user can later import the backup, unlock it locally, and recover the wallet context without relying on cloud notes, screenshots, or a centralized server.

So the first MVP is basically: “I use Zashi / Ywallet / another Zcash wallet, but I need a private local companion to organize the metadata around my wallet usage.”

I agree that if this were integrated directly into a wallet, the UX would be easier to understand. For the grant scope, I proposed it as a standalone MVP because it avoids custody, signing, wallet integration risk, and private key handling. But the design should still be wallet-adjacent from day one, and future wallet integration could be explored only after the metadata model and workflow are validated.

To make the scope easier to evaluate, I can tighten the MVP around one demonstrable workflow:

  • local encrypted Zcash address book
  • shielded/transparent/unified address labeling
  • memo templates and payment context
  • backup checklist and backup references
  • encrypted export/import
  • clear documentation showing how this sits beside an existing wallet

This means the MVP would not try to solve every recovery or vault use case. It would focus on whether a Zcash-specific metadata companion is useful enough as a workflow before expanding further.

1 Like
6

Would that narrower MVP flow make the project easier to evaluate, or do you think this type of metadata layer only makes sense if it is integrated directly into an existing wallet?

7

I’ll hold off on answering for now; you’ll find out why soon.

8

Understood, thanks for the note. I’ll wait for the official update and will be happy to clarify or revise the scope if needed

1 Like
9

Thank you for submitting your proposal. Following a thorough review by the ZCG and a period for community feedback on the forum, the committee has decided not to move forward with this proposal.

We sincerely appreciate the time and effort you invested in your application and encourage you to stay involved and continue contributing to the Zcash community. Further details will be available in the meeting minutes to be posted today.

10

Thank you for the review and for the detailed feedback.

I understand the main concern: as a standalone manual companion app, Z-Vault does not yet have a strong enough UX or integration path, especially because wallet metadata is stored differently across wallets and is not accessible to third-party apps without wallet support.

That feedback makes sense. The stronger direction would likely be to narrow this into a wallet-adjacent metadata schema or prototype that can be integrated directly by an existing Zcash wallet, rather than positioning it first as a standalone application.

I appreciate the committee’s time and the practical feedback