What If Buying Zcash Was as Easy as Buying Airtime?

Community Grants Minor Grants
1

Building a WhatsApp-native Zcash wallet for Tanzania.

In Tanzania, almost everyone knows how to buy airtime.

A small percentage of this, knows how to buy Zcash.

I don’t think that’s because people don’t value financial privacy. I think it’s because the path to using Zcash is still too complicated for someone who simply wants to send money.

That observation led me to spend the past few months building Pesa Ya Siri—Swahili for “Secret Money.” It is a WhatsApp-native interface for Zcash designed to make private digital cash as familiar and accessible as sending a message or buying an airtime voucher.

The Problem

Tanzania has one of the highest rates of mobile money adoption in Africa. From market vendors and motorcycle taxi riders to small businesses and large retailers, mobile money has become part of everyday life.

The convenience is undeniable, but it comes with a trade-off: every transaction leaves a record. Payment providers maintain detailed transaction histories, creating a financial trail that users have little control over.

For many people this may not seem important. For journalists, activists, small business owners, cross-border traders, or anyone who simply values financial privacy, it matters.

Zcash was designed to address exactly this challenge. Through shielded transactions, it allows users to transact without publicly revealing the sender, recipient, or transaction amount on the blockchain.

The challenge is not the technology—it is accessibility.

For someone new to cryptocurrency, getting started with Zcash typically involves downloading a wallet, securing a recovery phrase, understanding different address types, and finding a reliable way to acquire ZEC.

For many potential users, this is where the journey ends.

Why Zcash, and Why Now?

The upcoming Ironwood network upgrade represents another important milestone in the evolution of Zcash. Rather than building against temporary infrastructure, Pesa Ya Siri is being developed with the intention of integrating directly with the post-Ironwood network, allowing the production version to launch on the latest generation of Zcash shielded technology.

This provides an opportunity to introduce new users to Zcash using modern infrastructure from the outset.

What I Built

Instead of asking users to learn another application, I decided to bring Zcash to a platform they already use every day.

Pesa Ya Siri is a conversational interface for Zcash that operates entirely through WhatsApp.

A user sends CREATE to the Pesa Ya Siri WhatsApp number.

The system creates a wallet associated with their phone number.

From there they can check their balance, send funds to another user, redeem voucher codes, and eventually purchase mobile airtime—all through simple WhatsApp commands.

The goal is not to replace existing Zcash wallets, but to reduce the barriers to entry for first-time users.

A Different Approach to Onboarding

One of the biggest obstacles to cryptocurrency adoption is acquiring digital assets.

Pesa Ya Siri addresses this by introducing a voucher system inspired by the distribution model of traditional airtime scratch cards.

Voucher codes are generated by the platform, printed onto physical scratch cards, and distributed through local vendors.

A customer purchases a voucher using Tanzanian Shillings, scratches the card, and sends the redemption code through WhatsApp. Once validated, the corresponding value in ZEC is credited to the user’s wallet.

The value of each voucher is calculated using live market pricing, with a small pricing buffer to account for market movements between voucher generation and redemption.

Planned denominations include 2,000, 5,000, 10,000, 25,000, and 50,000 Tanzanian Shillings.

For users, the experience is intentionally familiar. They purchase a voucher in much the same way they purchase airtime today, without needing to navigate exchanges or cryptocurrency marketplaces.

Current Project Status

Pesa Ya Siri has progressed beyond the concept stage.

A functional MVP has been completed and is backed by a persistent database.

Current functionality includes:

  • Wallet creation

  • User registration

  • Balance management

  • Transaction workflows

  • Voucher redemption

  • Administrative voucher generation

  • Live ZEC price retrieval

  • Persistent data storage

The backend is publicly accessible:

https://web-production-fe8ba0.up.railway.app/health

The source code is available on GitHub:

Making the project open source is intentional. It allows anyone in the Zcash community to inspect the implementation, follow its progress, and contribute feedback.

From Prototype to Production

When I first shared this idea with members of the Zcash community, the response was simple:

