Review Period Open - Coinholder-Directed Grants Program Q1 2026

Community Grants Retroactive Grants
1

Now that the submission deadline has passed, the mandatory 30-day review period has begun. During this time, please review the submitted proposals and engage with the applicants in their individual grant threads. This is your opportunity to ask questions, share constructive feedback, test out the evidence provided for completed work and raise any concerns. The review period will end on March 17th and will be followed by a coinholder poll.

Below you will find a summary of each grant request with links to their individual grant threads (in the project name) as well as external resources. Grants are presented from least USD requested to most. Please visit the GitHub links for full details.

Project Name: ZChat - The First Working Zcash-Native Private Messenger

Organization: ZChat Privacy Technologies (Liberland)

Request: $5,000

Github: Link

Synopsis:

ZChat is a fully delivered, Zcash-native private messaging application that uses shielded Zcash transactions as its transport layer, making every message an on-chain transaction with an encrypted memo and requiring no phone number, email, accounts, or KYC—only a Zcash address. Built independently from scratch, the project introduces the ZMSG Protocol (v4), enabling rich features such as direct and group messaging, payment requests, reactions, replies, read receipts, and long messages via secure chunking, all within existing Zcash memo constraints and without reliance on future protocol upgrades. The delivered system includes a stable Android app with a self-custody wallet, group key management and rotation, production-grade cryptography (HKDF, authenticated key exchange, and ECIES with forward secrecy), and a lightweight web client for testing. As the only functioning Zcash messenger on mainnet today, ZChat demonstrates a novel, real-world use case for Zcash beyond payments and contributes tangible, independently built infrastructure to the ecosystem.

Evidence: (see GH link for full context)

Repository/Commit:

GitHub Repository - Full source code for ZChat Android app, web interface, and ZMSG protocol implementation

Publication:

  • Zcash Community Forum Thread - Grant application thread with January 2026 development update, community discussion, and technical details

  • Previous ZCG Application — Issue #142 - Original grant application documenting project scope and goals

    Deployment/Release:

  • zsend.xyz - Live web demo — working Zcash messenger, try it now

  • Android APK v2.8.1 available for download from GitHub releases or by whitelist request on zsend.xyz

    Other Evidence:

  • Zypherpunk Hackathon 2025 — prize winner ($600 awarded), results publicly verifiable

  • January 2026 Forum Update - Detailed technical progress post with security hardening documentation

Project Name: Zec-pay.com

Organization: Tomas Matejicek

Request: $22,600

Github: Link

Synopsis:

zec-pay.com is a web-based payment service that enables anyone to fund a transaction with BTC or transparent ZEC while the recipient receives shielded ZEC with an attached memo, supporting common use cases such as invoices, donations, and order references. The platform lowers barriers for users of transparent-only and hardware wallets by abstracting shielded transaction creation and memo handling, ensuring that final settlement occurs privately on Zcash. The system combines a frontend order interface with a backend state machine that generates unique deposit addresses, monitors Bitcoin and Zcash nodes for confirmed payments, executes BTC–ZEC swaps via the CoinEx API when required, and broadcasts shielded Zcash transactions from a managed hot wallet. It includes rebalancing between exchange and local liquidity, refund tooling, an admin dashboard, and hardened deployment infrastructure, and has been iteratively improved through public user feedback to enhance validation, clarity, and reliability.

Evidence: (see GH link for full context)

Project Name: Maya Protocol Advanced Shielded ZEC Support

Organization: Maya Protocol

Request: $45,000

Github: Link

Forum Discussion: Link

Synopsis:

Maya Protocol has independently built and deployed full end-to-end support for shielded Zcash (ZEC) on its cross-chain decentralized exchange, becoming the first and only permissionless DEX to enable native cross-chain swaps directly to and from shielded Sapling and Orchard addresses without intermediaries, KYC, or custodians. Forked from THORChain, Maya Protocol extends beyond prior grant-funded concepts to deliver production-grade functionality, including shielded inbound and outbound transactions, memo parsing via trial decryption, Unified Address normalization, expanded memo limits, robust ZEC UTXO management, NU6/NU6.1 upgrade support, and a custom Rust-to-Go FFI layer exposing shielded cryptography to its Go-based client. This retroactive grant application covers substantial uncompensated engineering work that gives Zcash users unprecedented access to cross-chain liquidity while preserving financial privacy, directly advancing Zcash’s ecosystem and mission.

