# Z-Vault: Local-First Encrypted Recovery Toolkit for Zcash Users **URL:** \ **Category:** Community Grants\ **Created:** [June 9, 2026, 1:17pm UTC](https://forum.zcashcommunity.com/t/z-vault-local-first-encrypted-recovery-toolkit-for-zcash-users/56108 "2026-06-09T13:17:30Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Lexiie](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lexiie/32/45576_2.png) [@Lexiie](https://forum.zcashcommunity.com/u/Lexiie)\ **Post date:** [June 9, 2026, 1:17pm UTC](https://forum.zcashcommunity.com/t/z-vault-local-first-encrypted-recovery-toolkit-for-zcash-users/56108/1 "2026-06-09T13:17:30Z")
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: > > > Terms and Conditions > > \- \[x\] I agree to the "Grant Agreement" (https://9ba4718c-5…c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471\_f81ef4e4b5f040038350270590eb2e42.pdf) terms if funded > \- \[x\] I agree to "Provide KYC information" (https://9ba4718c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471\_7d9e73d16b584a61bae92282b208efc4.pdf) if funded above $50,000 USD > \- \[x\] I agree to disclose conflicts of interest > \- \[x\] I agree to adhere to the "Code of Conduct" (https://forum.zcashcommunity.com/t/zcg-code-of-conduct/41787) and "Communication Guidelines" (https://forum.zcashcommunity.com/t/zcg-communication-guidelines/44284) > \- \[x\] I understand all milestone deliverables will be validated and accepted by their intended users or their representatives, who will confirm that the deliverables meet the required quality, functionality, and usability for each user story. > \- \[x\] I agree that for any new open-source software, I will create a "CONTRIBUTING.md" file that reflects the high standards of Zcash development, using the ""librustzcash" style guides" (https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#styleguides) as a primary reference. > \- \[x\] I understand when contributing to existing Zcash code, I am required to adhere to the project specific contribution guidelines, paying close attention to any "merge" (https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#merge-workflow), "branch" (https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#branch-history), "pull request" (https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#pull-request-review), and "commit" (https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#commit-messages) guidelines as exemplified in the "librustzcash" repository. > \- \[x\] I agree to post request details on the "Community Forum" (https://forum.zcashcommunity.com/c/grants/33) > \- \[x\] I understand it is my responsibility to post a link to this issue on the "Zcash Community Forums" (https://forum.zcashcommunity.com/c/grants/33) after this application has been submitted so the community can give input. I understand this is required in order for ZCG to discuss and vote on this grant application. > > Application Owners (@Octocat, @Octocat1) > > @Lexiie > > Organization Name > > Independent / Individual Contributor > > How did you learn about Zcash Community Grants > > Zcash community resources, previous ZCG grant applications, and public GitHub grant discussions. > > Requested Grant Amount (USD) > > 30,000 > > Category > > Wallets / Developer Tools / Privacy UX > > Project Lead > > Name: Lexiie Casanova > Role: Project Lead and Developer > Background: > Independent developer focused on privacy-preserving applications, browser-based tools, and user-facing developer products. Experience includes building web applications, extensions, and agent/tooling interfaces with a focus on practical UX and open-source deployment. > > Responsibilities: > - Lead product design and technical implementation > - Define the Z-Vault encrypted vault format and local-first architecture > - Implement the web application MVP > - Build Zcash-specific metadata, recovery, and memo anchoring workflows > - Maintain project documentation and public milestone updates > - Coordinate community feedback and milestone validation > > Additional Team Members > > \[\] > > Project Summary > > Z-Vault is a local-first, client-side encrypted recovery toolkit for Zcash users. It helps 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. > > Z-Vault does not store plaintext secrets on-chain and does not act as a wallet. Instead, it provides a secure companion layer for Zcash users who need to organize and protect the sensitive information surrounding their wallets. Zcash integration is used as an optional privacy-preserving anchoring layer for encrypted backup commitments and recovery references through shielded memo payloads. > > Project Description > > Zcash provides strong privacy at the transaction layer, but users still need safe ways to manage the sensitive context around wallet usage. In practice, wallet-adjacent information often ends up in insecure places such as cloud notes, screenshots, plain text files, messaging apps, or unstructured documents. This may include address labels, recovery instructions, memo templates, wallet notes, viewing-key references, backup locations, and emergency handoff instructions. > > Z-Vault addresses this gap by creating a local-first encrypted recovery toolkit specifically designed around Zcash usage. The MVP will be a browser-accessible web application that runs client-side, encrypts vault data locally, supports encrypted export/import, manages Zcash-specific metadata, and generates optional shielded memo anchor payloads for backup integrity commitments. > > The project intentionally avoids handling private keys, broadcasting transactions, or replacing existing Zcash wallets. Its role is to improve the recovery, organization, and privacy UX around Zcash wallet usage. > > Proposed Problem > > Zcash privacy depends not only on shielded transactions, but also on how users manage the sensitive information surrounding their wallets. Many users store wallet-related metadata in insecure or centralized places because there is no simple, Zcash-oriented recovery and metadata management tool. > > Common examples include: > > \- Address labels stored in plain text > \- Recovery instructions kept in cloud notes > \- Memo templates copied across messaging apps > \- Backup locations forgotten or undocumented > \- Transparent and shielded address context mixed together > \- Sensitive wallet-adjacent notes stored without encryption > \- No simple way to verify whether an encrypted backup has been modified > > This weakens user privacy and recovery reliability even when users are using Zcash correctly at the protocol level. > > Proposed Solution > > Z-Vault will provide a local-first encrypted vault for Zcash wallet-adjacent metadata. Users will be able to create an encrypted vault, store Zcash-specific recovery context, export/import encrypted backups, generate recovery packets, and optionally create Zcash shielded memo anchor payloads that commit to encrypted backup integrity. > > The solution focuses on: > > \- Client-side encryption > \- No backend dependency for core vault functionality > \- No plaintext secrets stored on-chain > \- No custody of funds > \- No private key management > \- Zcash-specific metadata and recovery workflows > \- Optional shielded memo anchoring for encrypted backup commitments > > Solution Format > > \- Local-first web application > \- Open-source repository > \- Encrypted vault file format > \- Zcash address metadata manager > \- Recovery checklist and recovery packet generator > \- Memo template manager > \- Optional Zcash shielded memo anchor payload generator > \- Public demo deployment > \- Documentation and reproducible demo steps > > Dependencies > > \- Browser cryptography APIs or audited open-source cryptographic libraries > \- Zcash address format references > \- Zcash memo format references > \- Public feedback from the Zcash community > \- Open-source hosting and demo deployment infrastructure > > The project does not depend on custom backend infrastructure for the core encrypted vault functionality. > > Technical Approach > > Z-Vault will use a local-first architecture. Vault data will be encrypted on the client before storage or export. The application will support encrypted backup files that users can store wherever they choose. The system will also generate backup integrity commitments, allowing users to verify whether a backup matches a previously saved commitment. > > For Zcash-specific functionality, the MVP will focus on wallet-adjacent metadata rather than transaction signing or wallet custody. It will support Zcash address labeling, address-type metadata, memo templates, recovery checklists, and optional shielded memo anchor payload generation. > > The project will avoid storing plaintext secrets on-chain. If a user chooses to use Zcash memo anchoring, the memo payload will contain only a commitment or reference related to an encrypted backup, not raw secret data. > > Upstream Merge Opportunities > > Z-Vault is not expected to require upstream changes to core Zcash protocol repositories. However, the project may produce reusable documentation, vault format references, Zcash memo anchoring patterns, and UX learnings that can inform other Zcash wallets, recovery tools, and privacy-focused user applications. > > Hardware/Software Costs (USD) > > $0 > > Hardware/Software Justification > > No dedicated hardware is required for the MVP. Development will use existing personal development devices and open-source tooling. > > Service Costs (USD) > > $1,500 > > Service Costs Justification > > Service costs cover public demo hosting, project website/domain, CI/release tooling, dependency scanning, browser testing, and basic project infrastructure required to make the project reviewable and maintainable by the Zcash community. > > Compensation Costs (USD) > > $28,500 > > Compensation Costs Justification > > Compensation costs cover product design, security and threat modeling, implementation of the local-first encrypted vault, Zcash-specific metadata tools, encrypted backup export/import, recovery packet generation, optional shielded memo anchoring payload generation, testing, documentation, public demo deployment, community feedback processing, and milestone reporting. > > Total Budget (USD) > > $30,000 > > Previous Funding > > No > > Previous Funding Details > > No previous ZCG funding has been received for this project. > > Other Funding Sources > > No > > Other Funding Sources Details > > No other funding sources are currently committed to this project. > > Implementation Risks > > \- Security design mistakes in encrypted vault architecture > Mitigation: produce a public threat model during startup phase, avoid custom cryptography where possible, document crypto choices, and keep scope limited to client-side encrypted metadata rather than wallet private key custody. > > \- Scope creep into wallet functionality > Mitigation: the MVP explicitly avoids transaction signing, private key management, wallet custody, or transaction broadcasting. > > \- User confusion around Zcash memo anchoring > Mitigation: documentation will clearly explain that memo anchoring is optional and stores only backup commitments or references, not plaintext secrets. > > \- Browser storage limitations > Mitigation: support encrypted export/import as a core feature and avoid dependence on a single browser storage mechanism. > > \- Lack of early user feedback > Mitigation: publish the repository and startup-phase specification early, post to the Zcash Community Forum, and incorporate feedback into milestone validation. > > Potential Side Effects > > \- Users may misunderstand Z-Vault as a full wallet > Mitigation: the product and documentation will clearly state that Z-Vault is not a wallet and does not manage private keys or funds. > > \- Users may store overly sensitive data despite warnings > Mitigation: the interface will include clear warnings, safe usage guidance, and documentation about what should and should not be stored. > > \- Users may assume Zcash memo anchoring backs up their data automatically > Mitigation: documentation will clearly distinguish between encrypted backup files and optional memo-based integrity commitments. > > Success Metrics > > \- Users can create and unlock a client-side encrypted vault > \- Users can export and import encrypted backups > \- Users can manage Zcash wallet-adjacent metadata locally > \- Users can generate encrypted recovery packets > \- Users can generate a backup integrity commitment > \- Users can generate an optional Zcash shielded memo anchor payload > \- Users can verify whether an encrypted backup matches a saved commitment > \- Public demo is available and reproducible > \- Documentation explains the threat model, safe usage, and limitations > \- Community reviewers can validate each milestone deliverable > > Startup Funding (USD) > > $6,000 > > Startup Funding Justification > > Startup funding will cover the initial project setup, technical specification, threat model, encrypted vault schema, UX design, Zcash memo anchoring format, repository setup, documentation structure, and early prototype work. > > This phase is important because Z-Vault deals with sensitive wallet-adjacent data. The project should not begin with implementation before clearly defining what data is handled, what is explicitly out of scope, how encryption is performed, and how optional Zcash memo anchoring avoids putting plaintext secrets on-chain. > > The open-source repository will be published during the startup phase. The initial repository will include the project specification, README, license, contribution guidelines, threat model draft, and early prototype structure. > > Milestone Details > > \- Milestone: 1 > Title: Encrypted Vault Core + Local-First Prototype > Amount (USD): $7,000 > Expected Completion Date: 2026-08-15 > Scope: Build the core local-first encrypted vault prototype. Focus on secure client-side encryption, vault file format, import/export, and basic Zcash metadata storage. > Deliverables: > - Local-first web app prototype > - Create/open encrypted vault flow > - Passphrase-based encryption flow > - Encrypted JSON export/import > - Zcash address metadata model > - Basic recovery checklist > - Initial automated test suite > Acceptance Criteria: > - User can create an encrypted vault locally > - User can export and re-import encrypted backup > - No plaintext vault data is sent to any backend > - Vault schema and crypto choices are documented > - Tests pass for encryption/decryption and backup restore flow > > \- Milestone: 2 > Title: Zcash Recovery Metadata + UX Layer > Amount (USD): $8,000 > Expected Completion Date: 2026-09-15 > Scope: Build the Zcash-specific user workflows around wallet-adjacent recovery metadata, address labels, memo templates, backup notes, and recovery packet generation. > Deliverables: > - Zcash address book > - Shielded/transparent address classification > - Transparent address privacy warning > - Memo template manager > - Recovery packet generator > - Improved user interface > - Documentation for user flows > Acceptance Criteria: > - User can manage Zcash addresses and labels > - User can distinguish transparent and shielded address metadata > - User can create encrypted recovery packets > - User can store wallet-adjacent notes without exposing plaintext > - Public demo shows complete local-first workflow > > \- Milestone: 3 > Title: Zcash Memo Anchoring + Public Release > Amount (USD): $9,000 > Expected Completion Date: 2026-10-15 > Scope: Add optional Zcash memo anchoring support for encrypted backup commitments and prepare the project for public release. > Deliverables: > - Backup integrity hash generation > - Zcash shielded memo anchor payload generator > - Backup verification flow > - Public demo deployment > - Full documentation > - Release build > - GitHub repository with README, CONTRIBUTING, and license > - Final report and community forum update > Acceptance Criteria: > - User can generate a commitment hash for an encrypted backup > - User can generate a memo payload suitable for optional shielded Zcash anchoring > - User can verify whether a backup matches a saved commitment > - Project has public documentation and reproducible demo steps > - Release is tagged and reviewable by the Zcash community 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 ---
**Author:** ![hanh](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/hanh/32/27853_2.png) [@hanh](https://forum.zcashcommunity.com/u/hanh)\ **Post date:** [June 19, 2026, 12:50pm UTC](https://forum.zcashcommunity.com/t/z-vault-local-first-encrypted-recovery-toolkit-for-zcash-users/56108/2 "2026-06-19T12:50:28Z")
Hi, how does your system offer on top of storing seed phrases / keys / etc in a password manager like 1password? ---
**Author:** ![Lexiie](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lexiie/32/45576_2.png) [@Lexiie](https://forum.zcashcommunity.com/u/Lexiie)\ **Post date:** [June 19, 2026, 1:04pm UTC](https://forum.zcashcommunity.com/t/z-vault-local-first-encrypted-recovery-toolkit-for-zcash-users/56108/3 "2026-06-19T13:04:29Z")
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. ---
**Author:** ![artkor](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/artkor/32/28573_2.png) [@artkor](https://forum.zcashcommunity.com/u/artkor)\ **Post date:** [June 22, 2026, 7:50am UTC](https://forum.zcashcommunity.com/t/z-vault-local-first-encrypted-recovery-toolkit-for-zcash-users/56108/4 "2026-06-22T07:50:17Z")
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. ---
**Author:** ![Lexiie](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lexiie/32/45576_2.png) [@Lexiie](https://forum.zcashcommunity.com/u/Lexiie)\ **Post date:** [June 22, 2026, 8:07am UTC](https://forum.zcashcommunity.com/t/z-vault-local-first-encrypted-recovery-toolkit-for-zcash-users/56108/5 "2026-06-22T08:07:29Z")
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. ---
**Author:** ![Lexiie](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lexiie/32/45576_2.png) [@Lexiie](https://forum.zcashcommunity.com/u/Lexiie)\ **Post date:** [June 24, 2026, 10:10am UTC](https://forum.zcashcommunity.com/t/z-vault-local-first-encrypted-recovery-toolkit-for-zcash-users/56108/6 "2026-06-24T10:10:48Z")
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? ---
**Author:** ![artkor](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/artkor/32/28573_2.png) [@artkor](https://forum.zcashcommunity.com/u/artkor)\ **Post date:** [June 24, 2026, 3:34pm UTC](https://forum.zcashcommunity.com/t/z-vault-local-first-encrypted-recovery-toolkit-for-zcash-users/56108/7 "2026-06-24T15:34:36Z")
I’ll hold off on answering for now; you’ll find out why soon. ---
**Author:** ![Lexiie](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lexiie/32/45576_2.png) [@Lexiie](https://forum.zcashcommunity.com/u/Lexiie)\ **Post date:** [June 24, 2026, 3:47pm UTC](https://forum.zcashcommunity.com/t/z-vault-local-first-encrypted-recovery-toolkit-for-zcash-users/56108/8 "2026-06-24T15:47:19Z")
Understood, thanks for the note. I’ll wait for the official update and will be happy to clarify or revise the scope if needed ---
**Author:** ![ZCG](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zcg/32/33712_2.png) [@ZCG](https://forum.zcashcommunity.com/u/ZCG)\ **Post date:** [June 24, 2026, 7:20pm UTC](https://forum.zcashcommunity.com/t/z-vault-local-first-encrypted-recovery-toolkit-for-zcash-users/56108/9 "2026-06-24T19:20:23Z")
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. ---
**Author:** ![Lexiie](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/lexiie/32/45576_2.png) [@Lexiie](https://forum.zcashcommunity.com/u/Lexiie)\ **Post date:** [June 24, 2026, 7:30pm UTC](https://forum.zcashcommunity.com/t/z-vault-local-first-encrypted-recovery-toolkit-for-zcash-users/56108/10 "2026-06-24T19:30:21Z")
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