Grant Application - {Zcash NU7 Compatibility for Wallet Core}

Community Grants Applications
1

Project Summary

I request $24,000 to harden, independently review and release the existing transparent v5 Wallet Core repair demonstrated through a pinned Vultisig Android integration. The MVP already produces a confirmed payment using mature Regtest inputs; this grant funds the remaining production work and six months of maintenance.

Project Description

This project will turn a working compatibility candidate into a reviewed, independently consumable release for the native transparent ZEC send workflow. It preserves the legacy transaction planning, preimage and external-signature interfaces used by the demonstrated Android caller.

The pre-grant work is documented at the public repository. It includes the Rust v5 serializer and ZIP 244 transaction ID/signing digests, the Zcash-specific legacy adapter, Android integration patches, an official-reference verifier, a built x86_64 Debug AAR and matching protobuf JAR, and recorded execution evidence.

The published baseline reports 39 passing offline checks, 10 passing selected native cases and 4,104 passing Android data-module JVM cases, with 41 documented native-host skips. The actual Android helper also executed on an API 35 emulator. Its funded v5 transaction was admitted and confirmed at height 151 by the unchanged pinned Zebra Regtest node. The transaction ID is faf4b20e3c0f94ed4233f866850de0537c7d10cad72572d6a8bc0c2ccd266230.

That demonstration covers the stated native P2PKH/SIGHASH_ALL workflow. It does not establish an independent security review, production wallet adoption, a complete multi-device MPC session or a public-network transaction. The grant will address the remaining activation policy, adversarial coverage, release packaging, external review, remediation and support. Completed implementation and MVP acceptance work are excluded from the request.

Proposed Problem

Under the proposed NU7 rules, wallet integrations that continue constructing version 4 transactions will produce payments the network rejects after activation, including transparent-only payments. A user could have sufficient spendable ZEC and provide the required signatures, yet still be unable to complete a payment through the affected workflow. Changing the branch identifier or re-signing cannot correct an unsupported transaction format; the payment must be rebuilt in a supported format.