Evidence: (see GH link for full context)

Project Name: ZChat - ZK Email in Halo2

Organization: ZK Email

Request: $50,000

Github: Link

Synopsis:

ZK Email is an open-source initiative focused on making zero-knowledge (ZK) cryptography more practical and user-friendly by developing core primitives and tooling within the halo2 ecosystem. The project’s halo2-zk-email suite provides reusable circuits that enable zero-knowledge verification of DKIM-signed emails, allowing selective proof of properties such as sender, subject, or content without revealing the full message. To achieve this, the team built modular libraries—including halo2-rsa for big-integer arithmetic and RSA verification, halo2-regex for DFA-based regex matching, halo2-base64 for encoding/decoding, and an optimized SHA256 for arbitrary-length inputs—on top of Axiom’s halo2-lib and the PSE halo2 fork. Designed as MIT-licensed public goods, these components are independently reusable and have already been adopted by multiple projects. The system architecture emphasizes scalability and deployability, using lookup-optimized range checks, universal verifier patterns, contract splitting to meet EVM size constraints, and recursive proof design suitable for efficient on-chain verification, while advancing developer tooling and foundational ZK infrastructure.

Evidence: (see GH link for full context)

Project Name: Zcash.me

Organization: ZcashMe, Inc.

Request: $61,200

Github: Link

Synopsis:

Zcash.me is a user-friendly identity and payments platform designed to simplify peer-to-peer transactions in Zcash by replacing complex addresses with human-readable profile pages and shareable links. The application enables users to create verified public profiles, accept payments via QR or wallet URI, denominate amounts in fiat with live conversion to ZEC, and receive ZEC even when senders initiate payments from other crypto assets through integrated cross-chain swap flows. It also provides searchable discovery of recipients by username or social handle, wallet API integrations for richer directory experiences, and verification mechanisms using memo + OTP and social authentication to confirm address ownership and identity. Built as a modular Next.js web application with a Postgres database, Supabase OAuth, external pricing oracles, and a dedicated background verification service leveraging Zcashd RPC and librustzcash, the project emphasizes secure authentication, scalable verification infrastructure, and practical usability features such as directories, referrals, and point-of-sale tooling to advance real-world peer-to-peer electronic cash adoption.

Evidence: (see GH link for full context)

Project Name: Pepper-Sync

Organization: Zingo Labs

Request: $461,000

Github: Link

Synopsis:

In response to slow synchronization being a major usability barrier to Zcash adoption in late 2024, Zingo Labs designed and deployed Pepper-Sync, a novel client-side synchronization implementation that achieves competitive raw performance and, at the time of release, enabled the fastest spend-before-full-sync experience in production. The project addresses the inherent “syncing problem” in private transactions—where resource-constrained devices must perform large volumes of trial decryption—by combining DAG-inspired techniques, incremental Merkle tree pruning, nullifier lookup for non-linear receipt tracking, and prioritized multithreaded scanning built on librustzcash primitives. This approach reduces unnecessary computation while preserving full privacy guarantees, enabling efficient detection of relevant notes and faster access to funds, especially for mobile users. Beyond the core algorithm, the team integrated Pepper-Sync into Zingo PC and Zingo Mobile alongside protocol upgrades (NU6/6.1, ZIP 317, ZIP 320), UX improvements, multilingual support, Tor opt-in, and broader accessibility features, ensuring real end-user impact. Complementary outreach, documentation, and support efforts expanded adoption and awareness, contributing to measurable download growth and a positive ecosystem effect by motivating improvements among other sync providers.

Evidence: (see GH link for full context)

  • The algorithm is already deployed in four Zingo Labs applications:
    zingo-cli, zingo-pc, zexcavator, and zingo-mobile.

  • Repository/Commit: Pepper-Sync – the core library

  • Deployment/Release: zexcavator – Community ZEC Recovery Tool