“Build it first.”

Initial post on this

The initial ZCG application on Github

The ZCG feedback on it

That was good advice.

Rather than continuing to describe the idea, I focused on building a working implementation.

Today, the backend is operational, the chatbot processes real commands, application data persists correctly, and the complete source code is publicly available.

The remaining work is infrastructure.

The current implementation uses mocked blockchain interactions while the surrounding architecture is completed. Following the Ironwood upgrade, the next stage is integrating a production Zcash Full Node, lightwalletd, WhatsApp Business, and commercial airtime services to support live transactions.

What’s Next

The immediate objective is to transition Pesa Ya Siri from a functional MVP into a production-ready pilot.

The next development phase includes:

  • Production infrastructure deployment

  • Dedicated Zcash Full Node and lightwalletd

  • WhatsApp Business integration

  • Airtime API integration

  • Production security and monitoring

  • Swahili educational content

  • Pilot deployment with real users

To support this work, I will be applying for an initial grant through ZecHub.

Why This Matters

Technology is adopted when it fits naturally into people’s existing habits.

In Tanzania, WhatsApp is already how people communicate.

Airtime vouchers are already how many people purchase digital value.

Pesa Ya Siri brings those familiar experiences together with the privacy guarantees provided by Zcash.

The objective is not simply to build another wallet. It is to make private digital cash accessible to people who may never have considered using cryptocurrency before.

The MVP is complete.

The code is public.

The next step is connecting the platform to the live Zcash network and validating it through real-world use.

If you’re part of the Zcash ecosystem, I’d genuinely value your feedback. Whether it’s technical criticism, questions about the architecture, or ideas for improving the user experience, those conversations will help shape the next phase of the project.

Asante sana.

Clemence Douglas

GitHub: GitHub - clemencedouglas/pesa-ya-siri · GitHub

8 Likes
2

I think one of the strongest ideas here isn’t the wallet itself—it’s the onboarding philosophy.

Instead of expecting people to change their existing habits, you’re bringing Zcash into workflows they already understand. That’s often where adoption succeeds or fails.

I also appreciate that you built an MVP before asking the community to evaluate the idea. Having something tangible to review leads to much more meaningful feedback than discussing concepts alone.

Looking forward to seeing how this evolves.

1 Like
3

I do like this idea, great way to bring mass adaptation. Messages are protected so no one can read what you say end-to-end encryption, but the downside.

Meta can still see some info like who talks to whom, when, and how often. Backups stored in the cloud are often not protected with encryption. There are many dangers like hackers, malware, and fake messages on WhatsApp especially for people using cryptocurrencies. These scams include swapping addresses pretending to be support or spreading viruses. Also, a Zcash bot makes WhatsApp even more of a target for attacks.

1 Like
4

Thank you for raising these concerns. They are legitimate and deserve a thorough response rather than a dismissal.

You are technically correct on all points. WhatsApp’s end-to-end encryption protects message content, however Meta retains metadata including the identities of communicating parties, frequency of communication, and timestamps. That is a documented limitation of the platform and I will not argue otherwise.

What I will offer is context.

Regarding metadata visibility, building on WhatsApp involves an intentional trade-off. Transaction amounts and wallet addresses are encrypted in transit, but Meta can observe that a given user has interacted with the Pesa Ya Siri service. For a Tanzanian user who currently operates entirely on M-Pesa, where the mobile operator has complete visibility into every transaction including amounts, counterparties, and timestamps, this represents a material improvement in financial privacy. The objective of Pesa Ya Siri is not perfect anonymity. It is meaningful, accessible privacy at scale for people who currently have none.

On cloud backup risks, Pesa Ya Siri does not store sensitive wallet data within WhatsApp message history. Wallet addresses and balances are held in a secured database entirely separate from the chat interface. A compromised WhatsApp backup would not expose any critical information about a user’s ZCash holdings.

