Hi @emersonian, to follow up on your questions: we currently don’t support generating just orchard addresses. However, if the community thinks there is a strong need for this, we can add it as part of the upcoming maintenance contract and bumped up in priority.
With regards to the first question, are you asking about something like a wallet connect integration?
Not “WalletConnect” the platform, but “Connect Wallet” the signing process.
Given a string, a web wallet should be able to sign it with the user’s private key to fulfill a lot of use cases, including allowing the user to sign into a website by using their wallet. This is a common UX across the industry. (try clicking “Connect” on ENS’ app for an example https://app.ens.domains/ )
Thanks @emersonian, understood. We can certainly add this to our list of proposed improvements. I’ll keep you posted as we start to push those through and begin working on them.
Hi again Zcash community. I’m happy to report that the Zcash Browser Wallet Library and Snap is now complete and is currently under audit! We will keep you updated as soon as the audit passes and the Snap becomes available.
Has anyone here used the Library in Vue/React environments? I have made a successful build of the library as I have cloned it in my simple Vue project.
I am thinking of building an extension and just getting some functions but I am not actually sure how to link the library and call it in my Vue project despite it sitting inside my project.
Another thing, what is the difference between snap and web-wallet libraries, which would be better to call if I want to do something like this:
Hello Zcash folks! The Zcash Metamask Snap is live and was recently announced here: https://x.com/ZcashCommGrants/status/1947295805313843575. We will now be moving into a one year phase of maintaining and improving the snap. Please feel free to check it out and reach out to us here if you have any ideas or suggestions for how the snap or library could be made more useful for you and the community!
Hey Zcash community! I’ll be posted monthly updates to keep everyone up to date on the maintenance and improvements that ChainSafe has been doing on the Metamask snap and associated libraries.
Here’s what our team shipped last month for the WebZjs browser wallet library and Snap:
Added “view key prompt” with description — Introduced a prompt to securely request the viewing key from users, improving clarity and UX when accessing shielded account data. (See discussion around view key handling in the MetaMask Snap environment here)
Added “Snap on install” dialog when installed from MetaMask store — Now the Snap installer clearly indicates the Snap context during installation via MetaMask.
Wrote local build script — Added a just build-web target in the root justfile to simplify local builds using wasm-pack. This produces a browser-ready WebZjs package in packages/webz-core. (Check out the justfile and README in the WebZjs GitHub repo).
Added Origins GitHub Actions workflow test — Introduced a CI test to verify allowed origins in webzjs-wallet, catching Snap-origin cross-origin issues before they reach production.
Added comments to webzjs-wallet PCZT code — Improved readability by annotating partially constructed Zcash transactions (PCZT) logic.
Fixed bugs related to connecting to Snap, with user instructions — Resolved stability issues around initialization and added step-by-step instructions for connecting to the Snap.
Completed fix for web wallet getAccountData — Finalized the implementation of getAccountData in the WebZjs web-wallet, ensuring accurate retrieval of shielded account information.
Let us know if you hit any issues testing this build!
Hi folks, I’m here to share another update on what ChainSafe worked on during month two of our maintenance grant for the Zcash Metamask Snap:
This past month we focussed on resolving two especially tricky bugs.
The first bug was that onInstall was not being triggering if a user was already on https://webzjs.chainsafe.dev.
The second issue was with a lack of snap dialog error on the cancel button. This issue was resolved to restore the same UX as before.
We have also added better error messages and updated the UI to be more intuitive during the install and setup process.
Check out this issue for more info on bug resolution: Snap does not start · Issue #118 · ChainSafe/WebZjs · GitHub
WebZ.js + MetaMask Snap — October Update
Hi folks, here’s a quick update on what ChainSafe has been working on this month:
Fixed end-to-end tests: ensuring our test suite runs cleanly and continues to validate expected Snap behavior.
Added CI for Snap manifest validation: automated checks now verify manifest consistency during builds, reducing the risk of publishing issues.
Introduced a build:prePublish script: this new step cleans up the Snap manifest before release, improving reliability and reproducibility.
Ongoing work on library updates: we’ve started implementing improvements around transparent address rotation and ephemeral address handling, laying groundwork for better privacy and usability in future releases.
As always, thanks to everyone testing and providing feedback, helping us catch edge cases and refine the experience.
If you run into issues or have suggestions, please share details in GitHub issues so we can reproduce and track them effectively.
WebZ.js + MetaMask Snap — November + December Update
Hi everyone, I’m writing with another update about ChainSafe’s ongoing work to maintain Webz.js and the Zcash MetaMask Snap. For the final months of 2025, we remained focussed on work to reconcile librustzcash with the latest NU 6.1 update. The work required here is much greater than we initially anticipated, and we plan to bring in a rust expert to help us finish the update as soon as possible. While we complete the update, certain functions of the snap may not function as expected. I will post here again as soon as our libraries and snap are fully reconciled with the new update.
Hi Colin,
Thank you for the regular updates on the forum and for pointing people to the WebZjs GitHub repository to report issues.
From a ZCG committee perspective, I wanted to flag one thing that’s important for us when evaluating ongoing maintenance grants. One of the few objective signals we have to assess monthly progress is the state of the public issue tracker. When many issues remain open without clear status updates, it becomes difficult to understand whether they are still relevant, already fixed, blocked upstream, or out of scope.
Even brief triage closing resolved issues, adding short status comments, or labeling issues as blocked/deferred would greatly improve clarity for us, without changing the actual scope of work. I fully recognize that the library is usable and has been adopted in hackathons; this is more about improving visibility into maintenance work from an oversight standpoint.
Thanks again for the ongoing work.
One more point I’d like to clarify, related to the earlier comment by @nuttycom. (Zcash Browser Wallet Library - #37 by nuttycom)
As I understand from the explanation above, transaction listing is not expected to be provided by zcash_client_backend by design, and would instead need to be implemented at the storage or in-memory backend level (within WebZjs itself).
Given that, could you clarify the current status of this from a WebZjs perspective?
Thanks in advance for the clarification.
Hi @artkor, thanks for reaching out about this. We have been heads down trying to get the snap and library up to date with NU6.1 and I agree that the repo could use some house keeping. We’ll aim to give it a quick refresh next week. I’ll let you know once it’s done 
Have reverted to our dev team, will have an answer for you shortly!
Hi @artkor, we just released a new version that includes transaction history tracking. Does this give you what you are looking for?
WebZ.js + MetaMask Snap — January 2026
Hi Zcash community 
Earlier today, Metamask published our extensive 6.1 update so the latest version of the snap is now live in prod! All user issues associated with the 6.1 descrepency are now resolved. At a high level, the update consisted of the following:
- Major dependency upgrade: Updated all Zcash Rust crates (zcash_client_backend, zcash_primitives, etc.) to NU6.1-compatible versions, requiring extensive Cargo.toml changes and resolving ~1000 lines of dependency conflicts
- Graceful upgrade handling: Implemented fallback mechanism to handle incompatible wallet data formats after upgrades - when IndexedDB data becomes incompatible, installs the wallet fresh available for resync instead of crashing, with user notification
- gRPC stability improvements: Added retry logic with exponential backoff for lightwalletd gRPC calls (GetTreeState, sync operations) to handle network interruptions and proxy timeouts during long syncs
- Account recovery fixes: Solved issues with wallet recovery after snap reinstallation by implementing proper credential restoration from MetaMask’s BIP44 seed and birthday block persistence in both IndexedDB and snap state.
In addition to the 6.1 update the latest version includes two new features:
- Transaction History: Built complete transaction history system with new Rust module (transaction_history.rs, 373 lines) exposing tx details via WASM bindings, plus React UI component for viewing past transactions
- Pending Transaction Tracking: Added real-time pending transaction monitoring with balance caching in snap state, allowing wallet to display accurate balances (confirmed + pending) even after cookie/IndexedDB clears, including auto-recovery on page reload
We are excited for this new release and hope that you all enjoy the new features!
Colin, thanks for this significant upgrade. From what I can tell, this commit delivers the exact transaction history/listing piece @nuttycom was asking about. Really appreciate the work.
Hi again @artkor, I’ve reverting with some additional info from our dev team that might help add some context with regards to your above query:
zcash_client_backend despite the name is just the protocol work. Transaction listing is fully implemented in WebZJS, zcash_client_memory handles the transaction listing and uses IndexedDB by design. SQLite could offer query flexibility, but is not needed at this time. IndexedDb stores what’s needed and keeps it all in the browser. If we see user demand for it, we can provide more filtering and reorganizing for our users, but we wouldn’t suggest doing this work unless there is clear demand for it. If you think this is something we should definitely prioritize, then we can move it higher up our todo list. Let us know what you think!
Thanks for the kind words @artkor, it’s our pleasure to keep building out this snap and make sure it becomes as functional and widely adopted as possible.
A paginated approach that returns everything is straightforward and seems fine to me; we actually have the same API for testing only in zcash_client_backend.
My inclination for how to approach this problem has been that we should use an approach that provides greater capabilities for filtering results; since directly accessing the data store permits that, that’s what we’ve gone with for the mobile wallets, using direct SQL queries, and that way you also get streaming of results as opposed to pagination. I just didn’t want to build a query DSL into the backend APIs that every backend had to write an interpreter for.