We believe @zcash-rn will be a foundational piece of developer infrastructure that empowers a new wave of mobile developers to build innovative, private applications on Zcash. We are eager to hear the community’s feedback and answer any questions you may have.
About Us
Chainscore Labs is an engineering research and development studio with a proven track record of delivering performant and secure systems for leading blockchain ecosystems. Our team has deep expertise across the full blockchain stack, from protocol engineering to modern mobile application development.
Hi @Prasad-Chainscore - Welcome to the forum, and thank you for submitting your grant proposal! We will review it in the upcoming weeks and reach out if we have any questions.
In the meantime, if you have any questions for us, you can post them to this thread or DM us at @ZcashGrants.
Zcash Community - We want to hear your feedback on this grant! You can post your comments to this thread or DM us at @ZcashGrants if you’d like to provide feedback in private.
Hi, nice to see interest in making it easier to develop Zcash apps with React Native. I believe there are already two actively maintained Zcash React Native libraries: zingo-mobile (libraries need to be extracted) and react-native-zcash. react-native-zcash is based on the official iOS/Android mobile SDK. While the API is fairly limited, I think it would work as a starting point to gauge interest.
The amount of requested funding seems a bit high given the risk that a new React Native implementation might not be used by new or existing Zcash apps. I think it would make more sense to work on extracting zingolib bindings out of zingo-mobile into an independent React Native library given the amount of work that has already been done on zingolib, and to see how feasible a port of the Warp Sync implementation of ywallet/zkool to React Native would be.
Thank you for pointing out @1337bytes! We found react-native-zcash the way to get started for RN devs, but its just a wrapper class lib that doesn’t do enough to lower the barrier to entry. Our proposal for a full-featured developer SDK for RN, provides a complete core library ( @zcash-rn/core), idiomatic Hooks ( @zcash-rn/hooks), a pre-built headless UI kit (@zcash-rn/ui-kit), and a scaffolding tool (create-zcash-app). With this, we’ll be drastically reducing the time and complexity for developers to build high-quality, performant Zcash apps.
Existing of proper toolings is essential for adoption. Greater risk is that no library gets significant adoption because the developer experience is poor
Additionally our approach being JSI-Native, built for React Native’s New Architecture to have significantly better performance for modern apps interacting w zcash. It’s a replacement to RN’s legacy bridge which both above lib uses, and is known causes UI lag and poor user experience, esp for data-heavy tasks like syncing
Hello! thank you for posting this proposal. I read through your document and researched a bit about it.
According to what I could find online, JSI-Native support adoption on React native development is somewhere from 25% to 50% at most. I don’t agree with your argument that your solution is “prepared for the future”. I’d rather it’s prepared for the present. I hope I’m wrong and that people would adopt Zcash at any cost, but I don’t see that any Engineering Manager with good judgement would actually rush their codebase’s evolution towards a new React Native Architecture to just adopt Zcash on their App. I think your application would be way better if it offered support for the 100% of React Native developers or at least… 90% of them with a bridge solution and a JSI solution so that they can just adopt Zcash and worry about their stack evolution later.
Another question:
Your design says that you would interface librustzcash with JSI, but at the moment librustzcash crates don’t offer a sync engine for light clients. They might in the future after Zallet changes are coded back to zcash_client_backend but it’s not available now. The mobile SDKs have a mixed approach (sorry! our bad! it was another era) and the sync engine is spread accross both sides of the FFI, how would you address that?
Thank you for the insightful feedback. We chose a JSI approach to avoid building on a deprecated, high-maintenance bridge as the New Architecture is now the default for all new RN projects. But you are right that there might be existing projects RN who might not want to push thru immediately right now (I suppose they might till we release - Q3-Q4 2026 but we could only predict :/). We’ll include both the modules in our spec, we’ll prioritise building out the JSI module but also support a wrapped bridge solution.
On librustzcash, the SDK will have a clean FFI boundary that isolates us from internal sync engine changes. If the Rust core evolves, our integration remains stable. But if there’s time for zcash_client_backend to be available we’ll evaluate the mobile SDKs’ approach to have the sync engine
Imo, these language bindings arent going to be used much when autogenerated and not used by an active project. We have seen that with the uniffi for go python and java.
Maybe if the API was more stable but our code base is very active specially with the zcashd deprecation going on.
Yes… but Zcash could actually benefit from integrations to existing Dart or React wallets. For example integration Cake wallet would be a huge win but last time I checked it was a Dart codebase. Ledger Live Mobile is a React Native codebase.
Can you think of some kind of an arrangement that could work for this? Maybe actively subsidizing a real product that depends on these integrations to be the DogFooding/active maintainer?
If you’re an active project that could benefit from a library like this, please don’t hesitate to reach out to me or to ZCG. We’ve found that the most successful outcomes often happen when projects like these are developed end-to-end in close collaboration.
@hanh I couldn’t agree more, simple auto-generated bindings are not a viable long-term solution. The instability of the underlying codebase is a major risk for any developer, and a library without an active user is destined to become abandonware.
Exactly the reason we proposed a complete developer SDK, with a stable, developer-facing API, than a thin binding. Packages like the @zcash-rn/hooks is designed to be that stable abstraction layer. It will provide a consistent, well-documented API to developers, abstracting away the complexities of the underlying data models in librustzcash. As the core Rust APIs change, we’ll handle the necessary updates within our native core (@zcash-rn/core), ensuring the JavaScript-level API remains stable and reliable
@pacu we’ve also proposed launching a few applications (like the Mobile Wallet, Payments) for reference, as our first stable implementations to be for dogfeeding- with which we’ll get to build a practical, robust, and battle-tested SDK from day one and commit us to its active, long-term maintenance.
On a sidenote - building a stable API and data model like Monero is essential, and we’ll be thrilled to collaborate as we build
Thank you for your submission. After consideration from ZCGand sufficient time for the community to provide feedback on the forum, the committee has decided to reject this proposal.
The committee appreciates your grant submission efforts and encourages you to continue as an active member of the Zcash community going forward!
