Grant Proposal: Zcash Extensible Wallet Interchange Format (ZeWiF)

Community Grants Applications
29

ZeWIF Status Update (3/26/25)

Blockchain Commons and Zingo Labs have made strong progress on the ZeWIF project in March, and have in fact dived deeper into some areas than expected, but are also facing some challenges with our scheduled milestones. Here’s more on all of that …

The main focus of work continues to be on the zmigrate tool (GitHub - BlockchainCommons/zmigrate: ZCash wallet migration framework), in the crate of the same name. This tool can now import data from zcashd using the functionality in the zewif-zcashd crate, which then abstracts that data into the ZeWIF in-memory abstractions in the zewif crate. Any developer can now build on this central tool: they create their own import and export crates, link them to the zewif crate, and support import and export from their own wallets. (All of these elements are still very much subject to refinement and testing, which we are relying on the Zcash community to contribute.)

We’ve talked with the developer who will be using this at ECC and of course we have the internal support of Zingo Labs, and we believe that what we have meets the needs of the April 1st zcashd deprecation, which of course was the most immediate need. In fact, we expect ECC to be working with the tool this week and Zingo Labs will be producing their first-cut zecwallet importer as part of our current milestones.

The main puzzle piece missing from the project at this time is the ability to import and export with the Gordian Envelope-based serialization format, which allows the storage of the in-memory data. It remains a top priority as we know some, perhaps most, wallets will use the file as an intermediary, but we think there are likely a couple of weeks work to close this out. (Our priority to date was instead advancing zmigrate and associated crates to their current state, where they successfully import zcashd data and other developers can start hooking into them for their own input and output wallet formats.)

Completing the Gordian Envelope work is going to represent a time overrun from our original proposal, and it’s the result of a number of factors.

  1. Complexity in translating zcashd. In collaboration with the Zcash community, we established the baseline abstractions for the zewif crate. However, it turns out that the mismatch between the information actually stored by zcashd and the zewif abstrations was high, and the coding to perform this translation turned out to be much more in-depth than planned. (See here for our most recent meeting on the subject, two weeks ago.)

  2. Intermediary Revision. Though we originally imagined the Gordian-Envelope file output format as the intermediary for all interchange, we increasingly see the in-memory ZeWIF binary representation as the core interchange and that some wallets might directly use that and never go to the Envelope-based text format. As such, the zmigrate tool and the zewif crate have received more attention and definition. (Developers might either use the tool or the zewif crate.)

  3. Creating Clear Separation of Responsibilities. To maximize accessibility to developers, we have refactored the original zmigrate crate into four crates:

  • The core zmigrate crate, which vends the command line tool.
  • The zewif crate contains the universal parsing framework and in-memory abstractions. This crate also directly supports the reading and writing of the zewif interchange format, which is based on Gordian Envelope.
  • Several front-end back-end libraries that support the parsing of wallet formats into zewif abstractions, and translating those abstractions to their format. zewif-zcashd is where most of our work has gone, in translating the zcashd format to the zewif abstractions. zewif-zingo only reads the Zingo file format but does not yet translate it to zewif abstractions. zewif-zecwallet mentioned in the diagram does not yet exist, but is intended to continue the pattern of third party-developed front/backend crates.

zewif-update
zewif-update607×784 50.8 KB

  1. Deprecation Deadlines. Our original proposal focused on the April deprecation deadline for zcashd as a hard requirement rather than more organically laying out a project and deriving the time needed from that. As the work proved to be in excess of the time, we’ve figured out how to support the needs of the deprecation while still leaving this one major element unfinished.

Beyond this, we always knew there would be desire for longer term support, particularly for revisions of ZeWIF as it comes into use. We can now see this is something that’s going to immediately be needed, because the developers that are starting to use our interchange format today are going to want that support over the next few weeks. (In fact, ECC has requested that we delay the release of the zewif crates specifically to allow time for integration and revision.)

We hope that @ZCG can extend our original grant for the work still needed to close out the Gordian Envelope output-format work on the original grant, and also that they can boost the grant to enable support for other developers in April.

To do so, we’d update the current Milestone 3 as follows, with our expectation being that we’ll have a full report out to close this on April 1 or April 2:

  • Zmigrate & Zewif crates for in-memory ZeWIF, available at GitHub
  • Cargo docs for ZeWIF Rust API
  • test suite (zewif-zcashd crate) for zcashd
  • test suite for a zecwallet-specific format.
  • First draft: Best practices doc for importing & exporting
  • First draft: Best practices for incorporating legacy or single-use wallet data as Envelope attachments

We’d then request a new milestone 3.5 for April 30th with the following deliverables:

  • ZeWIF-Envelope Import/Export Crate
  • Full ZeWIF Serialization Specification
  • Final versions of Docs

This would require the additional Blockchain Commons work:

  • ZeWIF Envelope Input & Output + Final Specification + Engineering Support for other developers (22 BC research days [e.g., April]: $26,400)
  • Finalization of Docs, Meeting Support (2 BC writing days: $2,000)

Milestone 3.5: $28,400

This would not affect Milestone 4, which is work that Zingo Labs would be doing in parallel to the new Blockchain Commons 3.5 work.

We are of course committed to finishing the work as specified in the original grant proposal, but as we said we hope that ZCG can support the extra time that’s been required, plus allow us to provide better follow-up for the community over the course of the rest of April.

Please let us know if we have approval for this, and if so we’ll submit the revised third milestone on the 1st or 2nd then the new 3.5 milestone around the 30th.

Thank you!

Christopher Allen
Blockchain Commons

10 Likes