5 Likes
3

One question: Project Name: [ZChat - ZK Email in Halo2]

I suppose that the full name of the project #4 not include “Zchat” in the name?

2 Likes
4

ZChat (Liberland): support.

Zec-pay.com: This seems to me to basically defeat the point of Zcash’s shielded features. It just is not difficult to use a wallet that directly supports shielded transactions. The BTC-to-ZEC functionality is a little more useful, but the website appears to be acting as a money transmitter (because it has temporary custody of the funds sent to it), while saying that it “never asks for sign-ups or KYC”. It doesn’t appear to have attracted regulatory attention but it easily could.

Maya Protocol Advanced Shielded ZEC Support: as I said here, I strongly support this grant.

ZK Email in Halo 2 (not sure why “ZChat” is also in the title): The paper is very short and I would have appreciated more detail. I am skeptical of the security assumptions: DKIM is not really designed to authorize monetary transfers.

Zcash.me: I’m generally very skeptical about this kind of centralized platform. What stops this becoming another Lavabit?

Pepper-Sync: This is a pretty expensive grant. Also wasn’t ZExCavator supposed to already be covered by another grant? Grant Application - Zcash Extensible Wallet Interchange Format (ZeWiF) · Issue #3 · ZcashCommunityGrants/zcashcommunitygrants · GitHub says:

Blockchain Commons and Zingo Labs will: collect and survey existing wallets (a wide-ranging survey, with a focus on zcashd and zecwallet); design an interoperable and extensible wallet interchange format that can preserve and secure data from zcashd and other wallets including legacy zecwallets; create Rust crates that import data into and export data from that interchange format; and produce a ZExCavator tool that recovers buried ZEC from old zecwallets.

I think ZExCavator cannot be cited as contributing to the scope of this grant, because the ZeWIF grant was supposed to fully pay for Zingo Labs’ part in its development (see deliverable #4.1). @hanh also points out other potential coverage duplication here.

4 Likes
Application for Retroactive Funding for Pepper-Sync (second attempt)
5

You’re correct, I updated our thread to clarify that the portion of ZExCavator we were requesting funding for is subsequent to the referenced ZeWIF grant, and in flight but as it’s not complete is not yet suitable for retroactive funding.

3 Likes
6

@daira Thank you for your feedback :slight_smile:

I fully agree that zec-pay.com is not end-to-end private in the way Zcash shielded transactions are, because the service can see the memo during processing. The intended use is cases where that is not a problem, such as memos that are already encrypted by the sender, or memos that are inherently non-sensitive metadata (invoice/order IDs, donation notes, etc.).

3 Likes
7

Thank you for the thoughtful question! :slight_smile:

As I understand it, Lavabit operated as a centralized service that received, stored and delivered user’s private messages. That created a single point where data could be compelled or seized.

ZcashMe cannot act as a middleman in this way because the app does not send or receive messages or money, and it does not hold them or even see them.

For transactions the user is provided ZIP321 URI that they can complete in their wallet. The application only supports shielded addresses and does not accept transparent addresses.

We recognize that metadata risks still exist at the network level. For example, visiting someone’s profile suggests that you may have interacted with them. Users who want stronger protections can choose to access the site with Tor or Nym to reduce IP and traffic metadata.

All information collected is limited to what users have chosen to make public, like their display name, bio, social media links, and the receiving address they want others to use.

In an upcoming release, users will be able to verify that their profile data was not altered by anyone else.

We expect others have similar concerns so we will make these points clear on our homepage.

Are there any concerns we failed to address?

2 Likes
8

Am making a last minute proposal due to extenuating circumstances.

Project Name: Cancel the Bootstrap Org / Electric Coin Company 2025 Q4 Grant

Organization: Bootstrap Org / Electric Coin Company

Request: -$2,673,974

Github: N/A

Synopsis:

In Q4 2025, a retroactive grant was approved for Bootstrap Org / Electric Coin Company for their work on Zashi and the Zcash protocol. Since the approval of that grant, the team members on the proposal have left the organization, and all the IP and work product listed for retroactive compensation were sold at a profit of $8m USD.

Given the material changes since the grant was approved, this proposal is to CANCEL the previous grant, which has not been dispersed from the lockbox.

Evidence:

This post from the Bootstrap board documents the settlement agreement and IP sale: A message from the Bootstrap board - #36 by TheBootstrapOrg

This post details the financials of Bootstrap, ECC and the IP sale amount of $8m: Q4 2025 Retroactive Grant Disbursement and Governance Integrity - #6 by peacemonger

Separately, there is an ongoing dispute about vetoing this grant [1, 2]. Regardless of the veto process, coin holders may want to vote to cancel this grant as well.

4 Likes
Polling Open: Coinholder-Directed Grants Program (Q1 Round)
9

Thank you for submitting this. We will be including the following question on the Q1 2026 ballot:

“Do you approve rescinding the Q4 2025 grant of $2,673,974 to Electric Coin Company (Bootstrap Org), given the organizational changes that have occurred since the original vote?”

Our basis for including this is ZIP 1016, which states: “If any contentious issue arises in connection with a grant (such as milestones not being met), or periodically for grants of indefinite duration, the Key-Holder Organizations SHOULD hold additional coinholder votes to determine whether funding should continue.”

5 Likes
10

Thank you, I agree with the ballot language.

1 Like
11

Leaving my notes on this retroactive grant vote to help participates get context for how I think about these votes.

1) ZChat - The First Working Zcash-Native Private Messenger

