Zcash Community Grants Meeting Minutes 5/11/2026

Community Grants Community Grants Updates
1

Zcash Community Grants Committee Google Meet Meeting: May 11, 2026

Attendance:

  • Artkor

  • GGuy

  • Hanh

  • Zerodartz

  • DecentralistDan

  • Alex (FPF resource, notetaker)

Key Takeaways:

All votes this week were unanimous.

Open Grant Proposals

  • Formal Verification of Halo 2 in Lean 4

    • 18-month project to formally verify Zcash’s Orchard protocol and Halo 2 circuits using Lean 4, covering soundness/completeness of five circuit gadgets, protocol-level security properties, and post-quantum migration analysis. All outputs open-source. Requesting $201,600.

      • Gguy: We’re keen on seeing the results of this work but we will need the core developers to evaluate each of the milestones.

      • Artkor: I’d like to thank the applicant for agreeing to present and discuss this proposal in more detail on the Arborist Call. I recognize the interest in this grant, but I agree that a final decision requires further technical review. If the grant is approved, milestone payments should depend on expert review, and the applicant should understand that this process may lead to delays for objective reasons outside ZCG’s control.

      • Hanh: We should have a review plan for the features month by month in advance so that we know that it’s not going to put all the difficult stuff at the end and all the trivial stuff in the beginning.

      • Gguy: We’ll go back to the core developers and applicants before making a decision on this.

      • Remains open

  • Feature Branch Testnet and Compatible Developer Tooling

    • Dedicated testnet for NU7-deferred features (ZSA, NSM), starting single-node and expanding to multi-node, synchronized with mainnet changes. Fills the gap left by the main testnet. Requesting $412,410.

      • Hanh: I haven’t sent the message to QEDIT yet, I will do so this week. I would also like to talk to the committee about using discretionary funds to provision some machines to deploy the testnet ourselves, running a couple of nodes to get this started.

      • Remains open

  • ​​BTCPayServer Multi-Account and 0conf Mempool Support

    • The applicant proposes to improve the existing BTCPayServer Zcash plugin by adding zero-confirmation (0conf) mempool notifications and multi-account/multi-store wallet support. The work includes building a new wallet RPC service on the Zkool GraphQL API, updating the plugin, and retroactive compensation for prior bug fixes and maintenance. The improvements would allow merchants to accept Zcash payments without waiting for block confirmation and enable shared BTCPayServer hosting across multiple merchants. Requesting $25,000.

      • Gguy: We’ve approved this one with changes made and we think this has use cases that will be beneficial to Zcash.

      • Artkor: This is an important area where we needed to work with Elias to revise the proposal structure and rebalance the priorities. I would also like to thank him for his contribution to maintaining the functionality of the BTCPayServer Zcash plugin and for responding quickly to merchant needs. I support approving the proposal in its latest revised form.

      • Zerodartz: I also approve this. I think that zero confirmation payment is a crucial part of user experience and it will make it more seamless. We need to level up the most used Zcash payment systems.

      • Decentralistdan: After meeting with the applicant and the revised proposal that also includes important feature improvements, I approve.

      • Approved

  • Zush · Quiet Money for Zcash, US Phase 1

    • Zush proposes a Zcash-integrated debit card product with two tiers: a no-KYC prepaid voucher tier (Visa gift cards + x402/CipherPay) and a light-KYC bank-tied tier (Column rails, Apple/Google Pay), both backed by a user-held ShieldedVault, with cashback paid in shielded ZEC. Requesting $100,000.

      • Artkor: This is a technically complex proposal and interesting in its own way. However, as before, I don’t think we can approve initiatives of this type since they look more like commercial projects than ZCG founded ecosystem infrastructure.

      • Hanh: Yeah I agree that more than 70% of the funding for making these cards available plus it’s only in the US for the moment. Hard to justify as being in scope.

      • Zerodartz: The idea isn’t bad but it’s not a good fit for ZCG. The market for this kind of card isn’t big enough yet to be practical at the moment.

      • decentralistdan: out of scope for ZCG funding.

      • Declined

  • Grassroots Marketing Team at DWeb Camp

    • A returning grassroots marketing team proposes sending four people to DWeb Camp 2026 in Berlin (July 2026) to conduct Zodl wallet demonstrations, Zcash/CipherPay education, and developer outreach, continuing a campaign series that has previously covered DevConnect Buenos Aires, ETHDenver, and ETHCC Cannes. Requesting $10,200.

      • Zerodartz: They’ve been a good team representing Zcash at events. This is a bit different type of event, more chill, and they can connect with likeminded people and discuss the future of privacy projects. And it’s a reasonable budget.

      • Artkor: Yes, I’d like to thank this team for their enthusiasm and their willingness to actively collaborate with contributions across the Zcash community.

      • Decentralistdan: This is a strong team, I like what they’ve been doing. After changing their application to fit better with this event. I think they could have a strong impact at the event and as Zerodartz said, meet some folks to collaborate with and hopefully come up with some future connections for collaborating going forward at other events as well.

      • Approved

  • Revocable Private Delegation in Token Holder Voting

    • Nethermind proposes a research and engineering project to design and prototype a private voting delegation protocol for Zcash token holders — enabling holders to delegate and revoke voting power without revealing their identity — intended to be composable with existing Zcash e-voting proposals. Deliverables are a design specification and a proof of concept**. Requesting $140,900.**

      • Hanh: This is not a big ask from the users and there is currently an effort going on with ZODL to make improvements to the voting system. Therefore I don’t think this isn’t going to have much traction. These days the key point would be to have a voting system integrated in ZODL and this one would not be.

      • Artkor: I agree. Josh, the head of ZODL team has already effectively announced a new coin holder voting system that will soon be available in their widely used Zcash wallet. We have also already participated in testing it. For that reason, I don’t think it makes sense to fund a parallel development effort in this area.

      • Zerodartz: I also think we had a lot of coin voting and token holder voting proposals recently and ZCG is not really looking to fund any until we have tested the new system and hopefully it works well and we don’t need to fund more different voting systems for now.

      • decentralistdan: additional voting mechanisms are currently out of scope for funding as the ecosystem is already pursuing this and I would like to see the current path mature

      • Declined

  • Teenagers in Blockchain Africa (TIBA)

    • TIBA proposes a three-month Zcash education and community activation program across Nigeria, delivering monthly physical meetups, developer workshops, X-Space discussions, and social media content to an existing audience of 500+ trained builders and 2,000+ community members, with the goal of introducing shielded transaction concepts and building a Zcash-aware developer pipeline on the continent. Requesting $12,600.

      • Artkor: Given the growing availability of specialized AI tools for programmers and broader self-direction learning, I no longer believe there is a strong need for programs of this kind. Anyone who has genuine interest can now learn independently and even make their first steps in programming with these tools, which is exactly what we have already seen. So I reject this proposal.

      • Zerodartz: This team seems new to Zcash and I would like to see them start with small contributions if they are interested in working on future community education projects.

      • Decentralistdan: agreed, I would like to see this team contribute to the ecosystem before approving a proposal

      • Declined

  • Zcash University Outreach Initiative – Mexico

    • Applicant proposes a structured university outreach initiative across five Mexican institutions (UNAM, IPN, Tec de Monterrey, UdeG, BUAP), delivering focused 1–2 day technical engagements covering Zcash privacy fundamentals and hands-on developer tooling, with the goal of cultivating small, durable campus communities rather than maximizing headcount. Requesting $47,500.

      • Hanh: Pretty much the same reason, we don’t know them, if they want to get this kind of funding our standard method is putting them in touch with ZecHub and start creating some track record with the community.

      • Declined

  • Zcash Sponsorship & Adoption Activation at KBCC 2026

    • Cryptogalaxy proposes a three-phase Zcash activation in Kenya centered on Gold Sponsorship at KBCC 2026 (May 14–15, Nairobi), followed by a post-conference Zcash Privacy Workshop (May 16), backed by a pre-existing Telegram community (280+ members) and X presence building pre-event awareness. Requesting $8,500.

      • Artkor: I don’t support approving this proposal for the same reasons given above. The relevance and effectiveness of programs of this kind are becoming increasingly unclear to me at this stage.

      • Zerodartz: I did notice this same team applied to ZecHub also recently with a lower budget and if they get support from there then they can at least start contributing on smaller scale.

      • Declined

  • Using Zcash in an internet freedom crowdfunding campaign

    • The Tor Project requests a ZCG matching pool contribution for a crypto-native crowdfunding campaign (May 19–June 18) benefiting 11 privacy and internet freedom projects, using quadratic funding mechanics, with Zcash positioned as a primary donation option and distributed to Tor Browser’s 4.8M daily active user base. Requesting $250,000.

      • Artkor: I’m glad that we have an opportunity to support the Tor team this year. Tor is one of the most important social infrastructure projects for people who need protection for privacy and fundamental freedoms, and it doesn’t have a straightforward commercial monetization model. For that reason I support approving the base amount of $50,000, and if Zcash community members are willing to attend and represent Zcash at the Tor project event, I would also be open to supporting the $100,000 level.

      • Gguy: I think the $50,000 tier makes sense for us. I approve that.

      • Hanh: If someone is willing to do the work for the $100,000 tier I think we’re open to fund that.

      • Zerodartz: Tor has been one of the most important internet privacy tools. Zcash supporting this initiative is very value aligned. And if there are Zcashers who would be available to represent Zcash at the event, we could raise the amount.

      • decentralistdan: highly aligned project and excited to fund this initiative

      • Approved ($50,000 tier)

  • Hito

    • Hito Wallet proposes to develop a cold signing module for Zcash Orchard shielded transactions, enabling fully offline private key signing on their hardware device with integration to mainnet via lightwalletd and the Zodl wallet interface. Requesting $50,000.

      • Artkor: I’m very happy to support approving this grant and I hope it will be fully implemented. Shielded Zcash should be available in every hardware wallet. And it would also be great if Hito eventually released a co-branded device for the Zcash community. I would certainly want to buy one for my collection.

      • Gguy: Yes I agree that hardware wallets are something that protect our users and we understand there is an elevated cost in developing hardware wallets over pure software wallets.

      • Hanh: I think we should fund it. The only question is if they are equipped with delivering the whole project considering it’s a small team. Bear in mind that Ledger and Trezor were not able yet to do so. This is not as simple as it looks. But it’s possible.

      • Zerodartz: I think this hardware wallet is really cool since it’s credit card sized and the budget is reasonable. If they can manage to pull it all off and get it working, then I can see it getting new Zcash users also.

      • Hanh: One of the considerations is to find a partner to do the companion app. I don’t think they have a partner yet or maybe they are planning to do it themselves?

      • Zerodartz: Yeah that’s good to consider. Which wallets would be open to partner with them?

      • Hanh: I think it’s a good project but I suspect large coin holders would not want to put their funds into something that has so little market share. We’ll see.

      • Approved

  • Zcash Arabia (May to September 2026)

    • Zcash Arabia proposes to scale an existing Arabic-language Zcash education and community initiative across the MENA region, expanding educational content, user onboarding, and developer engagement for Arabic-speaking audiences. Requesting $32,500.

      • Artkor: I regret to say that this time I do not have sufficient confidence that the demonstrated impact is proportional to the requested amount. The current public signals, including website quality, X activity, and Telegram engagement, do not provide sufficiently strong qualitative evidence to justify approving this grant. I vote to reject.

      • Zerodartz: I also don’t think the new proposal is that much more impactful compared to the fact that the monthly amount has more than doubled and team members are the same. So yeah, there seems to be some new plans, but it doesn’t seem to be worth this bigger budget. So the current grant application at least doesn’t get my support.

      • Hanh: I reject as well. Last time we talked to them we asked them to get in touch with ZecHub and work on integrating their academy and their gamification to do some project together and I don’t think any of this stuff has actually happened. So regardless of the money that they are asking now I don’t think they have delivered on what they said in the meeting we had with them.

      • Zerodartz: I think they translated some articles but they didn’t make it to ZecHub yet.

      • Hanh: I can see in the grant from Q1 that they said they would begin translation of some upcoming articles and then publish them in their academy in Arabic. I don’t think that has happened and we spent quite a long time talking to them to set expectations.

      • Decentralistdan: I’m a reject as well based on what was just said. Not executing on the previously agreed upon concept and lack of activity and price.

      • Declined

  • Pesa ya Siri Tanzania 2026

    • Pesa ya Siri proposes a 4-month pilot to embed Zcash as an everyday payment option in Tanzania through WhatsApp-based interaction, agent-assisted onboarding, and voucher-style access, targeting small retail, informal savings groups (chamas), and peer-to-peer transactions — including feature phone users. Requesting $5,800.

      • Artkor: This proposal did not convince me. It feels somewhat vague and I don’t see a clear enough reason to support approval.

      • Zerodartz: I think this region is not that big for us and ZCG can’t support every community in the world. The team doesn’t have enough background so it’s a decline from me currently.

      • Hanh: Reject as well. It’s way too ambitious considering the budget and the reputation of the team; we don’t know anything about them. They want to do something that is massive. I don’t think there’s any chance this is going to happen.

      • Gguy: I would always encourage new teams and contributors to establish a track record and place within the community before asking for grants.

      • Hanh: Yeah they need realistic expectations.

      • Declined

  • Quantir Privacy-Safe Risk Intelligence for Zcash Infrastructure

    • Quantir proposes to build an open-source, privacy-safe monitoring and alerting module for Zcash ecosystem infrastructure — covering wallets, Zapps, light-client services, and bridges — producing structured, explainable risk alerts from public or opt-in signals without touching shielded transaction data. Requesting $48,000.

      • Artkor: The visible Quantir product essentially looks like a repackaged block explorer. It filters large public transactions and overlays market-based risk metrics on top of them. In the context of Zcash, this would only apply to the transparent layer and does not address the infrastructure risks described in their proposal, such as Zebra, lightwalletd, sync failures, service degradation, etc. The basic version of this kind of monitoring does not seem technically difficult enough to justify a grant. So I reject this proposal.

      • Hanh: This proposal is extremely vague when it comes to what it means to do privacy risk intelligence and honestly it looks like AI slop. If you have seen the website and it looks like a block explorer I’m not surprised. I don’t think they really have done anything specific to Zcash or to privacy coins?

      • Zerodartz: I agree it’s too generic and the scope seems too big for the budget and doesn’t provide any currently practical value to Zcash.

      • Declined

  • Cypherpunk Policy Dinner

    • Project Glitch requests ZCG to anchor-sponsor the Cypherpunk Policy Dinner (CPD), an invitation-only dinner for ~100 people on October 21, 2026 in Washington DC, explicitly Zcash-branded and limited to Zcash ecosystem co-sponsors, positioned as a high-signal policy advocacy moment the evening before the DC Privacy Summit. Requesting $25,000.

      • Artkor: This proposal has generated substantial discussion both on the forum and within the committee. I believe Paul has provided thorough clarifications, and I don’t see a need to restate them here. What I do want to note is that I am grateful for Paul’s work and consider it important for Zcash. While I do not yet know where the committee’s overall view will land, I support approving this grant.

      • Gguy: Yeah I agree this proposal has not been open for a full week yet. I’d like to let the community ask any questions before we make a full decision, but I am leaning positive on this one. I think Paul has a track record of delivering on his activities. So given his track record is one of the reasons why I would support this grant.

      • Zerodartz: Paul has done a great job with his events in the past. I think the idea is good overall and education about privacy and Zcash to regulators overall makes sense. But this dinner event specifically seems too close to the line and would be hard for me to approve at the moment. A lot of discussions are happening on the forum also.

      • Remains open

  • Rore UI engine in rust

    • Rore proposes a hardware-accelerated, GPU-rendered UI framework in pure Rust (via WGPU) designed to replace Electron-based wrappers in Zcash desktop tooling, with a working proof-of-concept demonstrating ~130MB RAM and 1-3% CPU on a 100K row data grid. Requesting $50,000.

      • Gguy: This one is fairly new, we’ll need time to review.

      • Hanh: It’s unlikely to be accepted by me, there’s nothing in there yet. I mean I appreciate his effort to create a UI engine in Rust but it’s a massive amount of work. Something similar would require teams of hundreds of developers and it’s just him by himself. So if you go to what he has created so far there’s really nothing much there. It’s really a lot of work. I can’t imagine anybody is going to switch from the current tech technology stack to his engine. They’re just basic widgets. There’s little that you can build on, you would have to recreate the entire UI from scratch (just flexbox like) and the benefits are actually overstated because, sure you save memory because you don’t have to embed the JavaScript engine, but memory isn’t a problem anymore. Again I appreciate his effort but that’s not a good fit at this stage for us. It’s way too early. He would need another five years of development imo.

      • Zerodartz: I like what they said about using less memory but in 2026, if you even want to use a Zcash wallet, you need a decent computer and usually the RAM is not the main bottleneck.

      • Hanh: It’s not a problem. The RAM usage for synchronization is like 10 times bigger. I thought in the beginning that he was working on the backend but it’s really the UI part and this is not the tricky part of the application these days.

      • Remains open

  • Building Zcash’s Web3 Gateway: WalletConnect v2 Integration with BazaarSwap as Flagship dApp

    • This proposal seeks to build a WalletConnect v2 SDK for Zcash, enabling standardized wallet-to-dApp connectivity across all address types (transparent, Sapling, Orchard, Unified Addresses), with Zodl, Brave, and Vultisig as initial integration targets. Requesting $375,000.

      • Hanh: It was on the forum before. It’s not so easy to decide. I think he has some good points. Let me try to say what the deal is. What he says is that the biggest friction nowadays with Zcash and DeFi is the fact that you can’t connect your Zcash wallet app to a website and start trading directly like you can do with MetaMask or a bunch of other wallets on Ethereum or Solana. This is because there’s a protocol called WalletConnect. It’s a simple request-response protocol for saying “here is my balance” or “I want the wallet to approve a payment.” This is quite helpful when you deal with DeFi because the website can drive all the annoying parts, like calculating the payment value and how much you swap. I also considered integrating WalletConnect a few times back in the days of YWallet and again with Zkool. The only reason I didn’t do it is because there are no apps for Zcash and it’s very tied to Ethereum. Whenever you do a protocol connection, you negotiate a namespace, and all the namespaces for coins are Ethereum-based. Technically you could have something for Zcash because they did that for Tron. There are a few new cryptocurrencies added to WalletConnect, but the main thing they have in common is that they all have a smart contract feature which allows them to do DeFi. For us, if we want to do the WalletConnect thing, we first would have to talk with those guys to reserve a namespace for Zcash. We would have to integrate the protocol, which is technically not very hard because they have SDKs for all the major languages, including Flutter and JavaScript. The problem is not technical; the problem is that once you have integrated it, you have absolutely nothing to talk to. We would not even be able to test it; you would have to write the app on the other side that is going to act as the WalletConnect server. I told them that on the forum and that’s why they’re now talking about making BazaarSwap a flagship dApp. Before, it was not there; they wanted to do WalletConnect as a flagship proposal, but they swapped it around and are talking about BazaarSwap as the primary reason they are doing this proposal. So now the question is: is BazaarSwap going to be big enough to attract enough users to WalletConnect? It’s really not clear. The stuff they do there is going to be difficult to sell. It is another liquidity swap provider or portal. You would need to know whether you can have enough liquidity pooled to be competitive with the other guys. For me, it’s a reject because I don’t think BazaarSwap is going to be big enough to make WalletConnect worthwhile. Today you can do all of this using regular QR codes, just the way ZODL does it, because it’s just a swap; it’s nothing really complicated. The real reason WalletConnect is so popular on Ethereum is because of the smart contracts—you can actually negotiate the protocol and smart contract functions through WalletConnect, whereas with Zcash you can only say “give me your balance” and “make a payment.” It’s very limited.

      • Gguy: Agree, I’ll be looking into this one seeing if there’s a way to make this more useful to Zcash users. But yes, there definitely are some challenges.

      • Hanh: For this to be truly useful, we would need a multi-currency wallet that supports WalletConnect, such as Unstoppable or Edge. This would allow users to connect to a website and perform swaps natively with very little friction, avoiding the need to scan QR codes or manually verify transactions within the app. While there is value here, succeeding will be difficult; I give this initiative about a 20% chance of success, primarily due to business challenges rather than technical ones.

      • Remains open