Regarding scams and social engineering, this is the concern I take most seriously. Pesa Ya Siri will never request seed phrases from users, primarily because users in this model do not hold seed phrases. The bot will never solicit passwords or sensitive credentials. All supported commands are simple, predictable, and publicly documented. Clear guidance on what the service will and will never ask for will be distributed through our vendor network and community onboarding sessions in Dar es Salaam, Arusha and other Regions.

Regarding the increased attack surface, rate limiting, daily transaction caps, and phone number verification are being implemented as foundational security measures. These controls limit the potential damage from any single compromised account to a defined and recoverable amount.

On the longer term roadmap, integration with Telegram and Signal is already planned for users who require stronger metadata privacy guarantees. The backend architecture is deliberately decoupled from any specific messaging platform. Supporting an alternative channel requires a configuration change, not a rebuild of the core system.

I appreciate the rigour of your feedback. A project that cannot withstand hard security questions has no business asking people to trust it with their money.

1 Like
5

Ok, we on the same page great.

I like the Telegram and Signal idea more than WhatsApp a lot of people do use WhatsApp doe.

Quick story time: I’m trying to get more involved with my local community. The council member asks me about WhatsApp; I told him that I didn’t used that app and I’m on Signal. He said he never heard of it and was interested in the fact I knew about other apps etc. So, people will be open to use new apps when privacy is key.

1 Like
6

This is an interesting concept but why not submit it for the Zechub hackathon instead of a Zechub proposal
Also, seeing that you are in Tanzania, you can reach out to the Zcash East Africa team for community support

2 Likes
7

Thank you for the suggestion, I genuinely appreciate it.

We are aware of Zcash East Africa and the work they’re doing, and it’s great to have an established regional community in the ecosystem. At the current stage, though, the project requires very little community support, as our focus is on completing the remaining development and infrastructure needed for launch.

Where I believe Zcash East Africa will play a significant role is once the product is ready. That’s when we’ll begin a series of in-person onboarding sessions, vendor outreach, and educational workshops, and having a regional community with local experience will be invaluable in driving real-world adoption.

Regarding the ZecHub hackathon, I did look into it, but I feel Pesa Ya Siri has already progressed beyond the proof-of-concept stage that hackathons typically target. With a live backend, connected database, functional APIs, real-time TZS-to-ZEC price conversion, recharge card generation, and a WhatsApp chatbot processing real commands, the project is now at a stage where infrastructure funding through a grant is a more appropriate fit than ideation-focused competition.

Thank you again for the thoughtful suggestions and for engaging with the

project.

8

I actually agree with you. Signal and Telegram are definitely part of the long-term vision for Pesa Ya Siri, especially since they align much better with the privacy values that Zcash stands for.

The reason we’re starting with WhatsApp is simply because that’s where the majority of our target users already are. In Tanzania, it’s the platform people use daily for business, communication, and coordinating payments. If our goal is to onboard as many new users to Zcash as possible, it makes sense to meet them where they’re most comfortable.

As the project grows, the plan is to expand to Signal and Telegram, giving users more privacy-focused options while keeping the onboarding process as simple as possi

ble.

2 Likes
9

Understandable, how many user’s you have now on What’sApp using this?

1 Like
10

None yet, and I want to be transparent about that rather than inflate the number.

Pesa Ya Siri does not have live WhatsApp users at this moment because the WhatsApp Cloud API integration is the next step in the build, not something that has been completed yet. What exists today is a fully functional backend with a live database, working API endpoints, and a chatbot engine that processes every command correctly. Anyone can test it right now by sending a POST request to the live server. The product works. The WhatsApp connection and other integrations is what the ZecHub grant(we are yet to submit one though) is specifically intended to fund.

This is precisely why we are applying to ZecHub for a small initial grant rather than approaching ZCash Community Grants with a large ask. The honest position is this: we have built the engine, we have deployed it, we have proven the logic works, and now we need a modest amount of funding to connect it to the platform where our target users already are.

