### 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 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)
@shannona, @ChristopherA
### Organization Name
Blockchain Commons
### How did you learn about Zcash Community Grants
This is a continuation of our work with ZCG from early in the year.
### Requested Grant Amount (USD)
$4,500
### Category
Wallets
### Project Lead
```project-lead.yaml
Name: Christopher Allen
Role: Executive Director
Background: Founder of Blockchain Commons, Co-Author of TLS & DID standards
Responsibilities: Project Oversight
```
### Additional Team Members
```team-members.yaml
- Name: Wolf McNally
Role: Lead Researcher
Background: Developers for ZeWIF & Most Blockchain Commons software
Responsibilities: Engineering of ZeWIF Updates
```
### Project Summary
Update of ZeWIF crates & underlying crates to use `thiserror` instead of `anyhow` to allow for easier programmatic handling of errors.
### Project Description
On September 8, Kris Nuttycombe asked us to make a pass at revising error handling in the ZeWIF libraries (and other elements in our stack). He wanted us to change out "anyhow" to "thiserror" to make the errors more algorithmically accessible.
We were committed to doing this work because creating interoperability through ZeWIF lies near our own goals of creating user freedom. Since this work was requested by ECC, we also presumed that it was important for the continuing work on the zcashd deprecation.
We delivered Kris with updated libraries on September 18. Unfortunately, because our previous maintenance grant for ZeWIF was not approved, the work was unfunded: it came out of our pockets.
We're hoping that ZCG can fund this work already done to support the Zcash community.
Here's more details on what was done:
### Removed `anyhow` dependency in Blockchain Commons library stack
- While some of our crates already used `thiserror` version 1 in certain cases, ten of the library crates in our stack used `anyhow` for ad hoc, string-based error reporting, of which four foundational crates are directly or indirectly dependencies of the `zewif`, `zewif-zcashd`, `zewif-zingo`, and `zmigrate` crates:
- bc-envelope
- bc-components
- dcbor
- bc-crypto
- All library crates now exclusively use `thiserror` version 2 to report semantic errors. All such crates have had version number bumps and have been updated on https://crates.io.
- This was necessary so `zewif` crate, based on our stack, would not have (directly or indirectly) any dependency on `anyhow`, and all errors thrown are now relatively easy to deal with programatically and to internationalize. Our app-level crates (CLI tools, servers) still use `anyhow` as that is its best use. With these modifications, Zcash can adopt any Blockchain Commons library crates without re-introducing dependencies on `anyhow`.
### zewif
- Replaced the blanket `anyhow` dependency with a crate-local `Error` enum powered by `thiserror` v2, plus a `Result` alias, so every module now reports precise failure modes instead of opaque `anyhow::Error` values (`src/error.rs`, widespread signature updates across `src/*`).
- Updated all serialization helpers and macros (`blob_macro.rs`, `data_macro.rs`, `sapling_*`, `orchard_*`, etc.) to propagate the new typed errors and removed the no-longer-needed `StringContext` shim once conversions were in place.
- Aligned dependency metadata and removed the crate’s private `Cargo.lock`, relying on the workspace lock instead.
### zewif-zcashd
- Introduced a comprehensive `Error` type with contextual variants covering parser underflow, invalid CompactSize encodings, UFVK lookup failures, command execution errors, and more; added `ResultExt`/`OptionExt` helpers to maintain ergonomic error enrichment (`src/error.rs`).
- Rewrote the parser macro and supporting modules so every parser returns the new `Result`, eliminating `anyhow` from the parsing stack and improving diagnostics when decoding Berkeley DB wallet dumps (`src/parser/parse_macro.rs`, `src/zcashd_wallet/parseable_types.rs`, `src/zcashd_parser.rs`, etc.).
- Cleaned up obsolete scaffolding (e.g., removed the stale `Cargo.lock`, deprecated registry helpers) and refactored the migration code to surface the richer errors while trimming redundant warnings.
### zewif-zingo
- Dropped `anyhow` in favor of a focused `ParseError` enum implemented with `thiserror` v2, giving explicit variants for unsupported dump versions, malformed strings, IO failures, and mnemonic entropy errors (`src/error.rs`).
- Replaced the borrowed `zewif` parser stack with a lightweight `BinaryReader` wrapper that handles length-checked reads and contextualizes IO errors, yielding clearer parsing boundaries (`src/binary.rs`, `src/zingo_parser.rs`, `src/wallet_capability.rs`).
- Adjusted `Cargo.toml` and module exports so the crate builds solely on the new typed errors while continuing to service the CLI ingest path.
### zmigrate
- Overhauled the CLI tooling to match the typed-error stack: refreshed the zcashd dump script to validate Berkeley DB tooling before execution and pipe the new `--from/--to` interface (`run_zcashd_dumps.sh`), and re-enabled the Zingo ingestion path with a guarded `dump`-only workflow (`src/main.rs`, `src/zingo_cmd.rs`).
- Refreshed the regression suite to consume the updated APIs from `zewif`/`zewif-zcashd`, improving reporting for migration coverage and formatting the generated summaries (`tests/test_*`).
- Added an opt-in `zingo` Cargo feature so Zingo dependencies, scripts, and tests stay inactive unless explicitly requested, keeping default builds lean (`Cargo.toml`, `run_zingo_dumps.sh`, test modules).
### Proposed Problem
`anyhow` error reporting in libraries did not allow full algorithmic integration.
### Proposed Solution
Replace `anyhow` with `thiserror`.
### Solution Format
Update repos & associated Rust crates.
The major repos are:
https://github.com/BlockchainCommons/zewif
https://github.com/BlockchainCommons/zewif-zcashd
https://github.com/BlockchainCommons/zewif-zingo
https://github.com/BlockchainCommons/zmigrate
### Dependencies
The only dependencies were on our previous ZeWIF work.
### Technical Approach
The approach was simply to replace `anyhow` usage with `thiserror` v2 for any library crates. (CLI crates continue to use `anyhow`, as is appropriate.)
### Upstream Merge Opportunities
The main upstream opportunities are supporting the zcashd deprecation and making it easier to move data from zcashd to new wallets, particularly zallet.
### Hardware/Software Costs (USD)
$0
### Hardware/Software Justification
N/A
### Service Costs (USD)
$0
### Service Costs Justification
N/A
### Compensation Costs (USD)
$4,500
### Compensation Costs Justification
We specced this project out at 4 days. It came in slightly lower, at 30 hours. We are requesting repayment of engineer costs at $150/hour (x30 hours = $4,500).
### Total Budget (USD)
$4,500
### Previous Funding
Yes
### Previous Funding Details
This is an extension of work done for "Zcash Extensible Wallet Interchange Format (ZeWiF)", grant request #3
### Other Funding Sources
No
### Other Funding Sources Details
_No response_
### Implementation Risks
The only danger in the implementation is that it's a wide-scale update.
### Potential Side Effects
The goal is to make errors more visible to the program, with the linked result that they may be less visible to users, depending on implementation details of specific apps using the libraries.
### Success Metrics
We'll consider this successful if ECC is happy with the results. The last we heard was on September 18, when they said they'd be integrating the work into their crates over the next few days.
### Startup Funding (USD)
$0
### Startup Funding Justification
N/A
### Milestone Details
```milestones.yaml
- Milestone: 1
Amount (USD): $4,500
Expected Completion Date: 2025-09-18
User Stories:
- "As an engineer, I want errors that are more programmatic, so that I can integrate them into my own apps easier."
Deliverables:
- Updates to underlying crates: bc-envelope, bc-components, dcbor, bc-crypto
- Updates to ZeWIF crates: zewif, zewif-zcashd, zewif-zingo, zmigrate
Acceptance Criteria: Release of repos to GitHub (completed on September 18)
```
### Supporting Documents
```files.yaml
```