Grant amount: $5000

My vote: Approve

I generally think its a good idea to encourage early stage experimentation on Zcash. Given the grant amount is appropriate for experimentation I will be voting to approve this grant.

My concerns:

  • I was not able to get the web version fully working, I trust that others have been able to use the product. Given the small grant size am not going to put more effort into testing it.
  • I don’t think the Zcash blockchain is suitable to support a full messaging backend given scale constraints and the low txn value of a single chat message. I suspect a hybrid messaging backend secured by Zcash would make more sense (maybe Nostr or GunDB). Will leave that consideration up to the builders.
  • Would like to see this become a more secure wallet with cross platform support. The web version has browser based key storage. Lacks iOS support. Generally I think more wallets are good for Zcash especially if they have new use case focus.

2) zec-pay.com

Grant amount: $22,600

My vote: Reject

At first glance, this is a transparent pay server, but actually it solely converts t-ZEC and BTC into Shielded ZEC, so it is designed to support an increase of conversions to to shielded ZEC. In principle I like this idea, however there are problems with the implementation that cause me to vote to reject this grant:

  • The service appears to be entirely custodial, accepting BTC or t-ZEC onto their server and sending shielded ZEC. Shielding of ZEC can be done via any non-custodial wallet. Swapping of BTC to ZEC can be done via decentralized swaps such as Near intents or Maya.
  • Due to the custodial nature of the project, it may be collecting user information. There is no mention of any attempt to mitigate user privacy, and the service lacks a privacy policy.
  • The code is not open or available and is not audited, so the tech itself does not benefit the community.
  • There is no API or method for shops or ecommerce devs to integrate the service.
  • There is no traction with partners or plan to partner with any existing pay servers that service ecommerce platforms.
  • There are already several ZEC pay servers available, so this not adding to “experimentation” on Zcash.

Because of the above, a custodial proprietary shielding service with no traction does not seem to add value to Zcash. If seeking a grant in the future I would like to see either a more decentralized privacy preserving approach or real business traction.

3) Maya Protocol Advanced Shielded ZEC Support

Grant amount: $45,000

My vote: Approve

Maya is the #2 source of decentralized liquidity for ZEC. Strong support of all improvements on this integration. This grant is enables receiving from and sending to shielded addresses.

Would like to see shielding on Maya in the future! Would also like to figure out how to support more Maya ZEC integrations and liquidity.

4) ZK Email in Halo2

Grant amount: $50,000

My vote: Reject

ZK Email as a feature does not fit with any Zcash initiatives I am aware of. Core contributor str4d notes that this technology would not be of use within Zcash. Core contributor Daira notes the research paper lacks detail and may have faulty security assumptions.