The funds will be used to wire up a working product to WhatsApp, print the first batch of recharge cards, and onboard the first real users in Dar es Salaam, and this is a very different conversation from asking for funding based on an idea alone. The infrastructure exists. The grant closes the last gap between a working API and a product that ordinary Tanzanians can actually use tomorrow.

Once the WhatsApp integration is live, user acquisition begins immediately through our vendor network and community workshops.

That is when the user numbers become a meaningful metric to report.

11

Can you and the team start the WhatsApp, part solo then request funding once ready for the Signal and Telegram. Because by then we as a community can see the true value of this project.

1 Like
12

That’s a fair suggestion, and if the WhatsApp version could be launched independently, that’s probably the route I would have taken.

The challenge is that the remaining work isn’t made up of isolated features; it’s production infrastructure that all has to come together at the same time. To get Pesa Ya Siri live, we need a reliable Lightwalletd backend for Zcash synchronization, a production-grade WhatsApp API integration, a more robust database deployment on AWS, and the infrastructure to securely connect and manage all of those services. These components are interdependent, so deploying one without the others would leave us with a system that isn’t ready for real users.

That’s why we’re seeking a grant now. The funding isn’t for adding new ideas or expanding the project’s scope, it’s to complete the production infrastructure required to launch a stable and reliable service. The amount we’re requesting is actually quite modest considering what’s needed to move from a working prototype to a publicly available product.

If you’d like to see what has already been built, you don’t have to wait for the public launch. Most of the core functionality can already be exercised through Postman by calling the existing API endpoints. Everything is documented in this forum post, including the relevant links and instructions, so you’re welcome to explore the current implementation and see the progress firsthand.

1 Like
13

Making buying and spending Zcash as easy as spending airtime, That has a nice ring to it.

As a fellow African who has felt the struggle of having to purchase crypto from third parties, this would be a genuine changer for all.

In Nigeria here I have to either buy from a trusted vendor, pay high fees to withdraw from exchanges or even get ripped of completely, so I understand what this product would solve, I wish we would have one in Nigeria soon.

But I wonder how you would navigate the legal compliance side because I believe products like this need some sort of kyc or identify verification especially when sending and trying to receive money.

How do you plan on navigating that? Or are the laws different in Tanzania?

2 Likes
14

This comment means a lot, genuinely. The struggle you described in Nigeria is exactly what Pesa Ya Siri is designed to solve, and hearing it from someone who has lived it confirms that the problem is real and worth solving.

On the legal compliance and KYC question, you are absolutely right to raise it. Let me be transparent about how we are thinking through this.

Tanzania’s regulatory environment for digital assets is still developing. The Bank of Tanzania issued a notice in 2019 cautioning against cryptocurrency use, but has not enacted a comprehensive ban, and has since been actively studying frameworks for digital asset regulation. This places Pesa Ya Siri in a grey area that we are navigating carefully rather than ignoring.

Our approach has three layers.

  • The first is the custodial model. Because Pesa Ya Siri holds ZEC on behalf of users rather than giving them direct access to private keys, it operates more like a mobile money service than a pure cryptocurrency wallet. Mobile money operators in Tanzania are licensed under the National Payment Systems Act, and we believe this is the regulatory pathway most appropriate for what we are building. We intend to engage the Bank of Tanzania proactively before the pilot scales beyond a small controlled group.

  • The second is transaction limits. During the pilot phase, daily and monthly transaction limits will be enforced per phone number. This is standard practice for tiered KYC frameworks across Africa, where low-value transactions below defined thresholds are permitted with basic identification, typically a phone number and name, while higher-value transactions require more documentation. Tanzania’s National Identification Authority has a national ID system that we can integrate with at a later stage for users who want higher limits.

  • The third is ZCash’s compliance toolkit. ZCash supports selective disclosure, which means a user can voluntarily reveal transaction details to a regulator or auditor without compromising the privacy of their other transactions. This is a significant advantage over other privacy coins and gives us a credible conversation to have with regulators. We are not hiding from compliance. We are building infrastructure that makes compliance possible without destroying privacy for everyone.

