TL;DR​

• The Problem: Delegating ZK proof generation to servers often fails to preserve privacy, as the server sees your private inputs, though there are recent researches on private proof delegation ^{1 2 3} to mitigate this issue. Ultimately, true privacy requires client-side proving, but current performance is too slow for mainstream adoption.
• The Opportunity: Modern mobile phones and laptops contain GPUs well-suited to accelerating parallelizable ZK primitives (NTT, MSM, hashing). Benchmarks show field operations on smaller fields like M31 achieve more than 100x throughput compared to BN254 on an Apple M3 chip ⁴.
• The Gap: No standard cryptographic library exists for client-side GPU implementations. Projects reinvent primitives from scratch, and best practices for mobile-specific constraints (hybrid CPU-GPU coordination, thermal management) remain unexplored.
• Post-Quantum Alignment: Smaller-field operations in post-quantum (PQ) schemes (hash-based, lattice-based) map naturally to GPU 32-bit ALUs, making this exploration more valuable as the ecosystem prepares for quantum threats.

1. Privacy is Hygiene​

Ethereum's public ledger ensures transparency, but it comes at a steep cost: every transaction is permanently visible, exposing users' financial histories, preferences, and behaviors. Chain analysis tools can easily link pseudonymous addresses to real-world identities, potentially turning the blockchain into a surveillance machine.

As Vitalik put it, "Privacy is not a feature, but hygiene." It is a fundamental requirement for a safe decentralized system that people are willing to adopt for everyday use.

Delegating ZK proof generation to servers undermines this hygiene. While server-side proving is fast and convenient, it requires sharing raw inputs with third parties. Imagine handing your bank statement to a stranger to "anonymize" it for you. If a server sees your IP or, even worse, your transaction details, privacy is compromised regardless of the proof's validity. Though recent studies explore private delegation of provers ¹, true sovereignty requires client-side proving: users generate proofs on their own devices, keeping data private from the start.

This is especially critical for everyday Ethereum privacy. Think of sending payments, voting in DAOs, or managing identity-related credentials (e.g. health records) without fear of exposure. Without client-side capabilities, privacy-preserving tech remains niche, adopted only by privacy-maximalist geeks. Hence, accelerating proofs on consumer hardware could be the bedrock for creating mass adoption of privacy, making it as seamless as signing a transaction today.

2. GPU Acceleration: A Multi-Phase Necessity for Client Proving​

Committing resources to client-side GPU acceleration for ZKP is both a short-term and long-term opportunity for Ethereum's privacy landscape. GPUs excel at parallel computations, aligning perfectly with core primitives that could be used in privacy-preserving techs like ZKP and FHE, and client devices (phones, laptops) increasingly feature growing GPU capabilities. This could reduce proving times to interactive levels, fostering mass adoption.

Current Status and Progress​

Although client-side proving is a reality, the user experience is still catching up. CSP benchmarks from ethproofs.org show that while consumer devices can now generate proofs in seconds, the process often takes longer than 100ms. For scenarios requiring real-time experience, like payments or some DeFi applications, this delay creates noticeable friction that hinders adoption.

CSP benchmarks from ethproofs.org 5. Snapshot taken on January 19, 2026

Several zkVM projects working on real-time proving have leveraged server-side GPUs (e.g. CUDA on RTX-5090) for ~79x improvement on average proving times, according to site metrics from Jan 28, 2025 to Jan 23, 2026, validating the potential of GPU acceleration for proving.

On the client side, though still in the early stages of PoC and exploration, several projects highlight potential:

• Ingonyama ICICLE Metal: Optimizes ZK primitives such as MSM and NTT for Apple's Metal API, achieving up to 5x acceleration on iOS/macOS GPUs (v3.6 release detailed in their blog post).
• zkMopro Metal MSM v2: Explores MSM acceleration on Apple GPUs, improved 40-100x over v1. For details, check this write-up. Building on ZPrize 2023 winners Tal and Koh's WebGPU innovations (inspired by their implementation) ⁶.
• Ligetron: Leverages WebGPU for faster SHA-256 and NTT operations, enabling cross-platform ZK both natively and in browsers.

Broader efforts from ZPrize and Geometry.xyz underscore growing momentum, though protocol integration remains limited ⁷⁸.

Opportunities for Acceleration​

Several ZK primitives are inherently parallelizable, making GPUs a natural fit:

• MSM (Multi-Scalar Multiplication): Sums scalar multiplications on elliptic curves; parallel via independent additions, bottleneck in elliptic curve-related schemes.
• NTT (Number Theoretic Transform): A fast algorithm for polynomial multiplication similar to FFT but over finite fields; parallel via butterfly ops, core to polynomial operations in many schemes.
• Polynomial Evaluation and Matrix-Vector Multiplication: Computes polynomial values at points or matrix-vector products; high-throughput on GPU shaders via SIMD parallelism.
• Merkle Tree Commitments: Builds hashed tree structures for efficient verification; parallel-friendly for batch processing and hashing.

Additionally, building blocks in interactive oracle proofs (IOPs), such as the sumcheck protocol ⁹, which reduces multivariate polynomial sums to univariate checks, benefit from massive parallelism in tasks such as summing large datasets or verifying constraints. While promising for GPU acceleration in schemes like WHIR ¹⁰ or GKR-based systems ¹¹, sumcheck is not currently the primary bottleneck in most polynomial commitment schemes (PCS).

These primitives map directly to bottlenecks in popular PCS, as shown in the table below.

Table 1: ZK primitives mapped to PCS bottlenecks and GPU potential

Moreover, VOLE-based ZK proving systems, such as QuickSilver ²⁰, Wolverine ²¹, and Mac'n'Cheese ²², utilize vector oblivious linear evaluation (VOLE) to construct efficient homomorphic commitments. These act as PCS based on symmetric cryptography or learning parity with noise (LPN) assumptions. The systems are post-quantum secure. Their main prover bottlenecks are VOLE extensions, hashing, and linear operations, which make them well-suited for GPU acceleration through parallel correlation generation and batch processing.

In the short term, primitives related to ECC (e.g. MSM in pairing-based schemes) are suitable for accelerating existing, well-adopted proving systems like Groth16 or those using KZG commitments, providing immediate performance gains for current Ethereum applications.

Quantum preparedness adds urgency for the long term: schemes on smaller fields (e.g. 31-bit fields like Mersenne 31, Baby Bear, or Koala Bear ²³) align better with GPU native words (32-bit), yielding higher throughput. Field-Ops Benchmarks ⁴ confirm this. Under the same settings (not optimal for max performance but for fairness of experiment), smaller fields like M31 achieve over 100 Gops/s on client GPUs, compared to <1 Gops/s for larger ones like BN254.

As quantum tech advances, exploration related to PQ primitives (e.g. lattice-based or hash-based operations) will drive mid-to-long-term client-side proving advancements, ensuring resilience against quantum threats like "Harvest Now, Decrypt Later" (HNDL) attacks, as mentioned in the Federal Reserve HNDL Paper and underscored by the Ethereum Foundation's long-term quantum strategy, which is a critical factor if we are going to defend people's privacy on a daily-life scale.

3. Challenges: Bridging the Gap to Everyday Privacy​

Despite progress, some hurdles remain between the current status and everyday usability.

3.1 Fragmented Implementation​

• No standard crypto library exists for client-side GPUs, forcing developers to reinvent wheels from scratch, which is often not fully optimized.
• Lack of State-of-the-Art (SoTA) references for new explorations, leading to duplicated efforts.
• Inconsistent benchmarking: metrics like performance, I/O overhead, peak memory, and thermal/power traces are rarely standardized, complicating comparisons. Luckily, PSE's client-side proving team is improving this ⁵.

3.2 Limited Quantum-Resistant Support​

Most GPU accelerations have focused on PCS related to elliptic-curve cryptography (ECC) like IPA, Hyrax, and KZG (pairing-based). All are vulnerable to quantum attacks via Shor's algorithm. These operate on larger fields (e.g. 254-bit), inefficient for GPUs' 32-bit native operations, and schemes like Groth16 face theoretical acceleration upper bounds, as analyzed in Ingonyama's blog post on hardware acceleration for ZKP ²⁴. On the other hand, PQ schemes such as those based on lattices or hashes (e.g. FRI variants) are underexplored on client GPUs but offer greater parallelism.

3.3 Device-Specific Constraints​

Client devices differ vastly from servers: limited resources, shared GPU duties (e.g. graphics rendering), and thermal risks. Blindly offloading to GPUs can cause crashes or battery drain ^{25 26}. Hybrid CPU-GPU approaches, inspired by Vitalik's Glue and Coprocessor architecture, need further exploration. Key unknowns include:

• Task dispatching hyperparameters.
• Caching in unified memory. Check Ingonyama's Metal PoC for zero-cost CPU-GPU transfers.
• Balancing operations: GPUs for parallelism, CPUs for sequential tasks.

Apple GPUs have the unified memory model in which the CPU and the GPU share system memory

4. PSE's Roadmap for GPU Acceleration​

To achieve client-side GPU acceleration's full potential, we propose a structured roadmap focused on collaboration and sustainability:

1. Build Standard Cryptography GPU Libraries for ZK

   • Mirror Arkworks's success in Rust zkSNARKs: Create modular, reusable libs optimized for client GPUs (e.g. low RAM, sustained performance) ²⁷.
   • Prioritize PQ foundations to enable HNDL-resistant solutions. For example, lattice-based primitives like NTT that scale with GPU parallelism ²⁸.
   • Make it community-owned, involving Ethereum, ZK, and privacy ecosystems for joint development, accelerating iteration and adoption in projects like mobile digital wallets.

2. Develop Best-Practice References

   • Integrate GPU acceleration into client-side suitable protocols, including at least one PQ scheme and mainstream ones like Plonky3 ²⁹ or Jolt ³⁰.
   • Optimize for mobile, tuning for sustained performance over peaks and avoiding thermal throttling via hybrid CPU-GPU coordination.
   • Create demo protocols as end-to-end references running on real devices with GPU boosts, serving as "how-to" guides for adopting standard libs.

This path transitions from siloed projects to ecosystem-wide tools, paving the way for explorations in sections like our starting points below.

5. Starting Points​

zkSecurity's WebGPU overview highlights its constraints versus native APIs like Metal or Vulkan. For example, limited integer support and abstraction overheads.

To validate, a PoC was conducted to compare field operations (M31 vs. BN254) across APIs ⁴. Key findings:

• u64 Emulation Overhead: Metal's native 64-bit support edges WebGPU (1.26x slower due to u32 emulation), compounding on complex ops.
• Field Size vs. Throughput: Smaller fields shine. M31 hits 100+ Gops/s; BN254 <1 Gops/s (favoring PQ schemes).
• Complexity Amplifies Gaps: Simple u32 ops show parity (1.06x); advanced arithmetic like Montgomery multiplication widens to 7x for BN254.

Start with native APIs first, such as Metal for iOS (sustainable boosts), then WebGPU for cross-platform reach. This prioritizes real-world viability over premature optimization.

6. Conclusion​

Client-side GPU acceleration for ZKPs represents both immediate and long-term opportunities for Ethereum privacy, potentially improving UX for adopting privacy-preserving tech and enabling quantum-secure daily-life use cases like private payments. By addressing fragmentation, embracing PQ schemes, and optimizing for mobile devices, we can make privacy "hygiene" for everyone (from casual users to privacy-maximalists). We believe that with collaborative efforts from existing players and the broader community, everyday Ethereum privacy is within reach.

This progress was also showcased at DevConnect, where we presented Mopro’s approach to mobile proving and shared real-world learnings from building and deploying zk applications on mobile. You can watch the full talk.

The following milestones highlight what we accomplished.

Mobile SDK Management Solution​

We realized that for most zk protocol developers, building a full frontend is not essential—especially when the goal is to demonstrate a proof of concept or integrate the protocol into an existing product. What is essential, however, is a reliable and easy-to-use SDK.

To address this, we built reusable templates with Mopro bindings that can be integrated with minimal mobile development experience. These templates are designed to be easily extended into SDKs for multiple platforms, enabling zk protocol teams—such as zkEmail, Semaphore, and others—to focus on protocol design rather than frontend or mobile engineering.

Our approach is inspired by the Reclaim Protocol philosophy: a protocol should support as many platform SDKs as possible to unlock a broader range of applications and products.

Expanded FFI Support​

Although UniFFI provides a robust foundation for Rust FFI, it still requires manual effort to integrate with modern cross-platform frameworks such as Flutter and React Native. This added complexity can be a barrier for mobile developers.

In 2025, we streamlined this process by integrating multi-platform FFI generation into mopro-ffi. Today, Mopro can automatically generate bindings for Swift, Kotlin, Flutter (with flutter_rust_bridge), React Native (with uniffi-bindgen-react-native), and WebAssembly (with wasm-bindgen), eliminating the need to maintain platform-specific glue code. Developers define their interfaces once in Rust, and Mopro handles the rest.

Noir Support​

Alongside our existing support for Circom and Halo2, we integrated Noir into Mopro in 2025, recognizing its growing adoption as a frontend language for zero-knowledge circuits. Inspired by the zkPassport team, we enabled mobile proving and verification for Noir-based circuits.

Throughout the year, we participated in multiple NoirHack events and NoirCon, where we built Stealthnote Mobile, achieving up to 10× faster performance than the browser version and a superior user experience. We also released an example demonstrating how Noir proofs can be verified on-chain.

Hackathon Projects​

Throughout 2025, we participated in several hackathons and received over 50 project submissions built with Mopro. Below are a selection of standout projects developed this year.

Zuma​

Anonymous Event Attendance

ETHGlobal Trifecta — Zero Knowledge

• GitHub: https://github.com/chengggkk/zuma
• Submission: https://ethglobal.com/showcase/zuma-6vnoj

Zuma is a ZK-powered Luma-style application, inspired by Luma and Zupass. It combines the seamless user experience of native event apps with the strong privacy guarantees of zero-knowledge proofs.

When a user attends an event, the app generates a Semaphore proof to attest to attendance. Verifiers only need to validate the proof to confirm that the user is an attendee—without learning any personal information such as the user’s email address or name.

Stealthnote Mobile​

Glassdoor-Style Anonymous Forum

NoirHack 2025

• GitHub: https://github.com/vivianjeng/stealthnote-mobile

Stealthnote Mobile is inspired by stealthnote.xyz and demonstrates that Noir proofs can be generated and verified directly on mobile devices. Compared to the browser-based implementation, the mobile app achieves up to 10× faster performance.

While the browser version takes approximately 20 seconds to generate a Google OAuth proof, the mobile app completes the same operation in about 2 seconds, resulting in a significantly improved user experience. In the future, the app could integrate push notifications to notify users when new posts are available.

MobiScale​

Privacy-Preserving AI Biometric Verification with zkVM on Mobile

ETHGlobal Cannes 2025

• GitHub: https://github.com/ElusAegis/MobiScale
• Submission: https://ethglobal.com/showcase/mobiscale-n9vj6

Mobiscale represents a major technical milestone for Mopro, showcasing how mobile hardware can enable zkVMs on smartphones. The project combines AI-powered facial recognition with Apple’s Secure Enclave to verify identity in a privacy-preserving way.

Users upload a passport photo and take a live selfie, which are compared locally by an AI model to establish identity with high confidence. The system then generates zero-knowledge proofs using RISC Zero and Noir circuits, allowing third parties to verify identity claims without accessing biometric data, confidence scores, or image hashes.

ZeroSurf​

Seamless Browser-to-Mobile ZK Age Verification

ETHGlobal New Delhi 2025

• GitHub: https://github.com/Krane-Apps/zerosurf-anon-aadhaar
• Submission: https://ethglobal.com/showcase/zerosurf-9988k

ZeroSurf demonstrates a highly smooth user experience between browser applications and mobile native apps through deep linking. When accessing a website with age restrictions, users are redirected via a URL to a mobile app, where a zero-knowledge proof (in this case, an Anon Aadhaar proof) is generated.

The proof is then returned to the website, enabling verification without exposing sensitive information. This project expands the use cases for mobile-native provers and shows how browser-based applications can directly benefit from mobile zero-knowledge proving.

Future Direction​

In 2026, we propose the following direction for the community. While Mopro handles the FFI layer and ensures that proving systems work reliably across platforms, we also want to raise awareness that reaching users on different platforms requires more than just cross-platform compatibility.

To truly enable adoption, zk protocol developers should provide platform-specific SDKs that can be easily consumed by application developers on iOS, Android, web, and beyond. By offering well-designed SDKs tailored to each platform’s ecosystem, zk applications can achieve broader reach, better user experience, and faster integration across diverse platforms.

As for the Mopro team, we plan to collaborate with more projects to help them build and ship their protocol SDKs. We will continue exploring zkVMs on mobile and advancing client-side GPU research across different proving systems.

In addition, we aim to engage more deeply with mobile development communities and events, promoting the adoption of zero-knowledge proofs in real-world mobile applications.

Conclusion​

2025 was a milestone year for Mopro, proving that mobile zk is not only possible, but practical and accessible. As we move into 2026, we’re excited to keep pushing the boundaries of mobile proving and work closely with the community to bring zero-knowledge to more platforms and applications.

Several submissions exceeded expectations with standout UX features. Deeplink integration enables seamless transitions between mobile apps and browsers, allowing native mobile proving across existing browser applications that require ZK (like age verification for websites). NFC integration demonstrated tap-to-prove and tap-to-verify capabilities, creating an experience as intuitive as Apple Pay. These implementations show the maturity of client-side ZK proving and its readiness for real-world adoption.

Infrastructure Track: Client-Side Privacy​

🏆 Grand Prize: AccessFI​

View Project | GitHub

AccessFI reimagines event payments with NFC-powered privacy. Users receive P-256 compatible SECP256k1 NFC cards linked to their wallets, enabling instant tap-to-pay for tickets, registration, food, and merchandise while preserving privacy through deterministic encryption.

The system eliminates payment friction with 5-second NFC transactions that work on any EVM chain. Privacy is maintained through ZK proofs that verify user eligibility without exposing personal data. A single card handles all event interactions: tap-to-buy tickets, tap-to-register, tap-to-pay for concessions.

Application Track: General Privacy​

🥇 First Prize: zkETHer​

View Project | GitHub

zkETHer implements a privacy-preserving protocol for ERC20 tokens, functioning as a non-custodial mixer. Users deposit fixed amounts by submitting cryptographic commitments to an on-chain Merkle tree, then withdraw to new addresses using ZK proofs generated on their mobile devices.

The protocol uses X25519 (ECDH) for key exchange, HKDF-SHA256 for deriving secrets, and Poseidon2 hash for commitments. Mopro enables computationally intensive ZK proofs to be generated directly on phones, making privacy accessible without specialized hardware.

The circuit implementation is robust, though real-world feasibility needs improvement for production deployment. The architecture demonstrates how mobile-first proving can bring mixer-style privacy to standard ERC20 tokens.

🥈 Second Prize: Wisk​

View Project | GitHub

Wisk rethinks background verification for the digital age with zkPDF. Instead of sharing documents with third parties, users prove specific claims about government-issued certificates without revealing the full content.

The system integrates with India's DigiLocker to verify official PDFs. Using zkPDF, Wisk validates the government's digital signature embedded in PDFs and generates ZKPs for requested fields (name, PAN number, credentials). The entire process happens in the browser—raw documents never leave the user's device.

🥉 Third Prize: ZeroSurf​

View Project | GitHub

ZeroSurf is a mobile browser with built-in ZK age verification using Anon Aadhaar. The smooth deeplink integration allows users to prove age requirements without revealing birth dates, enabling privacy-preserving access to age-restricted content.

The implementation showcases how deeplinks can bridge mobile browsers and ZK proving apps, creating frictionless user experiences for privacy-preserving authentication.

Key Takeaways & Future Explorations​

The hackathon revealed several promising directions for client-side privacy:

UX innovations like NFC and deeplinks proved that privacy-preserving technology can match the convenience of traditional systems. These features should be modularized within Mopro to improve developer experience. We'll invite teams that built these integrations to contribute reusable components.

Photo-identity integrity emerged as a recurring theme across multiple projects, adding security layers to identity verification. Integrating solutions like Rarimo's Bionetta and zkCamera with mobile-native proving through Mopro could strengthen this approach.

We're excited to see more UX innovations emerge in future hackathons. Whether it's tap-to-prove bringing native mobile experiences, smooth deeplink transitions between apps and browsers, or entirely new interaction patterns—the goal is providing developers with easy-to-use building blocks. By modularizing these patterns in Mopro, we can transform what took teams days to build during the hackathon into features that take minutes to integrate.

Beyond these UX enhancements, there are also two fundamental challenges worth exploring:

zkTLS and Mobile Proving​

zkTLS enables portable, verifiable data from any HTTPS connection without server cooperation. Using multi-party computation (MPC), zkTLS allows users to prove statements about web data—like account balances, transaction histories, or credentials—without revealing the underlying information or requiring platform APIs.