The development team seems to have worked on this in collaboration with Axiom, 0xPARC, and EF PSE who have covered some of the costs but not all.

Given that this grants system is designed to support Zcash only and not any arbitrary zk technology, I reject this vote and suggest the proposer ask for reimbursement from the original commissioners of this project.

5) zcash.me

Grant amount: $7,200

My vote: Approve

Approving based on the principle of encouraging early stage experimentation on Zcash and the grant amount being in line with experiment stage.

In addition, I visited the Network School outside of Singapore and noted that this team had onboarded many of the participants to ZODL. I was delighted to learn that I was able to pay for many goods and services in ZEC. This is outside the scope of the grant, but I the non-tangible efforts of onboarding new users to Zcash are I think material to the intentions of the team.

Concerns:

  • Website is susceptible to a man-in-the-middle attack where receiving addresses can be replaced on the website’s frontend
  • Exposing public keys increases Quantum attack surface

I encourage the team to continue iterating on the product and onboarding new users to Zcash.

6) Pepper-Sync

Grant amount: $461,000

My vote: Reject

The proposal is $461,000.00 for the pepper-sync code, and nothing else. I find the library itself has not demonstrated a large value add to the ecosystem. I find the claimed cost (2x senior engineers for 15 months) to be an exaggeration or wasteful. As a voter, I do not think this proposal is a net benefit to the Zcash ecosystem, so I would vote AGAINST funding.

Full review of the proposal: Application for Retroactive Funding for Pepper-Sync (second attempt) - #18 by thowar2

7) Do you approve rescinding the Q4 2025 grant of $2,673,974 to Electric Coin Company (Bootstrap Org), given the organizational changes that have occurred since the original vote?

Approve. The team and the IP listed on the grant longer reside at that organization.

Summary

  1. Approve
  2. Reject
  3. Approve
  4. Reject
  5. Approve
  6. Reject
  7. Approve
4 Likes
12

Time to defend zec-pay.com against short-sighted criticism :slight_smile:

  • Custodial service - yes, that is true. zec-pay.com is intended for users who do not have (or do not want) a wallet supporting shielded payments, but still need to send a zcash payment with memo.
  • Show me one single other ZEC pay service, which supports MEMO. There is none other than zec-pay-com.
  • Privacy policy - it was trully missing, I’ve added it here:
    https://zec-pay.com/privacypolicy.php
  • For API, there is a method for shops to integrate the service, it is not a REST API as you could expect, it’s simpler but still effective. You can read about it here:
    https://zec-pay.com/integration.php
    Since you wasnt able to find this information easily, I’ve added several more links to the website pointing to it, to make sure users can find it more easily.
  • Business traction - zec-pay.com is used, for example, by crowdstore.net, a peer-to-peer marketplace. It normally prompts the user to send zcash using a QR code from their wallet, and as an alternative method, it offers to use zec-pay (with direct link to pre-filled form including the encrypted memo, using the integration mentioned above). I hesitated to mention this in the proposal because Crowdstore belongs to a more clandestine marketplace environment, but so be it.

Other than that, thanks @thowar2 for review, which resulted in some improvements :slight_smile:

1 Like
17

Thanks for the updates @Tomas-M. Please keep in mind that “Retroactive Grants” are for “proof of work” not “proof of vision”. While token holders could vote for a forward looking vision if they want, that is not the social intent. The reason they are retroactive is to prevent the looting behavior endemic of most crypto DAOs.

New notes:

  • Thank you for adding the privacy policy. At first glance I do not think the privacy policy is adequate at protecting user privacy in alignment with the Zcash ethos.
  • The integration URL is very helpful. Seems easy to use!
  • The traction at Crowdstore or elsewhere is unknown so it is difficult to judge.
  • I am hesitant to vote for grants of this size to reimburse closed source technology. Historically closed source grants have been to companies with proven user distribution.

My Vote: Reject - due to above criticisms.

1 Like
18

I have added a lengthy review of PepperSync and updated my original post.

Summary:

The proposal is $461,000.00 for the pepper-sync code, and nothing else. I find the library itself has not demonstrated a large value add to the ecosystem. I find the claimed cost (2x senior engineers for 15 months) to be an exaggeration or wasteful. As a voter, I do not think this proposal is a net benefit to the Zcash ecosystem, so I would vote AGAINST funding.

1 Like
19

Thanks for the review and the vote, @thowar2. Quick notes:

Web version: There’s no public web version of ZChat yet zsend.xyz/zchat.sh is just the landing pages. We’re still deciding on the desktop direction (web app vs native). The Android app is the only working product right now.

Android first: Our priority is polishing and properly testing the Android experience before spreading to other platforms. Message reliability, smooth ZEC transfers, a more friendly UI, swap-to-ZEC and some ZEC-to-fiat options are in progress right now.

Hybrid backend: Fully agree that Zcash alone isn’t suited for a complete messaging backend at scale. The hybrid options that we have now: Zcash for identity, trust, and privacy-critical message delivery; off-chain protocols (Nostr, WebRTC) for file sharing, voice/video calls, and real-time signaling. The shielded memo stays as the trust anchor for key exchange and payloads that need zk-SNARK privacy.

iOS and cross-platform: On the roadmap, after Android is solid.

Appreciate the support for early experimentation.

1 Like
20

Fair concern. Grants that reinforce shielded-by-default are the highest leverage here. Maya and ZChat both push adoption where it counts. Pepper-Sync’s price tag needs more context, but faster sync genuinely matters for getting new users through the door.

21

I agree that privacy is central to Zcash, and I also agree that a third-party facilitation service such as zec-pay.com cannot offer the same privacy guarantees as using Zcash directly in a self-custodial way. But I would not describe that as undermining Zcash’s purpose. zec-pay.com is not designed to replace native Zcash usage; it is designed to lower the barrier to entry for people who would otherwise never use Zcash at all.

Many potential users, including people who are unfamiliar with Zcash, may simply want to pay an invoice quickly and include a memo. For them, installing a wallet, acquiring ZEC through an exchange, completing KYC, and learning a new workflow can be enough friction to abandon the payment entirely. A service like zec-pay.com helps bridge that gap. It introduces new users to a real and distinctive capability of Zcash: the ability to send payments together with rich memo data.

That feature (the memo itself) has practical value in its own right, quite apart from the privacy properties of shielded transactions, because it makes Zcash far more useful for invoices, commerce, and other real-world payment flows. In that sense, zec-pay.com should be viewed not as a substitute for private Zcash usage, but as an onboarding layer that expands awareness, adoption, and ultimately demand for Zcash itself.

22

I have a process objection. This grant has already been vetoed by ZF and Shielded Labs, and the veto is valid according to the conditions of ZIP 1016. Bootstrap’s objection is invalid.

Once a grant has been vetoed, having a vote on whether to rescind it is not consistent with ZIP 1016:

If a grant is vetoed after passing a coinholder vote, then payments for it MUST be stopped.

Vetoes not only do not require, but do not allow for coin-holder approval. It is designed that way partly, although not exclusively, because one of the cases in which a veto can be applied is the case of a coin-holder vote for a grant that the Key-Holder Organizations could not legally pay. Bootstrap or ECC would have to resubmit the grant application in order for there to be another vote on that new application.

It is very intentional that a valid veto is irreversible for a given grant — that is necessary for definiteness and predictability of the veto mechanism. It does not prevent an identical grant application from potentially being re-approved if it is resubmitted (although I think it is unlikely that an identical grant application would be re-approved in this case).

The Key-Holder Organizations could have, consistently with ZIP 1016, called a vote on whether to re-approve the existing grant, but ZF and Shielded Labs chose to veto it instead. These are alternative mechanisms: one or the other can be used, not a mixture of both.

5 Likes
Polling Open: Coinholder-Directed Grants Program (Q1 Round)
23

Pinging @FPF about Review Period Open - Coinholder-Directed Grants Program Q1 2026 - #22 by daira and Polling Open: Coinholder-Directed Grants Program (Q1 Round) - #11 by daira

1 Like
24

This was resolved; see Polling Open: Coinholder-Directed Grants Program (Q1 Round) - #13 by FPF :