### Terms and Conditions
- [x] I agree to the [Grant Agreement](https://9ba4718…c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471_f81ef4e4b5f040038350270590eb2e42.pdf) terms if funded
- [x] I agree to [Provide KYC information](https://9ba4718c-5c73-47c3-a024-4fc4e5278803.usrfiles.com/ugd/9ba471_7d9e73d16b584a61bae92282b208efc4.pdf) if funded above $50,000 USD
- [x] I agree to disclose conflicts of interest
- [x] I agree to adhere to the [Code of Conduct](https://forum.zcashcommunity.com/t/zcg-code-of-conduct/41787) and [Communication Guidelines](https://forum.zcashcommunity.com/t/zcg-communication-guidelines/44284)
- [x] I understand all milestone deliverables will be validated and accepted by their intended users or their representatives, who will confirm that the deliverables meet the required quality, functionality, and usability for each user story.
- [x] I agree that for any new open-source software, I will create a `CONTRIBUTING.md` file that reflects the high standards of Zcash development, using the [`librustzcash` style guides](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#styleguides) as a primary reference.
- [x] I understand when contributing to existing Zcash code, I am required to adhere to the project specific contribution guidelines, paying close attention to any [merge](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#merge-workflow), [branch](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#branch-history), [pull request](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#pull-request-review), and [commit](https://github.com/zcash/librustzcash/blob/main/CONTRIBUTING.md#commit-messages) guidelines as exemplified in the `librustzcash` repository.
- [x] I agree to post request details on the [Community Forum](https://forum.zcashcommunity.com/c/grants/33)
- [x] I understand it is my responsibility to post a link to this issue on the [Zcash Community Forums](https://forum.zcashcommunity.com/c/grants/33) after this application has been submitted so the community can give input. I understand this is required in order for ZCG to discuss and vote on this grant application.
### Application Owners (@Octocat, @Octocat1)
@Jainakin
### Organization Name
Hardik Jain
### How did you learn about Zcash Community Grants
I learned about Zcash Community Grants through its website and GitHub repository, the Zcash Community Forum, and public discussions about reusable light-client SDKs for cross-platform mobile developers.
### Requested Grant Amount (USD)
$10,000
### Category
Wallets
### Project Lead
```project-lead.yaml
Name: Hardik Jain
Role: Lead SDK Engineer
Background: I am a mobile-wallet and SDK engineer specializing in Flutter/Dart and native iOS and Android integration. I authored [`@utexo/wdk-rgb-lightning`](https://github.com/UTEXO-Protocol/wdk-rgb-lightning), an RGB Lightning module for Tether's WDK, including Rust/C FFI bridges, iOS and Android binary packaging, external signing, secret management, automated testing, and releases. I previously worked on [AQUA Wallet](https://github.com/AquaWallet/aqua-wallet), a production Flutter wallet, where I built a Dart FFI module integrating Blockstream's Green Development Kit for Bitcoin and Liquid operations. This gives me directly relevant experience with Dart API design, Swift/Kotlin platform integration, secure wallet architecture, cross-platform delivery, and long-term SDK maintenance.
Responsibilities: I will own technical direction, maintainer and integrator coordination, Dart API design, Swift and Kotlin adapter implementation, threat modeling, release engineering, test infrastructure, documentation, milestone reporting, defect remediation, and post-release maintenance.
```
### Additional Team Members
```team-members.yaml
None / N/A. I am the sole applicant and will be responsible for all grant deliverables.
```
### Project Summary
I will build a production-grade, open-source Zcash Flutter Wallet SDK for Android and iOS, exposing a stable Dart wallet API backed by the existing Zcash Swift and Android Wallet SDKs. The plugin will reuse the native SDKs' supported synchronization, database migration, transaction proposal, PCZT, Tor, and Ironwood functionality instead of creating a third wallet engine or binding Dart to private Rust/JNI/C-ABI implementation details.
### Project Description
Flutter developers currently lack a maintained, production-grade package that exposes the supported public APIs of the Zcash Android and Swift Wallet SDKs through one coherent Dart contract. I will fill that gap with an embeddable wallet SDK suitable for independent wallets and applications that add non-custodial Zcash functionality.
I will deliver a Flutter plugin, not a standalone wallet product or UI component library. Integrating applications will retain ownership of product UX, policy, analytics, and key-backup flows. The plugin will own the cross-platform wallet integration boundary and provide typed APIs, lifecycle management, documentation, tests, and release artifacts.
I will keep the implementation boundary deliberately thin: Flutter app -> stable Dart API -> private generated Pigeon transport -> Swift/Kotlin adapter -> public native wallet SDK -> upstream-packaged Rust library.
On iOS, I will depend on `ZcashLightClientKit` through Swift Package Manager. That package already downloads its checksummed `libzcashlc` XCFramework for ordinary consumers. On Android, I will depend on the published `cash.z.ecc.android:zcash-android-sdk` Maven artifact, which carries the SDK's backend/JNI implementation transitively. Flutter application developers will not need a Rust toolchain, and I will not redistribute or directly call undocumented native symbols.
The production scope includes:
- Wallet creation, restoration, reopening, wiping, aliases, spending accounts, imported view-only accounts, and supported UFVK workflows.
- Explicitly isolated mainnet/testnet/test fixtures; sync lifecycle, connection/recovery progress, heights, and foreground/background behavior.
- Pool-aware balances; supported unified, custom unified, Sapling, transparent, TEX, and single-use address capabilities.
- History/pagination, memos, recipients, outputs, enhancement, and transparent UTXO refresh.
- Structured transfer, shielding, and ZIP-321 payment proposals represented by process-scoped native handles plus an inspectable Dart summary of every field that the agreed public native baselines expose. At the inspected Swift baseline this includes transaction count, total fee, and whether legacy Orchard funds are spent; richer step/pool/expiry detail will be exposed only if it becomes a supported public native contract.
- Creation/submission, broadcaster workflows, typed results, PCZT roles, external signing, and endpoint behavior supported by the selected native baselines.
- Ironwood plus high-level Orchard-to-Ironwood migration that preserves native privacy, scheduling, and recovery decisions.
- Rewind/rescan, server validation/evaluation, endpoint changes where supported, Tor status/configuration, optional exchange rates, and capability discovery for intentional platform differences.
- A documented foreground/background integration contract. Work that the operating system permits without a Flutter engine will run through native entry points and native-held key handles; the SDK will not pretend that iOS or Android guarantees unrestricted background execution.
"Parity" means functional parity for the agreed, published consumer capability matrix. It does not mean mechanically mirroring every Swift or Kotlin method. Debug SQL, internal JNI/C-ABI functions, generated gRPC types, test-only interfaces, and unstable/incubator features will not become public Dart API. Platform-only capabilities will be either normalized safely, exposed behind explicit capability flags, or documented as unsupported with a technical rationale. No silently degraded behavior will be presented as parity.
The independently versioned, permissively licensed Flutter API will identify its tested native versions. Compatibility CI, upgrade/migration guidance, security and logging policies, contributor/release documentation, a threat model, an example, and six funded maintenance months are deliverables.
#### Prior Art and Non-Duplication
I am not claiming this is the first Flutter-related Zcash work. The existing [`zcash` package](https://pub.dev/packages/zcash) is an early direct-Rust FFI package, and several Flutter wallets have application-specific Rust bindings. A separate July 2026 community proposal describes a three-package Flutter SDK built directly on `zcash_client_backend` and `zcash_client_sqlite`, with a bundled wallet UI ([forum proposal](https://forum.zcashcommunity.com/t/a-flutter-sdk-for-zcash-ffi-over-librustzcash-with-a-drop-in-shielded-wallet-ui/56639)).
My proposal has a different ownership boundary: it adapts the supported native wallet SDKs, contains no Flutter UI kit, and avoids maintaining an independent wallet database/synchronization engine. That distinction can reduce long-term protocol and migration drift, but architectural difference alone does not justify duplicate funding. At the start of Milestone 1, I will publish a coordination record and invite the other Flutter proposer and the Android and Swift SDK maintainers to identify opportunities to collaborate, merge, reuse, or rescope. I will not expand implementation beyond Milestone 1 until material overlap has a documented disposition.
### Proposed Problem
Zcash's mobile wallet behavior is already implemented in substantial Swift, Kotlin, and Rust codebases, but a Flutter team cannot consume those capabilities through a stable Dart package. A team that wants shielded ZEC in a Flutter application must currently do one of the following:
1. Build and maintain separate Swift and Kotlin integrations inside its application.
2. Extract an application-specific bridge from an existing wallet.
3. Bind directly to Rust and assume responsibility for wallet database, synchronization, migrations, native binaries, FFI safety, and protocol upgrades.
Each option creates a high entry cost and a long-lived security and maintenance obligation. It also encourages ecosystem fragmentation: lifecycle rules, error handling, pool migrations, fee/proposal semantics, Tor behavior, and recovery behavior can drift between implementations.
The native SDKs already encapsulate these difficult concerns. The Android SDK's public `Synchronizer` coordinates lightwalletd access, compact-block download, scanning/trial decryption, wallet data, and payments; its architecture explicitly treats JNI and network representations as internal rather than public APIs. The Swift SDK similarly exposes `Initializer` plus `Synchronizer`, with public state/event streams and proposal-based transaction APIs, while ordinary SwiftPM consumers receive a prebuilt Rust XCFramework. The missing layer is therefore not another cryptographic or synchronization implementation. It is a carefully designed, maintained Flutter consumer adapter.
The challenge is more than forwarding method calls. Swift and Android have different initialization and lifecycle semantics, different reactive primitives (Combine/`AsyncThrowingStream` versus Kotlin `Flow`/`StateFlow`), distinct error taxonomies, and some platform-specific capabilities. A production SDK must normalize those differences without erasing security-relevant information or exposing unstable implementation details.
### Proposed Solution
I will deliver one app-facing Flutter plugin with:
- A hand-designed Dart domain API based on wallet use cases, not a generated mirror of Swift/Kotlin classes.
- Private Pigeon-generated codecs and host APIs compiled in the same package version as their Dart counterpart.
- Swift and Kotlin adapters that call only supported public native SDK surfaces.
- Explicit wallet-handle ownership, cancellation, cleanup, and multi-engine behavior.
- Typed state streams and errors with stable codes, retryability, upstream/platform metadata, and privacy-safe messages.
- A two-phase payment contract: propose and review the upstream-supported summary first, then authorize/create/submit. There will be no convenience `send()` that hides the total fee, transaction count, legacy-pool warning, or other review information actually available from the selected native baselines. The grant will not promise proposal fields that the public native APIs do not expose.
- A pluggable key-authority contract with an opaque native key handle, a documented secure native storage reference implementation, and explicit secret-bearing import/restore/backup operations. After enrollment, ordinary authorization and eligible background work will resolve keys natively rather than repeatedly returning secrets through Dart. The plugin will not persist plaintext seeds or spending keys and will never include them in logs, errors, crash reports, or analytics.
- A high-level Ironwood migration API whose decisions remain in the native migration engine. Dart will represent state, instructions, required user consent, and scheduling; it will not invent transfer cadence, denomination, or recovery policy.
- Reproducible CI and end-to-end validation against testnet and deterministic Darkside/regtest fixtures, plus controlled low-value mainnet smoke validation before general availability.
- A clean-room example app that consumes the published package from pub.dev, with no path dependency, local SDK checkout, or Rust toolchain.
- Documented security verification of the Flutter/native boundary, lifecycle/concurrency behavior, secret handling, packaging, and release supply chain, followed by remediation before general availability.
The result will let a Flutter developer add the package, configure a supported lightwalletd endpoint and key provider, and use Zcash wallet capabilities through a documented API while continuing to receive protocol and database behavior from the maintained native SDKs.
### Solution Format
The solution will be delivered as:
- A public GitHub repository under my [`Jainakin`](https://github.com/Jainakin) account with a permissive license, with transfer or co-maintenance by an appropriate Zcash organization remaining possible by mutual agreement.
- A production Flutter plugin published to pub.dev under the proposed package name `zcash_flutter_wallet_sdk`, subject only to name availability when the first release is created.
- Swift/Kotlin adapters in the same release, using SwiftPM and the upstream Maven dependency graph.
- Stable Dart API, API/integration/migration/troubleshooting documentation, release policy, and capability parity matrix with explicit exclusions.
- Architecture records, threat model, key-authority and logging/privacy designs, SBOM, checksums/provenance, and release checklist.
- Example wallet plus separate clean-room consumer; unit, contract, native, reorg, failure, lifecycle, performance, and end-to-end tests.
- Signed/tagged source and pub.dev releases with changelogs.
- A public security-verification and remediation summary, subject to responsible-disclosure redactions.
- Six months of compatibility maintenance, security response, issue triage, and integration support after general availability.
### Dependencies
#### Technical Dependencies
- [Zcash Swift Wallet SDK](https://github.com/zcash/zcash-swift-wallet-sdk), consumed through its public Swift API and Swift Package Manager product.
- [Zcash Android Wallet SDK](https://github.com/zcash/zcash-android-wallet-sdk), consumed through its public `sdk-lib` API and published Maven artifact.
- `librustzcash`, `libzcashlc`, JNI libraries, SQLite, gRPC, Tor, and lightwallet protocol dependencies transitively selected and packaged by the native SDKs. I will not version or call those layers independently.
- Flutter stable, Dart, and [Pigeon](https://pub.dev/packages/pigeon) for the private typed host boundary.
- Community-operated lightwalletd endpoints for testnet/manual validation and deterministic Darkside/regtest infrastructure for reproducible integration tests.
- Apple and Android build/signing toolchains, devices/emulators, and CI runners that meet the native SDKs' supported minimums. At the inspected baseline, Swift declares iOS 13 and Android declares API 27; the final matrix will use the mutually agreed stable SDK baselines at project start. Because the upstream Swift SDK currently distributes through SwiftPM rather than CocoaPods, the iOS line will require [Flutter's supported SwiftPM plugin path](https://docs.flutter.dev/packages-and-plugins/swift-package-manager/for-plugin-authors) (currently Flutter 3.44+) and will test mixed projects that still use CocoaPods for unrelated plugins. A pure CocoaPods-only Zcash dependency path will not be fabricated by vendoring upstream binaries.
The distribution channel is itself a release gate. On the 2026-09-07 inspection snapshot, Swift `3.0.0` is a signed GitHub release and its package manifest references a checksummed `libzcashlc` XCFramework. Android has a signed `v3.0.0` GitHub tag, while Maven Central's indexed `zcash-android-sdk` page still identifies `2.7.0-rc.4` as its current version. This may be publication or indexing lag, but the Flutter GA baseline will use only versions that are actually obtainable through the documented consumer package manager and will record resolved artifacts/checksums in CI. Ironwood acceptance work is contingent on both selected public artifacts exposing the required production APIs.
#### Resource and Collaboration Dependencies
- Public technical review from people familiar with the native SDK maintenance roadmaps, requested through the relevant GitHub repositories and the Zcash Community Forum during Milestone 1.
- A documented non-duplication and collaboration decision with the author of the July 2026 direct-Rust Flutter proposal before implementation expands beyond Milestone 1.
- At least two independent Flutter integrators recruited through public Zcash and Flutter channels to validate milestone deliverables and perform clean-room integrations. Their identities and reports will be published before I claim the corresponding milestone.
- Timely upstream responses when a public API gap is discovered. I will not assume upstream merge acceptance or represent maintainer decisions as being under my control.
#### Dependency Management Policy
Each Flutter release will pin or constrain only published, supported native releases and publish a tested compatibility matrix. Automated canary builds will assess new native SDK releases. Security or protocol-critical updates will receive priority, while breaking updates will be released with migration notes and semantic-versioning discipline. The plugin will not silently switch native SDK versions or download unsigned binaries at runtime.
### Technical Approach
#### 1. Supported Native Facades, Not Direct Rust FFI
The iOS adapter will call `Initializer` and `SDKSynchronizer`/`Synchronizer`. The Android adapter will call `Synchronizer.new`, `CloseableSynchronizer`, and stable companion SDKs such as the production Orchard migration API. These are the layers intended to own database initialization/migration, synchronization, proposal construction, transaction persistence/submission, Tor behavior, and protocol upgrades.
Dart FFI will not be used to call the binaries embedded in the native SDK artifacts. Those binaries expose host-specific implementation interfaces: C ABI on Swift and JNI on Android. Calling them from Dart would couple the plugin to private symbols, bypass public model validation and lifecycle orchestration, duplicate native SDK logic, complicate library loading, and create a third compatibility surface. The current upstream discussion about duplicated Swift/Android FFI logic reinforces the need to consume the SDK facades rather than add another FFI wrapper ([librustzcash issue #2785](https://github.com/zcash/librustzcash/issues/2785)).
#### 2. Public Dart Contract
The public API will use immutable, documented Dart models. Zatoshi amounts, block heights, account identifiers, transaction identifiers, proposals, PCZTs, and byte sequences will receive explicit validation and safe-copy semantics. Numeric transport will be tested at signed and unsigned 64-bit boundaries so JavaScript-style number assumptions cannot enter mobile codecs.
Generated Pigeon classes will remain private implementation details. Pigeon explicitly warns that generated channel code can break between versions and that Dart and host code must be generated with the same Pigeon version; keeping all generated sides in one plugin release avoids cross-package skew. A hand-written Dart layer will provide semantic version stability independently of the generator.
The API will expose a capability descriptor. A capability must not appear available merely because one platform has a method with a similar name. Unsupported or upstream-experimental behavior will fail before execution with a typed capability error.
Native objects that cannot be transported faithfully, including synchronizers and Swift transaction proposals, will remain in per-engine native registries behind opaque, generation-checked handles. Dart receives immutable review summaries, not private protobuf/JNI/C-ABI models. Proposal handles are process-scoped, wallet-scoped, invalidated on close/restart, and deliberately not persisted; applications must repropose after process loss. This avoids depending on Android-only proposal serialization or reaching into Swift's internal `FfiProposal`.
#### 3. Lifecycle, Concurrency, and Streams
Each open wallet will have an opaque handle mapped to exactly one native synchronizer/adapter instance. The registry will prevent alias/network collisions, serialize mutating wallet operations, cancel subscriptions deterministically, and release native resources on `close`, wipe, plugin detachment, or engine teardown.
Every long-running host call will have an operation identifier and cancellation registry because cancelling a Dart `Future` does not by itself cancel Swift tasks or Kotlin coroutines. Native work will run off the UI thread in owned structured-concurrency scopes; platform-channel replies and host-to-Dart events will be marshalled according to Flutter's main-thread requirements. Late replies from cancelled or detached engines will be discarded deterministically.
The plugin will support multiple Flutter engines correctly. Flutter creates a plugin instance per engine, so engine-owned state will not be placed in uncoordinated static globals. Shared native process resources will be reference-counted or guarded, and wallet aliases will remain unique across active instances.
The adapters will reconcile native lifecycle differences:
- Swift constructs an `Initializer`, calls `prepare`, then explicitly calls `start`; it publishes Combine state/events and uses `AsyncThrowingStream` for transaction results.
- Android's `Synchronizer.new` performs initialization and starts the synchronizer; it publishes Kotlin `Flow`/`StateFlow`, provides foreground/background hooks, and closes through `CloseableSynchronizer`.
These will map to a documented Dart state machine such as `closed`, `opening`, `ready`, `syncing`, `synced`, `stopping`, and `failed`. Events will be broadcast streams with bounded buffering/coalescing for replaceable progress updates, while terminal transaction and error events will never be dropped. Ordering and cancellation rules will be contract-tested on both platforms.
#### 4. Accounts and Key Authority
Wallet initialization will distinguish new, restore, existing, and view-only flows while adapting the different native APIs. Account identifiers and purposes will be preserved; a Dart index will not be used as durable account identity.
The public contract will separate wallet operations from key custody through a `ZcashKeyAuthority`-style interface. Its production reference provider will live natively and return only an opaque key handle to Dart. It will use Keychain/Keystore access controls and encrypted application storage where needed. It will not claim that arbitrary seed material is stored directly inside Secure Enclave or StrongBox. Where hardware-backed protection is available, it will protect a wrapping key or access-control operation according to the platform's documented guarantees.
Secret material may cross the Dart/native boundary only in explicitly named creation, restoration, enrollment, one-shot authorization, or backup operations when the selected key authority requires it. No native wallet/database lock will be held while awaiting an app-supplied Dart callback. Secrets will be copied into native-owned memory for the shortest practical duration and cleared on a best-effort basis. The default logging, error, test-fixture, and telemetry paths will reject mnemonics, seeds, spending keys, viewing keys, memos, addresses, and transaction identifiers unless an API explicitly documents a deliberate export. No claim will be made that a managed runtime can guarantee perfect zeroization.
#### 5. Transactions and Privacy-Critical Decisions
The Dart API will preserve the native proposal model. A caller will request a transfer, shielding, ZIP-321, or migration proposal; inspect the request plus the public native summary; explicitly authorize; then create and submit using the generation-checked native handle. Transaction count, total fee, and legacy-Orchard use are available at the inspected Swift baseline. Detailed ordinary-proposal steps, pool crossings, and expiry are not currently public Swift `Proposal` fields and will not be claimed unless a maintainer-approved upstream API supplies them. Multi-transaction counts and per-transaction submission results will remain visible.
PCZT workflows will preserve separate creator, prover, signer, and finalizer roles. Byte payloads will be size-bounded and copied safely. The broadcaster API will preserve separation between creation and submission, endpoint selection, Tor failure classification, and retry/reconciliation results where supported upstream.
For Orchard-to-Ironwood migration, the Flutter layer will not calculate denominations, timing, anchor buckets, due-ness, or recovery decisions. It will drive the instructions and persisted state returned by the native migration engine, expose required background wakeups, and require applications to present the upstream privacy/cost implications before authorization. Platform scheduling limitations will be documented rather than hidden.
Background execution will be an explicit host contract, not a Dart timer. The adapters will expose native task entry points and scheduling instructions for work the upstream SDK supports without a live synchronizer or Flutter isolate. The example integration will show BGTaskScheduler-compatible iOS wiring and Android scheduler/lifecycle wiring where appropriate, including expiration/cancellation. Operations requiring interactive authentication will surface `userActionRequired` and resume in the foreground rather than weakening key-access policy.
#### 6. Errors and Diagnostics
Errors will include a stable Flutter code, operation, category, retryability, native platform, upstream code/class where available, and a privacy-safe diagnostic message. Cancellation will remain cancellation and will not be converted into a generic failure. Server/network mismatch, seed-required, invalid proposal, insufficient funds, Tor initialization, submit/reconciliation, migration attention, and unsupported-capability errors will be distinguishable without string parsing.
Logging will be disabled or minimal by default in release mode. Diagnostic logging will be opt-in, redact sensitive values, and document exactly what is emitted. Backend tracing will never be enabled by default.
#### 7. Verification Strategy
Verification will cover Dart models/state/errors, malformed and boundary-value Pigeon codecs, Swift/Kotlin adapters, and cross-language fixtures. Deterministic Darkside/regtest suites will exercise reorg, rewind, restore, submission failure, and recovery; testnet suites will cover account, sync/read, spend, PCZT, and supported Ironwood paths; release validation will add privacy-controlled low-value mainnet smoke tests.
Lifecycle/soak tests will cover cancellation, process and engine detachment, background/foreground, aliases, multiple wallets/engines, stream pressure, repeated open/close, and memory growth. Clean consumers will test iOS SwiftPM-only and mixed SwiftPM/CocoaPods hosts, including the declared minimum Flutter/Xcode versions, plus Android release/R8, advertised ABIs, 16 KB page compatibility, and resolved binary origins without Rust or local SDK checkouts.
Generated code will not inflate coverage. The hand-written Dart and adapter logic will target at least 80% branch coverage, but release acceptance will be based primarily on named behavioral scenarios and cross-platform contract conformance.
#### 8. Release and Maintenance
General availability requires a pub.dev production release, signed source tag, changelog, API docs, example app, compatibility matrix, SBOM/dependency inventory, provenance/checksum record, vulnerability-reporting process, and no known unresolved critical or high security defects.
During the six-month maintenance period, new stable native SDK releases will be assessed promptly in canary CI. Compatible security/protocol updates will be released quickly; incompatible updates will receive a public impact report, tracked work item, and coordinated release plan. Monthly ZCG forum updates will include releases, compatibility status, issues, security work that can be disclosed, and integrator feedback.
### Upstream Merge Opportunities
#### Repositories
- `zcash/zcash-swift-wallet-sdk`
- `zcash/zcash-android-wallet-sdk`
- Potentially `zcash/librustzcash` only if native maintainers identify a shared upstream defect or missing primitive. The Flutter project will not independently modify consensus or cryptographic code.
#### Expected Changes
No fork or change to either native SDK is required for the baseline architecture. The Flutter plugin will consume their public package products as an ordinary application dependency. Most semantic differences can and should be adapted inside the Swift/Kotlin plugin layers.
Source inspection has already identified one candidate public-API gap: ordinary Swift `Proposal` exposes transaction count, total fee, and a legacy-Orchard signal, but not a public serialized representation or detailed read-only step model; Android exposes serialization but similarly keeps its unsafe step model out of the app-facing API. The production wrapper can operate safely with opaque native handles and the available summary, but richer proposal review must be either a narrowly coordinated upstream read model or an explicit exclusion. Other gaps may include an adapter-safe structured error, lifecycle signal, capability query, deterministic test seam, or cross-platform method needed to implement an agreed user story. For each gap, I will:
1. Open an upstream issue with the Flutter use case and proposed contract.
2. Discuss it with maintainers before writing a patch.
3. Submit a small, focused PR following that repository's contribution rules if maintainers agree.
4. Keep the Flutter fallback explicit and avoid depending on an unmerged branch for a production release.
#### Ecosystem Benefit
Any accepted improvements would help all consumers of the native SDKs, not only Flutter. Structured errors, stable test hooks, and lifecycle/capability clarity can reduce bespoke integration code across wallets.
#### Coordination and Timeline
I will open public coordination threads with the native SDK maintainers and the other Flutter proposer at the start of Milestone 1. Candidate upstream work will be identified there and proposed early enough for normal review. Upstream merge is not a milestone acceptance condition because I cannot control maintainer decisions; the condition is a reviewed issue or pull request and a production-safe disposition.
The Flutter repository may later be transferred to or co-maintained by an appropriate Zcash organization if that organization, ZCG, and I agree. Until then, I will describe it accurately as community-built software based on official native SDKs, not as an official Zcash SDK.
### Hardware/Software Costs (USD)
$0
### Hardware/Software Justification
No hardware or software purchase is required for the funded scope. I will use my existing development equipment, open-source development tools, and available simulators and emulators.
### Service Costs (USD)
$0
### Service Costs Justification
N/A. I am not requesting funding for external services.
### Compensation Costs (USD)
$10,000
### Compensation Costs Justification
The requested compensation is a fixed **$10,000 cap** allocated across accepted deliverables rather than billed hourly. It is not an estimate of the project's market value. I will contribute the additional engineering and maintenance time required to satisfy the unchanged milestones as an in-kind contribution, with no entitlement to payment beyond the grant cap.
| Workstream | Grant-funded compensation |
|---|---:|
| Architecture, source analysis, capability matrix, threat model, and ecosystem coordination | $1,000 |
| Dart public API, Pigeon contract, plugin lifecycle, packaging, and release engineering | $2,000 |
| Swift adapter and iOS integration/testing | $1,500 |
| Kotlin adapter and Android integration/testing | $1,500 |
| Cross-platform integration tests, documentation, hardening, and remediation | $2,500 |
| Six months of maintenance, compatibility work, issue triage, and integrator support | $1,500 |
| **Total** | **$10,000** |
Milestone payments are fixed caps payable only after the associated deliverables and acceptance criteria are satisfied.
### Total Budget (USD)
$10,000
### Previous Funding
No
### Previous Funding Details
_No response_
### Other Funding Sources
No
### Other Funding Sources Details
_No response_
### Implementation Risks
1. **Upstream skew and artifact availability.** Swift/Android do not always release together, and a source tag does not prove package-manager availability. Mitigation: select published baselines, map capabilities, pin/test resolved artifacts and checksums, run upgrade canaries, and never use private snapshots for GA.
2. **Lifecycle, cancellation, and false parity.** Native initialization/start/stop semantics differ, and cancelling a Dart future does not cancel native work. Mitigation: one explicit Dart state machine, operation IDs, native cancellation, serialized mutations, stale-reply rejection, and cross-platform ordering tests.
3. **Ironwood complexity.** Migration includes planning, signing, proving, scheduling, privacy gates, and crash recovery. Mitigation: follow native engine instructions, persist only native-defined state, require consent, and test interruption/recovery; Dart will not implement a second policy engine.
4. **Secret exposure.** Creation, restore, backup, or one-shot authorization can move secret bytes across managed runtimes. Mitigation: opaque native key authority by default, explicit secret-bearing APIs, minimal copying/lifetime, best-effort clearing, redaction tests, no telemetry, and honest zeroization limits.
5. **Plugin/background lifetime.** Synchronizers, streams, aliases, and OS tasks can outlive a Flutter engine; user-presence policy may block background signing. Mitigation: generation-checked handles, detach cleanup, native schedulers/expiration, `userActionRequired`, and multi-engine/process-loss stress tests.
6. **Build conflicts.** Host SwiftPM/CocoaPods, Gradle/Kotlin, gRPC/SQLite, ABI, and minimum-OS constraints may collide. Mitigation: upstream package managers, clean representative hosts, release/R8/ABI testing, no binary repackaging, and published diagnostics/minimums.
7. **Flaky networks.** Public lightwalletd/testnet outages can hide defects. Mitigation: deterministic required CI, separately reported retry-bounded network suites, multiple endpoints, and public test status.
8. **Security defects discovered late.** Mitigation: threat modeling in Milestone 1, continuous boundary and secret-canary testing, a pre-freeze security checklist, reserved remediation time, responsible disclosure, and no GA with known unresolved critical/high defects.
9. **Duplication, adoption, and bus factor.** Mitigation: publish the prior-art and coordination decision in Milestone 1, recruit at least two independent validators, prove clean-room integration, document reproducible releases, maintain a tested release-access recovery procedure, and cancel or rescope if stakeholders find the package duplicative.
### Potential Side Effects
- “Built on official SDKs” could be mistaken for endorsement or a guarantee about upstream code. Naming and security docs will preserve upstream warnings and state the project's assurance boundary.
- One abstraction could hide platform privacy/lifecycle differences. Capability flags, semantic documentation, behavioral parity tests, and no silent fallback will keep differences visible.
- Diagnostics or convenience APIs could leak data or weaken key/proposal handling. Defaults will be allowlisted/redacted, with explicit key authority and mandatory review/authorization phases.
- Native wallet databases are not portable backups. Recovery documentation will use authority, birthday, and app metadata, never cross-platform database copying.
### Success Metrics
I will consider the project successful when all of the following are true:
1. Pub.dev and signed source releases include API docs, changelog, compatibility matrix, security/threat documents, SBOM, and reproducible release instructions.
2. Clean iOS/Android apps build and run without path dependencies, local SDK checkouts, Rust, or unpublished snapshots; CI verifies the SwiftPM XCFramework and Gradle SDK/backend graph.
3. Every in-scope native consumer capability has a tested implementation or reviewed explicit disposition, with no silent stubs or invented proposal fields.
4. End-to-end suites pass for new/restore/existing/view-only wallets, sync/recovery, balances/history/addresses, transfer/shielding/ZIP-321, PCZT, submission, reorg/rewind, and agreed Ironwood workflows.
5. Hand-written Dart/adapters reach at least 80% branch coverage, excluding generated code, while every money/key/lifecycle path has behavioral tests.
6. Automated canaries and release checks find no protected values in default logs, errors, analytics, or crash metadata.
7. GA has no known unresolved critical/high security defects; medium defects have documented fixes or dispositions, owners, and deadlines accepted by ZCG's technical validator.
8. At least two independent Flutter integrators complete and publish clean-room installation, read, spend, recovery, process-loss, and upgrade validation on both platforms.
9. Force-close/background tests converge without duplicate app-initiated submission, corrupted state, or lost native-persisted workflow state; OS limitations are documented.
10. During maintenance, stable upstream releases are assessed within five business days; compatible critical updates ship within 14 days or receive a public blocker plan, issues receive initial triage within five business days, and monthly reports precede payouts. Embargoes follow coordinated disclosure.
11. The architecture contains no direct Dart calls to private Rust/JNI/C ABI and no reimplemented consensus, proof, scan, or wallet-database engine.
### Startup Funding (USD)
$0
### Startup Funding Justification
I am not requesting a startup payment. Milestone 1 is funded only after its public architecture, coordination, threat-model, and validation deliverables are accepted. This reduces ZCG's risk and makes continued funding contingent on confirming that the work is needed, non-duplicative, and aligned with intended users and native SDK maintainers.
### Milestone Details
```milestones.yaml
- **Milestone: 1 - Architecture, Alignment, and Acceptance Contract**
**Amount (USD): $1,000**
**Expected Completion Date: 2026-12-15**
**User Stories:**
- "As a Flutter integrator, I want a reviewed capability and API contract so that I know exactly what the SDK will support and how platform differences behave."
- "As a native SDK maintainer, I want the Flutter layer to consume supported public APIs and avoid a third wallet engine so that it does not create unnecessary protocol and maintenance drift."
- "As a security-conscious integrator, I want explicit data flows, trust boundaries, and key-authority rules so that high-risk design defects are addressed before implementation expands."
**Deliverables:**
- Public architecture RFC and decision records, including the supported-facade decision and rejection of direct Dart-to-Rust/JNI FFI.
- Complete source-based capability inventory for the selected stable Swift and Android SDK baselines, with each capability marked core, platform extension, deferred upstream/unstable, or excluded with rationale.
- Public Dart API proposal, lifecycle state machine, concurrency/ownership model, stable error schema, and versioning/compatibility policy.
- Proposal-lifetime and review contract documenting process-scoped native handles, the exact public fields available on each baseline, and the accepted upstream-or-exclusion disposition for richer proposal details.
- Threat model, secret/key-authority design, logging/privacy policy, supply-chain model, and initial abuse/failure cases.
- Published prior-art and non-duplication report covering the existing pub.dev package, application-specific Flutter wallets, and the July 2026 direct-Rust proposal, including collaboration/merge/withdraw decisions.
- Published outreach, meeting notes, or review comments from native SDK maintainers, plus written milestone validation from at least two independent Flutter integrators recruited through public channels.
- Repository scaffold with license, `README.md`, `CONTRIBUTING.md`, `SECURITY.md`, CI skeleton, issue templates, and milestone acceptance harness.
**Acceptance Criteria:** At least two independent Flutter integrators and the ZCG technical validator confirm in writing that the capability and API contract addresses their integration user stories; the public matrix accounts for every public consumer capability inspected in both baseline SDKs; all maintainer and validator feedback has documented dispositions; no unresolved objection establishes that the project duplicates a preferable existing package; and the repository's architecture, threat-model, and CI documents are reproducible from a clean clone.
- **Milestone: 2 - Native Packaging, Lifecycle, Synchronization, and Typed Bridge**
**Amount (USD): $1,250**
**Expected Completion Date: 2027-02-15**
**User Stories:**
- "As a Flutter developer, I want to add one package and open a Zcash wallet on iOS and Android without installing Rust or editing the SDK source."
- "As an application engineer, I want deterministic lifecycle and state streams so that the app remains correct across backgrounding, cancellation, restart, and multiple Flutter engines."
**Deliverables:**
- Single Flutter plugin package with stable hand-written Dart facade and private Pigeon-generated Swift/Kotlin/Dart bridge.
- iOS SwiftPM dependency on the selected stable `ZcashLightClientKit` release and Android Maven dependency on the selected stable `zcash-android-sdk` release.
- Wallet-handle/alias registry, open/prepare/start/stop/close/wipe foundation, mainnet/testnet isolation, foreground/background hooks, and deterministic resource cleanup.
- Generation-checked proposal/operation handle registries, native cancellation propagation, stale-reply rejection, UI-thread event marshalling, and a documented native background-task entry contract.
- Normalized state, event, connection, progress, height, and error streams with bounded buffering and terminal-event guarantees.
- Multi-wallet, duplicate-alias, cancellation, engine detach/reattach, and multiple-engine tests.
- Clean-consumer CI builds for iOS simulator/device compilation and Android emulator/device architectures shipped by the upstream artifacts.
**Acceptance Criteria:** From a fresh machine/runner, validators add the package to a new Flutter app, build both platforms, open and close test wallets, observe documented state transitions, background/foreground the app, and run two independent wallet aliases without a Rust toolchain or local Zcash SDK checkout. All deterministic lifecycle/codec tests pass, detachment releases resources, duplicate aliases fail with a typed error, and binary origins/versions match the published compatibility record.
- **Milestone: 3 - Accounts, Keys, Sync Read Model, History, and Recovery**
**Amount (USD): $1,250**
**Expected Completion Date: 2027-04-15**
**User Stories:**
- "As a wallet developer, I want to create, restore, reopen, import, and remove accounts so that I can support spending and watch-only products safely."
- "As a wallet user, I want accurate addresses, pool-aware balances, history, memos, and recovery progress so that the application can explain what I own and when it is spendable."
- "As a security-conscious integrator, I want an explicit key provider and privacy-safe diagnostics so that secret custody is not hidden in convenience code."
**Deliverables:**
- New/restore/existing/view-only account workflows, account listing/import/deletion, wallet birthdays, seed-relevance checks where supported, and stable account identifiers.
- Key-authority interface plus documented and tested native encrypted-storage reference implementation, opaque native key handles, user-presence/locked-key states, and explicit enrollment/restore/backup/export ceremonies.
- Unified/custom unified, Sapling, transparent, TEX validation, and single-use transparent address APIs according to the capability matrix.
- Pool-aware balances, transaction streams/pagination, memos, recipients, outputs, enhancement, UTXO refresh, exchange-rate observation, and server validation/evaluation in agreed scope.
- Rewind, rescan/recovery, endpoint handling, and Tor status/configuration in agreed scope.
- Shared cross-language fixtures; Darkside/regtest reorg and rewind tests; testnet create/restore/view-only synchronization tests; redaction/policy tests.
**Acceptance Criteria:** Both validators independently complete the documented new, restore, existing, and view-only testnet scenarios on iOS and Android; a deterministic reorg/rewind fixture converges to the expected history and balances; all documented address/balance/history data agree with native reference results; secret-canary tests find no sensitive values in logs/errors/crash payloads; and unsupported platform capabilities fail explicitly rather than returning partial data.
- **Milestone: 4 - Spending, Shielding, PCZT, Submission, and Ironwood Migration**
**Amount (USD): $2,000**
**Expected Completion Date: 2027-07-15**
**User Stories:**
- "As a wallet user, I want to review the amount and recipient I requested, the total fee, transaction count, legacy-pool signal, and every additional field supported by the agreed capability matrix before authorizing a payment or migration."
- "As a Flutter wallet developer, I want transfer, shielding, ZIP-321, PCZT, and submission APIs with typed partial results so that I do not have to recreate native transaction state machines."
- "As a hardware/external-signer integrator, I want PCZT creator/prover/signer/finalizer boundaries so that spend authority can remain outside the online wallet."
**Deliverables:**
- Opaque native proposal handles plus immutable review DTOs for transfers, shielding, ZIP-321, and agreed pool-migration paths; the DTOs expose only the fields guaranteed by the selected public native baselines and the approved Milestone 1 disposition.
- Explicit authorization, transaction creation, broadcaster/submission, endpoint selection, reconciliation, cancellation, and multi-transaction result streams.
- PCZT creation, redaction, Sapling-proof requirement, proof addition, external signing handoff, finalization, and submission according to supported native capabilities.
- High-level Orchard-to-Ironwood migration controller that delegates planning/advance/prove/broadcast/recovery decisions to native migration engines, exposes scheduling/status, supports agreed software-key and external-signer paths, and carries privacy warnings.
- Failure-injection tests for cancellation, network rejection, ambiguous submission, process death, stale proposal, migration attention/rebuild, and duplicate-operation prevention.
- End-to-end testnet transactions on iOS and Android plus controlled low-value mainnet smoke evidence handled under the privacy policy.
**Acceptance Criteria:** Validators use the Dart API to inspect and explicitly authorize proposals, send and shield testnet ZEC, fulfill a ZIP-321 request, complete the agreed PCZT round trip, and execute/recover the selected Ironwood migration scenarios on both platforms. The request, total fee, transaction count, legacy-pool signal, all other matrix-promised review fields, and per-transaction results remain visible; stale proposal handles fail closed after close/restart; process interruption converges according to the native contract; no convenience path bypasses proposal review; and observed transactions/balances match the native reference behavior and on-chain/test-fixture results.
- **Milestone: 5 - Production Hardening, Documentation, and Release Candidate**
**Amount (USD): $1,500**
**Expected Completion Date: 2027-09-15**
**User Stories:**
- "As a developer who did not build the SDK, I want a clean integration path, complete documentation, and predictable upgrades so that I can adopt it without help from the author."
- "As a release owner, I want deterministic quality, privacy, compatibility, and recovery gates so that a published package is supportable in production."
**Deliverables:**
- Feature-complete release candidate with API docs, architecture and threat-model updates, integration cookbook, key-custody guide, platform configuration, migration guide, troubleshooting, and native-version upgrade playbook.
- Example wallet and separate clean-room consumer app using the release candidate as an external package dependency.
- Semver/deprecation policy, compatibility matrix, generated-code policy, SBOM/dependency inventory, artifact provenance/checksum records, release checklist, and maintainer/runbook documentation.
- Expanded unit/branch, contract, device, end-to-end, performance, soak, force-close, and failure-injection suites with public results.
- Integration reports and issue lists from at least two independent intended-user validators, with accepted fixes or documented dispositions.
- Pre-GA security-verification package, completed release checklist, and defect-disposition log.
**Acceptance Criteria:** Both intended-user teams integrate the release candidate from a package artifact on clean projects without author intervention and validate the core read, spend, recovery, and upgrade stories; all release gates pass on the supported matrix; hand-written code meets the coverage target; deterministic and required end-to-end tests are green; measured artifact/build/performance results are published; every known critical/high defect is resolved; and the security-verification package is complete and reproducible.
- **Milestone: 6 - Security Remediation and Production General Availability**
**Amount (USD): $1,500**
**Expected Completion Date: 2027-11-15**
**User Stories:**
- "As an integrator, I want a validated, versioned package with reproducible artifacts so that I can make an informed production adoption decision."
- "As a Zcash stakeholder, I want security findings remediated and residual risks stated honestly so that production claims are evidence-based."
**Deliverables:**
- Completed pre-GA security-verification report covering the Dart/native boundary, key handling, lifecycle/concurrency, transaction and migration state, logging/privacy, packaging, and release supply chain.
- Remediation patches, regression tests, validator retesting, and risk dispositions for defects not fixed immediately.
- Production pub.dev release; signed GitHub source release; changelog; API docs; SBOM; provenance/checksum record; compatibility matrix; and reproducible build/release evidence.
- Final clean-room installation and mainnet/testnet validation reports from both intended-user teams.
- Public release announcement, support channels, security contact, disclosure process, and six-month maintenance schedule.
**Acceptance Criteria:** The security-verification, CI, and validator reports identify no known unresolved critical/high defects; any medium residual risk has a documented owner and deadline accepted by the ZCG technical validator; the pub.dev package and signed source tag install reproducibly on both platforms; all GA gates and clean-room scenarios pass; at least two independent intended-user validators sign final acceptance reports; and package documentation accurately states upstream security warnings and does not imply official endorsement.
- **Milestone: 7 - Maintenance and Compatibility, Months 1-3**
**Amount (USD): $750**
**Expected Completion Date: 2028-02-15**
**User Stories:**
- "As an SDK adopter, I want timely compatibility and security maintenance so that the package remains usable as Flutter and native Zcash SDKs evolve."
- "As a community stakeholder, I want transparent support metrics and release status so that maintenance work is accountable."
**Deliverables:**
- Three monthly forum reports covering compatibility, releases, issues, validator feedback, and security work that can be disclosed.
- Upstream release assessments and compatible Flutter releases or public blocker/remediation plans according to the maintenance SLA.
- Issue triage, documentation fixes, regression tests, security response, and integrator support within funded scope.
- Updated compatibility matrix, changelog, SBOM, and release artifacts for every maintenance release.
**Acceptance Criteria:** Monthly reports are posted before payout; all stable upstream releases during the period have dated assessments; SLA metrics and dispositions are published; required security/protocol compatibility updates are released or have accepted public blocker plans; CI remains green on the supported matrix; and both validators confirm their integration remains buildable and core acceptance scenarios pass on the latest supported Flutter SDK release.
- **Milestone: 8 - Maintenance, Sustainability, and Handoff, Months 4-6**
**Amount (USD): $750**
**Expected Completion Date: 2028-05-15**
**User Stories:**
- "As a current or future maintainer, I want reproducible release ownership and a prioritized roadmap so that the SDK can continue after the grant."
- "As an adopter, I want the final funded release line to remain compatible and documented so that maintenance does not end abruptly."
**Deliverables:**
- Three additional monthly forum reports and the same compatibility, triage, security, and release obligations as Milestone 7.
- Maintainer onboarding walkthrough, release-key/access recovery procedure, ownership map, open-risk register, and contribution backlog.
- Six-month maintenance report covering releases, upstream response times, issue SLA, test reliability, adoption/integration evidence, security work, and remaining gaps.
- Public post-grant roadmap and sustainability/handoff proposal, including any repository transfer or co-maintenance discussions.
**Acceptance Criteria:** All monthly and final reports are published; stable upstream releases have complete dispositions; the latest supported package passes the full release matrix and both validators' core scenarios; a second authorized release custodian or documented recovery process can execute a dry-run release; unresolved issues and security risks are transparently recorded; and at least two independent intended-user validators plus the ZCG technical validator accept the maintenance and handoff evidence.
**Budget check:** `$1,000 + $1,250 + $1,250 + $2,000 + $1,500 + $1,500 + $750 + $750 = $10,000.`
```
### Supporting Documents
```files.yaml
- **My profile and portfolio:** [github.com/Jainakin](https://github.com/Jainakin)
- **Relevant SDK work:** [`@utexo/wdk-rgb-lightning`](https://github.com/UTEXO-Protocol/wdk-rgb-lightning)
- **Relevant production Flutter wallet:** [AQUA Wallet](https://github.com/AquaWallet/aqua-wallet), [iOS Deployed App](https://apps.apple.com/us/app/aqua-wallet/id6468594241), [Android Deployed App](https://play.google.com/store/apps/details?id=io.aquawallet.android&hl=en)
```