TLSNotary leads the MPC-based approach, using garbled circuits to split TLS session keys between users and notaries, ensuring neither party can forge proofs alone. This creates portable proofs of web data while preserving privacy.

Mobile integration remains an open challenge. While TLSNotary works well on desktop, coordinating MPC between mobile apps and browsers presents unique technical hurdles. Solving this would unlock powerful use cases: proving income from banking apps, verifying social media reputation, or demonstrating transaction history—all without sharing credentials or raw data.

Unified ZK Registry System​

The ZK identity landscape is fragmented. Projects like Anon Aadhaar, passport-based zkID solutions, and zkPDF each maintain separate on-chain registries. Users face redundant verifications, and developers must integrate with each system independently.

ERC-7812 proposes a solution: a singleton on-chain registry using Sparse Merkle Trees to store commitments to private data. Statements can be verified via ZK proofs without revealing underlying information.

With unified client libraries built around ERC-7812 and integrated with Mopro, developers would call one API after generating proofs on-device, regardless of proof type. The real power emerges in cross-application identity: a user proves their age once with Anon Aadhaar in one Mopro app, committing to ERC-7812. Later, a Mopro app using different schemes verifies that commitment without re-proving. The unified registry enables seamless credential reuse across the mobile applications while preserving privacy.

With innovative submissions ranging from protocol-level integrations to consumer-facing applications, Mopro track showed how mobile ZK proving is becoming increasingly practical. Teams leveraged Mopro's mobile proving capabilities to build everything from tamper-proof media verification to post-quantum secure smart accounts with EIP-7702, proving that privacy-preserving technology can be both powerful and user-friendly.

The Power of Client-Side Proving​

Before diving into the winners, it's worth highlighting what made this hackathon special. While many ZK applications rely on server-side proving or trusted execution environments (TEEs), Mopro enables developers to generate zero-knowledge proofs directly on mobile devices. This approach puts privacy control back in users' hands and opens up new possibilities for decentralized applications.

The submissions demonstrated two key trends: protocol developers integrating zkVM such as RISC-0 and libraries like Gnark with Mopro, and application developers building user-facing products that leverage existing ZK circuits. Both approaches are critical for the ecosystem's growth.

The Winners​

🥇 First Place: Mobiscale - Photo-ID Verification with Apple's Secure Enclave​

Project: Mobiscale
GitHub: ElusAegis/MobiScale

Mobiscale achieved what many thought impossible in a hackathon setting: a complete end-to-end proof of photo-ID verification running entirely on a mobile device in under 90 seconds. The team cleverly combined Apple's Secure Enclave for facial recognition, RISC-0 for TEE attestation verification, and Noir with the Barretenberg proving backend for ECDSA signature validation.

What makes this project remarkable is its practical approach to identity verification. By computing cosine similarity between a passport photo and a live selfie within the TEE, then proving this computation happened correctly using ZK proofs, Mobiscale demonstrates a privacy-preserving liveness check that could be deployed in the near future. The integration with Mopro shows how mobile proving can complement hardware security features to create robust identity solutions.

🥈 Second Place: Zkipper - PQ-Secure EIP-7702 Smart Accounts​

Project: Zkipper
GitHub: ZKNoxHQ/ZKipper

The ZKNox team showcased their cryptographic expertise at the hackathon with "Zkipper," a project that turns the ARX chips in ETHGlobal wristbands into transaction signers, enabling post‑quantum–secure smart accounts via EIP‑7702.

The technical achievement here is twofold: First, they successfully integrated Gnark with Mopro within the 36-hour timeframe, which is a significant contribution to the ecosystem. Second, they implemented Falcon512 post-quantum signatures to secure smart accounts, preventing "Bybit-style" attacks by separating admin commands onto distinct devices. This approach shows how Mopro can enable hardware-based security solutions that are both quantum-resistant and user-friendly.

🥉 Third Place: 👀Proov! - Tamper-Proof Media with ZK​

Project: 👀Proov!
GitHub: undefinedlab/PROOV_ZK

👀Proov! stood out not just for its technical implementation but for its exceptional UI/UX design. The team created a complete solution for tamper-proof media capsules, combining Mopro-generated proofs with AI-powered image summaries, decentralized storage on Walrus, and verification on Flow blockchain.

The project offers one-tap proof generation with instant cryptographic capsule creation, selective privacy controls, and future-disclosure capabilities. By embedding tamper-proof QR codes in image capsules, they made every photo machine-verifiable and portable across platforms like Instagram, X, and Telegram. This shows how ZKP can be packaged into consumer-friendly applications without sacrificing security or privacy.

Other Notable Submissions​

Beyond the top three winners, the Mopro track at ETHGlobal Cannes attracted submissions that collectively show the diversity of ZK use cases on mobile. Teams explored verification and attestation use cases through projects like ProofOfParticipation (GPS-based event attendance), ZKAge Proof Mobile (age verification for restricted services). Bidet's privacy-preserving NFC tag game showcased gaming and social use cases, and ProofOfFunds showed financial privacy by letting users prove they meet a cryptocurrency balance threshold without disclosing exact amounts or wallet addresses.

These submissions integrated various technical stacks across different proving frameworks—Circom and Noir—and mobile platforms—Swift (iOS), Kotlin (Android), React Native, and Flutter—alongside Mopro’s proving capabilities. This integration validates the platform’s flexibility across use cases and tech stacks. The diversity of both applications and technical aspect highlights the ecosystem’s readiness for real-world deployment and shows how mobile proving can address privacy challenges across multiple industries.

Key Insights and Developer Feedback​

The hackathon provided valuable insights into the state of mobile ZK proving:

What's Working Well:

• Mopro's developer experience received consistently positive feedback
• Teams successfully integrated various proving systems (RISC-0, Noir, Gnark) with Mopro
• The ecosystem is mature enough for developers to build meaningful applications in 36 hours

Challenges Identified:

• Writing circuits remains the biggest pain point for developers
• On-chain verification varies in stability (Circom is more mature, Noir is catching up)
• Developers need single-architecture templates for iOS-only or Android-only builds

Looking Forward: The Future of Client-Side Proving​

The diversity of submissions—from geo-proof games adapted from zkVerify's proof-of-geolocation circuits to age verification systems—shows that mobile ZK proving is ready for mainstream adoption. While Mopro may not pursue the same level of direct adoption as protocols aimed at end users, it serves a critical role as an incubation platform for client-side ZK applications especially on mobile phone.

Based on developer feedback, we're prioritizing several improvements:

• Enhanced Templates - Expanding variety for different use cases (Issue #503, Issue #438)
• Single Architecture Support - iOS-only and Android-only bindings for cross-platform frameworks like Flutter (Issue #502) and React Native (Issue #501).
• Improved DevEx - Better naming for custom bindings (Issue #500)
• Documentation - Simplified architecture overview (Issue #498)

Acknowledgments​

We'd like to thank all teams who participated in the Mopro track at ETHGlobal Cannes. Your innovation, dedication, and feedback are invaluable in advancing the state of mobile proving.

Special recognition goes to the ETHGlobal team for organizing an exceptional event and providing the infrastructure that makes these innovations possible.

Get Involved​

The work showcased at ETHGlobal Cannes is just the beginning. If you're interested in building with Mopro or contributing to the ecosystem:

• Explore the Mopro documentation
• Check out the project gallery for inspiration
• Join the community discussions on Telegram and contribute to the open issues

• Hybrid CPU-GPU approaches are essential for fully exploiting limited hardware such as mobile devices, improving MSM computation and accelerating proof generation.
• To unify GPU acceleration efforts, WebGPU's vendor-agnostic API and WGSL offer promising solutions that compile to native formats like SPIR-V (for Vulkan on Android) and MSL (for Metal on Apple devices).
• GPU acceleration for post-quantum proving systems could enable their widespread adoption.

Introduction​

GPU acceleration harnesses the massive parallelism of Graphics Processing Units (GPUs) to dramatically speed up tasks that would otherwise overwhelm traditional CPUs. Because GPUs can execute thousands of threads simultaneously, they have become indispensable for compute-intensive workloads such as machine-learning model training and modern cryptographic algorithms.

This technology plays a crucial role in advancing privacy-preserving applications, as zero-knowledge proofs (ZKPs) currently face a significant bottleneck due to the high computational cost of their core operations. By accelerating these operations, we can generate proofs more quickly and cost-effectively, which is essential for the broader adoption of privacy-focused solutions across Ethereum and other blockchain platforms.

Currently, research on GPU acceleration for cryptography remains fragmented, with each platform relying on its own framework: Metal on Apple devices, Vulkan on Android, and CUDA on NVIDIA hardware. Aside from CUDA, most GPU frameworks lack mature ecosystems of cryptographic libraries (e.g., NVIDIA's cuPQC and cuFFT).

Therefore, Mopro is investing in GPU acceleration through related grants (Issue #21, Issue #22, and Issue #153), as it advances our mission to make mobile proving both accessible and practical.

A Primer on Multi-Scalar Multiplication​

Multi-Scalar Multiplication (MSM) is an essential primitive in elliptic curve cryptography, particularly in pairing-based proving systems widely used for privacy-preserving applications. MSM involves computing a sum of the form $Q = \sum_{i=1}^{n}(k_i \cdot P_i)$, where $k_i$ are scalars and $P_i$ are points on an elliptic curve, such as BN254. This computationally intensive operation is ideal for GPU acceleration.

Metal MSM v2 is an open-source implementation, licensed under MIT and Apache 2.0, that optimizes MSM on Apple GPUs using the Metal Shading Language (MSL). Building on its predecessor, Metal MSM v2 offers significant performance improvements through algorithmic and GPU-specific optimizations, laying the foundation for further research into mobile proving acceleration with GPUs.

Recap on Metal MSM v1​

The first version of Metal MSM (v1) was an initial attempt to bring MSM computations on the BN254 curve to Apple GPUs, leveraging parallelism and optimizations like precomputation from the EdMSM paper by Bootle et al.¹. While it showed the potential for GPU acceleration, profiling result revealed key limitations:

• Low GPU Occupancy: At only 32%, the GPU was underutilized, leading to inefficient computation.
• High Memory Footprint: Peak VRAM usage was excessive, causing GPU hang errors on real mobile devices for instance sizes ≥ 2^14.
• Performance Bottlenecks: For an input size of 2^20 points, v1 took 41 seconds on an M1 Pro MacBook, indicating substantial room for improvement.

These challenges drove the development of a newer version, which introduces targeted optimizations to address these issues. For full context, refer to the detailed Metal MSM v1 Summary Report and Metal MSM v1 Profiling Report.

Metal MSM v2: What's New​

Metal MSM v2 introduces key enhancements over v1, significantly improving performance and resource efficiency. It adopts the sparse matrix approach from the cuZK paper by Lu et al.², treating MSM elements as sparse matrices to reduce memory usage and convert operations described in Pippenger's algorithm into efficient sparse matrix algorithms.

The implementation draws inspiration from Derei and Koh's WebGPU MSM implementation for ZPrize 2023. However, targeting the BN254 curve (unlike the BLS12-377 curve used by Zprize 2023) required different optimization strategies, particularly for Montgomery multiplications and for using Jacobian coordinates instead of projective or extended twisted Edwards coordinates.

Due to differences between shading languages (CUDA for cuZK, WGSL for WebGPU, and MSL for Metal), additional GPU programming efforts were necessary. For instance, dynamic kernel dispatching, which is straightforward in CUDA, required workarounds in Metal through host-side dispatching at runtime.

Key improvements include:

• Dynamic Workgroup Sizing: Workgroup sizes are adjusted based on input size and GPU architecture using a scale_factor and thread_execution_width. These parameters were optimized through experimentation to maximize GPU utilization as mentioned in PR #86.
• Dynamic Window Sizes: A window_size_optimizer calculates optimal window sizes using a cost function from the cuZK paper, with empirical adjustments for real devices, as detailed in PR #87.
• MSL-Level Optimizations: Loop unrolling and explicit access qualifiers, implemented in PR #88, enhance kernel efficiency, with potential for further gains via SIMD refactoring.

Benchmarks on an M3 MacBook Air with 24GB memory show 40x–100x improvements over v1 and ~10x improvement over ICME Labs' WebGPU MSM on BN254, adapted from Derei and Koh's BLS12-377 work. While still slower than CPU-only Arkworks MSM on small & medium input sizes, v2 lays the groundwork for a future CPU+GPU hybrid approach.

How Metal MSM v2 Works​

The general flow follows Koh's technical writeup. We pack affine points and scalars on the CPU into a locality-optimized byte format, upload them to the GPU, and encode points into Montgomery form for faster modular multiplications. Scalars are split into signed chunks to enable the Non-Adjacent Form (NAF) method, halving both bucket count and memory during accumulation.

Next, we apply a parallel sparse-matrix transposition (adapted from Wang et al.'s work³) to identify matching scalar chunks and group points into buckets. Then, using a sparse-matrix–vector product (SMVP) and the pBucketPointsReduction algorithm (Algorithm 4 in the cuZK paper²), we split buckets among GPU threads, compute each thread's running sum, and scale it by the required factor.

After GPU processing, we transfer each thread's partial sums back to the CPU for final aggregation. Since the remaining point count is small and Horner's Method is sequential and efficient on the CPU, we perform the final sum there.

The use of sparse matrices is a key innovation in Metal MSM v2, reducing memory requirements and boosting parallelism compared to previous approaches.

Understanding the Theoretical Acceleration Upper Bound​

In the Groth16 proving system, Number Theoretic Transform (NTT) and MSM account for 70–80% of the proving time. According to Amdahl's Law, the maximum speedup is limited by unoptimized components:

$\text{Speedup}_{\text{overall}} = \dfrac{1}{(1 - \text{time}_{\text{optimized}}) + \dfrac{\text{time}_{\text{optimized}}}{\text{speedup}_{\text{optimized}}}}$

If 80% of the prover time is optimized with infinite speedup, the theoretical maximum is 5x. However, data I/O overhead reduces practical gains. For more details, see Ingonyama's blog post on Hardware Acceleration for ZKP.

Benchmark Results​

Benchmarks conducted on an M3 MacBook Air compare Metal MSM v2 with the Arkworks v0.4.x CPU implementation across various input sizes.

Negative values indicate slower performance relative to the CPU baseline. The performance gap narrows for larger inputs.

Notes:

• For ICME WebGPU MSM, input size 2^12 causes M3 chip machines to crash; sizes not listed on the project's GitHub page are shown as "N/A"
• For Metal MSM v0.1.0, the 2^24 benchmark was abandoned due to excessive runtime.

While Metal MSM v2 isn't faster than CPUs across all hardware configurations, its open-source nature, competitive performance relative to other GPU implementations, and ongoing improvements position it well for continued advancement.

Profiling Insights​

Profiling on an M1 Pro MacBook provides detailed insights into the improvements from v1 to v2:

These metrics highlight the effectiveness of v2's optimizations:

• Latency Reduction: A 24-fold decrease in computation time for 2^20 inputs.
• Improved GPU Utilization: Occupancy increased from 32% to 76%, indicating better use of GPU resources.
• Reduced CPU Dependency: CPU share dropped below 3%, allowing the GPU to handle most of the workload.
• Lower Memory Footprint: Peak VRAM usage decreased from 1.6 GB to 220 MB, a 7.3-fold reduction.

Profiling also identified buffer reading throughput as a primary bottleneck in v1, which v2 mitigates through better workload distribution and sparse matrix techniques. See detailed profiling reports: v1 Profiling Report and v2 Profiling Report.

Comparison to Other Implementations​

Metal MSM v2 is tailored for Apple's Metal API, setting it apart from other GPU-accelerated MSM implementations:

• Derei and Koh's WebGPU MSM on BLS12: Designed for WebGPU, this implementation targets browser-based environments and may not fully leverage Apple-specific hardware optimizations.
• ICME labs WebGPU MSM on BN254: Adapted from Derei and Koh's WebGPU work for the BN254 curve, it is ~10x slower than Metal MSM v2 for inputs from 2^16 to 2^20 on M3 MacBook Air.
• cuZK: A CUDA-based implementation for NVIDIA GPUs, operating on a different hardware ecosystem and using different algorithmic approaches.

Metal MSM v2's use of sparse matrices and dynamic workgroup sizing provides advantages on Apple hardware, particularly for large input sizes. While direct benchmark comparisons are limited, internal reports suggest that v2 achieves performance on par with or better than other WebGPU/Metal MSM implementations at medium scales.

It's worth noting that the state-of-the-art Metal MSM implementation is Ingonyama's ICICLE-Metal (since ICICLE v3.6). Readers can try it by following:

• ICICLE Rust MSM example
• Experimental BN254 Metal benchmark

Another highlight is ElusAegis' Metal MSM implementation for BN254, which was forked from version 1 of Metal MSM. To the best of our knowledge, his pure GPU implementation further improves the allocation and algorithmic structure to add more parallelism, resulting in 2x faster performance compared to Metal MSM v2.

Moreover, by integrating this GPU implementation with optimized MSM on the CPU side from the halo2curves library, he developed a hybrid approach that splits MSM tasks between CPU and GPU and then aggregates the results. This strategy achieves an additional 30–40% speedup over a CPU-only implementation. This represents an encouraging result for GPU acceleration in pairing-based ZK systems and suggests a promising direction for Metal MSM v3.

Future Work​

The Metal MSM team has outlined several exciting directions for future development:

• SIMD Refactoring: Enhance SIMD utilization and memory coalescing to further boost performance.
• Advanced Hybrid Approach: Integrate with Arkworks 0.5 for a more sophisticated CPU-GPU hybrid strategy.
• Android Support: Port kernels to Vulkan compute/WebGPU on Android, targeting Qualcomm Adreno (e.g., Adreno 7xx series) and ARM Mali (e.g., G77/G78/G710) GPUs.
• Cross-Platform Support: Explore WebGPU compatibility to enable broader platform support.
• Dependency Updates: Transition to newer versions of objc2 and objc2-metal, and Metal 4 to leverage the latest MTLTensor features, enabling multi-dimensional data to be passed to the GPU.

Beyond these technical improvements, we are also interested in:

• Exploration of PQ proving schemes: With the limited acceleration achievable from pairing-based proving schemes, we're motivated to explore PQ-safe proving schemes that have strong adoption potential over the next 3–5 years. These schemes, such as lattice-based proofs, involve extensive linear algebra operations that can benefit from GPUs' parallel computing capabilities.
• Crypto Math Library for GPU: Develop comprehensive libraries for cryptographic computations across multiple GPU frameworks, including Metal, Vulkan, and WebGPU, to expand the project's overall scope and impact.

Conclusion​

Metal MSM v2 represents a leap forward in accelerating Multi-Scalar Multiplication on Apple GPUs. By addressing the limitations of v1 through sparse matrix techniques, dynamic thread management, and other novel optimization techniques, it achieves substantial performance gains for Apple M-series chips and iPhones.

However, two challenges remain:

• First, GPUs excel primarily with large input sizes (typically around 2^26 or larger). Most mobile proving scenarios use smaller circuit sizes, generally ranging from 2^16 to 2^20, which limits the GPU's ability to fully leverage its parallelism. Therefore, optimizing GPU performance for these smaller workloads remains a key area for improvement.
• Second, mobile GPUs inherently possess fewer cores and comparatively lower processing power than their desktop counterparts, constraining achievable performance. This hardware limitation necessitates further research into hybrid approaches and optimization techniques to maximize memory efficiency and power efficiency within the constraints of mobile devices.

Addressing these challenges will require ongoing algorithmic breakthroughs, hardware optimizations, and seamless CPU–GPU integration. Collectively, these efforts pave a clear path for future research and practical advancements that enable the mass adoption of privacy-preserving applications.

Get Involved​

We welcome researchers and developers interested in GPU acceleration, cryptographic computations, or programmable cryptography to join our efforts:

• GPU Exploration Repository (latest version includes Metal MSM v2)
• Mopro (Mobile Proving)

For further inquiries or collaborations, feel free to reach out through the project's GitHub discussions or directly via our Mopro community on Telegram.

Special Thanks​

We extend our sincere gratitude to Yaroslav Yashin, Artem Grigor, and Wei Jie Koh for reviewing this post and for their valuable contributions that made it all possible.

Noir has been gaining significant traction recently, and for good reason. It's renowned for its elegant circuit frontend design and high-performance backend. With robust SDKs that make building web-based zero-knowledge apps seamless—and the ability to verify proofs on-chain—Noir stands out as a powerful and promising framework for developing modern ZKP applications.

However, while Noir offers strong support for web-based applications, native mobile support is still limited within the ecosystem. Most existing resources for mobile development have been contributed by the zkPassport team, including key projects like

• noir_rs
• Swoir
• noir_android.
• noir-react-native-starter

Our work is deeply inspired by the zkPassport team’s contributions, but builds upon them with significant improvements and optimizations.

In this article, we’ll walk through how we integrated Noir into the Mopro project, highlighting the key challenges we faced and the opportunities we uncovered along the way. We'll also introduce Stealthnote Mobile, a fully native mobile application built with Noir, to demonstrate the potential and performance of running zero-knowledge proofs natively on mobile devices.

Build noir-rs​

Like many apps with Mopro, our journey began with building a Rust crate. We started by adopting noir_rs from the zkPassport team. However, we quickly ran into some major challenges: compiling the Barretenberg backend — the proving system used by most Noir projects — could take up to 20 minutes. On top of that, the build process required a very specific developer environment, and lacked caching, meaning the entire binary had to be rebuilt from scratch even after a successful build.

To address these issues, we introduced a solution in

• noir-rs: https://github.com/zkmopro/noir-rs

by prebuilding the backend binaries and hosting them on a server. During the build process, these binaries are downloaded automatically, eliminating the need for local compilation. This approach drastically reduces build time—from 20 minutes to just 8 seconds—and removes the need for any special environment setup. In fact, you can see from our GitHub Actions YAML file that no additional dependencies are required.

Suggestions​

Currently, the build process for the backend happens locally, which makes it non-reproducible and difficult to upgrade in CI environments like GitHub Actions. To improve this, we believe the build logic should be moved into CI. However, this process is quite complex and largely duplicated across repositories like the Noir and Aztec packages (See: publish-bb.yml).

Our proposal is that the Noir and Aztec teams consolidate this effort by building libbarretenberg.a within the same CI pipeline and releasing them. Since bb depends on these static libraries, they would naturally be compiled as part of that process. These prebuilt artifacts could then be published alongside the bb binary. This would allow downstream consumers like noir-rs to directly use the published binaries, eliminating the need to maintain custom build scripts or host binaries separately.

void acir_prove_ultra_honk(uint8_t const* acir_vec,
                           bool const* recursive,
                           uint8_t const* witness_vec,
                           uint8_t** out)

Go Mobile-Native​

Once we have the Rust crate ready, integrating it into a Mopro project allows us to easily generate bindings for both iOS and Android. Mopro significantly improves the mobile integration experience in the following ways:

1. No additional Swift or Kotlin bindings required

   Unlike the zkPassport team's approach—where they built separate Swoir and noir_android libraries with custom domain-specific interfaces—Mopro leverages uniffi to automatically generate language bindings. This means developers don’t need to manually maintain Swift ¹ or Kotlin wrappers ²; they can directly import and use the generated bindings in their mobile codebases. e.g.

   For swift:

   import moproFFI
   
   let proofData = try! generateNoirProof(circuitPath: zkemailCircuitPath, srsPath: zkemailSrsPath, inputs: inputs)
   

   For kotlin:

   import uniffi.mopro.generateNoirProof
   
   let proofData = generateNoirProof(circuitFile, srsPath, inputs)
   

2. Framework-Agnostic Design

   Mopro is not tied to any specific mobile framework. By defining reusable templates for each target framework, developers are free to choose the environment they’re most comfortable with. Currently, Mopro supports native iOS (Xcode + Swift), native Android (Android Studio + Kotlin), as well as cross-platform frameworks like React Native and Flutter—offering maximum flexibility and accessibility for diverse developer needs.

Mopro Support​

We’ve successfully integrated Noir proving into both Mopro-FFI and the Mopro CLI. You can now install the Mopro CLI and follow the steps in the Getting Started guide to create a Noir project. Simply replace the SRS and circuit files with your own, and provide your custom circuit input — that’s it!

We’ve also provided an example zkEmail repository featuring a Noir circuit

• mopro-zkemail-nr: https://github.com/zkmopro/mopro-zkemail-nr

along with a NoirHack workshop video.

Feel free to explore the repo, clone it, and follow along to learn how to use Noir with Mopro in a real-world application.

Challenge: Cross-platform support is limited​

Our current implementation draws heavily from the zkPassport team’s work, which currently supports iOS devices and ARM64 Android devices/emulators. However, there are limitations: iOS simulators—essential for efficient development and testing—are not supported, and many Android developers (especially those using Windows with WSL) rely on x86_64 emulators. Even CI environments like GitHub Actions commonly use x86_64 Android emulators.

Expanding support to these platforms is a significant challenge. The barretenberg backend, written in C++ and built with CMake, is large and complex, making cross-compilation non-trivial. While we’re evaluating the effort required to support additional architectures, we’re also hopeful that the Noir or zkPassport teams may address this gap in the future.

Case Study: Stealthnote Mobile App​

During the NoirHack 2025 (April 14th to May 10th), the Mopro team participated by building a mobile-native Noir application. Our project was inspired by Stealthnote, originally created by Saleel. Stealthnote is a web-based app that allows users to sign in with Google OAuth and prove ownership of their organizational email address. It leverages a Noir circuit to generate a zero-knowledge proof from the JWT issued by Google OAuth. You can read more about the original project in Saleel’s blog post.

We aim to enhance performance and user experience by building a fully native mobile app. At the same time, we want to demonstrate that the current Mopro + Noir stack is fully capable of supporting mobile-native development. Therefore, we decided to build a mobile version of Stealthnote.

What We Built​

During the hackathon, we developed

• Stealthnote Mobile: https://github.com/vivianjeng/stealthnote-mobile
• Testflight for iOS: download
• Android APK: download

A mobile-native frontend for the original Stealthnote project. To maintain compatibility, we kept the original Noir circuits and backend logic intact, focusing entirely on building the mobile frontend. Even so, creating a mobile frontend involved tackling many challenges across platforms.

We chose Flutter as our cross-platform framework because of its fast build times compared to React Native and its rich ecosystem of packages for mobile functionalities—such as Google authentication, biometric login, camera access, gallery browsing, and file storage. In our view, Flutter is currently the best choice for building high-performance, cross-platform apps.

Our architecture separates responsibilities clearly:

• Flutter handles:

  1. UI/UX design
  2. Google OAuth authentication
  3. Backend API communication

• Rust handles:

  1. Parsing the JWT and converting it into the structured inputs required by the Noir circuit
  2. Generating and verifying Noir proofs
  3. Ephemeral key generation using Ed25519 and Poseidon2
     
  info

  To learn how to integrate Mopro Rust bindings into a Flutter project, please refer to the

  • Flutter Setup section
  • flutter-app example
  • mopro_flutter_package plugin example

This clear separation lets us leverage the strengths of both technologies—Flutter’s frontend speed and flexibility, and Rust’s performance and security for core cryptographic logic.

Benchmark​

While the Mopro team anticipated the outcome, the benchmark results are still notable: a mobile-native prover delivers performance up to 10 times faster than running the same proof in a browser environment.

Challenge: Insufficient Rust tooling and SDKs.​

One of the main challenges we faced was converting all the TypeScript functions used in StealthNote into their Rust equivalents. For standard cryptographic operations like Ed25519 signatures, this was relatively straightforward — Rust has mature libraries we could rely on.

However, Poseidon2 presented a bigger challenge. Unlike the original Poseidon hash, Poseidon2 is a newer variant used in the Noir circuits. Unfortunately, there was no direct Rust implementation available. The Noir team primarily supports a TypeScript version via bb.js, which is a wrapper around Barretenberg's C++ implementation compiled to WASM. This made it hard to fully understand the logic and port it to Rust.

Eventually, we located the Poseidon2 Noir circuit and its permutation logic in the noir-lang repository. Using that as a reference, we implemented our own version of

• poseidon2.rs in Rust: https://github.com/vivianjeng/stealthnote-mobile/blob/main/src/proof/poseidon2.rs

aligning it with the Noir circuit to ensure compatibility.

Suggestions​

Since Barretenberg already provides a C++ implementation for most Noir circuit functions, it would actually be more efficient and sustainable for the Noir or Aztec team to maintain a native C++ or Rust SDK for Rust developers — rather than focusing primarily on the JavaScript (bb.js) interface.

As we suggested earlier, an ideal solution would be for the team to publish precompiled static binaries (e.g. libbarretenberg.a) alongside versioned releases. This way, other developers — like us — could easily integrate these binaries into their Rust projects using proper FFI bindings.

This approach would remove the need for every developer to rebuild Barretenberg from source or maintain their own custom builds. For example, our bb.rs project demonstrates this idea, but it still lacks many of the standard library features available in bb.js, such as: poseidon2, blake2, AES encryption/decryption. Providing official support for these as native libraries would greatly improve the developer experience and adoption for building performant, mobile-native or server-side ZK applications.

Conclusion​

We began integrating Noir with Mopro in early April, and the process progressed smoothly — thanks in large part to the foundational work done by the zkPassport team. In contrast to our experience with the Circom prover (which took several months to make mobile-compatible), Noir integration was faster and more straightforward.

However, we also discovered significant gaps in Noir’s current support for mobile-native development. While the prover itself is crucial, a complete SDK ecosystem is equally important. At the moment, teams aiming to build mobile-native apps — like zkPassport — must develop many of the components from scratch, rather than being able to rely on official tooling or prebuilt libraries from the Noir team.

This raises a challenge: what if a project doesn’t have the expertise, time, or resources to build and maintain a mobile-native infrastructure? These barriers can prevent great ideas from becoming usable apps.

There’s still a long road ahead — for both the Mopro team and the Noir ecosystem — to provide a full suite of mobile-native infrastructure that can empower ZK developers, whether they're building the next zkPassport or an entirely new kind of app.

Finally, we want to encourage more developers to explore building mobile-native apps. These platforms offer better performance, deeper device integration, and more seamless user experiences — which are essential if you want your ZK project to truly reach users.

Contribution​

All kinds of contributions are welcome! 🎉

Feel free to check out the current issues on the Mopro GitHub repository, or open a new issue if you notice something missing or have ideas to improve the project.

Here are some current Noir-related issues worth exploring:

• [Noir] Download SRS script #423
• [Noir] separating proof bytes and public signals bytes #422
• [Noir] React native template update #410
• [Noir] Flutter template update #409

Feel free to reach out to the Mopro team on Telegram @zkmopro for questions or support, and follow us on X (formerly Twitter) @zkmopro to stay up to date with our latest progress!

For a long time, mobile proving has been tough for developers, especially with zero-knowledge proofs. Developers often spend more time running circuits on mobile than actually building them. A major factor for improving UX will be how quickly we can integrate these proving circuits into mobile apps.

Most mobile proving applications have historically used the Rapidsnark/Witnesscal setup, which is quite messy. It requires a good amount of app development experience, raising questions about how many code changes are needed compared to newer setups like Mopro.

In my past experience, it took me 15 days to figure out how to set up proving circuits on Android. One frustrating part of the Witnesscal/Rapidsnark setup is that you need to write native code for each platform. For binding functions in C++, you still have to write Java for Android and Objective-C for iOS. Recently, React Native has gotten some good updates with Turbo Repo architecture, which I thought could be a solution for this — https://hackmd.io/@0xvikasrushi/BJhNL6g_yl

Integration Time​

How long does it take for a developer to integrate and run a circuit on mobile?

• You still need to write some native code, but it’s minimal. Mopro’s unified Rust bindings are shipped via a Kotlin package, so it’s pretty much plug-and-play. For Android, it’s fairly simple — no need to write any C++ code. :)
• Developers should focus on writing circuits rather than building an SDK. I was happy to only need to spend 3–4 days putting together a basic SDK that can generate and verify proofs—no need for a fancy frontend.

Code Changes Required​

How many files need to be modified? Is the integration minimal or does it require significant changes?

• Previously, we had a cpp/ folder filled with obscure, hard-to-maintain code — two types of binding, different binaries for witness calculation, and a complicated setup process. Now, that’s all automated, and integration is much smoother.

Cross-Platform Support​

Does it require writing platform-specific code (e.g., Java for Android, Objective-C for iOS), or is it abstracted away?

• Yes, but only a very small amount of platform-specific code is needed.
• In this particular integration, we were able to go from 700 lines to less than 100 lines of actual code.
• These ~100 lines are native Kotlin logic used to bind native code to JavaScript, and the implementation is clean and generic enough.

Benchmark Performance​

How do Mopro’s binding benchmarks compare to implementations like Anon Aadhaar?

• There was approximately a ~7% improvement in Execution time

LOG  Mopro Execution time: 3957 milliseconds
LOG  Rapidsnark Execution time: 4220 milliseconds

Conclusion

All in all, integrating Mopro with Anon Aadhaar allowed for:

• Fast proving with latest bindings + RapidSnark: Uses modern proving setups under the hood, so things run fast and smooth.
• Easy to plug in, great dev experience: Just works out of the box. We didn’t have to fight the SDK—focus stayed on writing circuits.
• Cross-platform code: Local, browser, or cloud—same code works across all platforms.
• Less platform-specific code: Code is clean and portable—no hacks or infra-specific tweaks needed.
• Future scaling: Architecture is solid. Easy to grow, optimize, and plug into bigger systems.

TL; DR Mopro now ships pre-built native packages for Swift (iOS), Kotlin (Android), Flutter, and React Native.
Just one import and one build. Proving made simple!

Announcing Mopro Native Packages​

We're excited to launch Mopro native packages, enabling developers to effortlessly generate and verify zero-knowledge proofs (ZKPs) directly on mobile devices. These native packages leverage Rust's performance and seamlessly integrate with popular mobile frameworks. Built using the Mopro CLI, they're available for direct import via each platform's package manager.

You can also easily create your own customized native packages by following zkmopro-docs.

This blog provides a quick guide on integrating these packages into your projects, outlines how we built them (so you can customize your own), addresses challenges we overcame, and highlights future developments. Let's get started!

Import, Build, Prove - That's It​

Mopro's native packages simplify the integration process dramatically. Unlike the traditional approach that requires crafting APIs, generating bindings, and manually building app templates, these pre-built packages allow developers to import them directly via package managers and immediately begin developing application logic.

For ZK projects, converting your Rust-based solutions into mobile-native packages is straightforward with Mopro. Our guide on "How to Build the Package" explains the process clearly.

For instance, our zkEmail native packages were created by first defining ZK proving and verification APIs in Rust, generating bindings with mopro build, and embedding these into native packages. The circuit is the header-only proof from zkemail.nr_header_demo.

Here's how zkEmail performs on Apple M3 chips:

iOS

Android

Flutter App for iOS & Android zkEmail Example

Notice that, with Mopro and the use of Noir-rs, we port zkEmail into native packages while keeping the proof size align with Noir's Barretenberg backend CLI. It transfers the API logic directly to mobile platforms with no extra work or glue code needed!

How it worked before Mopro​

Previously, integrating ZKPs into mobile applications involved more manual work and platform-specific implementations. For example, developers might have used solutions like:

• Swoir: https://github.com/Swoir/Swoir/tree/main
• noir-android: https://github.com/madztheo/noir_android/tree/main

These approaches often required developers to handle bridging code and manage dependencies separately for each platform, unlike the streamlined process Mopro now offers.

With Mopro, developers can leverage pre-built native packages and import them directly via package managers. This, combined with automated binding generation, significantly reduces the need for manual API crafting and platform-specific glue code.

While developers still write their application logic using platform-specific languages, Mopro simplifies the integration of core ZK functionalities, especially when leveraging Rust's extensive cryptography ecosystem.

Under The Hood​

Developing native packages involved tackling several technical challenges to ensure smooth and efficient operation across different platforms.

This section dives into two key challenges we addressed:

1. Optimizing static library sizes for iOS to manage package distribution and download speeds.
2. Ensuring compatibility with Android's release mode to prevent runtime errors due to code shrinking.

Optimizing Static Library Sizes for iOS​

Why Static Linking?​

UniFFI exports Swift bindings as a static archive (libmopro_bindings.a). Static linking ensures all Rust symbols are available at link-time, simplifying Xcode integration. However, it bundles all Rust dependencies (Barretenberg Backend, rayon, big-integer math), resulting in larger archive sizes.

Baseline Size​

The full build creates an archive around ≈ 153 MB in size. When uploading files over 100 MB to GitHub, Git LFS takes over by replacing the file with a text pointer in the repository while storing the actual content on a remote server like GitHub.com. This setup can cause issues for package managers that try to fetch the package directly from a GitHub URL for a release publish.

While uploading large files may be acceptable for some package management platforms or remote servers like Cloudflare R2, the large file size slows down:

• CocoaPods or SwiftPM downloads
• CI cache recovery
• Cloning the repository, especially on slower connections

Our Solution: Zip & Unzip Strategy​

To keep development fast and responsive, we compress the entire MoproBindings.xcframework before uploading it to GitHub and publishing it to CocoaPods, reducing its size to about ≈ 41 MB.

We also found that by customizing script_phase in the .podspec (check our implementation in ZKEmailSwift.podspec), we can unzip the bindings during pod install. This gives us the best of both worlds: (1) smaller packages for distribution and (2) full compatibility with Xcode linking. The added CPU cost is minor compared to the time saved on downloads.

Comparison With Android​

On Android, dynamic .so libraries (around 22 MB in total) are used, with symbols loaded lazily at runtime to keep the package size small. In contrast, because iOS's constraint on third-party Rust dynamic libraries in App Store builds, static linking with compression is currently the most viable option, to the best of our knowledge.

Ensuring Android Release Mode Compatibility​

Another challenge we tackled was ensuring compatibility with Android's release mode. By default, Android's release build process applies code shrinking and obfuscation to optimize app size. While beneficial for optimization, this process caused a java.lang.UnsatisfiedLinkError for Mopro apps.

The root cause was that code shrinking interfered with JNA (Java Native Access), a crucial dependency for UniFFI, which we use for Rust-to-Kotlin bindings. The shrinking process was removing or altering parts of JNA that were necessary for the bindings to function correctly, leading to the UnsatisfiedLinkError when the app tried to call the native Rust code.

The Fix: Adjusting Gradle Build Configurations​

Our solution, as detailed in GitHub Issue #416, involves a configuration adjustment in the consuming application's android/build.gradle.kts file (or android/app/build.gradle for older Android projects). Developers using Mopro need to explicitly disable code and resource shrinking for their release builds:

android {
    // ...
    buildTypes {
        getByName("release") {
            // Disables code shrinking, obfuscation, and optimization for
            // your project's release build type.
            minifyEnabled = false
            // Disables resource shrinking, which is performed by the
            // Android Gradle plugin.
            shrinkResources = false
        }
    }
}

Impact and Future Considerations​

This configuration ensures that JNA and, consequently, the UniFFI bindings remain intact, allowing Mopro-powered Android apps to build and run successfully in release mode. This approach aligns with recommendations found in the official Flutter documentation for handling similar issues. While this increases the final app size slightly, it guarantees the stability and functionality of the native ZK operations. We are also actively exploring ways to refine this in the future to allow for optimized builds without compromising JNA's functionality.

The Road Ahead​

a. Manual Tweaks for Cross-Platform Frameworks​

Cross-platform frameworks like React Native and Flutter require additional glue code to define modules, as they straddle multiple runtimes. Each layer needs its own integration.

For example, in our zkEmail React Native package, we use three separate wrappers.

• [TypeScript] MoproReactNativePackageModule.ts: declares the public API and lets the React Native code-gen load the native module.
• [Swift] MoproReactNativePackageModule.swift: loads bindings into Objective-C–discoverable classes.
• [Kotlin] MoproReactNativePackageModule.kt: loads bindings and bridges via JNI.

Similarly, for our zkEmail Flutter package, a comparable set of wrappers is employed:

• [Dart] zkemail_flutter_package.dart: defines the public Dart API for the Flutter plugin, invoking methods on the native side via platform channels.
• [Swift] ZkemailFlutterPackagePlugin.swift: calls the underlying Rust-generated Swift bindings.
• [Kotlin] ZkemailFlutterPackagePlugin.kt: bridges Dart calls to the Rust-generated Kotlin bindings.

b. Support for Custom Package Names​

Initially, we encountered naming conflicts when the same XCFramework was used in multiple Xcode projects. Addressing this to allow fully customizable package names is an ongoing effort.

Initial progress was made with updates in issue#387 and a partial fix in PR#404. Further work to complete this feature is being tracked in issue#413.

What's Next: Shaping Mopro's Future Together​

Currently, the Mopro CLI helps you create app templates via the mopro create command, once bindings are generated with mopro build.

Our vision is to enhance this by enabling the automatic generation of fully customized native packages. This would include managing all necessary glue code for cross-platform frameworks, potentially through a new command (maybe like mopro pack) or by extending existing commands. We believe this will significantly streamline the developer workflow. If you're interested in shaping this feature, we invite you to check out the discussion and contribute your ideas in issue #419.

By achieving this, we aim to unlock seamless mobile proving capabilities, simplifying adoption for developers leveraging existing ZK solutions or porting Rust-based ZK projects. Your contributions can help us make mobile ZK development more accessible for everyone!

If you find it interesting, feel free to reach out to the Mopro team on Telegram: @zkmopro, or better yet, dive into the codebase and open a PR! We're excited to see what the community builds with Mopro.

Happy proving!

This tutorial guides developers through getting started with Mopro and building a native mobile app from scratch. It covers

• Setting up an example multiplier2 Circom circuit

  • Starting from 0. Prerequisites

• Modifying it to use a different circuit, such as keccak256

  • Starting from 6. Prerequisites

• Additionally, we'll integrate the semaphore-rs Rust crate to generate native bindings and run the implementation on both iOS and Android.

• We also offer comprehensive iOS and Android tutorials to guide you through the entire process, ensuring you don’t miss anything!

  • iOS
  • Android

0. Prerequisites​

• XCode or Android Studio
  • If you're using Android Studio, ensure that you follow the Android configuration steps and set the ANDROID_HOME environment variable.
• Rust and CMake

1. Download Mopro CLI tool​

We offer a convenient command-line tool called mopro to streamline the development process. It functions similarly to tools like npx create-react-app or Foundry, enabling developers to get started quickly and efficiently.

git clone https://github.com/zkmopro/mopro
cd mopro/cli
cargo install --path .
cd ../..

2. Initialize a project with Mopro CLI​

The mopro init command helps you create a Rust project designed to generate bindings for both iOS and Android. This step is similar to running npx create-react-app, so select the directory where you want to create your new app.

mopro init

Start by selecting a name for your project (default: mopro-example-app).

Next, choose the proving system that best fits your needs—Mopro currently supports both circom and halo2. For this example, we’ll be using circom.

Next, navigate to your project directory by running:

cd mopro-example-app

3. Build Rust bindings with mopro CLI​

mopro build command can help developers build binaries for mobile targets (e.g. iOS and Android devices).

mopro build

• Choose debug for faster builds during development or release for optimized performance in production.

• Select the platforms you want to build for: ios, android, web.

• Select the architecture for each platform:

  • iOS:

• Android:

Next, you will see the following instructions displayed:

4. Create templates for mobile development​

mopro create command generates templates for various platforms and integrates bindings into the specified directories.

mopro create

Currently supported platforms:

• iOS (Xcode project)
• Android (Android Studio project)
• React Native
• Flutter
• Web

After running the mopro create command, a new folder will be created in the current directory, such as:

• ios
• android
• react-native
• flutter
• web (currently does not support Circom prover)

You will then see the following instructions to open the project:

If you want to create multiple templates, simply run mopro create again and select a different framework each time.

5. Run the app on a device/simulator​

iOS​

Open the Xcode project by running the following command:

open ios/MoproApp.xcodeproj

Select the target device and run the project by pressing cmd + R.

Alternatively, you can watch this video to see how to run the app.

Android​

Open the Android Studio project by running the following command:

open android -a Android\ Studio

Run the project by pressing ^ + R or ctrl + R.

Alternatively, you can watch this video to see how to run the app.

6. Update circuits​

This section explains how to update circuits with alternative witness generators and corresponding zkey files. We use the Keccak256 circuit as a reference example here.

1. Add wasm and zkey file in the test-vectors/circom folder

   • wasm: https://ci-keys.zkmopro.org/keccak256_256_test.wasm
   • zkey: https://ci-keys.zkmopro.org/keccak256_256_test_final.zkey

2. In src/lib.rs file, update the circuit's witness generator function definition.

   -  rust_witness::witness!(multiplier2);
   +  rust_witness::witness!(keccak256256test);
   
   mopro_ffi::set_circom_circuits! {
   -    ("multiplier2_final.zkey", WitnessFn::RustWitness(multiplier2_witness))
   +    ("keccak256_256_test_final.zkey", WitnessFn::RustWitness(keccak256256test_witness))
   }
   
   warning

   The name should match the lowercase version of the WASM file, with all special characters removed.
   e.g.
   multiplier2 -> multiplier2
keccak_256_256_main -> keccak256256main
aadhaar-verifier -> aadhaarverifier

3. Similar to Step 3, regenerate the bindings to reflect the updated circuit.

   mopro build
   

4. Manually update the bindings in the app by replacing the existing ones.

   • iOS:

     • Replace ios/MoproiOSBindings with MoproiOSBindings.

   • Android:

     • Replace android/app/src/main/jniLibs with MoproAndroidBindings/jniLibs

     • Replace android/app/src/main/java/uniffi with MoproAndroidBindings/uniffi

   info

   We aim to provide the mopro update CLI tool to assist with updating bindings. Contributions to this effort are welcome.https://github.com/zkmopro/mopro/issues/269

5. Copy zkeys to assets

   • iOS:
     Open Xcode, drag in the zkeys you plan to use for proving, then navigate to the project’s Build Phases. Under Copy Bundle Resources, add each zkey to ensure it's included in the app bundle.

     Alternatively, you can watch this video to see how to copy zkey in XCode.

   • Android
     Paste the zkey in the assets folder: android/app/src/main/assets.

     Alternatively, you can watch this video to see how to copy zkey in XCode.

6. Update circuit input and zkey path

• Update zkeyPath to keccak256_256_test_final

  • iOS:
    

  - private let zkeyPath = Bundle.main.path(forResource: "multiplier2_final", ofType: "zkey")!
  + private let zkeyPath = Bundle.main.path(forResource: "keccak256_256_test_final", ofType: "zkey")!
  
  • Android:
    

  - val zkeyPath = getFilePathFromAssets("multiplier2_final.zkey")
  + val zkeyPath = getFilePathFromAssets("keccak256_256_test_final.zkey")
  

• Update circuit inputs: https://ci-keys.zkmopro.org/keccak256.json

  • iOS:
    

  - let input_str: String = "{\"b\":[\"5\"],\"a\":[\"3\"]}"
  + let input_str: String = "{\"in\":[\"0\",\"0\",\"1\",\"0\",\"1\",\"1\",\"1\",\"0\",\"1\",\"0\",\"1\",\"0\",\"0\",\"1\",\"1\",\"0\",\"1\",\"1\",\"0\",\"0\",\"1\",\"1\",\"1\",\"0\",\"0\",\"0\",\"1\",\"0\",\"1\",\"1\",\"1\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\"]}"
  
  • Android:
    

  - val input_str: String = "{\"b\":[\"5\"],\"a\":[\"3\"]}"
  + val input_str: String = "{\"in\":[\"0\",\"0\",\"1\",\"0\",\"1\",\"1\",\"1\",\"0\",\"1\",\"0\",\"1\",\"0\",\"0\",\"1\",\"1\",\"0\",\"1\",\"1\",\"0\",\"0\",\"1\",\"1\",\"1\",\"0\",\"0\",\"0\",\"1\",\"0\",\"1\",\"1\",\"1\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\",\"0\"]}"
  

7. Then Run the app again like in step 5.

7. Update Rust exported functions​

Currently, only generateCircomProof and verifyCircomProof are available with the bindings, but the bindings can be extended to support nearly all Rust functions.

Here is an example demonstrating how to use the Semaphore crate.

1. Update Cargo.toml

   Import semaphore crate from: https://github.com/worldcoin/semaphore-rs

   info

   We are using this specific commit 340d4ad for semaphore-rs.

   Cargo.toml

   semaphore-rs = { git = "https://github.com/worldcoin/semaphore-rs", features = ["depth_16"], rev = "340d4ad"}
   

2. Define a function to generate semaphore proof

   Here is an example to define semaphore prove and verify in src/lib.rs

   Alternatively, we can create a demo function called semaphore() to run the code from the README.

   src/lib.rs

   use semaphore_rs::{get_supported_depths, hash_to_field, Field, identity::Identity,
               poseidon_tree::LazyPoseidonTree, protocol::*};
   
   pub fn semaphore() {
       // generate identity
       let mut secret = *b"secret";
       let id = Identity::from_secret(&mut secret, None);
   
       // Get the first available tree depth. This is controlled by the crate features.
       let depth = get_supported_depths()[0];
   
       // generate merkle tree
       let leaf = Field::from(0);
       let mut tree = LazyPoseidonTree::new(depth, leaf).derived();
       tree = tree.update(0, &id.commitment());
   
       let merkle_proof = tree.proof(0);
       let root = tree.root();
   
       // change signal and external_nullifier here
       let signal_hash = hash_to_field(b"xxx");
       let external_nullifier_hash = hash_to_field(b"appId");
   
       let nullifier_hash = generate_nullifier_hash(&id, external_nullifier_hash);
   
       let proof = generate_proof(&id, &merkle_proof, external_nullifier_hash, signal_hash).unwrap();
       let success = verify_proof(root, nullifier_hash, signal_hash, external_nullifier_hash, &proof, depth).unwrap();
   
       assert!(success);
   }
   
   warning

   You can also try returning a value; otherwise, nothing will happen after execution. e.g.

   pub fn semaphore() -> bool {
       // ...
       return success;
   }
   

3. Export the function through UniFFI procedural macros

   You can simply use the UniFFI proc-macros (e.g. #[uniffi::export]) to define the function interfaces.

   info

   For more details, refer to the UniFFI documentation.

   + #[uniffi::export]
   pub fn semaphore() {
       // generate identity
       let mut secret = *b"secret";
       ...
   

4. Run mopro build again and manually update the bindings for iOS and Android as explained in Step 6.

5. You can now call the semaphore() function you just defined on both iOS and Android. 🎉

8. Conclusion​

• By following the tutorial, you will learn to create a native mobile ZK app with:

  • A simple circuit
  • Custom circuits
  • Custom functions and structs

• Just like with the Semaphore case, this approach can be extended to any Rust crate, as long as you define the input and output types according to the UniFFI documentation.

• Alternative platforms, such as wasm for web, and frameworks like React Native and Flutter are also supported. Please check out:

  • https://github.com/zkmopro/react-native-app
  • https://github.com/zkmopro/flutter-app

  Or simply run mopro build for these frameworks.

• There are still many challenges to address, and contributions are highly encouraged. Feel free to explore the issues list.

  • https://github.com/zkmopro/mopro/issues
  • https://github.com/zkmopro/gpu-acceleration/issues

• We encourage developers to build mobile apps, as it helps us enhance the developer experience and gain a deeper understanding of the challenges involved.

Throughout 2024, we compared various Groth16 provers for Circom. Our goal was to demonstrate that native provers (written in C++ or Rust) outperform snarkjs in terms of speed. Along the way, we uncovered some fascinating insights, which we’re excited to share with you in this post.

To understand a Groth16 prover, let’s break it down into two main components: witness generation and proof generation.

Witness Generation: This step involves processing inputs along with witness calculation functions to produce the necessary witness values for a circuit. It's a purely computational step and does not involve any zero-knowledge properties.

Proof Generation: Once the witness is generated, this step takes the witness and the zkey (generated by snarkjs) to compute the polynomial commitments and produce a succinct zero-knowledge proof.

Ideally, developers should have the flexibility to switch between different witness generation and proof generation implementations. This would allow them to leverage the fastest options available, optimizing performance and enhancing their development experience.

However, each of these tools presents unique challenges. In the following sections, we will delve into these challenges in detail and provide a comparison table for clarity.

Witness Generation​

snarkjs​

• https://github.com/iden3/snarkjs

snarkjs is one of the most widely used tools for generating Groth16 proofs and witnesses. Written in JavaScript, it runs seamlessly across various environments, including browsers on both desktops and mobile devices. However, it faces performance challenges with large circuits. For instance, an RSA circuit can take around 15 seconds to process, while a more complex circuit like zk-email may require up to a minute to generate a proof. This highlights the need for optimized solutions, such as leveraging mobile-native capabilities and even mobile GPUs, to significantly enhance performance.

witnesscalc​

• https://github.com/0xPolygonID/witnesscalc

witnesscalc is a lightweight, C++-based tool designed for efficient witness generation for circuits compiled with Circom. It offers a faster alternative to JavaScript-based tools like snarkjs. With cross-platform support and compatibility with other ZKP tools, Witnesscalc is ideal for handling performance-sensitive applications and large circuits.

While Witnesscalc performs exceptionally well with circuits such as RSA, Anon Aadhaar, Open Passport, and zkEmail, integrating it into Mopro presents challenges due to its C++ implementation, whereas Mopro is built on Rust. We are actively working to bridge this gap to leverage its performance benefits within the mobile proving ecosystem.

wasmer​

• https://github.com/arkworks-rs/circom-compat

One option available in Rust is circom-compat, maintained by the Arkworks team. This library uses the .wasm file generated by Circom and relies on the Rust crate wasmer to execute the witness generation. However, wasmer doesn’t run natively on devices—it creates a WebAssembly execution environment for the .wasm file. As a result, the performance of wasmer is comparable to the WebAssembly performance of snarkjs running in a browser.

Initially, we encountered memory issues with wasmer during implementation (issue #1). Later, we discovered that the Apple App Store does not support any wasmer functions or frameworks, making it impossible to publish apps using this solution on the App Store or TestFlight (issue #107). As a result, we decided to abandon this approach for Mopro.

circom-witness-rs​

• https://github.com/philsippl/circom-witness-rs

Another Rust-based option is circom-witness-rs, developed by the Worldcoin team. Unlike solutions that rely on WebAssembly (wasm) output from the Circom compiler, this tool directly utilizes .cpp and .dat files generated by Circom. It employs the cxx crate to execute functions within the .cpp files, enhanced with optimizations such as dead code elimination. This approach has demonstrated excellent performance, particularly with Semaphore circuits. However, we discovered that it encounters compatibility issues with certain circuits, such as RSA, limiting its applicability for broader use cases.

circom-witnesscalc​

• https://github.com/iden3/circom-witnesscalc

The team at iden3 took over this project and began maintaining it under the name circom-witnesscalc. While it heavily draws inspiration from circom-witness-rs, it inherits the same limitation—it does not support RSA circuits. For more details, refer to the "Unimplemented Features" section in the README.

rust-witness​

• https://github.com/chancehudson/rust-witness

Currently, Mopro utilizes a tool called rust-witness, developed by a member of the Mopro team. This tool leverages w2c2 to translate WebAssembly (.wasm) files into portable C code. By transpiling .wasm files from Circom into C binaries, rust-witness has demonstrated compatibility across all circuits and platforms tested so far, including desktop, iOS, and Android. Additionally, its performance has shown to be slightly better than that of wasmer.

Proof Generation​

snarkjs​

• https://github.com/iden3/snarkjs

As mentioned earlier, snarkjs is the most commonly used tool for generating Groth16 proofs. However, its performance still has room for improvement.

rapidsnark​

• https://github.com/iden3/rapidsnark

Rapidsnark, developed by the iden3 team, is an alternative to snarkjs designed to deliver faster Groth16 proof generation. Similar to witnesscalc, it is written in C++. While it shows promising performance, we are still working on integrating it into Mopro.

ark-works​

• https://github.com/arkworks-rs/circom-compat

The primary Rust-based option is circom-compat, maintained by the Arkworks team. Arkworks is a Rust ecosystem designed for programmable cryptography, deliberately avoiding dependencies on native libraries like gmp. In our experiments, Arkworks has proven to work seamlessly with all circuits and platforms. If you have Rust installed, you can easily execute Groth16 proving using Arkworks without any issues. As a result, Mopro has adopted this approach to generate proofs for cross-platform applications.

Comparison Table​

Here, we present a table comparing different witness generators and proof generators to provide a clearer understanding of their features and performance.

In this comparison, we use circom-witnesscalc as a representative for both circom-witness-rs and circom-witnesscalc, as they share fundamentally similar implementations and characteristics.

Conclusion​

In conclusion, we found that the witnesscalc and rapidsnark stack offers the best performance, but integrating it into Rust presents significant challenges. These tools rely heavily on C++ and native dependencies like gmp, cmake, and nasm. Our goal is to integrate these tools into Rust to make them more accessible for application development. Similar to how snarkjs seamlessly integrates into JavaScript projects like Semaphore and ZuPass, having a Rust-compatible stack would simplify building cross-platform applications. Providing only an executable limits flexibility and usability for developers. In 2025, we are prioritizing efforts to enable seamless integration of these tools into Rust or to provide templates for customized circuits.

We recognize the difficulty in choosing the right tools and are committed to supporting developers in this journey. If you need assistance, feel free to reach out to the Mopro team on Telegram: @zkmopro.

Here are the milestones we’ve achieved this year, along with key reflections on our journey.

Optimizing Developer Workflow​

We streamlined the development process through significant codebase refactoring. By merging mopro-core and mopro-ffi into a single mopro-ffi folder and consolidating the iOS, Android, and web apps into a test-e2e folder, we reduced folder depth, making it easier for contributors to locate functions.

Additionally, we removed the circuits compilation and trusted setup processes, along with unused toolchain targets. These optimizations have drastically improved our CI workflow, reducing the peak runtime from around 1 hour to just 10 minutes (10 times faster)!

We also enhanced the Mopro CLI, significantly reducing the time required for setup and usage. As mentioned earlier, users no longer need to install unnecessary toolchains or download unused circuits from the Mopro repository.

Looking ahead to 2025, we plan to make the CLI even more accessible by providing precompiled binaries for download, eliminating the need for git clone during installation.

Users can now quickly clone the repository and build an iOS or Android project in just three commands—mopro init, mopro build, and mopro create—all within 3 minutes! For detailed instructions, check out the Getting Started section.

Enabling Multi-Platform Support​

In addition to Swift for iOS and Kotlin for Android, we’ve now created templates for cross-platform frameworks like React Native and Flutter. The CLI has been updated to support these platforms, and the documentation has been refreshed to reflect these enhancements.

Please refer to the following resources:

• React Native Setup
• React Native App
• Flutter Setup
• Flutter App

Additionally, Mopro now supports WASM for web browsers. We provide wasm-bindgen for the Halo2 prover, enabling developers to use the Mopro CLI to generate website templates with bindings. This significantly reduces the time spent navigating the outdated Halo2 tutorial available at Using halo2 in WASM (It was authored in 2022).

Please refer to the following resources to learn how to use Mopro for building WASM applications for web browsers:

• WASM Setup

Expanding Compatibility with General Rust Functions​

We realized that generating and verifying proofs alone isn’t sufficient for application developers. To address this, we made the Mopro template compatible with any Rust crate or function, allowing developer to extend the FFI interface directly through Rust code.

For instance, if a developer needs a Poseidon hash function but neither Swift nor Kotlin provides a Poseidon hash library, they can integrate a Rust Poseidon crate. First, they define the function API in Rust, such as:

#[uniffi::export]
pub fn poseidon(input: Vec<u8>) -> Vec<u8>{
    // Poseidon hash implementation
}

By annotating your function with #[uniffi::export], UniFFI automatically declares the appropriate FFI type and generates the necessary bindings for Swift, Kotlin.

Once processed, the generated foreign language bindings expose your custom functions seamlessly. You can then call the Poseidon function in your Swift or Kotlin code as if it were a native API, enabling straightforward cross-language integration.

For more details on how UniFFI processes your Rust code to generate these bindings, please refer to the Uniffi - Procedural Macros.

By running mopro build again, the developer can generate Swift and/or Kotlin bindings for the Poseidon hash function. They can then easily call the function in Swift or Kotlin like this:

let hash = poseidon(input: input)

or in kotlin

val hash = poseidon(input)

Additionally, this approach is compatible with WASM for browsers. You can define a function in Rust as follows:

use serde_wasm_bindgen::to_value;
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn poseidon(input: JsValue) -> Result<JsValue, JsValue> {
    // Poseidon function implementation
    to_value(...)
}

Then, by running mopro build again with the web target, you can generate the necessary bindings for the web. Once built, you can call the poseidon function directly in JavaScript, making it seamlessly accessible in browser-based applications.

The Rise of New ZK Mobile Apps​

This year, we’ve seen a growing number of ZK mobile apps being developed. Some notable examples include:

1. World ID
2. Anon Aadhaar
3. Open Passport
4. Myna Wallet
5. FreedomTool

These apps benefit significantly from mobile-native proving compared to using tools like snarkjs. For instance, Anon Aadhaar achieves up to 8x faster performance with rapidsnark compared to snarkjs.

For more details on the benchmarks, please refer to the benchmark section.

While we’ve provided the Mopro stack with rust-witness and ark-works, most applications are leveraging the witnesscalc and rapidsnark stack for faster proving, particularly with RSA circuits.

Given the adoption trends and benchmark results, we've recognized the need to prioritize improving rapidsnark integration and further enhancing the developer experience. This will be a key focus in Q1 of 2025.

We’re excited to see even more ZK mobile-native apps emerge in the near future, delivering improved performance and enhanced user experiences.

Final Thoughts and Looking Ahead​

The Mopro tool has become more robust, now supporting multiple platforms. However, our vision extends further—we aim to develop a mobile-native ecosystem as comprehensive and developer-friendly as the JavaScript/TypeScript ecosystem, empowering developers to seamlessly build innovative apps.

As we look to the future, we encourage developers to explore the opportunities in building ZK mobile applications. By leveraging mobile-native proving, you can create apps that are not only faster but also more accessible to users worldwide. Let’s work together to shape the next wave of ZK technology and bring its benefits to mobile platforms!