Hi Zcash community,
Zucchini Wallet 0.5.2 is now published on the Chrome Web Store, and we have
published two npm packages for developers building Zcash integrations.
The live Chrome listing shows 4,000 users as of September 27, 2026. Thank
you to everyone trying the wallet and sending feedback. That is the store’s
displayed user count, not a claim about daily activity or transaction volume.
What changed in 0.5.2
- Refreshed design: clearer balance and action grouping, consistent icons,
improved settings and sheets, and more feedback when an action succeeds or fails. - Receiving-address rotation: create another shielded receiving address
within the same account. Previous receiving addresses remain usable. - Optional local contacts: explicitly save, edit and remove recipients in
encrypted local storage. Sending does not automatically save a contact. - Seven languages: English, German, Japanese, Simplified Chinese, French,
Arabic and Spanish, with a Settings selector and Arabic right-to-left layout. - Website Connect and payment requests: grant permissions to a compatible
website, then review each payment separately. Revoke connections in Settings. - Optional sharing after an X tip: a prewritten draft you choose whether
to post. It is specific to X tips and does not automatically publish anything. - Incoming viewing-key export: password-gated local export for uses such as
private receipt scanning. Connected websites cannot request this export.
Tipping and the X registry
The optional X content script puts a Tip button on posts. If the recipient is
registered, their receiving address resolves and the wallet opens a send review.
If not, it prepares an invitation for the sender to review and post.
registry.zucchinifi.xyz explains how the
recipient can connect X inside Zucchini and confirm their receiving address.
There is no escrow or reserved tip in the invitation flow. After registration,
the sender can make a direct payment.
This registry binds an X identity to a receiving address. It is separate from
our work on merchant-domain registration and signed invoices. Rotating a wallet
receiving address does not automatically change an existing X registration.
Existing integrations and their boundaries
ZNS name resolution, X tipping, Peer Buy and 1Click swaps remain part of the
wallet. They were already present before 0.5.2; this update improves the
surrounding experience rather than introducing all four for the first time.
- ZNS: resolve a Zcash name and review the payment destination.
- 1Click / NEAR Intents: obtain a route quote, deposit and track a swap.
- Peer: use supported fiat-payment options for Base USDC settlement,
followed by a separately approved conversion to ZEC.
Availability, liquidity, minimums and fees depend on the provider and route.
The Buy flow distinguishes a 0.5% referral fee from a 1 USDC sponsorship fee;
the latter is non-refundable once collected. These are not necessarily the
entire cost of a route. Some conversion paths use transparent Zcash receipt
before shielding, which is a different privacy boundary from a direct shielded
ZEC payment.
We are continuing end-to-end Buy validation; a completed real-provider purchase
and recovery test remains outstanding in our release acceptance record. We
welcome reports about unclear steps without asking anyone to share payment
credentials or private wallet material.
npm packages and examples
npm install @zucchinifi/dapp-sdk@0.2.0
The dApp SDK provides typed wallet discovery, permissions and Zcash payment
requests. Ordinary website payments work with 0.5.2 without merchant registration.
The supported ZIP-321 profile is one recipient, an explicit positive ZEC amount
and an optional printable UTF-8 memo. Connection does not authorize payment or
certify the merchant. A submitted transaction is not yet a confirmed receipt.
0.2.0 changes the API from 0.1.x; see the
migration guide.
The SDK has no seed derivation, wallet database, spending-key handling or proving
engine. Its EVM/Solana discovery helpers do not add those chains’ signing to
Zucchini Wallet.
npm install @zucchinifi/zcash-scanner@0.1.0
The scanner package is a Node wrapper around a separately built Rust scanner.
It uses an incoming viewing key locally and fetches chain data from a configured
lightwallet provider. It cannot spend funds and does not require you to run a
full node. Operators still manage scanner checkpoints, reorganizations,
confirmation thresholds and application receipt handling. An incoming viewing
key is sensitive; keep it on the private backend.
Both packages are available in our public SDK repository,
under MIT or Apache-2.0, with runnable checkout and scanner examples. The
experimental signed-merchant APIs are not enabled in production Wallet 0.5.2.
Native iOS/macOS progress
We are building SwiftUI apps for iPhone and Mac with a Rust wallet engine based
on the Zakura wallet-library family.
Transaction construction, proving and signing run locally. These remain
development/testing builds; this post does not announce an App Store or
TestFlight release. We will share more as device testing and distribution
progress.
What would help us next
We would especially appreciate feedback on:
- Whether payment reviews make the recipient, amount, fee and next action clear.
- X tipping and registration: where, if anywhere, the flow is confusing.
- Translation quality and Arabic layout from people who use those languages.
- Developer experience with the basic Connect → Pay example and SDK docs.
For support, contact x@zucchinifi.xyz. For development discussion, use
SDK issues or reply here.
Please never post recovery phrases, viewing keys or payment-account credentials.
Thanks to the Zcash ecosystem, the ZNS, Peer, NEAR Intents and Zakura contributors,
and everyone whose feedback has shaped this release.