7 Likes
2

Small clarification. It’s not the same team that applied to ZecHub, just similar proposal and goal.

3

@ZCG Hello everyone and thank you for taking the time to review the Rore UI Engine proposal. I would like to clarify a few important architectural points regarding the scope and necessity of this engine.

  1. It’s not just about RAM; it’s about CPU contention and “Zero-Jank” UX.

While saving memory is beneficial, the main problem that Rore solves is CPU cache misses and VDOM contention. When zebrad or librustzcash is actively generating heavy zk-SNARK proofs or synchronization blocks, it requires maximum CPU priority. Traditional electron/web interfaces rely on virtual DOM differentiation and JavaScript garbage collection, which steal CPU cycles and cause UI freezing (jank) during heavy data flows.

Rore provides a smooth UI with minimal resource consumption, and does not slow down the underlying computation.

  1. Feasibility: This is not a 5-year project
    I completely agree that building a GUI framework from scratch is a 100-person job. But Rore is not reinventing the wheel. I am combining ready-made components that are already in the RUST ecosystem. I am not trying to rebuild flutter/React. I am narrowly adapting Rore and adapting it only for the Web3 world. As stated in Milestone, I will initially create an infrastructure tailored only for ZCash. And it is quite realistic to develop it in 5-6 months.

  2. Developer friction solved in phase 3