The underlying compatibility gap is documented in Wallet Core [issue #4910](trustwallet/wallet-core#4910), which identifies v4-only Zcash transaction construction. Our investigation also traces the legacy interfaces used by the pinned Vultisig Android integration. A complete repair must therefore work through that caller’s planning, signing and native-package boundaries. Adding v5 support elsewhere in the library does not establish that this existing workflow can use it.

Our published acceptance evidence reproduces the failure in an isolated Zebra Regtest environment: a freshly signed v4 transaction with the correct NU7 branch identifier was rejected because of its version. The candidate repair then produced a v5 transaction through the actual Android helper that the unchanged pinned node accepted and confirmed.

A working repair now exists, but independent security review, activation-policy hardening, additional adversarial coverage and production Android release packaging remain unfinished. These are necessary steps between a demonstrated development build and a release that wallet developers can evaluate and integrate.

The urgency follows from the proposed consensus cutoff. If an affected integration reaches activation without a compatible update, restoring its payment workflow will require the same integration, testing and release work while users are already encountering rejected transactions. Completing that work in preparation for activation gives developers time to validate the migration before their users depend on it.

Proposed Solution

I will complete the remaining work needed to deliver a reviewed, versioned v5 compatibility release for the supported native transparent P2PKH/SIGHASH_ALL send workflow. Completed MVP implementation and validation are excluded from the funding request.

The work will address five requirements:

  1. Correct activation handling. Define and enforce transaction-version, branch-freshness and expiry requirements across activation and reorganisation boundaries. Preserve the supported legacy planning and external-signature interfaces, with explicit errors when a valid supported transaction cannot be constructed.

  2. Payment correctness across the complete integration. Extend tests for selected inputs, recipient and change outputs, fees, send-max, supported metadata and external signatures. Add malformed-request cases and fuzzing, using reference checks for transaction IDs and signing digests.

  3. Usable Android release packages. Produce arm64-v8a and x86_64 packages with the matching protobuf JAR, build instructions, checksums and provenance. Demonstrate clean package consumption and actual helper execution on both architectures, then repeat the funded NU7 Regtest acceptance flow using the release candidate.

  4. Independent review and remediation. Commission review of the changed serialization, signing commitments, planning, external-signature assembly and native integration boundaries. Publish the report and findings disposition. Critical or high findings within the agreed scope must be resolved and independently retested before a production release designation.

  5. Migration and maintenance. Publish the supported caller contract, migration instructions and known limitations. Provide six months of bounded defect support with monthly reports, and submit focused upstream contributions while keeping the delivered source and packages independently buildable.

Milestone acceptance will require validation against published criteria by an intended-user representative agreed with ZCG. The result will give wallet developers a documented and reviewed migration path for the supported integration, backed by package-level execution and node-acceptance evidence.

Solution Format

A public source release and Android integration package for the supported native transparent ZEC send workflow.

Deliverables will include:

  • Wallet Core Rust/C++ changes and the Vultisig Android integration patch.

  • A documented support matrix covering P2PKH, SIGHASH_ALL, multiple inputs, recipient/change outputs, send-max, fees and supported metadata.

  • Android release packages for arm64-v8a and x86_64, with the matching protobuf JAR, build instructions, checksums and provenance.

  • Additional regression tests, fuzzing entry points and recorded Android/node acceptance checks.

  • An independent review report, remediation record and migration documentation.

  • Six months of bounded maintenance with monthly public reports.

  • Shielded transactions, swaps, v5 PCZT, new MPC protocols, Apple/WASM packaging and full wallet UI validation are outside scope.

Dependencies

The work depends on Wallet Core, Vultisig Android, official Zcash specifications and reference vectors, the Rust/C++ and Android toolchains, and a Zebra version implementing the relevant NU7 rules. Release evidence will identify the exact source, dependency and toolchain revisions used.

Validation requires build capacity and access to arm64-v8a and x86_64 Android runtimes.

Independent review requires a confirmed quotation and schedule before engagement. Milestone validation also requires an intended-user representative agreed with ZCG; that role will be confirmed before validation begins.

Maintainer feedback will inform upstream contributions. Merge and release decisions remain with the maintainers, while the delivered source and packages will remain independently buildable

Technical Approach

The candidate uses one Rust implementation for v5 serialization, ZIP 244 transaction IDs and signing digests. A Zcash-specific C++ adapter connects it to the supported legacy planning, preimage and external-signature interfaces used by the Android caller.

Remaining hardening will establish explicit transaction-version, branch-freshness and expiry rules across activation and reorganisation boundaries. Validation will check the relationship between the original request, selected inputs, recipient/change outputs, fees and supplied signatures.

Additional tests will cover amount and fee boundaries, dust, send-max, duplicate or inconsistent inputs, supported metadata and invalid external signatures. At least two fuzzing entry points will cover transaction decoding and request/plan validation, with published configurations, seed corpora and recorded results. Transparent metadata support will remain limited to zero-value OP_RETURN outputs containing at most 80 payload bytes.

Release checks will exercise the actual Android helper on both declared architectures, demonstrate clean consumption of the AAR and matching protobuf JAR, and repeat the funded NU7 Regtest flow using the release candidate. Relevant Bitcoin and Komodo regressions will check shared code affected by the changes.

Independent review will cover the changed serialization, signing commitments, planning, external-signature assembly and native/package boundaries. Findings will receive documented dispositions, with fixes and independent retesting where required.

New original code and documentation will use MIT. Existing third-party material will retain its upstream licenses and notices, as documented in NOTICE. The license selection is Other because the package includes derivative contributions subject to those upstream terms. Acceptance of those terms for the funded contributions is requested. The release will include a license inventory and CONTRIBUTING.md referencing applicable upstream guidance and librustzcash style guides.

Upstream Merge Opportunities

Contributions will target:

These changes could benefit other integrations using the same supported interfaces. No consensus-node modification is proposed.

I will seek feedback on interface behavior, version selection, packaging and test expectations, then submit focused contributions against documented baselines. Upstream merge dates are outside my control. Opening a pull request alone will not satisfy a milestone.

Relevant upstream work will be checked before funded changes and each unpaid milestone. Suitable work will be reused and credited, with duplicated unpaid scope and cost removed. Material scope changes will be agreed with ZCG.

Open Source License

Other

Hardware/Software Costs (USD)

0

Hardware/Software Justification

None

Service Costs (USD)

$6,000

Service Costs Justification

A $6,000 allowance is reserved for independent review, reporting and remediation verification. The planning basis is 40 hours at $150 per hour.

A reviewer has not yet been contracted, and this allowance is not a supplier quotation. Before engagement, I will confirm the reviewer’s qualifications, independence, scope, price and schedule.

If an adequate review cannot be commissioned within the allocation, I will agree a revised plan with ZCG before committing the funds. Unused review funds will not be reassigned without agreement.

Compensation Costs (USD)

$18,000

Compensation Costs Justification

Remaining work Hours Cost
Production hardening 40 $4,000
Additional supported-case coverage 40 $4,000
Android release packaging and build/consumption checks 20 $2,000
Remediation and retesting allowance 32 $3,200
Six months of maintenance, averaging eight hours per month 48 $4,800
Total 180 $18,000

Total Budget (USD)

$24,000

Previous Funding

Yes

Previous Funding Details

My previous ZCG grant, GraphSense Zcash Shielded Accounting Repair, received $8,000. The official record marks it Grant Complete, with all three milestones completed.

Application and completion record

This application covers separate deliverables.

Other Funding Sources

No

Other Funding Sources Details

None

Implementation Risks

Changes to network rules, dependencies or upstream interfaces may require adjustments. I will refresh the supported baselines and test affected boundaries before release.

The existing x86_64 Debug validation does not establish release behavior on both architectures. Actual helper execution and package-consumption checks on arm64-v8a and x86_64 are required for the release milestone.

Reviewer availability or findings may affect the eight-week delivery target. Findings exceeding the remediation allocation will be reported with a revised plan. Unresolved critical or high findings within the agreed review scope will block a production release designation.

Equivalent upstream work may become available during delivery. It will be assessed for reuse, with duplicated unpaid work removed from the request.

Potential Side Effects

Changes to transaction construction, version selection or fees can affect existing callers. A defect could cause rejection or produce outputs or fees that differ from the intended request. Request-to-transaction checks, reference comparisons and independent review will address these risks.

Stricter validation may reject inputs previously tolerated by a caller. Migration instructions will document supported formats, metadata bounds, signature requirements and errors. Relevant shared-code regressions will check for unintended effects on affected Bitcoin and Komodo paths.

Success Metrics

  • All published supported and negative test cases pass on the final revision, including activation boundaries, branch freshness, fees, send-max, metadata and external signatures.

  • At least two fuzzing entry points have published configurations, seed corpora and recorded results.

  • Both Android architectures execute the actual helper successfully, and a clean consumer build resolves the delivered AAR and matching protobuf JAR. Mandatory runtime checks are executed rather than skipped.

  • The release candidate produces the intended funded v5 payment and confirmation under the documented NU7 Regtest rules. Evidence checks request binding, selected inputs, outputs, fee, transaction ID and signing digests.

  • The independent report identifies the revisions and artifacts reviewed. Critical and high findings within scope are resolved and independently retested before the production release designation.

  • The agreed intended-user representative validates each milestone against its acceptance criteria.

  • Six monthly maintenance reports and a final handoff are published.

Startup Funding (USD)

$0

Startup Funding Justification

None

Milestone Details

Milestone 1: Production Hardening and Additional Coverage

Amount: $8,000
Expected completion date: 26 November 2026

User story

As a wallet integrator, I want explicit version, branch and request-validation rules so that the supported send workflow constructs the intended payment across activation boundaries.

Deliverables

  • Hardening changes and a documented caller contract covering version selection, branch freshness, expiry, input association, amounts, fees and external signatures.
  • Additional supported and negative tests, plus at least two fuzzing entry points with configurations, seed corpora and recorded results.
  • Contribution guidance, a license inventory, applicable license notices and a recorded upstream overlap check.

Acceptance criteria

  • The agreed representative reviews the caller contract and executes the documented new coverage against the pinned revision.
  • Published supported and negative cases produce the expected results.
  • Fuzzing results and contribution/license material are public.
  • The evidence distinguishes funded changes from the completed MVP.

Milestone 2: Android Release Candidate and Integration Validation

Amount: $2,000
Expected completion date: 10 December 2026

User story

As an Android wallet developer, I want release packages and matching bindings that I can build and consume on the declared architectures.

Deliverables

  • Release-candidate packages for arm64-v8a and x86_64, with the matching protobuf JAR, checksums, source/toolchain pins and build provenance.
  • Clean build and consumption instructions, actual helper execution on both architectures and relevant shared-code regression results.
  • A funded NU7 Regtest acceptance run using the release candidate, with migration instructions.

Acceptance criteria

  • The agreed representative reproduces a clean package-consumption build and verifies successful helper execution on both architectures.
  • Recorded node evidence confirms the intended payment.
  • Reference checks verify request binding, selected inputs, outputs, fee, transaction ID and signing digests.
  • Evidence identifies the source and artifacts used.

Milestone 3: Independent Review, Remediation and Reviewed Release

Amount: $9,200
Budget allocation: $6,000 independent-review allowance and $3,200 remediation engineering.
Expected completion date: 31 December 2026, subject to the contracted review schedule.

User story

As a wallet developer evaluating the release, I want independent review of the changed transaction and native integration code, with important findings resolved and retested.

Deliverables

  • An independent report identifying reviewer qualifications, independence, scope, exact revisions, methods, findings and exclusions.
  • Remediation commits and regression tests for actual findings, with independent retesting. The engineering allocation is 32 hours at $100 per hour.
  • A reviewed release, final checksums, findings disposition record and updated migration documentation.

Acceptance criteria

  • Critical and high findings within the agreed scope are resolved and independently retested.
  • Remaining findings and limitations are disclosed.
  • Affected package, runtime and transaction checks are repeated after remediation, with evidence identifying the final shipped revision.
  • The agreed representative validates the final deliverables.
  • Material additional remediation is agreed with ZCG before scope or budget changes.

Milestone 4: Six Months of Maintenance and Public Reporting

Amount: $4,800
Expected completion date: 30 June 2027, assuming milestone 3 is accepted on 31 December 2026. Maintenance will run for six months after actual acceptance.

User story

As a developer using the delivered integration, I want defects triaged and supported regressions maintained for a defined period after release.

Deliverables

  • Forty-eight engineering hours of bounded maintenance across six months for in-scope defects and relevant consensus/dependency monitoring.
  • Six monthly public reports covering issue status, fixes, regression results and remaining limitations.
  • A final handoff covering supported versions, build/test reproduction and open issues.

Acceptance criteria

  • The six-month period and all six reports are complete.
  • The agreed representative verifies the issue record and final handoff.
  • Reported in-scope defects have a documented resolution or agreed disposition.
  • Maintenance remains within the delivered scope, excluding new features, unrelated chains and unbounded future-upgrade work.

Supporting Documents

  • Public source repository
    Implementation patches, tests, build scripts and project documentation.

  • MVP acceptance ledger
    Recorded verification, native build and Android execution results, including the funded v5 transaction confirmed on Zebra Regtest. Identifies completed checks and their limitations.

  • Complete source and evidence package
    Downloadable archive containing the source handoff, patches, tests, scripts and recorded execution evidence.

  • Android validation package
    The x86_64 Debug AAR and matching protobuf JAR used for the completed MVP validation.

1 Like