On Nigeria specifically, the situation is more complex given the CBN’s restrictions on cryptocurrency-related banking. But the architecture of Pesa Ya Siri is designed to be replicable. Once we have a working, compliant model in Tanzania, the intention is to open-source the full deployment toolkit so that builders in Nigeria and elsewhere can adapt it for their own regulatory context. The WhatsApp layer, the recharge card distribution model, and the custodial wallet engine are all portable.

The honest answer is that we are building this in the order that makes sense: prove the product works, engage regulators early, and scale within whatever framework emerges from that conversation. We would rather be at the table when the rules are written than trying to retrofit compliance after the fact.

Thank you for this question. It is one of the most important ones anyone has asked about this project.

15

Hi Clemence, Edward here from BlockDesk News. Really impressive work — congratulations on getting to a functional MVP.

What stands out most to me is the onboarding insight. Meeting people where they already are (WhatsApp) instead of asking them to learn a new app is exactly the kind of thinking the ecosystem needs, and the airtime-voucher model is genuinely clever

I personally think that is usually the hardest part of adoption, so yerr pretty nice work here. If you want to reach out I am always happy to support devs in the Zcash space.

1 Like
16

But isn’t this just… every custodial wallet ever? Not to mention that… you are the new surveilling party, and the legal system in most countries have subpoenas. They will just subpoena you instead, and you wouldn’t even be able to reveal that you have been compromised if a gag order is attached from a court. This is quite literally what Zcash was meant to PREVENT, was it not?

Not to mention the fact that the voucher redemption metadata can be linked to the money being received. In theory, and in theory only, shielded privacy may “help” someone here. But in reality, for someone as technologically inept as to be unable to operate a Zcash buying procedure, it would be trivial for the authorities to extract transaction histories from the devices of targeted victims. It completely deletes the benefit of using Zcash.

Ironically, Zcash’s shielded transactions make it easier for the company administering the service to steal all the money here, as there is no transparency nor a mechanism for users, who don’t actually possess the ZEC, from stopping or checking anything. You are literally issuing IOUs, this is literally Tether but easier to steal. At least with Tether in Venezuela, people can see where the money went after it was skimmed. What recourse do people have if you just… stop responding?

Finally, how do you intend to get past Meta’s ironclad barriers regarding bots on WhatsApp? They demand that the bots use the official gateway, which is monitored and mediated by Meta or its affiliated third parties. P2P bots using real numbers are both forbidden and risky.

1 Like
17

Yeah, this is equivalent to putting literally any other settlement layer. You could be settling in US dollars to Roubles from a bank in Hong Kong and it would make no difference. In the end, it’s just numbers on paper, and your “persistent database” wording doesn’t help. What’s different between this and ANY pre-cryptocurrency database?

1 Like
18

Okay, I just discussed with some of my colleagues. Their question, just like mine, is that say you, or well, Mallory, decides to rug the treasury. The numbers become worthless. What are the users’ positions?

  • If using USDT:
    • Assuming you were faithfully settling each transaction, they have a log of every transaction made, even if anonymised (can be verified by matching metadata). This helps prove their case legally.
    • Mallory now needs to actively wash the money, committing a host of traceable crimes and OFAC sanction violations in the process.
    • Law enforcement can track Mallory.
    • Circle or Tether can blacklist Mallory, freeze the currency, and burn it/re-mint to victim.
  • If using ZEC as a settlement layer (shielded):
    • Assuming you were faithfully executing transactions… actually, it doesn’t matter. Nobody has any proof you ever actually resolved any transactions. You could have just put it in a 8% APY pool.
    • Victims are left no recourse.
    • Law enforcement can STILL recover each and every transaction from your “persistent database”
    • Mallory doesn’t have to do OFAC sanction violations, the money is exceedingly easy to smuggle out.
    • Law enforcement cannot touch Mallory.

What possible reason would be to touch ZEC here?

1 Like
19

These are the most substantive criticisms this project has received and they deserve a direct, honest engagement. I will address each point in turn.