No one is forced to write low-level WGPU shaders. Phase 3 introduces Declarative Web Syntax Macros. Zcash developers write components using familiar HTML/JSX-like syntax (e.g. view! { <div …div>}), which compiles to native GPU code. The barrier to entry will be very low.

4

Thank you for the detailed technical feedback. I want to address your concerns about market viability by clarifying the institutional context that informed this proposal (Grant Application Forum Post)

Clarifying the Initial Discussion

The forum introduction that prompted your feedback was an introduction to BazaarSwap as a platform and business. It was not a proposal for WalletConnect v2 integration at that time. The current grant application represents the first formal proposal for WalletConnect v2 infrastructure, informed by Crosslink’s development timeline and LST-ZEC’s anticipated launch.

BazaarSwap’s value proposition as a cross-chain liquidity aggregator stands independently from this infrastructure request. The WalletConnect v2 integration enhances that existing platform by enabling non-custodial wallet connectivity, but does not define its core utility.

Crosslink: The Ecosystem Inflection Point

Shielded Labs is targeting completion of a Crosslink prototype within 12 months, with a 9-month productionization phase to follow. This consensus upgrade will introduce staking mechanics to Zcash, producing liquid staked ZEC (LST-ZEC) as a primary ecosystem asset.

Once Crosslink activates on mainnet, LST-ZEC holders will require non-custodial access to decentralized finance applications. This is not speculative demand, it is an architectural requirement of the protocol upgrade itself.

