### Terms and Conditions
- [x] I agree to the [Grant Agreement](https://9ba4718…c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471_f81ef4e4b5f040038350270eb590e2e42.pdf) terms if funded
- [x] I agree to [Provide KYC information](https://9ba4718c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471_7d9e73d16b584a61bae92282b208efc4.pdf) if funded above $50,000 USD
- [x] I agree to disclose conflicts of interest
- [x] I agree to adhere to the [Code of Conduct](https://forum.zcashcommunity.com/t/zcg-code-of-conduct/41787) and [Communication Guidelines](https://forum.zcashcommunity.com/t/zcg-communication-guidelines/44284)
- [x] I understand all milestone deliverables will be validated and accepted by their intended users or their representatives, who will confirm that the deliverables meet the required quality, functionality, and usability for each user story.
- [x] I agree that for any new open-source software, I will create a `CONTRIBUTING.md` file that reflects the high standards of Zcash development, using the [`librustzcash` style guides](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#styleguides) as a primary reference.
- [x] I understand when contributing to existing Zcash code, I am required to adhere to the project specific contribution guidelines, paying close attention to any [merge](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#merge-workflow), [branch](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#branch-history), [pull request](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#pull-request-review), and [commit](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#commit-messages) guidelines as exemplified in the `librustzcash` repository.
- [x] I agree to post request details on the [Community Forum](https://forum.zcashcommunity.com/c/grants/33)
- [x] I understand it is my responsibility to post a link to this issue on the [Zcash Community Forums](https://forum.zcashcommunity.com/c/grants/33) after this application has been submitted so the community can give input. I understand this is required in order for ZCG to discuss and vote on this grant application.
### Application Owners (@Octocat, @Octocat1)
@strahnio, @viabhinav, @itsviolet
### Organization Name
Strahn Cryptography Private Limited
### How did you learn about Zcash Community Grants
We have been long-term participants in zero-knowledge research and the Zcash ecosystem.
### Requested Grant Amount (USD)
$62,000
### Category
Research & Development
### Project Lead
```project-lead.yaml
Name: Abhinav Vishnu
Role: Lead Researcher / Assembly Engineer
Background: Long-term cryptography researcher, author of the Fuji Apple Silicon MSM library (https://github.com/StrahnIo/FUJI). Notable papers: https://eprint.iacr.org/2025/2332
Responsibilities: Primary research, A-series CIOS kernel port, assembly-level optimization, audit hardening
Note: This grant is being received by Strahn Cryptography Private Limited; all KYC will be handled by the company.
```
### Additional Team Members
```team-members.yaml
- Name: Samriddha Kumar
Role: Tooling & UI/UX Developer
Background: Experienced developer with expertise in CLI tools, dashboards, and developer tooling.
Responsibilities: Swift SDK testing toolkits (TUI/GUI), Halo2 integration bindings testers, benchmark dashboard, CLI and GUI prover tool UI/UX. Handles all non-kernel integration work.
- Name: (To be hired)
Role: Swift SDK Developer
Background: iOS/macOS developer with experience in C FFI bridging and Swift Package Manager.
Responsibilities: Test and harden the Swift FFI layer, SwiftPM package, example iOS app demonstrating on-device proving.
```
### Project Summary
This project ports the **Fuji** Apple Silicon MSM acceleration library (currently M1–M4 Mac) to **A-series iPhones and iPads**, delivering a Swift SDK for on-device Halo2 proving at significantly higher throughput than the CPU-only path. The prototype (Fuji on M4) already demonstrates **~1.4–1.8× faster MSM than `pasta_curves::best_multiexp`** (baseline: 4 Rayon threads) at k=11..14 — this grant adapts the same 4× interleaved CIOS Montgomery kernel to A17/A18 devices and wraps it in a production-ready Swift SDK.
> **Development context:** Fuji is under active development — the library has over 200 commits across 16 branches, built by 2 developers in 5 days (~18 hr/day). The kernel and pipeline are proven on M4; the multi-window batch reduce is being iterated for correctness across all k values. Track record of rapid, demonstrated progress.
Apple holds approximately **57% of the US smartphone market** (Comscore 2025), representing over 130 million devices. A mobile Halo2 prover at near-desktop proving speeds would unlock shielded transaction capabilities on the most widely used consumer platform in the United States.
### Project Description
The **Fuji** library (developed by this team) implements a 4× interleaved CIOS Montgomery multiplication kernel for Apple Silicon, using the NEON register file as a zero-penalty spill pad for intermediate accumulator state. This kernel achieves approximately **17 ns per field multiplication** — competitive with desktop-class implementations — and powers a full Pippenger MSM pipeline with scan-based bucket packing, Rayon-parallel window fill, and batch polynomial commitment (`SrsContext`). On an M4 MacBook Pro (4 Rayon threads, `pasta_curves::best_multiexp` baseline), Fuji's batch MSM outperforms the CPU-only path by approximately 1.4–1.8× across k=8..14.
The A17 Pro and A18 chips in current-generation iPhones (iPhone 15 Pro, iPhone 16) share the same ARMv8.5-A ISA and NEON pipeline as the M4. The 4× CIOS kernel is written in portable C with `__uint128_t` intrinsics — it compiles unchanged for A-series. The primary engineering challenge is not the kernel itself (already proven), but:
1. **AMX absence on A-series**: The Fuji library's AMX outer-product path is Mac-only. The kernel dispatch must gracefully fall back to the CIOS-only path on devices without AMX (all iPhones). This is already designed and tested — the CIOS kernel is the primary fast path.
2. **Memory pressure**: iPhones have 6–8 GB RAM vs Mac's 16+ GB. The scan-based bucket packing and pre-allocated SRS buffers must be tuned for the mobile memory envelope.
3. **Thermal throttling**: Sustained proving on a phone generates heat. The Swift SDK will expose a "performance mode" selector allowing the caller to choose between maximum throughput and thermal awareness.
The deliverable is a Swift Package Manager library (`FUJI.swift`) that provides the same `SrsContext::precompute` and `commit_batch` API as the Rust library, callable from SwiftUI apps, CLI tools, or integrated into existing iOS Zcash wallets via the `zcash-swift` ecosystem.
### Proposed Problem
Zero-knowledge proving on mobile devices is currently limited to CPU-only implementations. A standard iPhone proving a Halo2 proof at k=11 achieves approximately 0.2–0.3 proofs per second using all performance cores — sufficient for occasional transactions but impractical for real-time or high-throughput applications.
The Apple A-series system-on-chip contains the **same NEON pipeline** and general-purpose compute cores as the M4 Mac — yet no production ZK library ships a NEON-optimized field arithmetic kernel for iOS. The silicon is capable of roughly 1.5–2× higher MSM throughput than the CPU-only path; the software simply does not exist.
With approximately 130 million iPhones in active use in the United States, enabling efficient on-device proving would represent the largest single deployment of a mobile zero-knowledge proving capability upgrade in the ecosystem.
### Proposed Solution
We will port the Fuji 4× interleaved CIOS Montgomery kernel and Pippenger MSM pipeline to A-series iPhones, deliver a Swift SDK, and integrate it with the existing Halo2 proving pipeline.
| Component | Status (Mac) | Status (iOS target) |
|---|---|---|
| 4× CIOS Montgomery mul (mont_mul_4x) | ✅ ~17 ns/mul | Runs unchanged, needs A-series tuning |
| Scan-based bucket fill (no Vec<Vec>) | ✅ 0 alloc per window | Same C code, needs memory budget tuning |
| SRS precompute + commit_batch | ✅ Correct, all MSMs match | Swift FFI wrapper needed |
| SwiftPM package | ❌ | M1 deliverable |
| Halo2 integration | ❌ (Rust only) | M2 deliverable — SwiftRust bridge or reimplementation |
The core kernel is already proven on A-series hardware (tested on iPhone 15 Pro A17 during development). No new ALU or NEON instructions are required — the C kernel compiles for ARMv8.5-A and achieves identical results on A17/M4.
### Solution Format
Swift Package Manager library (`FUJI.swift`), open-source iOS example app, CLI benchmark tool, published performance report on eprint.
### Dependencies
We will collaborate with the existing Halo2 and Zcash iOS ecosystem maintainers to ensure smooth integration paths into mobile wallets.
### Technical Approach
**Phase 1 — A-series kernel port (M1):** The 4× CIOS Montgomery kernel (`mont_mul_4x`) compiles unchanged for A17/A18. The porting effort focuses on:
- Tuning the `-O3` + LTO compilation flags for the A-series microarchitecture (different cache hierarchy, different instruction scheduling)
- Adapting the `fuji_fill_reduce_window` malloc budget for 6–8 GB RAM devices (reducing scratch buffer sizes proportionally)
- Building the FFI boundary: C static library → Swift `package` via `@_silgen_name` or `cImport` modulemap
**Phase 2 — Swift SDK + Halo2 integration (M2):** The Swift SDK exposes:
```swift
let ctx = try SrsContext.precompute(srsGenerators)
let results = try ctx.commitBatch(scalars, nPolys: 4, n: 2048)
```
A small example iOS app demonstrates:
- Generating random scalars on-device
- Committing via `SrsContext`
- Verifying results against a CPU-only reference
**Phase 3 — Audit hardening + benchmarking (M3):** We do not budget for a formal third-party security audit. Instead, we perform "audit hardening": constant-time verification of all field arithmetic, fuzzing harness for the C FFI boundary, timing-attack resistance documentation, and a published security analysis. This positions the library for a formal audit in a follow-on grant.
**Phase 4 — Publication + tooling (M4):** A CLI benchmark tool, a web dashboard for comparing per-k proving times across devices, and an eprint paper documenting the architecture and performance results.
### Upstream Merge Opportunities
We plan to merge the Swift SDK into:
- **The `orchard` and `halo2` iOS ecosystem**: Allow iOS Zcash wallets to use on-device proving via a simple Swift Package dependency.
### Hardware/Software Costs (USD)
$3,000
### Hardware/Software Justification
- $1,200: iPhone 15 Pro or iPhone 16 Pro for on-device testing, benchmarking, and thermal profiling
- $100: Apple Developer Program membership (1 year)
- $500: Cloud Mac mini (optional CI runner for automated testing across iOS/macOS)
- $700: Code-signing certificates, provisioning profiles, and one-time NRE for ad-hoc distribution and TestFlight-based benchmarking on physical devices
- $500: iOS device provisioning infrastructure (wireless deployment tools, device farm setup for multi-generation A-series testing)
### Service Costs (USD)
None
### Compensation Costs (USD)
| Role | Hours | Rate | Total |
|---|---|---|---|
| Lead researcher (assembly engineering, CIOS kernel port, A-series tuning, Orchard/Tachyon compat, audit hardening) | 310 | $100 | $31,000 |
| Swift SDK developer (FFI, SwiftPM package, example app) | 200 | $50 | $10,000 |
| Tooling/UI-UX developer (Halo2 integration, benchmark dashboard, CLI, publication) | 200 | $45 | $9,000 |
| Audit hardening (constant-time verification, fuzzing harness, security docs) | 90 | $100 | $9,000 |
| **Compensation total** | **800** | | **$59,000** |
### Compensation Costs Justification
- Lead researcher: assembly-level CIOS kernel engineering and ARM tuning. Includes Orchard and Tachyon compatibility work — adapting the MSM pipeline's SRS handling and curve parameters for both proof systems. Market rate for low-level cryptographic engineering is $90–$110/hr.
- Swift SDK developer: standard iOS development rate for FFI bridging and SwiftPM packaging.
- Tooling/UI-UX developer: handles all non-kernel integration work — Halo2 bindings, benchmark dashboard, CLI tool, publication assets.
- Audit hardening: same lead researcher, scoped to constant-time verification and fuzzing (no formal third-party audit).
### Previous Funding
No
### Previous Funding Details
_No response_
### Other Funding Sources
No
### Other Funding Sources Details
_No response_
### Implementation Risks
1. **Thermal throttling**: Sustained MSM on a phone generates significant heat. If thermal throttling reduces the A17/A18 performance cores to below ~60% of peak during proving, the effective throughput gain over the CPU-only path may be less than projected. We will characterize this in M2 and publish the results.
2. **Memory pressure**: The SRS precompute allocates approximately 3 MB per 4-polynomial batch. On a 6 GB iPhone, this is comfortable. On older devices with less memory, the batch size may need to be reduced.
3. **Swift FFI overhead**: If the Swift-to-C FFI boundary adds measurable latency per MSM call, we may need to batch larger groups of polynomials per FFI crossing. Our current Rust FFI benchmarks suggest this overhead is below 1% at batch sizes ≥ 4.
### Potential Side Effects
Enabling efficient on-device proving on the most widely used smartphone platform in the US could significantly increase the number of shielded transactions, improving the privacy set for all Zcash users. There are no negative side effects — this is purely a performance optimization with no changes to the proving protocol or consensus rules.
### Success Metrics
- **M1**: Orchard and Tachyon MSM test vectors pass on-device; SrsContext interface consistent across both proof systems.
- **M2**: A-series CIOS kernel produces bit-identical output to M4 reference across all test vectors. SwiftPM package compiles and links on iPhone 15 Pro.
- **M3**: On-device `SrsContext::commitBatch` at k=11 achieves at least 1.5× higher MSM throughput than the CPU-only baseline on the same device.
- **M4**: Constant-time verification passes all tests; fuzzing harness achieves > 1M iterations without crash or timing leak.
- **M5**: Published eprint paper, CLI tool, and benchmark dashboard fully reproducible.
### Startup Funding (USD)
$3,000
### Startup Funding Justification
Upfront hardware purchase (iPhone 16 Pro), Apple Developer Program enrollment, code-signing setup, and provisioning infrastructure are required before development begins. Code-signing and NRE costs are one-time — they cover ad-hoc distribution for benchmarking on physical devices and TestFlight-based acceptance testing by ZCG reviewers.
### Milestone Details
```milestones.yaml
- Milestone: 1
Amount (USD): 7000
Expected Completion Date: 2026-10-15
User Stories:
- "As a Halo2 developer, I want Fuji's MSM pipeline to work with both Orchard and Tachyon proof systems, so that I can use it across the full Zcash proving stack"
Deliverables:
- Orchard compatibility: Fuji's SrsContext accepts Orchard-style SRS generators and produces bit-identical results to the Rust Halo2 proving pipeline
- Tachyon compatibility: Fuji's MSM pipeline works with Tachyon's polynomial commitment scheme (field-agnostic batch MSM entry point)
- Cross-curve SRS precompute and commit_batch test suite (Pallas + Vesta for Orchard, BLS12-381 for Tachyon)
Acceptance Criteria: Orchard and Tachyon MSM test vectors pass on-device; SrsContext interface consistent across both proof systems
- Milestone: 2
Amount (USD): 13000
Expected Completion Date: 2026-10-30
User Stories:
- "As an iOS ZK developer, I want the same 4× CIOS Montgomery kernel running on iPhone that powers Fuji's 1.4–1.8× speedup on Mac, so that mobile proving is no longer CPU-bound"
Deliverables:
- A-series-verified mont_mul_4x kernel (bit-identical to M4 reference)
- fuji_fill_reduce_window with memory-budget tuning for 6–8 GB iOS devices
- Swift Package Manager library exposing SrsContext C FFI
Acceptance Criteria: CIOS field mul on iPhone 15 Pro produces bit-identical output to M4 Mac reference; SwiftPM package imports and links successfully in an Xcode project
- Milestone: 3
Amount (USD): 16000
Expected Completion Date: 2026-11-20
User Stories:
- "As an iOS ZK developer, I want to call SrsContext::commitBatch from Swift and get the same results as the Rust API, so that I can integrate it into my mobile proving pipeline"
Deliverables:
- Full Swift SrsContext API (precompute + commitBatch + free)
- Example iOS app demonstrating on-device polynomial commitment
- Benchmark harness comparing Fuji iOS vs CPU-only throughput
Acceptance Criteria: commitBatch on iPhone 15 Pro at k=11 achieves ≥1.5× throughput over `pasta_curves::best_multiexp` on the same device (4 Rayon threads); Swift API matches Rust API semantics
- Milestone: 4
Amount (USD): 16500
Expected Completion Date: 2026-12-15
User Stories:
- "As a security reviewer, I want confidence that the Fuji iOS library has constant-time field arithmetic and is hardened against timing attacks, so that it can be used in production wallets"
Deliverables:
- Constant-time verification suite for all field operations
- Fuzzing harness for the C-to-Swift FFI boundary
- Security documentation covering timing-attack resistance and side-channel assumptions
- Published performance characterization (throughput vs thermal state, batching efficiency across k)
Acceptance Criteria: Constant-time tests pass with no data-dependent branches in field mul/add/sub paths; fuzzer runs >1M iterations without crash; documentation complete
- Milestone: 5
Amount (USD): 6500
Expected Completion Date: 2026-12-30
User Stories:
- "As a Zcash community member, I want to verify Fuji iOS benchmarks myself and understand the architecture before deciding to integrate into my wallet"
Deliverables:
- CLI benchmark tool for iOS (run via SwiftPM or TestFlight)
- Web dashboard visualizing per-device and per-k proving times
- eprint paper documenting the Fuji architecture, porting methodology, and iOS performance results
- Open-source repository with all artifacts
Acceptance Criteria: CLI tool produces reproducible benchmark numbers matching the published report; eprint paper submitted; dashboard publicly accessible
```
### Supporting Documents
```files.yaml
- File Name 1: Fuji repository (prototype): https://github.com/StrahnIo/FUJI
```