Open-source Orchard-based Wallet Service for Enterprises – Looking for Users & Feedback

Community Collaborations
1

Hello Zcash community

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.

Thanks

2 Likes
2

I think you should talk to @aarnott who is to my knowledge someone who has a very valuable mix between zcash wallet development and big-scale systems.

2 Likes
3

Thanks @pacu — really appreciate the intro.

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.

1 Like
4

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.

1 Like
5

Thanks — that aligns with what I’ve been hearing from operators too.

At scale, having to manage thousands of transparent addresses and private keys becomes a real operational bottleneck for exchanges and custodians.

That’s part of why I’m interested in whether shielded-side accounting and note-based models could simplify this in the long run.

6

I am not sure why having thousands of transparent private keys would be an issue. Did you hear otherwise from exchange system designers?

7

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.

8

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?

9

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