RE: Kestrel + ZecAuth: Open Zcash Wallet Connectivity with African Fiat On/Off-Ramps
Thanks for raising this. I think there may be some overlap in how the existing KuvarSend infrastructure and the work proposed to ZCG are being interpreted, so I’d like to clarify the distinction.
KuvarSend’s existing payment infrastructure is already live and is not what we are asking ZCG to fund. KuvarSend launched less than two months ago and currently has 1,090+ registered users and has processed over $40.9K in transaction volume. We already operate the underlying African payment rails, settlement infrastructure, compliance flows, and fiat payment integrations ourselves.
Our involvement with the Zcash East Africa community has primarily been around supporting Zcash adoption and demonstrating how Zcash could integrate into an existing African payments product. What we showed there was a working prototype demonstrating the intended interaction between KuvarSend, ZecAuth, and the wallet. That work helped validate that the concept is technically feasible, but the prototype is not yet the production-ready, documented, security-reviewed, reusable infrastructure described in this ZCG proposal.
The ZCG request is specifically for the Zcash-specific engineering required to productionize that prototype, namely:
-
ZecAuth: turning the existing prototype into a documented, tested and open wallet-to-application authorization protocol, including application binding, scoped authorization, replay protection, expiry, revocation, standardized errors, developer documentation and reference implementations.
-
Kestrel: separating the prototype wallet into a standalone open-source, self-custodial Zcash wallet with production-grade iOS/Android implementations, secure key storage, shielded transactions, Unified Addresses, ZecAuth connectivity and the required Zcash privacy/migration functionality.
-
Production integration and validation: integrating those components with KuvarSend as the first real-world implementation, then completing testing, a public integration environment, an independent security review, Android performance validation, reproducible builds and production releases.
KuvarSend’s existing payment rails are therefore a dependency and an in-kind contribution from us, rather than a grant deliverable. We deliberately structured it this way because we did not think ZCG should pay us to rebuild fiat infrastructure that we already have.
What ZCG would fund is the layer that does not yet exist at production quality: the open-source Zcash wallet, authorization technology, security work, developer tooling and the production Fiat↔ZEC integration that proves these components work outside of a demo.
The reason KuvarSend is important to the proposal is that it gives this work an immediate real-world deployment environment rather than leaving ZecAuth and Kestrel as standalone prototypes. We already have users and transaction activity, so the grant can take the Zcash-specific components from prototype to production and test them with an actual African payments use case.
There is also no intention to have ZCG fund KuvarSend’s proprietary payment, liquidity, compliance or settlement infrastructure. Those remain outside the grant scope.
So the distinction is essentially:
Existing today:
KuvarSend payment infrastructure + an early ZecAuth/Kestrel prototype.
What Zcash East Africa has seen:
The prototype and our work demonstrating/supporting Zcash integration and adoption.
What ZCG would fund:
Productionizing ZecAuth and Kestrel as open-source Zcash infrastructure, completing the production-grade integration, security review, testing, documentation and public releases.
I hope that clarifies where the funding would actually be applied and why the fact that KuvarSend already exists is an advantage to the proposal rather than the subject of the funding itself.