Zcash Community Grants Meeting Minutes 9/14/2026

Community Grants Community Grants Updates
1

Grant Dashboard

Zcash Community Grants Committee Google Meet Meeting: September 14, 2026

(Part 1, Part 2 follows in the first comment)

Attendance:

  • Artkor

  • Zerodartz

  • Paul

  • Hanh

  • Gguy

  • Alex (FPF resource, notetaker)

Votes split where indicated.

Key Takeaways:

Open Grant Proposals

  • Taking Zcash to the Streets: Education & Real-World Feedback in Türkiye

    • Applicant proposes a 10-part Turkish Zcash YouTube education series published on the Crypto Epoch channel, followed by a 3-day Istanbul street interview campaign gauging crypto/Zcash awareness and directing interested participants to the series, with small Zcash-branded rewards for engagement. Requesting $6,955.

      • Artkor: I haven’t really seen crypto education done through street interviews before. It might work, but I’m not comfortable funding it up front without seeing the quality first, or knowing if this format can work as a series and keep people interested. In its current form, I reject this one.

      • Gguy: This is the kind of thing I’d like to see proven first before funding, so I’m going to reject this.

      • Zerodartz: I would also like to see an example first episode or something in that style before funding.

      • Hanh: Reject as well, based on the other videos from the website. They don’t seem to add a lot of value compared to the other videos we have.

      • Declined

  • Recoverify: Pre-Loss Backup Recovery Verification for Zcash Wallets

    • Applicant proposes an open-source Rust CLI and local web UI that generates a non-secret Recovery Record from a working wallet, then later verifies a saved backup against that record — testing whether the backup reproduces all recovery-relevant state (accounts, addresses, derivation ranges, pool coverage) before the original wallet is lost, with classified results (Verified / Incomplete / Additional material required / Unable to verify / Verified empty). Requesting $2,990.

      • Gguy: Technically speaking it doesn’t add much value and I have some security concerns.

      • Artkor: I agree. The developers of each wallet are in the best position to design and test their own backup and recovery features, so I don’t think we need a separate tool for this.

      • Hanh: The best way to test whether your recovery works is to recover into another wallet, which gives you 100% certainty because it also does the synchronization. Since you are already installing an app (Recoverify), you might as well install a wallet. Second, I don’t want to recommend that people enter their seed phrase into an application just for the purpose of verifying their seed phrase. That is exactly what a scammer can ask you to do, and it would be very confusing for users. (Not implying Recoverify is a scam)

      • Zerodartz: Agree with others on the security concern. Reject.

      • Declined

  • Zcash World, Mumbai (Devcon 8 week)

    • Applicant proposes a multi-phase Devcon 8 week program anchored by a one-day fully shielded ZEC environment (registration requires a wallet, Z-BAZAAR accepts only shielded ZEC, 250–300 wallet onboards, live device benchmarking on entry-level Android hardware), followed by merchant onboarding of 20 Mumbai businesses during Devcon week, ecosystem engagement on the Devcon floor, and content capture throughout — with the benchmarking dataset released open-licensed and an after-movie published within 72 hours. Requesting $20,300.

      • Artkor: I liked that this proposal includes practical use of shielded transactions, testing wallets on low-end devices, and an attempt to onboard local merchants. It also comes from an active team we’ve already been following, so I’m happy to support this proposal.

      • Hanh: I approve as well. It has a concrete plan, a known team, and a very reasonable budget. Everything looks very good.

      • Gguy: I agree. I’m excited to see how this event goes.

      • Zerodartz: I will also approve, since this team has a proven track record in the Zcash community already. They have done some onboarding in India, and they will also collaborate with the WebZero hackathon. That is great to see.

      • Paul: I think it’s a really cool idea, and hopefully it can be used for future events as well. Looking forward to seeing how it turns out.

      • Approved

  • Zcash Privacy Literacy Lab Canada

    • Applicant proposes a free, account-free web learning module with 12 interactive privacy scenarios (transparent vs. shielded transfers, viewing keys, selective disclosure, exchange touchpoints, metadata limits), a Rust scenario generator using real Zcash libraries on regtest/testnet, and a dated Canadian regulatory source map (30+ records covering recordkeeping, reporting, and consumer protection) — with independent technical and Canadian legal review, public correction log, and MIT/MIT-compatible licensing. Requesting $15,000.

      • Artkor: I think this overcomplicates a fairly simple education problem. If the goal is just to explain the difference between transparent and shielded transactions and show what information is visible, existing Zcash tools and content can already do that quite clearly. I reject.

      • Zerodartz: These sorts of educational projects are cool, but in the current age I don’t think they’re worth as much anymore, and it’s much simpler to build these tools if the need arises for a specific event for example. If you don’t already have a user base who will start learning these things, the impact will also be very marginal.

      • Declined

  • 0xramp: Non-custodial ZEC ⇿ local-fiat ramp for emerging markets

    • Applicant requests a grant to expand and harden a working non-custodial local-currency-to-ZEC ramp already live at 0xramp.app — $13,381 settled USDC across 220 orders in August 2026 across 8 corridors (BRL, INR, IDR, ARS, VES, NGN, COP, Ecuador-USD), with ZK social verification instead of KYC, NEAR Intents swap leg, zero interface fees, and Noir Wallet integration — targeting NGN/COP/ECU production launch, shielded-first delivery, Tor onion service, public metrics dashboard, and integration with ZCG-funded community referral paths. Requesting $206,000.

      • Gguy: I had some concerns about the tooling and safety for users. Because it is not completely decentralized, there may be a custodial risk across the payment systems involved, so I can’t approve this one today.

      • Paul: For me this falls into a category where it’s a business they’re trying to start that should be revenue generating. I really don’t like ZCG being in the position of helping people start a business that needs to be self-sustaining. I think that could be a bad investment.

      • Artkor: I know there are real risks with this proposal, but I still want to support it because I like ambitious ideas and people who are willing to take a real shot at them. I approve this one.

      • Hanh: I reject. The connection between these companies is not clear enough for me. Users will put their funds into various systems, in particular P2P.me, which is in charge of the fiat settlement, and the added value for Zcash is not clear — all the work is actually done by P2P.me. I’m afraid that if a user has their account blocked, they would not know that it’s because of some third party.

      • Zerodartz: I think it’s a great project, but in practice the user takes all the risks, and their accounts might get frozen along with other funds they didn’t even transfer with crypto. That’s a bit too risky for ZCG to fund in my view. The risks should also be much more clear on the site when users do their swaps or on and offramps. Decline from me at the moment.

      • Hanh: Some people compare this to NEAR and Red Bridge. In my opinion the difference here, and the reason I’m not approving this one where I approved the other ones, is that this one is fairly centralized around the company P2P.me, whereas the other ones are decentralized solutions. It is a bit scary when a regulator can block a bank account.

      • Declined (Yes: Artkor; No: Gguy, Paul, Hanh, Zerodartz)

  • ZecBit - NFT Infrastructure for ZSAs

    • Applicant requests a grant to publish three open ecosystem infrastructure components for Zcash Shielded Assets — ZMD-1 (open metadata standard for ZSAs, already in use on testnet), a key-less deterministic indexer (reproducible catalog anyone can run), and shielded payment intake tooling (lightwalletd scanning, trial decryption, memo-tag matching, reconciliation) — built on top of an already-running marketplace, with the marketplace itself explicitly excluded from the funded deliverables. Requesting $48,000.

      • Gguy: Unfortunately we’ve had to decline this one. It doesn’t fit with the current state of ZSAs, and I don’t think it is going to practically work or provide value for Zcash users.

      • Artkor: Additionally, I think most people in the community probably noticed the red flags around this proposal on the forum, and that’s why we declined it too. I’d also remind anyone who wants to put their own money into projects like this to do their own research and be careful.

      • Hanh: There are also reports of people who put money in to buy these ZSAs, which were backed by testnet, and they were not refunded. Unfortunately it seems like our worries materialized.

      • Declined async

  • ZEC Invoice Preflight: ZIP-321 Validation for Zcash Merchants

    • Applicant requests a forward grant to move a working self-funded prototype (live demo, 20 tests, CLI doctor, handoff schema v1) to a reproducible public tool — adding GitHub CI, CONTRIBUTING.md, npm packaging (zcash-invoice-preflight), acceptor outreach/validation loop, expanded malformed input fixtures, and 12 months of demo maintenance — providing compose-time validation for single-payment ZIP-321 invoices before errors reach the customer. Requesting $3,000.

      • Hanh: It’s a library that would check the validity of payment URIs — ZIP-321 is about payment URIs. I don’t think this is needed, because the payment URI is generated by the merchant using a library that interfaces with librustzcash, so the validity of the payment URI is pretty much guaranteed.

      • Declined async

  • Security Audit of Zaino

    • Applicant proposes a scoped public security audit of Zaino — covering core indexing/chain-state tracking (zaino-state), gRPC/JSON-RPC service layer (input validation, DoS surfaces), privacy-relevant data paths (wallet/transaction linkage inference), and Rust dependency/supply-chain review — delivered as a public report in Cyfrin’s standard format with severity-rated findings. Requesting $120,000.

      • Gguy: Unfortunately the Zaino team isn’t ready for an audit yet. But we will keep an eye on the Zaino project and explore any auditing needs in the future.

      • Declined

  • Zcash SeedSigner: DIY open source air gapped signer for shielded ZEC

    • Applicant proposes to build a Zcash-capable DIY hardware signer based on the SeedSigner platform (Raspberry Pi Zero + LCD + camera, ~$35 in generic off-the-shelf parts) — implementing PCZT/ZIP-374 signing with on-device ZIP-244 sighash recomputation, RedPallas spend authorization, ZIP-32 key derivation, and QR/UR transport compatible with existing Zodl releases, with a working proof-of-concept already on GitHub (libzcash-signer, 676ms median for derive+sighash+sign+verify on real Pi Zero hardware). Requesting $65,000.

      • Artkor: I think it’s a cool technical project and honestly I’d like to play with it myself, but it feels too niche for ZCG funding, especially at this budget. I don’t think an air-gapped DIY signer is a priority for the community right now. With so many hacks in crypto, I think most regular users will prefer hardware wallets from well-known companies. So I reject.

      • Gguy: I agree that this is a fun project, but unfortunately I don’t think the value matches the ask. I’m going to reject.

      • Paul: I agree to reject. There are also the concerns about hot wallet integration mentioned in the proposal. The proposal mentions upstream integration with ZODL, and until that were agreed upon I think it would be premature to make that assumption.

      • Zerodartz: It’s reject from me as well, even though it’s probably a cool nerdy project. It’s not worth the funding from us right now with a very limited user group.

      • Hanh: The ZODL integration is a bit of an issue, but he did mention that only a small change is needed, so maybe he can do it without. I agree it’s a bit too expensive. It’s really a hobbyist project, because in terms of cost it isn’t really cheaper than buying a hardware wallet once you account for the parts you have to buy and assemble, and the result will be less secure because it doesn’t have a secure element. For a hobbyist project, this request is way too high for me.

      • Declined

  • Colosseum | Crypto World’s Fair | Zcash Track

    • Applicant proposes a Zcash-dedicated track within a multi-chain online hackathon (September 14–October 12) to attract startup founders to build on Zcash protocols, with a dedicated prize pool and post-competition support for promising teams. Requesting $250,000.

      • Gguy: I think this is an interesting application. Unfortunately there are some things I would like to discuss and address before we entered something like this, around total funding, and given that Zcash is not a smart contract or have scriptable computable blockchain like some of the others we fit a little bit differently into the hackathon compared with the other cryptocurrencies. I have concerns about funding into a joint pool when Zcash is a little separate from the other cryptocurrencies. Given that this hackathon started today, I think we should continue discussions, so we can be rest before the next round starts. That way we can iron out some of these details and think about projects that we can get the community and participants interested in. So unfortunately a reject from me today, but I’m looking to the future for this.

      • Hanh: I will reject for similar reasons. Of the $250,000 total, only $100,000 is assigned to properly Zcash projects. The rest will be split between potentially other coins, and $50,000 will go to the team. If they plan to do this kind of sponsorship for many projects, $50,000 feels like a lot to pay for operations. I would understand if the operations were just for us, but if they run ten different coins then I don’t see why we pay so much when it’s split with the other coins. I would rather have more going to the top Zcash projects. The other concern is what we are going to get, since we don’t have programmability.

      • Paul: I would come at it a little differently. We’ve seen a lot of really good things come out of hackathons recently in the Zcash ecosystem — it’s been quite a surprise to me. People have reached out to me and told me about this team and their track record in the Solana ecosystem, and apparently it’s been very successful. It’s not only a hackathon; it actually follows on to help fund the teams to become viable projects, so it’s almost a combination of a hackathon and a startup incubator, which I think is pretty cool. Given that, and that having them come into the Zcash ecosystem would be a pretty big deal, I would approve.

      • Hanh: But then Zcash would get more. I just think it’s too much overhead — you pay $250,000 but only less than half will go to Zcash.

      • Paul: That is a good point for sure.

      • Zerodartz: Wouldn’t it also be an issue that they’re starting today and we haven’t even decided yet? It’s a bit too rushed, I think. Maybe next time would make more sense if we had a longer head start. This time I’m rejecting.

      • Gguy: Their request was to have someone from the ZODL team involved as well.

      • Artkor: I’m positive on this one. I support the idea of funding this specific hackathon in the future because it will help attract more talented developers to Zcash.

      • Approved (applicant revised grant post-meeting and ZCG voted async to approve)

  • Zcash East Africa @ Africa Blockchain Festival 2026

    • Applicant requests funding for a a staffed Premium booth at Africa Blockchain Festival 2026 (October 15–17, Nairobi, 3,000+ registered delegates), a side event at Western Delicacy (an already-onboarded Nairobi restaurant accepting shielded ZEC), a 30-day virtual 3-day onboarding session with task-based retention, and developer cohort recruitment — targeting 65+ ZODL onboards, 40+ verifiable on-chain z2z transactions, 100+ new community members, and 200+ documented conversations. Requesting $11,040.

      • Gguy: I have concerns around the structure of this grant, especially that a lot of it — or all of it — is startup funding. I want to confirm that first.

      • Artkor: I reviewed the recent activity of this team and I think I’m ready to support this proposal in its current form.

      • Hanh: I’m supportive too. I’m a bit concerned as well about all the funding being up front, but on the other hand they have to pay for this before they attend. I would suggest a 50/50 split: 50% up front and 50% on delivery.

      • Artkor: The materials are prepared in advance, and the booth also has to be paid for upfront.

      • Paul: I think it’s reasonable to do the 50/50 split, and I would support it if we can take that approach.

      • Zerodartz: I did some research on the team and they have some track record already. Maybe the 50/50 option won’t work — the booth would still have to be paid up front, I think — but some of the other costs could be paid afterwards. Leaning to approve, but I would like to see some adjustments.

      • Hanh: I also share the concern that they seem to push their KarSend integration. Since I don’t know what it is, I would rather not have ZCG associated with that product if it turns out to be a scam.

      • Gguy: It sounds like we have a few things to work out first. Does someone want to reach out to the team?

      • Artkor: I can, tomorrow.

      • Remains open (pending a revised payment split; Artkor to contact the applicant)

  • Zcash Integration in Coin Wallet (WebZjs + lightwalletd)

    • Applicant requests a grant to add first-class Zcash support (Unified Address receive, z→z/z→t/t→z with memos, on-device scanning/proving/signing) to an existing 25+ chain wallet (browser, Electron, mobile) using WebZjs with Ironwood support, backed by self-operated lightwalletd infrastructure including a Tor endpoint. Requesting $100,000.

      • Artkor: I don’t have a problem with adding Zcash to Coin Wallet, but I find the full $100,000 request difficult to justify. Coin Wallet is already a commercial product with transaction fees and an existing swap business, so adding ZEC can create value for them as well. It is also a very competitive wallet market, and their own target is only a few thousand ZEC users. If this were breaking entirely new ground, the request would be easier for me to support. That is also why I think it is useful to look at what similar Zcash wallet work has cost. While the projects are not directly comparable, Noir recently built a Zcash wallet from scratch for about $54,000, which is a useful reference point.

      • Hanh: We checked both proposals — this one and the next one go together. This one is a wallet based on the Zcash JavaScript library that they are proposing to build as part of the second grant. It would be a pure-JavaScript wallet that runs in the browser, and for security reasons I don’t think it’s appropriate to have secret keys stored in the browser. Independently of that, the amount of work to reimplement all the logic of zero-knowledge proofs, Halo 2, Ironwood and so on in JavaScript seems to be a very wasteful effort and actually provides less security and less benefit than what we have. In my opinion this is not very worthwhile.

      • Artkor: To clarify on the first proposal, I reject.

      • Gguy: I generally agree with the other members’ feedback.

      • Paul: I agree.

      • Zerodartz: I also agree. Coin Wallet isn’t the biggest wallet we have seen apply, so in that sense there’s less impact on Zcash users, and the JavaScript library doesn’t seem secure enough for Zcash standards.

      • Declined

