I’ve open-sourced a project called Web3 Wallet Service — a Rust + React wallet backend designed to bring Zcash Orchard (Halo2) privacy into real business workflows.
GitHub:
This is not a consumer wallet. It is a wallet management service that supports all four Zcash transfer modes:
• T→T
• T→Z
• Z→Z
• Z→T
with:
• commitment trees
• nullifiers
• witnesses
• encrypted memos
• role-based access and audit logs
⸻
Why this matters
Zcash privacy is powerful, but today it’s hard for organizations to use it in real systems.
This project lets businesses use Orchard for:
• Payroll & commissions (Z→Z, no public salary leaks)
• Supplier & vendor payments
• OTC & large trade settlement
• Exchange deposit / withdrawal flows (T↔Z)
• Treasury & custody operations
• Cross-border payments with memo-based reconciliation
⸻
What I’m looking for
I’m looking for:
• people who want to use Zcash in real systems
• feedback on what’s missing
• bug reports
• feature requests
• Orchard performance & UX pain points
If you have a use case and something doesn’t work —
tell me and I’ll build it.
Yes, I’d love to connect with @aarnott. This project focuses on the infrastructure layer for using Orchard in real business workflows (custody, treasury, settlement)。
I’ve been working on commitment trees, note/witness tracking, and role-based transaction flows on top of Zebra / librustzcash, so his feedback would be extremely valuable. I’ll reach out.
I’ve only heard this second-hand, but I understand large org users (i.e., exchanges) need to manage several thousands of transparent addresses, and their corresponding keys.
Yes — ZEC airdrops and bulk private payouts are very likely for ecosystem incentives, cross-chain programs, and exchange-side distributions.
At that scale, T-addresses + multisig explode into key, policy, and HSM complexity, which is exactly where note-based shielded distribution makes far more operational sense.
When I hear that orgs need thousands of transparent addresses – why? Because they say so (out of ignorance)? Why not use shielded addresses for these purposes? Each additional transparent address requires another call to the Zcash node or lightwallet server. A diversified shielded address does not. And (as I’ve proven with my Nerdbank.Zcash library and eZcash wallet) diversified shielded addresses can be used to understand separation of payments, so that you may generate any number of them and still know which particular address received a payment.
Also, why track thousands of private keys when you can generate them all from a seed phrase? You mentioned HSM, so is it that their security model requires that you have access to an individual private key without ever having access to the master seed?
Thanks — I think we’re talking about different layers.
I’m referring to bulk payouts / airdrops to many independent recipients, where each address represents a separate user outside the sender’s trust domain, not internally derived addresses from a single seed.
In this setting, HSMs are typically used for multi-party approval and policy-controlled signing, not just key storage
If you held off because the project looked too rough — now’s a reasonable moment to try. Real deployment friction / API gaps / integration paper-cuts → feedback welcome.
Diversified shielded addresses — partially: FullViewingKey::address(diversifier, External) is wired internally, but the REST API only exposes one UA per wallet today. The N-diversifier endpoint is the natural next step — exactly your eZcash / Nerdbank.Zcash design.
ZIP-32 + BIP-39 derivation already lives in keys.rs, but create_wallet generates an independent SpendingKey per wallet instead of using master-seed → ZIP-32 accounts. Real correctness gap, not a HSM choice. Roadmap: master-seed-per-tenant + each wallet = ZIP-32 account index.
HSM — v0.1 wording was misleading. Future story: master seed sealed in HSM, derived spending keys via sign-only handle. Will fix the docs.