The Interoperability Necessity

LST-ZEC utility depends on standardized wallet-to-dApp connectivity. Current options are:

  • Custodial bridges (wrapped tokens, CEX deposits)

  • Custom point-to-point integrations (wallet-specific development)

  • WalletConnect v2 (standardized, non-custodial, 600+ wallet ecosystem)

WalletConnect v2 is the industry standard mechanism for non-custodial wallet interoperability. It is the only mechanism that enables LST-ZEC to participate in:

  • Rujira Primitives (currently live, will support ZEC lending, borrowing, and liquidity pools)

  • THORChain swaps

  • MayaChain swaps

  • 600+ additional WalletConnect-compatible applications

Without standardized wallet connectivity, LST-ZEC users are forced back to custodial solutions, which is the opposite of Zcash’s core value proposition.

Why BazaarSwap Matters (And Why It Doesn’t)

You are correct that a single DApp cannot drive WalletConnect adoption. That is not the ask.

BazaarSwap’s role is to serve as a proof of concept that demonstrates:

  • WalletConnect v2 functions correctly for all Zcash address types (transparent, Sapling, Orchard, Unified)

  • Cross-chain liquidity aggregation is a valid use case for LST-ZEC

  • The infrastructure is production-ready and secure before other wallets and DApps build on it

