# Grant Proposal: Zcash Extensible Wallet Interchange Format (ZeWiF) **URL:** \ **Category:** Applications\ **Created:** [December 13, 2024, 11:19pm UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730 "2024-12-13T23:19:20Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![BC-Shannon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/bc-shannon/32/30022_2.png) [@BC-Shannon](https://forum.zcashcommunity.com/u/BC-Shannon)\ **Post date:** [December 13, 2024, 11:19pm UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/1 "2024-12-13T23:19:20Z")
Blockchain Commons & Zingo Labs have partnered to put together a proposal to aid with the zcashd deprecation, to improve interoperability among wallets, and to help salvage legacy wallet funds that might otherwise be lost. It’s the Zcash Extensible Wallet Interchange Format (ZeWiF), submitted in the new GH system: > > > \### Terms and Conditions > > \- \[X\] I agree to the \[Grant Agreement\](https://9ba4718…c-5c73-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 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) > > @ChristopherA, @shannona > > \### Organization Name > > Blockchain Commons with Zingo Labs > > \### How did you learn about Zcash Community Grants > > Long familiarity with the blockchain ecosystem, and discussion with some Zcash ecosystem principals. > > \### Requested Grant Amount (USD) > > $121,200 > > \### Category > > Wallets > > \### Project Lead > > \`\`\`project-lead.yaml > Name: Christopher Allen > Role: Chief Architect > Background: Christopher Allen is the coauthor of the TLS and DID standards and is currently working with the IETF to advance dCBOR and the Envelope data format for standardization. Recognized as a “Top 100 Influencer in Identity,” he was Principal Architect at Blockstream, Vice President at Blackphone, and CTO of Certicom. Today, he is the Executive Director of Blockchain Commons. For this project, Christopher is coordinating between Blockchain Commons and Zingo Labs to offer a solution that reflects both wide knowledge of the cryptocurrency ecosystem and specific details of Zcash needs. > Responsibilities: Oversee project & provide technical vision > \`\`\` > > > \### Additional Team Members > > \`\`\`team-members.yaml > \- Name: Wolf McNally > Role: Lead Researcher & Designer > Background: Wolf McNally is Blockchain Commons' lead researcher and engineer, who developed most of Blockchain Commons' specifications, such as Animated QRs, Uniform Resources (URs), and Sharded Secret Key Reconstruction (SSKR), and also designed LifeHash and the upcoming Provenance Mark specification. > Responsibilities: Design of extensible interchange format, engineering of libraries for import and export. > \- Name: Darío Paz > Role: Developer > Background: Darío Paz is a software engineer at Zingo Labs who previously founded Mayland Labs, a startup that explored the intersection between design, virtual spaces and digital assets. He has worked on MoonyApp, developing a signal-trading platform, and has over three years of experience working on EVM-based blockchains. > Responsibilities: Survey of wallets, testing of Blockchain Commons format & libraries, design of real-world ZExCavator tool to recover content from old zecwallets. > \- Name: Shannon Appelcline > Role: Technical Writer > Background: Shannon Appelcline is an award-winning nonfiction author and technical writer who has written for numerous blockchain and DeFi companies and who has described most of Blockchain Commons' specifications. > Responsibilities: Organization & recording of wallet survey, authorship of various best practices. > \`\`\` > > > \### Project Summary > > To support the deprecation of zcashd, we will create an extensible wallet interchange format for Zcash that supports historic wallet.dat, such as that found in zcashd, and leaves rooms for expansions and improvements in the future. > > \### Project Description > > The goal of the project is to create an extensible interchange format that may be used immediately to extract content from zcashd and other legacy wallets and longer term to allow users to move between different wallets without worrying about losing information or even assets. > > This will be done in four phases: > > 1. Wallet Survey > 2. Wallet Interchange Specification Design > 3. Rust Import & Export Libraries > 4. Legacy Wallet CLI Tool > > The specifics of this are described in the Solution Format section, but ultimately the results of this project will be that: wallet developers can easily produce importers, exporters, and sweep tools to allow transition between wallets; and users can even salvage old wallet content themselves using a CLI tool. > > \### Proposed Problem > > The zcashd reference client is being deprecated, and this means that funds must be exported from the client and converted to other wallets. The fact that there are now at least four popular major wallets and numerous lightclient wallets, each with their own formats for metadata about funds and transactions, makes this transition challenging as does the number of Zcash address formats (transparent, sprout, sapling, and orchard) and the proliferation of key generation formats (master keys, seeds for HD keys, and BIP-39 compatible seeds for HD keys). > > This reflects a longer standing problem in the Zcash community: any type of migration between wallets is very difficult (see for example https://forum.zcashcommunity.com/t/shifting-from-zeclite-to-zashi/47756). It's been covered by numerous GitHub Issues, including zcash #6873 (https://github.com/zcash/zcash/issues/6873), zips #821 (https://github.com/zcash/zips/issues/821), zips #964 (https://github.com/zcash/zips/issues/964), and librustzcash #1552 (https://github.com/zcash/librustzcash/issues/1552). > > The zcashd deprecation therefore offers a major opportunity: we can create an interoperable wallet interchange format that not only serves the main purpose of exporting data from zcashd in a standardized manner, but that also supports the interoperability of the whole Zcash wallet ecosystem going forward, ensuring that users always have their choice of wallet and are never locked into a single provider out of fear of losing past transactions, addresses, seeds, or keys. > > This helps to preserve the fairness and openness that are among Zcash's core values. > > \### Proposed Solution > > Blockchain Commons and Zingo Labs will: collect and survey existing wallets (a wide-ranging survey, with a focus on zcashd and zecwallet); design an interoperable and extensible wallet interchange format that can preserve and secure data from zcashd and other wallets including legacy zecwallets; create Rust crates that import data into and export data from that interchange format; and produce a ZExCavator tool that recovers buried ZEC from old zecwallets. > > The primary users of this solution will be current and future wallet developers. Zingo Labs has already agreed to work with us and we've also reached out to Andrew Arnott and other members of the Zcash ecosystem. We expect to reach out to all of the other major wallet developers, including ECC (Zashi) and YWallet. > > As wallets adopt the extensible wallet interchange format, wallets customers will become users too, and they should see big wins in the ability to make their own choices on which wallets to use. > > \### Solution Format > > This project is laid out in four phases: > > 1. WALLET SURVEY. Examine current wallets to enumerate all stored information on seeds, keys, addresses, and transactions including labels, notes, unmined transactions, and other wallet-specific data, with highlighting of information that is not legacy and that is stored by at least two different wallets, and therefore the highest priority for inclusion in an extensible wallet format. The goal here is to be thorough in recording all off-chain data stored in wallets (and perhaps even on-chain data that is replicated in wallets). > \* Deliverable #1.1: One or more meetings for wallet developers (Month 1). > \* Deliverable #1.2: Final report on all surveyed data, which at a minimum includes coverage of zcashd and zecwallet but is expected to cover a wide diversity of wallets, including highlight of data suggested for inclusion in a extensible wallet interchange format (Month 1). > 2. WALLET INTERCHANGE SPECIFICATION DESIGN. Create a format that will allow the export of zcashd and zecwallet data as well as data from other major Zcash wallets and future expansions. > \* Deliverable #2.1: Interchange design document, describing a format focused on well-known data that is used by two or more major wallets (including zcashd, zecwallet/zingo, zashi, and eZcash). The goal of this document is to provide what's needed to export data from popular wallets and for wallet companies to import any exported data (Month 2). > \* Deliverable #2.2: A developer's how-to document describing the use of Envelope attachments for data not included in basic interchange format. > \* Deliverable #2.3: An example implentation using the Envelope format for storage of non-standard zcash wallet data, based on user testing of deliverables #2.1 & #2.2 by Zingo Labs (Month 2). > 3. RUST IMPORT & EXPORT LIBRARIES. Release an open-source reference importer and exporter Rust library for the new extensible wallet interchange format. > \* Deliverable #3.1: A Rust crate to import a wallet into an intermediate in-memory representation, using API inputs (Month 3). > \* Deliverable #3.2: A second Rust crate to convert that intermediate representation to the serialized Gordian Envelope format as an export. (Month 3). > \* By dividing the import/export library into two crates, we give developers the ability to convert into other serialized formats if they prefer. > \* Alongside the two crates, an integration test will ensure the validity of the libraries using a real-world wallet format and will be published as part of the open-source release but isn't intended as a user-facing tool. > \* Deliverable #3.3: A Rust abscissa CLI for testing the import of a zecwallet-specific format (Month 3). > \* Deliverable #3.4: A best practices document on importing & exporting data. > 4. LEGACY WALLET CLI TOOL. Expand the Rust abscissa CLI into a single-purpose tool that extracts legacy wallet.dat files from ZecWallet Fullnode and zcashd via the ZeWiF format, syncs the wallet, and exports the updated wallet via ZeWiF for compatible consumers. This will provide an important community utility, as well as a proof of concept of the advantages offered by the standard ZeWiF format. > \* Deliverable #4.1: Full legacy wallet CLI tool (ZExCavator). > > The extensible interchange format, the Rust crates, and the ZExCavator wallet tool together comprise the technical heart of this project. The two best practices documents are meant to supplement that. > > The phase 2 document, on using Envelope attachments, will lay out which data was incorporated into the core interchange format, which was delegated to attachments, and the general reasons for doing so (as best-practices support for future extensions). This will include discussions on legacy vs. modern formats and how they're supported differently to ensure the interchange format isn't saddled with technical debt from the start. The document will also provide guidance on attachment formatting and usage as well as how to access an archival copy of the original wallet data. > > The phase 3 document then talks about best practices for importing and exporting data. This will discuss ways that legacy data can be imported or converted (primarily through sweeps from legacy keys) and also what an importer should do if it is unable or unwilling to import all data. > > \### Dependencies > > This project is already a collaboration between Blockchain Commons and Zingo Labs. We have also begun work with other principals working in the Zcash ecosystem. Still more collaboration will be required to achieve the best success. We feel that it's especially important to get buy-in from ECC because of their central position in maintaining librustzcash and zcashd. > > We believe we're on the path to success here, both because we've already begun these discussions and because Blockchain Commons has worked with a variety of wallet developers before in the larger blockchain ecosystem, leading to the successful deployment of formats such as Animated QRs, Uniform Resources, Sharded Secret Key Reconstruction, and Envelope itself. > > The other major dependency is making sure that we can properly support the the zcashd deprecation plan. The current goal is for zcashd to close out in April 2025, which is obviously very near. To support this, we'd like to be able to have the format fully available for use and testing by the start of April. To meet that deadline, our initial three months of work would need to be January, February, and March (with the final legacy wallet tool from Zingo Labs to follow in April). An end-of-the-year decision on this project would allow us to fulfill that timeline. Otherwise, things will get pushed back, which would endanger the April deprecation date. > > \### Technical Approach > > This project will take advantage of the extant Gordian Envelope technology, which is a data storage and exchange format intended for sensitive and confidential data, exactly like this. Gordian Envelope (see https://developer.blockchaincommons.com/envelope/) is privacy-focused and supports encryption and elision without destroying signatures. It can even be used over untrusted or unreliable transports, all of which should be to the benefit to wallet interchange (though the best benefits might await a later stage than the more pragmatic need to get wallets input and output, which is the heart of this proposal). > > With those technologies the approach should be fairly simple: > > \* Survey existing wallets and collected wallet.dat files & talk with wallet designers > \* Spreadsheet all possible data elements > \* Highlight all repeated, non-legacy data (used by at least two wallets) > \* Register CBOR tags for highlighted data > \* Write specification for Envelope/CBOR-based extensible wallet interchange format > \* Write how to incorporate other data into Envelopes as "Envelope Attachments" > \* Write Rust crate that supports import of data into intermediate in-memory format. > \* Write Rust crate that supports export of in-memory format to serialized Gordian Envelope format. > \* Write test suite to read a specific wallet format and call other Rust crates to convert it into Gordian Envelope format. > \* Write full reference app for important zecwallet format. > > We expect the extensible interchange format to encode data in three ways: > > 1. Widely used data that we expect will be used well into the future will be encoded to explicit specifications with CBOR tagging. > 2. Less common data or data types that have been deprecated will be encoded as "attachments", which are essentially "blobs of data", with the format referenced in conjunction with a specific vendor. This allows preservation of data without creating technical debt for the data format for little-used or older content. > 3. The entirety of the original wallet file can also be preserved, probably in a compressed, encrypted form with metadata revealing where it came from. This allows its review in the future if anything is determined to be missing. > > Because Gordian Envelope supports encryption, data that is stored (such as Zcash keys, addresses, seeds, and of course the archived data) can be encrypted with a symmetric key, protecting it on disk or in transport. Because of the standardization of this encryption method, this data remains fully interoperable. An exporting wallet could even sign the data and that signature would remain valid after the encryption, if proof was desired of the origin and validity of the seeds, keys, archival, and other data. This is all a crucial improvement over the use of older formats such as JSON, which do not natively support encryption, and so do not offer it in a standardized way. > > Future Possibilities > > This proposal does not include long-term support of the new extensible interchange format. We think that upgrades, bug fixes, improvements, training workshops, and more comprehensive documentation on the format might all be desirable. We're happy to work with wallet companies on their individual needs or to write a future proposal for longer term support if needed. > > We also think there's an opportunity to make it \*easier\* to manage encryption of ZeWIF content during storage and transmission. (We think that a password-to-encryption-key method is likely the optimal way to manage easy encryption with less concern of loss.) However, our goal in this proposal is to focus on creating a forward-looking interchange format that can quickly support the zcashd deprecation, so we haven't extended into this parallel area of research. This is another place where we are happy to write a new proposal in the future to improve this support as usage of the format matures. > > Finally, we generally believe that there is value in more universal reference applications that can help designers and developers to test out formats, to ensure compatibility, and to see best practices. Blockchain Commons has written an iOS app called Gordian Seed Tool and a few CLI apps, including seedtool and keytool, that offer such support for Bitcoin, Ethereum, and Tezos. We'd like to bring these over to Zcash, but such a project could be better specced out once the extensible interchange format is finalized, so that it can be fully integrated. > > We hope to advance some of these possibilities in the future. > > \### Upstream Merge Opportunities > > The extensible interface format will be merged primarily into wallet systems. > > \### Hardware/Software Costs (USD) > > $0 > > \### Hardware/Software Justification > > N/A > > \### Service Costs (USD) > > $0 > > \### Service Costs Justification > > N/A > > \### Compensation Costs (USD) > > $121,200 > > \### Compensation Costs Justification > > This budget is based on rates for Zingo Labs contractors ($90/hr) and Blockchain Commons' contractors ($125/hr for our technical writer, $150/hr for our lead engineer & researcher). > > It breaks down as follows: > > Phase 1: > \* Research into Zcash address derivations & wallet file formats as well as review of current Zcash-related Rust crates (3 BC research days: $3,600) > \* Comprehensive survey of zcashd, zec/zingo, and eZcash wallets (20 ZL days: $14,400) > \* Management & recording of wallet meeting, overview & coordination of survey & writing of final report (6 BC writing days: $6,000) > > Phase 2: > \* Interchange specification (15 BC research days: $18,000) > \* Attachment best practices (3 BC writing days: $3,000) > \* Review of howto and example implementation (20 ZL days: $14,400) > > Phase 3: > \* Wallet importer & exporter library & test suite (25 BC engineering days: $30,000) > \* Importing & Exporting best practices (3 BC writing days: $3,000) > \* POC ZeWiF consumer & CLI-app importer (20 ZL days: $14,400) > > Phase 4: > \* Zcash Community Utility ZExCavator (20 ZL days: $14,400) > > > \### Total Budget (USD) > > $121,200 > > \### Previous Funding > > No > > \### Previous Funding Details > > \_No response\_ > > \### Other Funding Sources > > No > > \### Other Funding Sources Details > > \_No response\_ > > \### Implementation Risks > > The biggest challenges will be adoption, and adoption that's rapid enough to meet those deadlines. We would like all of the major wallet developers to create true interoperability by incorporating the extensible wallet interchange format in advance of the zcashd deprecation date, but we're well aware that might not be sufficient time depending on each team's priorities. > > The other major issue is the fact that older wallets, including zcashd, may have keys not based on seeds or keys based on seeds that were not originally BIP-39 compatible. For many modern wallets, this will require either an adjustment to how they store keys or else a sweep function to import master-key-based funds. We've built a similar sweeptool-cli for Bitcoin (https://github.com/BlockchainCommons/sweeptool-cli) and can highlight it as a reference. We'll also discuss in our best practices ways to accomodate these older keys, in order to reduce Zcash's technical debt without losing funds. > > The biggest unknown threat is not knowing what data might be in ancient wallets. We're hoping things are pretty clean because the Zcash ecosystem has had just more than eight years to really create differentiation within their wallets, but it's still an unknown possibility. > > \### Potential Side Effects > > Any standardization implicitly creates limits. By saying how things should be done, you might be limiting the innovation of doing new things in new ways. We'll do our best to prevent this through our planned survey (which should catch all the major ways things are being done currently) and through our best practices for use of Envelope attachments (which will describe how to incorporate data other than that which is explictly included in the wallet interchange standard). > > \### Success Metrics > > Our major metric for success will be how many wallets have incorporated the format. We'll report that out a month or two after zcashd is deprecated and at the one year mark, by which time we expect everyone who's planned to incorporate the new format has. > > The other success metric will be if users find it easier to move among wallets and if otherwise lost funds are recovered. > > > \### Startup Funding (USD) > > 0 > > \### Startup Funding Justification > > N/A. > > \### Milestone Details > > \`\`\`milestones.yaml > \- Milestone: 1 > Amount (USD): 24,000 > Expected Completion Date: 2025-01-31 > Deliverables: Survey of Zcash Wallets & Final Report. > \- Milestone: 2 > Amount (USD): 35,400 > Expected Completion Date: 2025-02-28 > Deliverables: Interchange specification; Best practices for incorporating legacy or single-use wallet data as Envelope attachments; Example implementation of interchange specification. > \- Milestone: 3 > Amount (USD): 47,400 > Expected Completion Date: 2025-03-31 > Deliverables: Import Rust crate; Gordian Envelope Export Rust crate; test suite (or CLI or crate); Best practices doc for importing & exporting; Rust abscissa CLI to test import of a zecwallet-specific format. > \- Milestone: 4 > Amount (USD): 14,400 > Expected Completion Date: 2025-04-30 > Deliverables: ZExCavator Zcash recovery tool. > \`\`\` > > > \### Supporting Documents > > \_No response\_ As noted, this is a partnership between Blockchain Commons & Zingo Labs. Here’s some of the bio info that didn’t fit into the new grant format: > Blockchain Commons has been working for over five years on bringing together wallet developers across the blockchain ecosystem to create secure & interoperable systems that protect the human dignity of their participants. This project will allow them to extend that expertise to the Zcash ecosystem. > > Some of Blockchain Commons’ major achievements for wallet design include the introduction of an interoperable Animated QR specification ([Animated QRs - Developer Resources](https://developer.blockchaincommons.com/animated-qrs/)), formulation of the Lifehash visual hash specification ([LifeHash - Developer Resources](https://developer.blockchaincommons.com/lifehash/)), creation of the security-tested Sharded Secret Key Reconstruction library ([GitHub - BlockchainCommons/bc-sskr: Sharded Secret Key Reconstruction (SSKR) reference library in C](https://github.com/BlockchainCommons/bc-sskr)), and development of the dCBOR ([draft-mcnally-deterministic-cbor-11 - dCBOR: A Deterministic CBOR Application Profile](https://datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor/)) and Envelope structured data formats ([draft-mcnally-envelope-08 - The Gordian Envelope Structured Data Format](https://datatracker.ietf.org/doc/draft-mcnally-envelope/)) for the IETF. More information on Blockchain Commons’ work for wallet design can be found in the 2023 Yearly Overview ([Blockchain Commons 2023 Overview](https://www.blockchaincommons.com/quarterlies/Yearly-2023/)) as well as overviews from previous years ([Posts by Tag - Blockchain Commons](https://www.blockchaincommons.com/tags/#yearly-overview)). > > Zingo Labs is a well-known wallet and infrastructure development team in the Zcash community. They contributed to the early implementations of the NU5 and Orchard protocol clients, contributed to core code in librustzcash, zcash-stack, and zebra and are the primary stakeholders of the Zaino lightwallet-proxy project. They have extensive experience with zcash wallet formats, including lightclient wallets, that make them ideal zcash-specific partners for the blockchain-agnostic Blockchain Commons. > == We think this is work that is crucial for the zcashd deprecation, but also something that will improve the whole Zcash infrastructure through new interoperability. ---
**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:** [December 14, 2024, 3:38am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/2 "2024-12-14T03:38:13Z")
The wallet format is one thing, another thing is how secret keys are derived. For which there is a zip but not complete agreement from wallet developers. For instance, Ywallet doesn’t follow it for performance reasons. Transparent addresses are not scanned, etc. Also, current wallets do not support the full extent of the keys from wallet.dat (and certainly not the sprout keys), therefore even if they understand the zwif format, the end user would not be able to recover their funds. Many people user ywallet as a recovery tool and in 90% of the time, they have the seed so it’s not a format issue. A common format is still a good thing to have moving forward, but I wanted to point out that backward compatibility may not be achievable and/or worthwhile. In which case, the work is much easier (tedious but simple). ---
**Author:** ![zancas](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zancas/32/42011_2.png) [@zancas](https://forum.zcashcommunity.com/u/zancas)\ **Post date:** [December 14, 2024, 4:21am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/3 "2024-12-14T04:21:46Z")
Good points, and I agree with most of them in-principle, but differ on the degree. We are considering different key derivation patterns and this is an issue that I believe the Block Chains commons team have successfully dealt with in multiple cases previously. Per this assertion: > [@hanh](#): > > Also, current wallets do not support the full extent of the keys from wallet.dat (and certainly not the sprout keys), therefore even if they understand the zwif format, the end user would not be able to recover their funds. Are you referring to the “naive diversification” via secret-key-generation strategy that zecwallet employed? If that’s the problem you’re considering, then we agree that it’s significant, and intend to **specifically** design a tool to recover all knowable funds in that case. It’s exactly this that is motivating the development of ZExCavator. > [@hanh](#): > > A common format is still a good thing to have moving forward, but I wanted to point out that backward compatibility may not be achievable and/or worthwhile. In which case, the work is much easier (tedious but simple). I am in 100% agreement with you on this point. It’s important to not over-sell what can be recovered, it’s a function of both which wallet saved the data, and which version of that wallet. That having been said we _can_ recover at least some and possibly all funds from the ZECWallet family of wallets with some caveats (mainly around “naive-diversification”). We believe that, in and of itself, makes the modest cost of the tool **well** worth the effort. But even if the tool **itself** isn’t very successful, a real selling point of this work, is that it invites other instances of ZExCavator-like tools. So if our reference implementation can be improved on, for example, by an expert in a particular legacy wallet, then it will be quite easy to export the data from one tool, and load it in another. ---
**Author:** ![pacu](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/pacu/32/15383_2.png) [@pacu](https://forum.zcashcommunity.com/u/pacu)\ **Post date:** [December 14, 2024, 4:23am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/4 "2024-12-14T04:23:08Z")
This grant addresses one of the paths of the Zcashd deprecation dag and sets Zcash wallets to have a common, well designed, extensible and interoperable The new format can accommodate existing wallet data so that tools can be developed to make use of it. I understand it’s not plug-and-play backwards compatibility because as Hahn pointed out it’s hardly achievable. It’s backed by renowned and experienced developers like @ChristopherA that has many years of experience in the field and has successfully designed and deployed many formats like these before. Thanks you Blockchain Commons and Zingo Labs for putting all of this effort and ECC engineers for your help reviewing and always being well predisposed to help and give your honest opinion and feedback Best of luck to the grant candidates! ---
**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:** [December 14, 2024, 5:04am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/5 "2024-12-14T05:04:40Z")
My comment was about setting expectations regarding the usability of the grant. The section about risks around adoption is my biggest concern. IMO, people would expect the Zewif format to be the ultimate interop solution and put the blame on the wallets when they can’t recover their funds. I don’t think two wallets that adopt zewif will always show the same balance. It feels that the technical description is not clear enough in this area, and end users could misinterpret the capabilities. In other words: “don’t be upset if zewif can’t recover your funds in ywallet”. > [@zancas](#): > > But even if the tool **itself** isn’t very successful, a real selling point of this work, is that it invites other instances of ZExCavator-like tools. So if our reference implementation can be improved on, for example, by an expert in a particular legacy wallet, then its quite easy to export the data from one tool, and load it in another. My point is that these tools are going to be lossy. Wallet developers are aware of the technical details, but the users are not. > [@zancas](#): > > We believe that, in and of itself, makes the modest cost of the tool **well** worth the effort. I wouldn’t say the cost is modest. I agree this tool is good, but it doesn’t depend on zewif. These users, more often than not, have lost access to their wallet file and just have the seed. I think the beginning of the grant is good, but then it adds work that isn’t going to pan out. IMO, it’d be good if the grant enumerated the use cases where it guarantees success and clearly showed its limitations. PS: I had considered writing a free tool for Zecwallet, but after analysis, its scope was more extensive than expected and it was too challenging to implement _efficiently_ (that was during the spam period). It’s based on a conversion tool from zcashd to zwl format and the parsing of zwl file in ywallet. [https://www.youtube.com/watch?v=Shvfdx4aZwM](https://www.youtube.com/watch?v=Shvfdx4aZwM) Good luck with the grant ---
**Author:** ![NaomiBrockwell](https://avatars.discourse-cdn.com/v4/letter/n/8dc957/32.png) [@NaomiBrockwell](https://forum.zcashcommunity.com/u/NaomiBrockwell)\ **Post date:** [December 20, 2024, 3:33am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/6 "2024-12-20T03:33:50Z")
OMG yes please!!! Been trying to recover funds for well over a year, and keep hitting road blocks. And I know many others with the same issue who’ve come to me privately. This would be an amazing tool for the community, thank you so much for working on it! 🙏 🙏 🙏 💛 💛 💛 ---
**Author:** ![zancas](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zancas/32/42011_2.png) [@zancas](https://forum.zcashcommunity.com/u/zancas)\ **Post date:** [December 20, 2024, 4:10am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/7 "2024-12-20T04:10:25Z")
It’s important to note that we want to account for the broadest possible set of existing wallets, so if you have time please share any wallet schema for YWallet with @dorianvp ! ---
**Author:** ![zancas](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zancas/32/42011_2.png) [@zancas](https://forum.zcashcommunity.com/u/zancas)\ **Post date:** [December 20, 2024, 4:12am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/8 "2024-12-20T04:12:14Z")
Great to hear from _Real World Zcashers_ demanding real utility. ---
**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:** [December 20, 2024, 4:14am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/9 "2024-12-20T04:14:16Z")
It just uses zip-32 and bip-44. ---
**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:** [December 20, 2024, 4:26am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/10 "2024-12-20T04:26:29Z")
The demand is real but I am still not convinced this would fix the use cases @NaomiBrockwell mentioned. For ZWL, you need the seed + number of transparent addresses + number of shielded addresses, because it uses bip-44 and zip-32. > With the zingolib (or warp), you could write a recovery tool in less than 1h. To be clear, I am not saying ZeWIF is a bad idea, I am arguing that the proposal states: 1. People want a tool to recover their funds 2. ZeWIF would offer that 3. Let’s make a standard where for _all_ wallets 4. Then people can interop between wallets. Imo, 1. is true. But it does not imply that you _need_ 2, 3, 4. I am sure you will not get every wallet to switch to the zeWIF, because we can’t even get wallets to switch to UA (or even consensus branch id). ---
**Author:** ![zancas](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zancas/32/42011_2.png) [@zancas](https://forum.zcashcommunity.com/u/zancas)\ **Post date:** [December 20, 2024, 4:45am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/11 "2024-12-20T04:45:01Z")
Push button recovery for multiple keys as generated by historical ZECWallet is explicitly covered in our plan. In the case that the user has a wallet.dat, the ZeWiF format will account for the set of keys recorded. In the case where the user only has a seed, a gap rule heuristic can be used. The output of the tool will be a wallet-file in a standard format allowing the user to select any wallet that supports the standard, eZcash, Zashi, Zingo, YWallet? Let’s give the User control. My understanding of @NaomiBrockwell 's problem statements is that she specifically cares about these cases. Assuming that she’s representing a group of private zcashers, that alone more than justifies the tool. I have yet to meet a User that **objects** to the idea that they could then choose whichever (standard format supprting) wallet they want to subsequently manage their recovered funds. ---
**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:** [December 20, 2024, 4:49am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/12 "2024-12-20T04:49:09Z")
I understand the tool. I don’t see the need of zeWIF. The user won’t object to it. I am saying it won’t be available in practice because wallet devs have to adopt it. Anyway, I think I made my point clear. Good luck on your grant. PS: I think we can crowdfund the recovery tool. ---
**Author:** ![JayJay](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/jayjay/32/21033_2.png) [@JayJay](https://forum.zcashcommunity.com/u/JayJay)\ **Post date:** [December 20, 2024, 5:12am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/13 "2024-12-20T05:12:35Z")
Yes. Please, build this. This is absolutely needed. Zcash needs to become known as a community that takes care of its own. I have had so many people I have tried to onboard be scared off by the idea of losing funds because of reliability concerns. I’m a professional software engineer myself and have been trying to solve this problem by going back and building old images and it has been an absolute nightmare. I just don’t have enough time to dedicate to this. I can only imagine what it must feel like and look like to people without technical savy. ---
**Author:** ![zancas](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zancas/32/42011_2.png) [@zancas](https://forum.zcashcommunity.com/u/zancas)\ **Post date:** [December 20, 2024, 5:25am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/14 "2024-12-20T05:25:58Z")
Cool! Well the intention is that this tool will be something that folks like you can both use, _and enhance_, for any specific issues that you’re facing. Maybe you’ll just open issues on the repo letting us know about specific problems… but maybe you’ll extend the format yourself (because ZeWiF is Zcash **extensible** Wallet interchange Format) and enable the tool to recover even more funds, by enabling the tool to handle a new kind of wallet.dat. Wouldn’t that be a fun PR? ---
**Author:** ![NaomiBrockwell](https://avatars.discourse-cdn.com/v4/letter/n/8dc957/32.png) [@NaomiBrockwell](https://forum.zcashcommunity.com/u/NaomiBrockwell)\ **Post date:** [December 20, 2024, 5:42am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/15 "2024-12-20T05:42:42Z")
sounds great 🙂 ---
**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:** [December 20, 2024, 8:18am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/16 "2024-12-20T08:18:34Z")
> [@hanh](#): > > With the zingolib (or warp), you could write a recovery tool in less than 1h. If you are curious, I am attempting to do this here 🤣 > **[Making a ZWL Recovery Tool](https://www.youtube.com/live/hibj9OfzuWg?feature=share)** Stream is over. > **[GitHub - hhanh00/zwl-recover](https://github.com/hhanh00/zwl-recover)** > > Contribute to hhanh00/zwl-recover development by creating an account on GitHub. ---
**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:** [December 24, 2024, 12:03am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/18 "2024-12-24T00:03:29Z")
@BC-Shannon at the most recent meeting, the [@ZcashGrants](https://forum.zcashcommunity.com/groups/zcashgrants) Committee voted to approve this proposal and has requested that you provide monthly updates via the forum in this thread. ---
**Author:** ![BC-Shannon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/bc-shannon/32/30022_2.png) [@BC-Shannon](https://forum.zcashcommunity.com/u/BC-Shannon)\ **Post date:** [December 24, 2024, 7:22am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/19 "2024-12-24T07:22:51Z")
Thanks! We look forward to getting started with the new year. ---
**Author:** ![BC-Shannon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/bc-shannon/32/30022_2.png) [@BC-Shannon](https://forum.zcashcommunity.com/u/BC-Shannon)\ **Post date:** [January 3, 2025, 11:02pm UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/20 "2025-01-03T23:02:54Z")
We’ve figured out a schedule & begun work on the January phase 1 on this project. To further support it, we’ll be holding a (virtual) meeting on January 15th (10am PT) for Zcash wallet developers & other interested parties. I posted a full description here: - [Zcash Extensible Wallet Interchange Format (ZeWIF) Meeting](https://forum.zcashcommunity.com/t/zcash-extensible-wallet-interchange-format-zewif-meeting/49927) Hope to see some of you there. Our goal for the meeting is to do our best to make sure we’re not missing anything & ensure that we can accommodate anything that’s widely used (2+ wallets) in Zcash wallet metadata. Our initial plan is to close out the January milestones by Wednesday, the 29th. We’ll report back afterward! ---
**Author:** ![Taz](https://avatars.discourse-cdn.com/v4/letter/t/3da27b/32.png) [@Taz](https://forum.zcashcommunity.com/u/Taz)\ **Post date:** [January 4, 2025, 9:31am UTC](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730/21 "2025-01-04T09:31:11Z")
Thanks for all your work hanh. Many of us really appreciate it; as a Linux user since '96 it’s nice to see someone who understands what open source is truly about - even if you do use MacOS which ripped off BSD due to the MIT license as opposed to GPL2 😉 [Next page](https://forum.zcashcommunity.com/t/grant-proposal-zcash-extensible-wallet-interchange-format-zewif/49730.md?page=2)