2000 character limit reached
FibRace: a large-scale benchmark of client-side proving on mobile devices (2510.14693v1)
Published 16 Oct 2025 in cs.CR
Abstract: FibRace, jointly developed by KKRT Labs and Hyli, was the first large-scale experiment to test client-side proof generation on smartphones using Cairo M. Presented as a mobile game in which players proved Fibonacci numbers and climbed a leaderboard, FibRace served a dual purpose: to engage the public and to provide empirical benchmarking. Over a three-week campaign (September 11-30, 2025), 6,047 players across 99 countries generated 2,195,488 proofs on 1,420 unique device models. The results show that most modern smartphones can complete a proof in under 5 seconds, confirming that mobile devices are now capable of producing zero-knowledge proofs reliably, without the need for remote provers or specialized hardware. Performance was correlated primarily with RAM capacity and SoC (System on Chip) performance: devices with at least 3 GB of RAM proved stably, when Apple's A19 Pro and M-series chips achieved the fastest proving times. Hyli's blockchain natively verified every proof onchain without congestion. FibRace provides the most comprehensive dataset to date on mobile proving performance, establishing a practical baseline for future research in lightweight provers, proof-powered infrastructure, and privacy-preserving mobile applications.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
Overview
This paper describes FibRace, a mobile game that secretly doubled as a science experiment. The goal was to test whether regular smartphones can create “zero-knowledge proofs” on their own, quickly and reliably. Over three weeks, more than 5,000 people across 99 countries played the game and their phones generated about 2.2 million proofs. The results show that modern phones can usually make these proofs in just a few seconds, which means privacy-friendly apps can run directly on your device without needing special servers.
Objectives
The researchers wanted to answer simple, practical questions:
- Can everyday smartphones create zero-knowledge proofs by themselves, without using cloud computers?
- How fast is proof-making on different phones?
- What phone features (like memory and chip speed) matter most?
- Is this stable enough for real apps, and can a blockchain handle verifying so many proofs?
How They Did It
First, two key ideas explained simply
- Zero-knowledge proof: Imagine you want to prove you solved a puzzle, but you don’t want to reveal the solution. A zero-knowledge proof lets you convince others you’re right without sharing your secrets. It’s great for privacy.
- Fibonacci numbers: This is a famous sequence where each number is the sum of the previous two (like 0, 1, 1, 2, 3, 5, 8...). The game asked phones to prove they calculated a specific Fibonacci number correctly.
The game setup
- Players opened the FibRace app and tried to “prove” a randomly chosen Fibonacci number as fast as possible.
- Their phone generated the proof locally using a mobile-optimized system called Cairo M (made by KKRT Labs).
- The proof was then sent to Hyli, a blockchain designed to check these proofs quickly. Hyli verified every proof “onchain” (on its network).
- The app recorded technical details like the phone model, RAM (memory), chip type, and how long the proof took.
- No personal data or money rewards were involved—just scores, speed, and collecting digital cards.
What They Found
Here are the main results, explained in simple terms:
- Participation: 6,047 player names were registered; 5,156 people generated at least one valid proof. Players used 1,420 different phone models across 99 countries. In total, 2,195,488 proofs were created.
- Speed: Most phones finished a proof in a few seconds. High-end phones (like new iPhones and iPads) often took 3 seconds or less. Many modern phones landed under 5 seconds; older or low-end phones tended to be slower (often 6–10 seconds or more).
- Hardware matters: Two things made the biggest difference:
- RAM (memory): Phones with at least 3 GB of RAM usually worked well. Below that, proving often failed. Stability rose as RAM increased, and problems mostly disappeared beyond about 6 GB.
- Chip performance (SoC): Newer, faster chips proved quicker. Apple’s A19 Pro and M-series were the fastest, with top Qualcomm Snapdragon, MediaTek Dimensity, Kirin, and Exynos chips also doing well.
- Reliability: The overall crash rate was low (about 0.72%). Most crashes happened on phones with lower memory (3–4 GB), mainly due to running out of memory during heavy tasks.
- Blockchain verification: Hyli verified every proof on its network without clogging or slowing down, even during busy hours. This shows a blockchain can handle lots of user-generated proofs smoothly.
Why This Is Important
- Privacy: If your phone can generate proofs by itself, your sensitive information never leaves your device. You can prove things (like your age or identity) without exposing private data.
- Simpler apps: Developers don’t need to run expensive servers to make proofs. Phones can do the heavy lifting, which reduces cost and complexity.
- New possibilities: This could enable privacy-friendly games, secure identity checks, and other apps where you can interact and prove things offline, then sync later.
Limitations
To keep the experiment simple and fun, the researchers made some trade-offs:
- Only one type of task: They mostly proved Fibonacci calculations. Real apps might use more complex tasks (like cryptographic hashes), which could behave differently.
- No energy/heat measurements: They didn’t track battery use or phone temperature. Players reported some heat and battery drain during long sessions, but it wasn’t measured.
- Game interruptions: Because it was a game, some “crashes” might actually be players force-closing the app, which makes the data a little noisy.
Takeaway and Impact
FibRace shows that creating privacy-preserving proofs directly on smartphones is no longer just an idea—it works in the real world. Modern phones can usually finish a proof in only a few seconds, and a blockchain like Hyli can verify millions of them without slowing down. This opens the door to a new generation of apps where users keep control of their data, and the phone becomes the main engine for security and privacy. Future studies will likely test more complex tasks and measure battery and heat, but the core message is clear: zero-knowledge proofs can run on your phone today.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
Below is a single, concrete list of what remains missing, uncertain, or unexplored, framed to guide actionable follow-up research.
- Circuit diversity: results are based on a single, arithmetic-heavy Fibonacci circuit; no evaluation of more representative workloads (e.g., SHA-2/Keccak, ECDSA/EdDSA, Merkle proofs, range proofs, recursive/aggregated proofs, SNARK/STARK verifier circuits).
- Complexity scaling: lack of a formalized mapping from witness size (n in [1..100000]) to trace length/cycle count and time; no published scaling law or per-n stratified latency curves to validate linearity/sub-linearity and isolate device effects from circuit complexity.
- Security level sensitivity: only 96-bit security was tested; no measurements at 128-bit (or higher) security to assess viability for production-grade deployments and the runtime/memory trade-offs.
- Memory footprint profiling: no per-proof peak/average memory traces, allocator behavior, or memory-pressure telemetry; unclear where memory hot spots occur and how to systematically reduce RAM usage to support ≤3 GB devices.
- Inclusion of low-end devices: devices with <3 GB RAM were effectively excluded; no exploration of algorithmic strategies (e.g., streaming IOPs, segmented proving, lookup-heavy variants, recursion/aggregation) or configuration tuning to enable proofs on low-memory hardware.
- Crash attribution ambiguity: user-initiated exits (foreground/background app lifecycle events, force quits) are indistinguishable from technical crashes; no in-app instrumentation to disambiguate failure modes or to tag OS-reported crash reasons.
- Unresolved concurrency bug: suspected Rust thread lifecycle/cleanup issue under high-frequency minting remains unroot-caused; no systematic stress testing, profiling, or reproducible minimal test case presented to verify and fix resource leaks.
- Energy and thermal effects: no instrumentation of battery drain, device temperature, or throttling; no sustained-run experiments to quantify performance degradation, thermal ceilings, or user comfort thresholds (energy per proof, proofs per Wh).
- Power-state and OS policy impacts: no control for battery state-of-charge, battery health, power saver modes, background restrictions, or OEM thermal policies that can materially alter performance and stability.
- Measurement fidelity: unclear timing boundaries for “proof duration” (e.g., wall-clock vs. monotonic timers, inclusion/exclusion of preprocessing/serialization); no validation of timer accuracy across OSes or synchronization with cycle counters.
- Frequency metric validation: “Cairo M cycles per second” is reported but not calibrated against hardware performance counters; unclear whether cycles are comparable across compiler flags, OS versions, and devices.
- Multivariate performance modeling: correlations are presented (e.g., RAM, SoC) but no multivariate regression or feature-importance analysis controlling for confounders (thermal state, OS version, background load, storage I/O).
- OS/platform fragmentation: no stratified analysis by OS major/minor versions, kernel schedulers, or vendor-specific runtime policies; iOS vs. Android performance and stability differences are not isolated.
- Multi-core scaling: no analysis of parallelization strategy, core affinity, big.LITTLE behavior, or speedups vs. core count; unclear whether Cairo M saturates available cores efficiently on different SoC topologies.
- Hardware accelerators: no investigation of SIMD/NEON, GPU, NPU/AI-accelerator, or Apple AMX utilization for proving; unclear acceleration potential vs. energy overhead on mobile.
- Background load robustness: impact of concurrent user activity (other apps, notifications, I/O) on latency, crash rate, and jitter is not quantified; no QoS characterization under realistic multitasking.
- Network/offline UX: while proving is local, the workflow depends on onchain verification; no experiments on offline queuing/sync, intermittent connectivity, or the impact of network delays on user-perceived latency and retries.
- Device attestation and data integrity: no hardware-backed attestation (e.g., Play Integrity/DeviceCheck) to ensure device model/SoC metadata authenticity; open risk that device characteristics in the dataset can be spoofed.
- Selection bias: participants are self-selected gamers/crypto-curious users; under-representation of very low-end markets, older OS versions, or enterprise-managed devices likely; no sampling correction or targeted recruitment to balance the device distribution.
- Repeatability and longitudinal stability: without accounts, long-term device-level behavior (aging effects, battery wear, seasonal ambient temperatures) cannot be analyzed; no multi-week sustained-proving paper per device model.
- Reproducibility and build transparency: while datasets are public, it is unclear whether prover builds, compiler flags, and app code are reproducible and pinned; lack of reproducible artifacts impedes independent replication.
- Onchain verification throughput claims: verification success on Hyli testnet is reported without detailed latency distributions, failure modes, or economic costs; no adversarial stress tests (burst floods, malformed submissions) or mainnet-like fee/MEV conditions.
- Generalizability beyond Cairo M: no cross-prover comparisons (e.g., Plonky2, Halo2, Nova/HyperNova, Spartan, Ligero) on identical circuits to benchmark relative mobile performance and memory footprints.
- User acceptance thresholds: the ≤5 s target is assumed, not user-tested; no UX studies linking latency and energy drain to task abandonment, session length, or satisfaction across application types (payments, identity, gaming).
- Dataset granularity: logs lack fine-grained runtime stats (peak RSS, GC/allocator events, temperature, CPU frequency states, throttling events) needed to pinpoint bottlenecks and guide optimization.
- Parameter sensitivity: no sweeps over prover parameters (e.g., FRI degree, blowup factors, hash choices) to map accuracy–performance–memory trade-offs on mobile.
- Security and threat modeling on-device: no analysis of side-channel risks (power/EM, microarchitectural leaks) or tamper-resistance when generating proofs on compromised devices; open questions for sensitive identity use cases.
- Cross-environment coverage: focus on smartphones; no exploration of wearables, tablets beyond iPad M-series, or constrained IoT/embedded devices to map the broader client-device frontier.
- Fair ranking of SoCs: SoC leaderboards are reported without confidence intervals or normalization for ambient/thermal conditions and witness sizes; statistical uncertainty and repeat-run variance are not shown.
Practical Applications
Overview
FibRace demonstrates that client-side zero-knowledge proof (ZKP) generation on modern smartphones is viable, fast (median ≈ 6.37 s; many devices ≤ 5 s), and reliable (overall crash rate ≈ 0.72%), with clear hardware thresholds (RAM ≥ 3 GB). Hyli’s blockchain verified >2 million proofs onchain without congestion, validating end-to-end workflows. Below are practical applications derived from these findings, methods, and innovations, grouped by deployability and linked to relevant sectors, tools, workflows, and feasibility assumptions.
Immediate Applications
The following applications can be deployed now on mainstream smartphones, provided circuits stay within current memory/latency budgets and verifiers accept client-side proofs.
- Privacy-preserving age and identity checks for websites, communities, and apps
- Sectors: identity, social platforms, retail/e-commerce, gaming
- Workflow: user holds a verifiable credential locally; the app uses Cairo M to generate a predicate proof (e.g., “age ≥ 18”) on-device; Hyli or a server verifies and grants access
- Tools/products: Cairo M Mobile SDK; Hyli Verification API; VC/DID libraries; lightweight circuit catalog for common predicates
- Assumptions/dependencies: device RAM ≥ 3 GB; acceptable security level (96 bits today, upgradeable); standardized credential schemas; platform/merchant acceptance; no TEEs required if data origin is trusted by design
- Client-side proving in mobile wallets and dApps
- Sectors: finance, blockchain, fintech
- Workflow: wallet generates ZK proofs locally for transaction validity, policy compliance, or rate limits; proofs verified onchain (Hyli) or by offchain verifiers
- Tools/products: Cairo M SDK integrated in wallets; Hyli-native verifier modules; UX patterns for ≤ 5 s proving
- Assumptions/dependencies: L1/L2 support for Cairo M verification; RAM ≥ 3 GB; proof latency tolerable for user actions; circuit sizes kept within current memory footprint
- Offline-verifiable access control and ticketing
- Sectors: events, transportation, facilities
- Workflow: on-device proof-of-ownership or proof-of-right-to-enter generated without network; verifier scans QR/NFC and validates proof; optional asynchronous onchain settlement via Hyli
- Tools/products: offline verifier app; compact circuits for rights/validity; revocation lists sync
- Assumptions/dependencies: offline verifiers available; short proving times; credential lifecycle management (issuance/revocation)
- Enterprise attestations without exposing sensitive data
- Sectors: software/IT, compliance, HR
- Workflow: employee proves role/clearance using locally stored credential and ZKP; gates access to internal systems without revealing full identity details
- Tools/products: internal verifiers; policy circuits (role membership, least privilege); device capability gating
- Assumptions/dependencies: corporate PKI/VC issuance; verifier integration; RAM ≥ 3 GB; audit trails via Hyli optional
- Proof-of-computation games and collectibles (FibRace-style)
- Sectors: gaming, education, community engagement
- Workflow: players solve puzzles; app generates client-side proofs and mints shareable “proof cards” with times/leaderboards; onchain verification ensures integrity
- Tools/products: “Gamified Benchmark” SDK; leaderboard modules; social sharing templates
- Assumptions/dependencies: circuits sized for mid-range devices; safeguard against thermal throttling during bursts; no financial incentives needed to drive organic participation
- Developer tooling: device capability profiling and adaptive circuit selection
- Sectors: software development, dev tools
- Workflow: app queries RAM/SoC; selects circuit complexity and proving parameters accordingly; degrades gracefully for 3–4 GB RAM devices
- Tools/products: capability profiler library; circuit presets; crash telemetry dashboards leveraging FibRace dataset
- Assumptions/dependencies: access to device metadata; robust fallbacks for memory pressure; use of the FibRace dataset for heuristics
- Logistics and field operations: route or condition proofs via courier smartphones
- Sectors: logistics, mobility, last-mile delivery
- Workflow: driver phone generates proofs of time-window compliance, route progression, or proof-of-presence; verifier validates without raw location disclosure
- Tools/products: route-policy circuits; verifier APIs; optional Hyli settlement for auditability
- Assumptions/dependencies: trusted data origin (GPS/app integrity); RAM ≥ 3 GB; no TEEs implies policy designs that tolerate origin uncertainty or combine with lightweight attestation
- Academic and R&D benchmarking replicated through public games
- Sectors: academia, cryptography research, performance engineering
- Workflow: reproduce FibRace’s gamified approach for other provers/circuits, collect real-world performance data across devices
- Tools/products: open datasets; Jupyter analysis notebooks; standardized ethical data-minimization templates
- Assumptions/dependencies: opt-in participation; IRB/ethics alignment; cross-platform coverage
- Cost-optimized app architectures that remove remote proving infrastructure
- Sectors: startups, SaaS, mobile software
- Workflow: shift proof generation to end-user devices; rely on Hyli (or equivalent) for verification; reduce server OPEX/CAPEX
- Tools/products: architecture blueprints; SDK integration guides; billing models based on verification rather than proving
- Assumptions/dependencies: end-user device capability; verifier scalability; maintain UX ≤ 5 s latency for interactive flows
Long-Term Applications
These applications are promising but require further research, circuit complexity expansion, performance/energy optimizations, standardization, or ecosystem adoption.
- Healthcare privacy apps: on-device proofs over medical data
- Sectors: healthcare, digital health
- Workflow: prove treatment eligibility/compliance or lab-result predicates without exposing raw data; clinician/verifier validates
- Tools/products: medical predicate circuits (set membership, range proofs); EHR integrations; consent management
- Assumptions/dependencies: regulatory approvals; stronger security parameters (≥ 128 bits); complex circuits and optimized memory footprint; provenance/attestation of inputs
- Financial compliance and creditworthiness without data exposure
- Sectors: finance, banking, insurance
- Workflow: AML/KYC predicates, risk scores, income verification via VC + ZKP; lenders verify without accessing sensitive raw data
- Tools/products: standardized financial predicate circuits; issuer/verifier ecosystems; auditability onchain
- Assumptions/dependencies: credential standards (VC/DID) adoption; verifiers’ legal acceptance; heavier circuits; potential TEEs/attestation for data integrity
- On-device advertising and analytics with privacy guarantees
- Sectors: advertising, martech
- Workflow: prove conversions/engagement metrics locally without sharing raw telemetry
- Tools/products: conversion-proof circuits; advertiser/verifier SDKs
- Assumptions/dependencies: industry standards and acceptance; anti-fraud controls; balancing battery/thermal impacts for sustained activity
- Secure biometrics with ZK proofs of match
- Sectors: security, identity
- Workflow: prove “face/fingerprint matches” without revealing biometric template
- Tools/products: biometric-match circuits; secure local storage
- Assumptions/dependencies: specialized acceleration (GPU/NEON/NPU); potential TEEs; advanced circuit design
- Edge/IoT data integrity proofs
- Sectors: industrial, energy, smart devices
- Workflow: sensors generate proofs of measurements or policy compliance at the edge
- Tools/products: ultra-light circuits; embedded provers
- Assumptions/dependencies: constrained hardware (RAM below smartphone levels); alternative acceleration; offline verification networks
- Real-time AR/VR and interactive ZK experiences
- Sectors: gaming, AR/VR
- Workflow: sub-second proofs for in-experience rules or anti-cheat mechanisms
- Tools/products: GPU-accelerated mobile provers; fast verifiers
- Assumptions/dependencies: significant prover optimization; thermal/battery instrumentation; circuit specialization
- National-scale e-government credentials using client-side proofs
- Sectors: public sector, policy
- Workflow: citizens hold credentials; prove rights/eligibility locally; services verify without central ID storage
- Tools/products: credential issuance infrastructure; verifier networks; governance frameworks
- Assumptions/dependencies: standardization (VC/DID), legal frameworks mandating data minimization; broad device support; auditing/compliance tooling
- Prover optimization and energy-aware instrumentation
- Sectors: academia, dev tools, sustainability
- Workflow: reduce RAM footprint; measure/optimize thermal and energy impacts; adapt circuits to device profiles
- Tools/products: energy/thermal telemetry SDKs; adaptive proving schedulers
- Assumptions/dependencies: OS-level metrics access; research into memory-lean circuit constructions; sustained benchmarking campaigns
- Cross-chain verification of Cairo M proofs and interoperability
- Sectors: blockchain infrastructure
- Workflow: verify Cairo M proofs across multiple L1/L2s; standardized proof formats
- Tools/products: cross-chain verifier libraries; bridges
- Assumptions/dependencies: multi-chain support; consensus-layer integrations; standard proof schemas
- ZK + device attestation for trusted data origin
- Sectors: mobile OS, security
- Workflow: combine ZK predicates with attestation (TEE/Secure Enclave) to prove properties about genuine device state or data capture
- Tools/products: attestation APIs; combined circuits and verification flows
- Assumptions/dependencies: OS vendor support; attestation keys; privacy-preserving attestation designs
- UX and policy standards for client-side proving
- Sectors: product design, standards bodies, regulators
- Workflow: define acceptable latency/battery thresholds, privacy guarantees, and data-minimization requirements for ZK-enabled apps
- Tools/products: best-practice guides; certification programs
- Assumptions/dependencies: robust empirical datasets (energy/thermal); multi-stakeholder consensus; iterative refinement as devices evolve
Notes on Assumptions and Dependencies
- Hardware thresholds: current viability is strongest on devices with RAM ≥ 3 GB; stability improves beyond 6 GB.
- Security parameters: the benchmark used ≈ 96-bit security; financial/healthcare-grade uses likely require ≥ 128 bits.
- Circuit complexity: FibRace tested a low-memory arithmetic circuit (Fibonacci); heavier real-world circuits (hashes, set membership, signatures) need further optimization and RAM reductions.
- Energy/thermal effects: not measured; sustained proving may trigger throttling and battery drain—instrumentation and optimizations are needed for long-duration use cases.
- Data origin and integrity: client-side ZK proves correctness of a statement but not authenticity of the input; some applications will require device attestation or trusted credential issuance.
- Ecosystem adoption: verifiers (chains, servers, institutions) must accept client-side proofs; standard schemas and interoperability will accelerate deployment.
- Network assumptions: Hyli demonstrated high-throughput onchain verification; other chains or offchain verifiers may require scaling or integration work.
Glossary
- arithmetic circuit: A computation represented as a network of field operations used in zero-knowledge proving. "an arithmetic circuit with low memory usage."
- Autobahn consensus: A high-speed Byzantine fault-tolerant blockchain consensus protocol. "Hyli's implementation of the Autobahn consensus can absorb high-frequency proof submissions from a large user base (Giridharan et al. 2024)."
- Cairo M: KKRT Labs' mobile-optimized zero-knowledge virtual machine and prover. "KKRT Labs's Cairo M, a ZK-VM optimized for mobile hardware, was designed to address this challenge (KKRT Labs 2025)."
- client-side proving: Generating cryptographic proofs locally on the user's device rather than on servers. "Client-side proving minimizes friction for both developers and users."
- cycle counts: The number of VM execution cycles needed to produce a proof; a performance metric. "helps refine benchmarks for memory footprint, cycle counts, and acceptable crash rates."
- ECDSA: Elliptic Curve Digital Signature Algorithm; p256 denotes the NIST P-256 curve. "in-browser proving for p256 ECDSA signatures was still largely impractical, with only Noir achieving limited usability (Vlad 2025)."
- Layer 2 roll-ups: Blockchain scaling solutions that batch transactions off-chain and post proofs to the base layer. "Layer 2 roll-ups and blockchain settlement layers."
- Ligero: A lightweight zero-knowledge proof system designed for efficiency. "Google's zkWallet with Ligero"
- M31 prime field: A specific finite field modulus used for computations in Cairo M circuits. "on the M31 prime field."
- Noir: A high-level language for writing zero-knowledge circuits and proofs. "with only Noir achieving limited usability"
- OOM: Out-of-memory failures when a process exceeds available RAM. "which could lead to OOM-type crashes."
- onchain: Executed or recorded directly on the blockchain. "A proof is deemed valid if successfully generated, sent to Hyli, verified by Hyli, and settled onchain on Hyli."
- proof frequency: The rate of proof computation, measured in cycles per second. "CPU frequency correlates strongly with proof frequency, confirming Cairo M's effective scaling on mobile hardware."
- proof-powered L1: A Layer-1 blockchain designed to natively verify zero-knowledge proofs. "a proof-powered L1 and a mobile-optimized prover can function seamlessly"
- proof throughput: The number of proofs processed per unit time. "Proof throughput and crash incidence followed inversely proportional patterns"
- remote prover: An external service that generates proofs for clients. "the proof must be generated by the user, not by a remote prover (Kuhn 2025)."
- security bits: A measurement of cryptographic strength expressed in bits of brute-force effort. "with 96 security bits."
- settlement layer: The blockchain layer where transactions are finalized and proofs are anchored. "blockchain settlement layers."
- SoC (System on Chip): Integrated hardware combining CPU, GPU, memory controller, and other components. "Performance was correlated primarily with RAM capacity and SoC (System on Chip) performance"
- testnet: A non-production blockchain network used for testing. "settled on the Hyli testnet blockchain."
- thermal throttling: Automatic reduction of device performance to prevent overheating. "thermal throttling or sustained high-load conditions on some devices."
- trusted execution environments: Hardware-isolated environments for secure computation. "No remote provers, cloud relays, or trusted execution environments were used."
- witness: The private inputs to a zero-knowledge circuit that prove a statement without revealing the inputs. "we benched a wide range of witnesses"
- zero-knowledge proofs: Proofs that verify correctness of a statement without revealing the underlying data. "Zero-knowledge proofs have become a cornerstone of blockchain scalability and privacy."
- ZK-VM: A virtual machine whose executions are amenable to zero-knowledge proof generation. "a ZK-VM optimized for mobile hardware"
- zkWallet: A wallet that uses zero-knowledge proofs for privacy-preserving operations. "Google's zkWallet with Ligero"
Collections
Sign up for free to add this paper to one or more collections.