BazaarSwap (https://bazaarswap.io) aggregates liquidity from over 350+ decentralized exchanges across 45+ cross-chain protocols, including THORChain and MayaChain. Once WalletConnect v2 integration is complete, BazaarSwap will enable non-custodial ZEC liquidity access on THORChain through native wallet connectivity. This is a capability that does not currently exist for Zcash users.

BazaarSwap’s integration with leading cross-chain infrastructure is documented in Rubic Exchange’s public ecosystem documentation: https://docs.rubic.finance/rubic/overview/ecosystem

This positions BazaarSwap as a legitimate first integration demonstrating WalletConnect v2 functionality, not as a commercial bet on a single application’s success.

Why Zcash’s Architecture Doesn’t Limit WalletConnect’s Value

You correctly identified that Zcash lacks smart contract functionality, which is the primary driver of WalletConnect adoption on Ethereum. This distinction is important and worth addressing directly.

WalletConnect’s value on Ethereum derives from enabling users to negotiate smart contract interactions through a standardized protocol. Zcash does not need this capability. LST-ZEC utility does not depend on smart contract execution on the Zcash layer.

Instead, LST-ZEC derives utility from deployment across external DeFi ecosystems:

  • Rujira Primitives: Users lend, borrow, and provide liquidity using LST-ZEC without executing Zcash smart contracts

  • THORChain and MayaChain: These protocols handle settlement and execution; WalletConnect simply enables users to authorize transactions from their Zcash wallet

  • Other WalletConnect-compatible applications: Similarly, these platforms execute logic on their own layers while WalletConnect enables simple, non-custodial wallet authorization

WalletConnect for Zcash is not about enabling complex contract negotiation. It is about enabling non-custodial transaction authorization across external DeFi platforms that already support Zcash assets.

Regarding multi-currency wallet support: Unstoppable Domains, Edge Wallet, and similar platforms will naturally integrate WalletConnect v2 for Zcash once the standard is established. Their incentive is user demand. Once LST-ZEC exists and users seek to deploy it in DeFi, these wallet teams will update their repositories to reflect the latest WalletConnect protocol additions for Zcash support. This is a routine maintenance update, not a speculative build.

The distinction you raised between QR codes and wallet connectivity is also worth clarifying. For a single swap on a single chain, QR code authorization is sufficient. But LST-ZEC’s value depends on liquidity deployment across multiple ecosystems simultaneously: users need to manage positions across Rujira, THORChain, and MayaChain without scanning QR codes for each transaction. This is where standardized wallet connectivity becomes necessary, not optional.

Wallet Integration is Not Speculative

You identified a real constraint: wallets need incentive to integrate. We have already had initial discussions with two wallet teams that currently support WalletConnect v2. Their integration path is straightforward. They update their repository to reflect the latest protocol additions for Zcash support.

Once WalletConnect v2 is standardized for Zcash, wallet integration becomes a routine update, not a custom development effort. Wallet teams integrate because:

  • Their users hold Zcash and will demand access to LST-ZEC utility

  • WalletConnect v2 integration is no longer optional for competing wallets

  • The effort is maintenance-level, not engineering-intensive

Institutional Validation

Vitalik Buterin has provided a second round of funding to Shielded Labs to accelerate Crosslink development, emphasizing that Zcash is “one of the most honorable crypto projects focused on privacy.” This funding is explicitly supporting the productionization phase of Crosslink, including security audits and thorough analysis.

The convergence of these initiatives (Crosslink’s core infrastructure work backed by external funding and a 12-month development roadmap, paired with WalletConnect v2 standardization) represents a coordinated ecosystem build, not speculative infrastructure.

Success Metrics Are Infrastructure-Level

The proposal’s success criteria are independent of any single application’s commercial performance:

  • SDK passes independent security audit with zero critical findings

  • 2+ wallets successfully integrate the SDK

  • SDK is listed in WalletConnect’s official ecosystem registry

  • 1+ production application deploys LST-ZEC via WalletConnect v2

These are ecosystem infrastructure benchmarks, measured by standardization and adoption enablement.

The Timing Argument

This proposal positions WalletConnect v2 integration to be complete and audited at the moment LST-ZEC enters active circulation on mainnet. This is synchronized infrastructure development, not speculative deployment.

Once LST-ZEC is live, the market demand for wallet connectivity is not “hoped for.” It is architectural. Users holding a new asset class on Zcash will immediately seek ways to deploy that asset in DeFi. WalletConnect v2 is the mechanism that makes this possible without custodial intermediation.