On the custodial model and surveillance

You are correct. A custodial model makes the operator a surveillance party. The keys are held centrally, the data is held centrally, and a subpoena compels disclosure of both. This is not disputed.

The honest framing is that Pesa Ya Siri at the pilot stage is not a complete ZCash privacy solution. It is a ZCash onboarding tool for people who currently have zero financial privacy on M-Pesa, where Vodacom, the government, and every third party with API access can see the full transaction history of every user. Moving from that environment to one where transaction amounts are at minimum shielded on the ZCash blockchain is a meaningful improvement, even if it does not satisfy ZCash’s full privacy guarantee. That distinction should have been stated more clearly from the beginning.

On device-level extraction

Also correct. For a user who requires a WhatsApp interface to interact with ZCash, law enforcement with physical device access recovers the chat history. WhatsApp message content is encrypted in transit but sits on the device. Shielded transactions do not address this at the application layer and no claim has been made that they do.

On the IOU problem, the rug risk, and transaction proof

This is one of the strongest points raised and it warrants the most direct response.

To be unambiguous: no real ZCash transactions have been executed. The current system is a mocked backend. The ZCash integration is the next engineering milestone, to be funded by this grant. There is no on-chain transaction history to reference, shielded or otherwise, because none has occurred yet. Claiming otherwise would be dishonest and no such claim has been made in this thread.

In the current custodial architecture as designed, users will hold IOUs against the operator wallet once the system goes live. If the operator stops responding, the funds are at risk. There is no on-chain proof of individual balances in a custodial model. There is no recourse mechanism (for now). This will be addressed and the outcome updated on this post.

The comparison between USDT and shielded ZEC in a custodial context is well constructed. USDT has Circle as a backstop with blacklisting and reissuance capability. A custodial shielded ZEC service has none of that infrastructure. The very feature that makes ZCash private makes a custodial ZEC service harder to audit and more exploitable than a custodial stablecoin service. This is a genuine architectural weakness, not a communications problem.

The resolution is non-custodial architecture where each user holds a real on-chain z-address and genuinely controls their own ZEC. The custodial model was chosen for user experience simplicity at the pilot stage. But the critique is valid: it introduces a trust dependency that undermines the core ZCash value proposition. This is a legitimate reason to treat the non-custodial migration as a near-term engineering priority rather than a distant roadmap item.

On WhatsApp API restrictions

Pesa Ya Siri uses the official WhatsApp Cloud API through Meta’s Business Platform, not an unofficial gateway or a third-party bot. This is correct implementation. However the underlying point stands: Meta mediates every message. That is a centralisation point and a known limitation of building on any platform controlled by a third party.

It is also important to be direct about something: WhatsApp is the journey, not the destination. It was chosen because it is the dominant communication platform in Tanzania, the market this project is built for. The architecture is deliberately decoupled from any specific messaging platform. Signal, Telegram, and eventually a purpose-built non-custodial mobile interface are all on the roadmap. WhatsApp is where Tanzanian users are today. The product meets them there while the longer-term infrastructure is built underneath.

On what differentiates this from a conventional database

At the custodial pilot stage, not much. A conventional database with user balance records could technically replicate the same functionality. The ZCash value proposition only fully materialises when users hold real z-addresses and transactions settle on-chain without a custodian in the middle. At the pilot stage the primary differentiator is the onboarding mechanism — physical recharge cards converting cash to ZEC without requiring an exchange account — not the privacy guarantee itself. This should have been stated more precisely.

What this critique has clarified

A genuine architectural tension has been identified that the project must resolve before it can honestly claim to deliver ZCash’s privacy properties. The roadmap will explicitly commit to a non-custodial migration path with a defined timeline. Users must be able to verify their balances on-chain, withdraw to self-custody at any time, and not depend on operator honesty for the safety of their funds.

That will not be a Phase 3 consideration. It is a foundational requirement for a product that uses ZCash’s name.

This critique has made the project more honest and the architecture more defensible. It is appreciated.