3 Likes
Zcash in the Real World: Education and Street Interviews in Türkiye
Grant Application - Zcash Integration in Coin Wallet (WebZjs + lightwalletd)
Grant Application: Security Audit of Zaino
Grant Application - 0xramp: Non-custodial ZEC ⇿ local-fiat ramp for emerging markets
Grant Application: Zcash Privacy Literacy Lab Canada
Recoverify — Backup Recovery Verification for Zcash Wallets
Zcash Flutter Wallet SDK
[Grant Application] Zcash Marketing & Education Campaign on X and Binance Square
Grant Application - zcashlib: A Pure-JavaScript Zcash Library
Grant Application - 0xramp: ZEC payments and wallet integrations (revision of #408)
Grant application - Zcash SeedSigner, a DIY open source air gapped signer for shielded ZEC
2

  • zcashlib: A Pure-JavaScript Zcash Library

    • Applicant requests a forward grant to build the first pure-JavaScript implementation of Zcash’s shielded protocol — transparent transactions, shielded key hierarchy/viewing keys/Unified Addresses, trial decryption/commitment tree/background scanning, and a JavaScript Groth16 prover for Sapling circuits — validated against official test vectors and librustzcash, with no WASM or native bindings. Requesting $150,000.

      • Artkor: In addition to the concerns already mentioned, everyone who has ever served on ZCG knows how expensive it is for the community to maintain libraries over time. In this case I don’t think it makes much sense to support two similar ones in parallel. The library we already have, and that is already being used, is enough. So I reject the second proposal too.

      • Gguy: As stated for the previous grant, we’re rejecting this one as well today.

      • Declined

  • Zcash Awareness, Education & Community Growth Campaign

    • Applicant requests a grant for a social media marketing campaign on X and Binance Square — educational threads, posts, and articles about Zcash’s privacy features and technical updates, with community engagement and query responses. Requesting $5,000.

      • Artkor: I didn’t find anything in the accounts that were provided that gave me confidence this project makes sense, so I decline this.

      • Gguy: I also struggled to see the value in this project.

      • Paul: I would reject. I can’t imagine that we need a growth campaign on X at this point. If everyone else’s feed is like mine, it’s dominated by Zcash. I just can’t imagine there’s value in funding more education on X.

      • Zerodartz: Agreed. Decline.

      • Declined

  • Zcash Flutter Wallet SDK

    • Applicant requests a grant to build a production Flutter plugin for the Zcash Android and Swift Wallet SDKs — a stable Dart API with typed platform bridge (Pigeon), Swift/Kotlin adapters to official SDK public APIs, lifecycle management, capability matrix, automated CI, and 6 months of post-release maintenance — explicitly not a wallet UI, not a new wallet engine, and not direct Rust FFI. Requesting $10,000.

      • Gguy: A year or two ago this might have been something I would have looked at more closely, but as it exists today, and given the changes in AI and software development, I don’t think this is something I’m willing to fund at this amount.

      • Hanh: There actually are a few wallets out there that already use this technology. YWallet uses Flutter for the UI with librustzcash and some private Rust code for the back end, so this is not new. Lately we have a couple of other wallets doing the same thing — Vizor is also on Flutter and Zkool is also on Flutter. The approach we have all taken differs from this one, because we have the back end and business logic in Rust and use code generation to bind between Flutter and Rust. What they propose to do here is fairly manual binding. If they do manual binding, the price they quote is too low; if they do automatic binding, it is too high, because obviously you can do it automatically. And if they do automatic binding it would actually be not that useful, because librustzcash does not have the abstractions that are needed to call it natively from Flutter. Long story short, this doesn’t really fit anywhere, so I reject.

      • Declined

  • 24 Videos @zkMarketer

    • Applicant requests a grant to fund 12 weeks of 2-per-week short documentary-style films (24 total) assembled from existing ecosystem footage — clips from protocol engineers, co-founders, outside commentators, and institutional voices threaded into single-argument 2-minute films, with everything downloadable at full quality, no credit required. Requesting $60,000.

      • Gguy: I think we were impressed with some of the content we’ve already seen, and we’re looking to approve this one today.

      • Artkor: He has already shown that he can make good Zcash content, and I’ve seen in practice that this is exactly the kind of content that tends to spread organically and reach a wider audience. I approve.

      • Paul: I approve. I really appreciate the approach taken here to demonstrate the kind of product that can be created and give us something concrete to evaluate before asking for ZCG funding. That is super helpful in this case. I think the content is great, the price is reasonable, and it’s generating a lot of content in a short amount of time with milestones. I think it’s a really good project. Happy to approve.

      • Zerodartz: The strength is that a lot of Zcashers have already supported these videos by sharing them on Twitter, and they have done quite well also numbers wise — they’re very well edited and put together. So even though the budget is a bit on the higher side compared with the industry average for short-form videos, it makes sense, since the quality and research of the topics is there. It’s $2,500 per video. I approve.

      • Approved

  • ZecScope (Zcash network upgrade / ZIP tracker)

    • Applicant proposes a public open-source website tracking Zcash ZIPs, network upgrade roadmap, wallet readiness matrix, and ZCG funding/resourcing view — modeled on Ethereum’s Forkcast, with automated sync from the zips repo and PR-based wallet team submissions, plus an 8-week post-launch stabilization window. Requesting $36,300.

      • Hanh: I’m not clear what it’s going to do. I like the idea, but I don’t know if it’s going to work out, because a lot of the data is not easy to collect.

      • Gguy: I also had concerns that a lot of this information might require manual input and can’t be automated or sourced from GitHub or a document that already exists. I may reach out to the applicant to make them aware that this might not be possible, even though I like the idea.

      • Hanh: When they say network upgrade roadmap, we were concerned that we don’t have a roadmap for network upgrades as far as I know. The ZIP tracker is also very challenging, because there are tons of ZIPs in different states — some abandoned, some in progress — and you can’t really tell from GitHub. The wallet readiness matrix is also challenging, because some wallets report things that are not exactly correct and some don’t report anything; I’m one of the ones who doesn’t report much. It would be good to have, it’s just very challenging.

      • Zerodartz: That’s good feedback for developers and the community — we should have a clearer roadmap for the network upgrades.

      • Remains open (data availability concerns; Gguy to contact the applicant)

  • Kestrel + ZecAuth: Open Zcash Wallet Connectivity with African Fiat On/Off-Ramps

    • Applicant requests a grant to productionize three integrated components: ZecAuth (scoped wallet-to-application authorization protocol), Kestrel (production self-custodial Zcash wallet derived from their ZecWallet prototype), and KuvarSend’s ZecAuth integration (first production fiat↔ZEC on/off-ramp using ZecAuth, targeting African local currencies) — with 1,200+ registered users, 600+ transactions, and $30,000+ volume already on KuvarSend. Requesting $12,000.

      • Artkor: I don’t have a clear decision on this one yet, but I’m inclined to decline it, because a big part of the project seems to depend on KuvarSend’s existing payment infrastructure, and from what I understand that infrastructure already exists and is already being used — at least based on the East Africa proposal we discussed today. So I’m not sure what exactly ZCG would be funded here.

      • Too early to vote

  • Zcash Wallet State Integrity: Self-Healing Transaction History

    • Applicant requests a grant to fix three specific transaction-history integrity defects in zcash_client_sqlite — nullable trust_status in v_transactions (causing complete history query failure in mobile SDKs), unusable stored transaction bytes blocking re-retrieval, and missing shielded output attribution when funding account is discovered after storage — with regression tests and mobile SDK validation for each. Requesting $8,500.

      • Hanh: He’s offering to fix a couple of bugs. In cases like this it’s a matter of knowing whether these bugs are worth fixing. There are a bunch of things in the GitHub issue database which are old issues that nobody really cares about anymore. It’s not worth just picking a bug, and the price is very high — several thousand for one bug.

      • Too early to vote

  • Research on a fully constant-time proving pipeline for open-source hardware wallet architectures, reusable for standard computers

    • Applicant requests a grant to research and implement architecture-specific constant-time alternatives to algorithms in the Halo2 proving pipeline — targeting STT chips/FPGAs for AST parsing and potentially full proving, with secondary x86-64 and ARM implementations for desktop/mobile, motivated by the hardware wallet context where full circuit validation is currently impractical. Requesting $96,000.

      • Too early to vote
3 Likes
Grant Application — ZecScope (Zcash network upgrade / ZIP tracker)
3

Thanks review and spending the time with the proposal :folded_hands: , I want to address the points raised since I think some of them come from a misunderstanding

I think it’s a cool technical project and honestly I’d like to play with it myself, but it feels too niche for ZCG funding, especially at this budget.

The wishlist lists hardware wallet support and lightweight physical storage, so the question is really about the DIY approach, and I think that is the strongest part of the proposal not the weakest (and one of the main reasons SeedSigner exists in Bitcoin). A commercial hardware wallet means trusting a vendor’s supply chain and a vendor’s customer database.

Leaks of customer database keeps hapening left and right, and then these users get target by fishing campaings (I.E Trezor on X: "Two days ago, we received an update from our shipping provider, ShipMonk. We're deeply saddened to share the news that the recent data breach affects more customers than originally thought. Another 67,000 customers from the US who ordered between November 2019 and August 2021 were af… / X ), some users are being targeted in real life by criminals to steal their crypto ( A man with a bitcoin fortune was allegedly tortured for weeks in a New York City home. Here's what we know. - CBS News ).

Because this device can be built from off the shelf parts, no one can know that these are meant to build a hardware wallet, so it preserves your privacy as a holder in real life too.

cc @artkor

I agree that this is a fun project, but unfortunately I don’t think the value matches the ask. I’m going to reject.

I will resubmit at 30,000 USD

cc @GGuy

I agree to reject. There are also the concerns about hot wallet integration mentioned in the proposal. The proposal mentions upstream integration with ZODL, and until that were agreed upon I think it would be premature to make that assumption.

@paulbrigner on the ZODL integration point, I think the proposal was unclear here and that is on me. The signer does not need anything from ZODL to work, it will speak the same PCZT over UR transport that Zashi already uses with Keystone, so a released Zashi build can hand a transaction to the device and broadcast the signed result today with no changes on the wallet side.

What I meant by upstream integration was the nice to have of Zashi listing the device by name in its hardware wallet screen (whch is an easy change I can submit on my own for improved UX)

It’s reject from me as well, even though it’s probably a cool nerdy project. It’s not worth the funding from us right now with a very limited user group

@zerodartz on the limited user group: I think is smaller than it should be precisely because the option does not exist yet. Today if you hold shielded ZEC and want your keys off your phone you have exactly one class of device to choose from, all commercial (with a vendor supply chain).

Anyone who wants an open, verifiable signer has no options, so of course that group looks like zero from the outside. On Bitcoin the same group turned out to be large once the option was available, specially users that value privacy. the Bitcoin SeedSigner latest release image was downloaded over 20k times in the two months since July.

The ZODL integration is a bit of an issue, but he did mention that only a small change is needed, so maybe he can do it without. I agree it’s a bit too expensive. It’s really a hobbyist project, because in terms of cost it isn’t really cheaper than buying a hardware wallet once you account for the parts you have to buy and assemble, and the result will be less secure because it doesn’t have a secure element. For a hobbyist project, this request is way too high for me.

@hanh on cost: the parts are around 50 USD, so is cheaper, but I agree price is not the argument. The argument is that nothing about the device passes through a vendor, no order, no shipment, no firmware download signed by a company, no customer record. You buy generic parts anywhere, build the image yourself or verify the published one against a reproducible build, and nobody knows you own it.

On the secure element I would argue the SeedSigner operational model is more secure. A secure element protects a secret that is stored on the device against someone who has the device in hand but this design stores nothing. The seed is loaded per session from a password protected SeedQR, lives in RAM while you sign, and is gone when you power off.

There is no secret at rest for an attacker to extract. This is a short explanation:

On the request being too high, I will resubmit is at 30,000 USD

Thanks again for taking the time to review the proposal and for the feedback :folded_hands:

2 Likes
Grant application - Zcash SeedSigner, a DIY open source air gapped signer for shielded ZEC (resubmission)
4

SeedQR is not a secure way to store your seed phrase. Anyone can take a quick pic of it, so it has to be very tightly guarded. That becomes a weaker link in your security chain.

5

@hanh a SeedQR is the seed, a photo of it is the same as a photo of the 24 words (which is also an input option on the seed signer, just less convenient), so it has to be stored exactly like the written backup, in a safe, on steel, wherever you keep the words today.

That is the point tho, is not a new secret in the chain, is the same backup a Ledger or Keystone user already has on paper. A secure element does not remove the paper backup, it just means you also have a second copy of the seed inside a device

I does mean the user needs physical access to the seeds whenever he wants to use the device, so its not as convenient as the seed stored in the device, but certainly is not inherently “less secure” than devices with a physical secure element, but it relies on a completely different security model that trades off physical tamper-resistance storage for statelessness

6

It’s less secure because if someone has physical access to:

  • the seed QR: they have your funds
  • the ledger device: they need to break the secure element
7

I think that compares the wrong two things. A Ledger user also has a backup, the 24 words on paper or steel, and whoever gets physical access to that has the funds, same as with a SeedQR.

Device vs device, someone who takes a Ledger has to break the secure element and the PIN, someone who takes a SeedSigner gets a Raspberry Pi with nothing on it, there is no secret in the device to attack

8

The Ledger user doesn’t need the seeds whenever they want to use the device. Most high value Ledger owners I know either use the bank secure item deposit facility with an passphrase-encrypted seed, or store it in a very secure location once.

They intentionally make it harder to find it themselves, since banks require hours of paperwork and sometimes days of notice before they finally ID check you and allow you to access the seed.

9

Completely fair, for such an user a SeedSigner would not be the best option, but we dont need to have one or the other, we can have both types of devices, that serve different types of users

A user who wouldnt want to trust vendor in the chain at all and is comfortable handling/properly custoding their seed, the SeedSigner is probably better, I myself am such an user :sweat_smile:, and is why I am a big proponent of the SeedSigner and I am trying to bring it to more blockchains

10

Or just… use an iPhone if you don’t have enough money to warrant Ledger-like security? iPhones are REMARKABLY secure, I personally have known over 110 people who use a spare iPhone SE on Lockdown Mode as a Ledger with a screen. Apple offers $2,000,000 for an exploit which can breach lockdown mode, and nobody’s gonna waste a $3M god-tier journalist-killing exploit to steal your 0.4 BTC. Game theory baby.

11

But that requieres a lot of trust, a phone has radios that you can turn off in software but are not absent, and you cant verify what the OS or the app is doing, you need to trust Apple and the app vendor, which is fine for you but is exactly the trust in thiord parties that projects like the SeedSigner are trying to remove, the Pi Zero 1.3 for example has no wireless hardware at all and the image is opensource and reproducible, so the device is provably air gapped

Also, if you really wanted to use an IPhone, is there even an offline shielded Zcash app for iPhone?

12

Trivial to implement, just switch the network upload payload to a QR. Well established QR airgap pattern in dozens of wallet.

Funnily, they are effectively absent. Lockdown mode turns off things at the kernel level, that’s why the breach of lockdown mode has a $2M bounty. If you can gain access to the kernel, you have effectively broken down all security.

But that brings up a question: Your Raspberry Pi’s basic RP2040 chip has no hardware or software sandbox, unlike Apple’s hardened A-series chips. Side channels, thermal spike detection, fault injection, cache recovery, there are DOZENS of attacks the chip is vulnerable to during operation!

You… you expect users to run untrusted firmware too…

13

The SeedSigner OS and firmware are open source, every user can inspect it, audit it, build it and deploy them themselves, so they don’t need to trust, they can verify (albeit it does requieres some technical knowledge)

BTW I do see your point, the offline IPhone is probably also a good enough solution for some users

Anyways thanks everyone for the input and taking the time to engage with the proposal :folded_hands:

14

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.