# Grant Application - Kestrel: Native Mobile WalletConnect for Zcash **URL:** \ **Category:** Applications\ **Created:** [November 2, 2026, 12:13pm UTC](https://forum.zcashcommunity.com/t/grant-application-kestrel-native-mobile-walletconnect-for-zcash/58756 "2026-11-02T12:13:13Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![raycre8-g](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/raycre8-g/32/45360_2.png) [@raycre8-g](https://forum.zcashcommunity.com/u/raycre8-g)\ **Post date:** [November 2, 2026, 12:13pm UTC](https://forum.zcashcommunity.com/t/grant-application-kestrel-native-mobile-walletconnect-for-zcash/58756/1 "2026-11-02T12:13:14Z")
Hi everyone, Aderemi from Kuvarpay here. We have submitted a grant application to Zcash Community Grants and would really value the community’s feedback before the committee reviews it. **GitHub application:** [Grant Application - {Application Name} · Issue #532 · ZcashCommunityGrants/zcashcommunitygrants · GitHub](https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/532) **Funding requested:** $20,000 ($3,000 startup + three milestones) **Timeline:** 12 weeks **License:** MIT This replaces our earlier application, [Kestrel + ZecAuth (#421)](https://forum.zcashcommunity.com/t/kestrel-zecauth-open-zcash-wallet-connectivity-with-african-fiat-on-off-ramps/57503), which was declined in September. The scope has changed substantially, as explained below. ## Overview Kestrel is an open-source, self-custodial Zcash wallet for iOS and Android. It will be the first native mobile implementation of the shared Zcash WalletConnect standard that @noir_wallet published under grant #391. Alongside the wallet, we will release a reusable wallet-side module and an integration guide so other mobile Zcash wallets can add WalletConnect without building it from scratch. ## The problem **Zcash mobile users can’t use WalletConnect.** A shared Zcash WalletConnect spec now exists, and Noir is implementing it in a browser wallet. But no mobile wallet offers WalletConnect for Zcash today. We checked the source of Zodl (iOS and Android) and Zingo mobile and found no WalletConnect dependency. Most Zcash users hold ZEC on their phones, so dApps that adopt the standard still can’t reach them. **Every mobile wallet would have to build the same thing.** Pairing, session handling, a permission manager, approval screens, and mapping requests onto the Zcash SDK. Without a reusable implementation, each team repeats this work and makes its own privacy decisions. **Some privacy questions are still open.** The v1 spec deliberately defers balance and history methods, and it allows but doesn’t require a different address per app. There’s also a format limit: CAIP-10 caps an account address at 128 characters. A Unified Address with Orchard, Sapling and transparent receivers is about 213 characters, and only an Orchard-only one (about 106) fits. ## What we will deliver 1. **Kestrel for iOS and Android.** Shielded send and receive, Unified Addresses, Ironwood support with the ZIP-318 Orchard to Ironwood migration, on-device keys, PIN and biometrics, built on the current Zcash mobile SDKs (4.x). 2. **The shared spec, implemented natively on mobile.** `zcash_requestAccounts`, `zcash_getAccounts`, `zcash_sendTransaction` and the account and chain events, as published. Any dApp built for the standard works with Kestrel unchanged. Each connected app gets its own fresh Orchard-only address, so apps can’t link your activity across sites. We are not implementing `zcash_signTransaction`, for the privacy reasons the spec itself gives. 3. **A reusable React Native module** with the session layer, permission manager, Zcash method handlers and approval screens. React Native wallets can adopt it directly, and native wallets can follow the same structure. 4. **Contributions to the shared spec** , plus a public integration guide and a lessons-learned report on what was hard and what would make the next integration easier. The spec contributions are proposals for balance and history consent, per-app addresses, the CAIP-10 account format, and a candidate scheme for the optional `zcash_signMessage`. That scheme uses per-app sign-in keys that are not linked to your addresses or your transactions. ## How this relates to Noir’s work This is meant to complement grant #391, not compete with it. Noir defined the standard and is shipping it on the browser. Kestrel brings the same standard to native mobile and feeds what we learn back into the shared spec. We will coordinate with the Noir team on our proposals and on one shared namespace registry entry, so the ecosystem has a single standard. ## What changed since our previous application The feedback on #421, from the committee and here on the forum, was consistent. People asked why we weren’t using WalletConnect instead of our own transport. They said work that mainly helps one company or one service isn’t a good fit for ZCG. And they said documentation and practical guidance for the next teams would be valuable. This application is built around that feedback. It uses WalletConnect and the shared spec, every company-specific part is removed (no KuvarSend or fiat ramps), and the guide and lessons-learned report are funded deliverables. ## Budget | Item | Amount | | --- | --- | | Compensation (3 people, 12 weeks, part-time) | $15,000 | | Independent security review | $3,000 | | Light-client infrastructure | $1,000 | | CI and crash monitoring | $600 | | Reference dApp hosting and test infrastructure | $400 | | **Total** | **$20,000** | ## Milestones | | Due | Amount | Main deliverables | | --- | --- | --- | --- | | Startup | On approval | $3,000 | SDK 4.x upgrade, infrastructure, security review scoping | | 1 | 2026-12-29 | $5,500 | Kestrel core wallet on iOS and Android, WalletConnect pairing and sessions | | 2 | 2027-01-26 | $5,500 | Spec methods, per-app addresses, payment approval, reusable module on npm, reference dApp, ZIP-318 migration | | 3 | 2027-02-23 | $6,000 | Security review, store releases, integration guide, lessons-learned report, spec proposals, mainnet demo | Dates assume a December 1 start and shift if approval comes later. ## Team - **Aderemi Azeez** , Project Lead. Built ZecAuth and the ZecWallet prototype at ZecHub Hackathon 3.0. - **Abdulhammed Abdulazeez** , Mobile Engineer (iOS / Android). - **Abdulazeez Jubril Kolawole** , Backend / Infrastructure. Built Z3 Launcher at ZecHub Hackathon 3.0. ## Feedback we would especially value - **Mobile wallet teams:** would a reusable WalletConnect module be useful to you? What would make it easy to adopt? - **dApp developers:** what do you need from a mobile Zcash wallet over WalletConnect? - **Privacy:** does a fresh address per connected app feel like the right default? How should balance and history access be consented to? Full details, including user stories and acceptance criteria for each milestone, are in the application: > > > \### Terms and Conditions > > \- \[x\] I agree to the \[Grant Agreement\](https://9ba4718…c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471\_f81ef4e4b5f040038350270590eb2e42.pdf) terms if funded > \- \[x\] I agree to \[Provide KYC information\](https://9ba4718c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471\_7d9e73d16b584a61bae92282b208efc4.pdf) if funded above $50,000 USD > \- \[x\] I agree to disclose conflicts of interest > \- \[x\] I agree to adhere to the \[Code of Conduct\](https://forum.zcashcommunity.com/t/zcg-code-of-conduct/41787) and \[Communication Guidelines\](https://forum.zcashcommunity.com/t/zcg-communication-guidelines/44284) > \- \[x\] I understand all milestone deliverables will be validated and accepted by their intended users or their representatives, who will confirm that the deliverables meet the required quality, functionality, and usability for each user story. > \- \[x\] I agree that for any new open-source software, I will create a \`CONTRIBUTING.md\` file that reflects the high standards of Zcash development, using the \[\`librustzcash\` style guides\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#styleguides) as a primary reference. > \- \[x\] I understand when contributing to existing Zcash code, I am required to adhere to the project specific contribution guidelines, paying close attention to any \[merge\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#merge-workflow), \[branch\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#branch-history), \[pull request\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#pull-request-review), and \[commit\](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#commit-messages) guidelines as exemplified in the \`librustzcash\` repository. > \- \[x\] I agree to post request details on the \[Community Forum\](https://forum.zcashcommunity.com/c/grants/33) > \- \[x\] I understand it is my responsibility to post a link to this issue on the \[Zcash Community Forums\](https://forum.zcashcommunity.com/c/grants/33) after this application has been submitted so the community can give input. I understand this is required in order for ZCG to discuss and vote on this grant application. > > \### Application Owners (@Octocat, @Octocat1) > > @raycre8-g > > \### Organization Name > > Kuvarpay Limited > > \### How did you learn about Zcash Community Grants > > We were encouraged by squirrel in the ZecHub community to apply after demonstrating our Zcash work at ZecHub Hackathon 3.0, including ZecAuth and the ZecWallet prototype. > > \### Requested Grant Amount (USD) > > $20,000 > > \### Category > > Infrastructure > > \### Project Lead > > \`\`\`project-lead.yaml > Name: Aderemi Azeez > Role: Project Lead / Founder, Kuvarpay Limited > Background: Full-stack engineer and fintech founder building crypto and payment infrastructure for African markets. He previously built KuvarPay, a crypto payment gateway, and RaySwap, a multi-chain exchange. For ZecHub Hackathon 3.0 he created ZecAuth, a Zcash wallet-to-application authorization protocol with ZIP-32-derived RedPallas signatures, and ZecWallet, the bare React Native prototype that Kestrel is built from. > Responsibilities: > - Project delivery and technical leadership > - Kestrel architecture and WalletConnect integration > - Shared-spec implementation and extension proposals > - Coordination with Noir Wallet on the shared Zcash WalletConnect spec > - Integration guide, lessons-learned report, and ZCG reporting > \`\`\` > > \### Additional Team Members > > \`\`\`team-members.yaml > \- Name: Abdulhammed Abdulazeez > Role: Mobile Engineer (iOS / Android) > Background: Mobile engineer trained at African Leadership University and co-founder of Zidify, with experience building cross-platform fintech applications. He currently works on the ZecWallet prototype that will become Kestrel. > Responsibilities: > - Kestrel iOS (Swift + ZcashLightClientKit) and Android (Kotlin + Zcash Android SDK) > - SDK 4.x upgrade, native bridges, Ironwood and ZIP-318 migration > - Wallet UX, approval screens, PIN, biometrics, automatic locking > - App Store and Google Play releases > \- Name: Abdulazeez Jubril Kolawole > Role: Backend / Infrastructure Engineer > Background: Software engineer and KuvarPay COO with experience in fintech APIs, blockchain infrastructure, and production systems. He built Z3 Launcher for ZecHub Hackathon 3.0, a Go-based deployment and management system for Zebra, Zaino, and Zallet. > Responsibilities: > - Reusable React Native WalletConnect module: packaging, tests, npm release > - Reference dApp and its hosting > - Light-client endpoints, CI, crash monitoring, test environments > \`\`\` > > \### Project Summary > > Kestrel is an open-source, self-custodial Zcash wallet for iOS and Android that will be the first native mobile implementation of the shared Zcash WalletConnect standard funded under grant #391. It ships with a reusable wallet-side module and an integration guide so other mobile Zcash wallets can add WalletConnect without building it from scratch. > > \### Project Description > > Kestrel builds on two things the Zcash ecosystem already has: WalletConnect as the transport and session layer, and the Zcash WalletConnect specification that Noir Wallet published in September 2026 under ZCG grant #391. Noir's work defines the shared standard and ships it in a browser wallet. Kestrel brings the same standard to native iOS and Android, and packages the wallet side as an open-source module so other mobile wallets do not have to build it again. > > This application replaces our earlier proposal #421, which the committee declined at its September 28, 2026 meeting. We have acted on each point the committee raised: > > \- Artkor recommended WalletConnect over a custom integration layer, and said he would rather fund documentation, implementation guides, and practical feedback that make integration easier for the next teams. Kestrel now uses WalletConnect and Noir's shared spec in place of our own ZecAuth transport, and the integration guide and a lessons-learned report are funded deliverables. > \- Gguy, Zerodartz, and Paul found the earlier proposal too specific to one wallet and one service. The reusable module and the spec contributions in this proposal are built to be used by other wallets, not only by Kestrel. > \- Hanh saw the earlier proposal as funding our own business. KuvarSend, fiat ramps, and every company-specific component have been removed. No deliverable depends on a Kuvarpay commercial product. > > From ZecAuth we keep the experience of designing scoped, per-capability consent for shielded Zcash. We contribute it as proposals to the shared spec instead of as a separate protocol. > > \### Proposed Problem > > 1. Zcash mobile users cannot use WalletConnect. > WalletConnect is the standard way wallets connect to web applications on most major chains. For Zcash, a shared namespace and method specification now exists (grant #391), and Noir is implementing it in a browser wallet. No mobile wallet offers WalletConnect for Zcash today; we checked the source of Zodl (iOS and Android) and Zingo mobile and found no WalletConnect dependency. Most Zcash users hold ZEC on their phones, so dApps that adopt the standard still cannot reach them. > > 2. Every mobile wallet would have to build the same integration. > Adding WalletConnect to a Zcash wallet means pairing, session handling, a permission manager, approval screens, and mapping requests onto the Zcash SDK. Without a reusable implementation, each wallet team repeats this work and makes its own privacy decisions. > > 3. Some privacy questions in the shared spec are still open. > Noir's v1 spec deliberately defers balance and transaction-history methods, and it allows but does not require a different address per application. There is also a format constraint: CAIP-10 limits an account address to 128 characters, while a Unified Address with Orchard, Sapling, and transparent receivers is about 213 characters. Only an Orchard-only Unified Address (about 106 characters) fits. These questions affect every wallet that implements the standard and are best settled once, in the shared spec. > > \### Proposed Solution > > Over twelve weeks we will deliver four things. > > 1. Kestrel for iOS and Android > A production self-custodial Zcash wallet, built from our ZecWallet prototype and upgraded to the current Zcash mobile SDKs (4.x) with NU6.3 support: > \- Wallet creation and restoration, with seed storage in iOS Keychain and Android Keystore > \- Shielded send and receive, Unified Addresses, balances, and transaction history > \- Ironwood support and the ZIP-318 Orchard to Ironwood migration flow > \- PIN, optional biometrics, and automatic locking > \- WalletConnect pairing by QR code and deep link, session review, approval, persistence, and disconnection > > 2. Native mobile implementation of the shared Zcash WalletConnect spec > Kestrel implements Noir's published v1 spec as written, so a dApp built for the standard works with Kestrel without changes: > \- zcash\_requestAccounts and zcash\_getAccounts, returning only the address the user authorizes for that application > \- zcash\_sendTransaction: the application sends a payment intent, and Kestrel builds, displays, signs, and broadcasts the transaction on the device > \- zcash\_accountsChanged and zcash\_chainChanged events > \- Chain identifiers zcash:mainnet and zcash:testnet > Kestrel gives each connected application its own fresh Orchard-only Unified Address, so applications cannot link a user across sites and the account identifier fits the CAIP-10 length limit. We will not implement zcash\_signTransaction; we agree with the spec's reasoning that letting an application construct shielded transactions leaks note-selection metadata. > > 3. Reusable wallet-side module > An MIT-licensed React Native module containing the WalletConnect session handling, the Zcash method handlers, the permission manager, and reference approval screens. React Native wallets such as Zingo mobile can adopt it directly. Native Swift and Kotlin wallets such as Zodl can follow the same structure using the integration guide. > > 4. Spec contributions, an integration guide, and a lessons-learned report > \- Written extension proposals submitted to the shared spec: zcash\_getBalance and zcash\_getTransaction with explicit per-request consent; the per-application address strategy; and the CAIP-10 account format > \- A candidate scheme for the optional zcash\_signMessage method, based on the ZIP-32-derived RedPallas signatures we built and tested for ZecAuth > \- A draft zcash entry for the ChainAgnostic namespaces registry, prepared with Noir > \- A public integration guide for mobile wallet teams, and a lessons-learned report covering what was difficult, the SDK gaps we hit, and what would make the next integration easier > > \### Solution Format > > Software and documentation, all public and MIT-licensed: > \- Kestrel repository with reproducible build instructions > \- Kestrel iOS and Android release builds, plus App Store and Google Play submissions > \- Reusable React Native WalletConnect module for Zcash, published to npm with tests > \- Open-source reference dApp built with standard Reown AppKit against the shared spec > \- Spec extension proposals and a draft namespace registry entry > \- Mobile wallet integration guide > \- Lessons-learned report > \- Independent security review findings and remediation status > \- Mainnet demonstration video and final ZCG report > > \### Dependencies > > Technical: Zcash Swift wallet SDK 4.x (ZcashLightClientKit, github.com/zcash/zcash-swift-wallet-sdk), Zcash Android wallet SDK 4.x (github.com/zcash/zcash-android-wallet-sdk), Reown WalletKit (the WalletConnect wallet SDK) and AppKit for the reference dApp, React Native (bare), Zaino/lightwalletd light-client endpoints, Apple and Google developer platforms. > > Specification: the Zcash WalletConnect Technical Architecture and Protocol Specification published by Noir Wallet under grant #391. Kestrel implements its v1 as published. > > Collaboration: we will coordinate with Noir Wallet on spec extension proposals and the namespace registry entry. Their acceptance of our proposals is not required to complete this grant, and no other ZCG grantee is required for delivery. WalletGuide listing depends on WalletConnect's review timeline; our acceptance criteria require submission, not approval. > > \### Technical Approach > > Wallet architecture > Bare React Native with native modules: Swift over ZcashLightClientKit on iOS and Kotlin over the Zcash Android SDK on Android. Seed material is generated and kept on the device in iOS Keychain or Android Keystore. Sensitive actions require fresh authentication. > > WalletConnect layer > Kestrel uses Reown WalletKit for pairing (QR code and wc: deep links), session proposals, requests, updates, and disconnection. Requests pass through four parts, following the layering in the shared spec: > \- Session layer (WalletKit): receives proposals and requests > \- Permission manager: checks every request against the approved application, chain, account, and method; anything not approved is rejected before the wallet core is touched > \- Zcash method handlers: map each spec method onto SDK calls > \- Wallet core: builds, proves, signs, and broadcasts on the device > Private keys and viewing keys never pass through WalletConnect. > > Accounts and addresses > On a new session, Kestrel derives a fresh Orchard-only Unified Address for that application with getCustomUnifiedAddress, which both 4.0.0 SDKs expose, and returns it as the CAIP-10 account (zcash:mainnet:\). The address is about 106 characters, within CAIP-10's 128-character limit. Different applications receive different addresses. > > Payments > zcash\_sendTransaction carries a payment intent (recipient, amount, memo), mapped to ZIP-321 where applicable. Kestrel creates a ZIP-317 fee proposal through the SDK, shows the requesting app, recipient, amount, fee, memo, and network, and only builds and broadcasts after the user approves. The result (txid or a structured rejection) is returned to the application. > > Consent > The approval screen lists each requested method with a plain-language description of what it reveals. WalletConnect requires a wallet to approve every method a dApp marks as required, so only optional methods can be declined individually; the integration guide recommends that dApps request sensitive methods as optional. > > Reusable module > The session layer, permission manager, method handlers, and approval screens are packaged as a React Native module with no dependency on Kestrel's app code, published to npm with unit tests and a sample integration. > > Licensing: all new code is MIT-licensed, and each new repository includes a CONTRIBUTING.md following the librustzcash style guides. > > \### Upstream Merge Opportunities > > We do not plan to fork or modify any Zcash repository. Kestrel uses the released Zcash mobile SDKs as dependencies. > > Contributions we plan to make upstream: > \- Shared Zcash WalletConnect spec (Noir Wallet): extension proposals for zcash\_getBalance, zcash\_getTransaction, per-application addresses, the CAIP-10 account format, and a zcash\_signMessage candidate scheme. These benefit every wallet implementing the standard. > \- ChainAgnostic namespaces registry: a draft zcash namespace entry, prepared with Noir so the ecosystem submits one entry, not two. > \- Zcash Swift and Android wallet SDKs: issues and fixes for any bugs, missing interfaces, or documentation gaps we hit, filed following each repository's contribution guidelines. > > Upstream review and merge timelines will not block completion of this grant. > > \### Open Source License > > MIT > > \### Hardware/Software Costs (USD) > > $0 > > \### Hardware/Software Justification > > No purchases are needed. Kuvarpay provides development machines, Apple Developer and Google Play Console accounts, code-signing infrastructure, and iOS and Android test devices as an in-kind contribution. > > \### Service Costs (USD) > > $5,000 > > \### Service Costs Justification > > | Item | Cost | > | -- | -- | > | Independent security review | $3,000 | > | Zaino / light-client infrastructure | $1,000 | > | CI and crash monitoring | $600 | > | Reference dApp hosting, TLS, and test infrastructure | $400 | > | Total | $5,000 | > > Independent security review ($3,000): a focused external review of WalletConnect session handling, permission enforcement, per-application address handling, payment approval, key storage, and sensitive-action authentication. > Zaino / light-client infrastructure ($1,000): project endpoints and monitoring for testnet development and mainnet validation. > CI and crash monitoring ($600): automated builds and tests for the app and module, release validation, crash diagnostics. > Reference dApp hosting ($400): public hosting and TLS for the reference dApp used in acceptance testing and the mainnet demo. > > \### Compensation Costs (USD) > > $15,000 > > \### Compensation Costs Justification > > | Team member | Role | Compensation | > | -- | -- | -- | > | Aderemi Azeez | Project Lead / Protocol and Full-Stack | $5,000 | > | Abdulhammed Abdulazeez | Mobile Engineering (iOS / Android) | $5,000 | > | Abdulazeez Jubril Kolawole | Backend / Infrastructure | $5,000 | > | Total | | $15,000 | > > Each team member is compensated $5,000 for twelve weeks of part-time work, about $417 per week. The grant funds the Zcash-specific engineering; Kuvarpay contributes additional engineering capacity and existing equipment. > > \### Total Budget (USD) > > $20,000 > > \### Previous Funding > > No > > \### Previous Funding Details > > \_No response\_ > > \### Other Funding Sources > > No > > \### Other Funding Sources Details > > \_No response\_ > > \### Implementation Risks > > 1. Shared spec changes > Risk: Noir's spec is a v1 draft and may change during the project. > Mitigation: we implement v1 as published and track changes with Noir. The module keeps the spec mapping in one layer, so updates stay small. > > 2. Required versus optional methods > Risk: WalletConnect requires wallets to approve every method a dApp marks as required, so users can only decline optional methods. > Mitigation: Kestrel shows every requested method before approval, and the integration guide recommends that dApps request sensitive methods as optional. > > 3. SDK upgrade > Risk: the ZecWallet prototype runs on Zcash mobile SDK 2.5.2, and the current releases are 4.0.0 on iOS and Android. The 4.0.0 notes also say migration-proposal failures are not yet classified. > Mitigation: the upgrade happens in the startup phase, before feature work. Kestrel handles migration errors generically and reports gaps upstream. > > 4. WalletGuide listing > Risk: listing depends on WalletConnect's review timeline. > Mitigation: we submit during Milestone 2, and acceptance requires submission evidence, not approval. > > 5. Noir reference application timing > Risk: Noir's reference application may not be public when we need it for interoperability testing. > Mitigation: our acceptance testing uses our own reference dApp built with standard Reown AppKit against the published spec, plus Noir's application when it is available. > > 6. App store review > Risk: Apple or Google review may run past the project timeline. > Mitigation: submissions begin early, and signed builds with submission evidence satisfy acceptance. > > \### Potential Side Effects > > Address correlation: a connected application learns the address the user authorizes. Kestrel limits this by giving each application its own fresh address, so applications cannot link a user's sessions to each other. > > Misleading payment requests: a malicious application may request a payment the user did not intend. Kestrel shows the requesting app, recipient, amount, fee, and memo, and nothing is sent without explicit approval. > > Wallet fingerprinting: applications may learn which wallet a user runs, as with any WalletConnect wallet. > > Relay dependency: WalletConnect sessions depend on the WalletConnect relay. Normal wallet use (send, receive, shield, migrate) does not, and keeps working if the relay is unavailable. > > \### Success Metrics > > Grant deliverables (required): > \- Kestrel completes the shared-spec connect and payment flow with the reference dApp on mainnet, on iOS and Android > \- Each connected application receives a different address > \- The reusable module is on npm, documented, and passing tests in CI > \- Spec extension proposals are public and submitted to the spec maintainers > \- The integration guide and lessons-learned report are public > \- The security review and remediation status are public > \- App Store, Google Play, and WalletGuide submissions are completed > > Ecosystem metrics (tracked, not promised): > We will report other wallet teams evaluating or adopting the module, dApps connecting to Kestrel, which of our spec proposals are adopted, Kestrel installs, and crash-free sessions. > > \### Startup Funding (USD) > > $3,000 > > \### Startup Funding Justification > > The startup amount lets the SDK upgrade, infrastructure setup, and security-review scoping begin immediately. Dates assume a December 1, 2026 start; if approval comes later, each milestone date shifts while the twelve-week schedule stays the same. > > | Item | Amount | > | -- | -- | > | Engineering: upgrade the ZecWallet prototype to Zcash mobile SDK 4.x, rename it to Kestrel, set up repositories | $1,500 | > | Infrastructure: light-client endpoints, CI, test environment, Reown project setup | $700 | > | Security review: reviewer scoping and engagement | $800 | > | Total | $3,000 | > > The $3,000 is part of the $20,000 total. The remaining $17,000 is tied to the three milestones ($5,500 + $5,500 + $6,000). > > \### Milestone Details > > \`\`\`milestones.yaml > \- Milestone: 1 > Amount (USD): 5500 > Expected Completion Date: 2026-12-29 > User Stories: > - "As a Zcash user, I want to create or restore a self-custodial wallet on my iPhone or Android phone, so that I can hold and spend shielded ZEC without trusting a third party." > - "As a Zcash user, I want to scan a WalletConnect QR code or tap a connection link and see which app is connecting and what it is asking for, so that I only connect to apps I trust." > - "As a dApp developer, I want my app built for the shared Zcash WalletConnect spec to pair with a mobile wallet, so that I can reach Zcash users on their phones." > Deliverables: > - Kestrel repository (MIT) with reproducible build instructions and CONTRIBUTING.md > - Kestrel on Zcash mobile SDK 4.x for iOS and Android, with NU6.3 support > - Wallet creation, restoration, sync, Unified Addresses, shielded send and receive, transaction history > - Seed storage in iOS Keychain and Android Keystore; PIN, optional biometrics, automatic locking > - Reown WalletKit integration: QR and deep link pairing, session proposal review, approve, reject, persistence across restarts, disconnection > - Testnet builds for iOS and Android > Acceptance Criteria: A reviewer can build Kestrel from the repository, create and restore a testnet wallet, receive and send shielded ZEC, and pair Kestrel with a test dApp by QR code and by deep link on iOS and Android. The session screen shows the app's name, domain, and requested methods. Approve and reject both work, and an approved session survives an app restart and can be disconnected from either side. > \- Milestone: 2 > Amount (USD): 5500 > Expected Completion Date: 2027-01-26 > User Stories: > - "As a Zcash user, I want each connected app to see only an address created for that app, so that different apps cannot link my activity together." > - "As a Zcash user, I want to review the recipient, amount, fee, and memo of every payment request before anything is sent, so that an app cannot move my funds without my approval." > - "As a mobile wallet developer, I want a reusable open-source WalletConnect module for Zcash, so that I can add WalletConnect to my wallet without building it from scratch." > - "As a Zcash user with Orchard funds, I want a guided Orchard to Ironwood migration, so that my funds move to the new pool with the privacy trade-offs explained." > Deliverables: > - Shared-spec v1 methods in Kestrel: zcash\_requestAccounts, zcash\_getAccounts, zcash\_sendTransaction, and the zcash\_accountsChanged and zcash\_chainChanged events > - A fresh Orchard-only Unified Address for each connected application, used as its CAIP-10 account > - Payment review screen with on-device build, sign, and broadcast, returning the txid or a structured rejection to the app > - Reusable React Native WalletConnect module (MIT), published to npm with documentation and tests > - Open-source reference dApp built with standard Reown AppKit against the shared spec > - ZIP-318 Orchard to Ironwood migration flow in Kestrel > - Spec proposals for per-application addresses and the CAIP-10 account format, shared with Noir Wallet > - WalletGuide listing submitted for Kestrel > Acceptance Criteria: On testnet, the reference dApp connects to Kestrel, receives an address created for it, and sends a payment request that the user reviews and approves; the dApp receives the txid. A second app receives a different address. If Noir's reference application is public, the same flow is shown working with it. The module installs from npm and its tests pass in CI. A testnet wallet holding Orchard funds completes the ZIP-318 migration flow. > \- Milestone: 3 > Amount (USD): 6000 > Expected Completion Date: 2027-02-23 > User Stories: > - "As a Zcash user, I want to install Kestrel from the App Store or Google Play, so that I can use it without building it myself." > - "As the Zcash community, I want an independent security review with published findings, so that I can judge whether Kestrel is safe to use with real funds." > - "As the next wallet team adding WalletConnect, I want an integration guide and an honest account of what was hard, so that my integration takes less time." > - "As a maintainer of the shared Zcash WalletConnect spec, I want concrete proposals for the open privacy questions, so that every wallet can settle them the same way." > Deliverables: > - Independent security review of session handling, permission enforcement, address handling, payment approval, and key storage, with findings and remediation status published > - Mainnet release builds for iOS and Android; App Store and Google Play submissions > - Mobile wallet integration guide > - Lessons-learned report > - Spec proposals for zcash\_getBalance and zcash\_getTransaction consent, and a zcash\_signMessage candidate scheme, submitted to the shared spec > - Draft zcash namespace registry entry prepared with Noir Wallet > - Mainnet demonstration video and final ZCG report > Acceptance Criteria: The security review is complete, and every critical finding within our control is fixed or documented as a release blocker. Release builds are public and store submissions are evidenced (store approval is outside our control). The guide, report, and spec proposals are public, and the proposals are submitted to the spec maintainers. A recorded mainnet demo shows the reference dApp connecting to Kestrel, receiving an address created for it, and completing a payment request the user approves. > \`\`\` > > \### Supporting Documents > > \`\`\`files.yaml > \- ZecAuth (ZecHub Hackathon 3.0): https://github.com/ZecHub/zechub/tree/main/Hackathon/2026/ZecAuth > Our wallet-to-application authorization protocol, including the ZecWallet React Native prototype that Kestrel is built from > \- Z3 Launcher (ZecHub Hackathon 3.0): https://github.com/ZecHub/zechub/tree/main/Hackathon/2026/Z3Launcher > Deployment and management system for Zebra, Zaino, and Zallet, built by Abdulazeez Jubril Kolawole > \- Zcash WalletConnect Integration, grant #391: https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/391 > The approved grant whose published spec Kestrel implements > \- Previous application, #421: https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/421 > Declined September 28, 2026; this application acts on that feedback > \`\`\` Thank you for reading. We will answer questions here and post monthly updates in this thread if the grant is approved.