### 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)
N/A
### Organization Name
Maheswaran Velmurugan (soloking1412) - Independent developer and security researcher, solo applicant
### How did you learn about Zcash Community Grants
Through X post
### Requested Grant Amount (USD)
$19,500
### Category
Research & Development
### Project Lead
```project-lead.yaml
Name: Maheswaran Velmurugan
Role: Solo developer and security researcher (Freelancer)
Background: Full-stack Web3 developer and Web3 security researcher (github.com/soloking1412, 100+ public repos). 20+ confirmed High/Medium findings across EVM protocols on Sherlock, Code4rena, Cantina, and Immunefi. Completed Arbitrum Foundation grant (Stylus-Toolkit: github.com/soloking1412/Stylus-Toolkit, build/deploy/gas-profile tooling for Stylus contracts, both milestones accepted, 32.6% gas savings). Completed Stacks Foundation grant (satoshi-yield: github.com/soloking1412/satoshi-yield, non-custodial sBTC yield optimizer). Contributed a fuzz-testing crate to Bitcoin Development Kit (BDK): three cargo-fuzz targets (apply_update, create_tx, descriptor_parse) plus CI workflow, referencing issue #61. Comfortable across Rust, TypeScript, Python, and Solidity. Self-hosts own infrastructure (Oracle Cloud).
Responsibilities: Full project execution - harness design, crate development, integration reviews, documentation, forum reporting.
```
### Additional Team Members
```team-members.yaml
N/A
```
### Project Summary
An open-source Rust test kit that lets wallets, exchanges, and SDKs verify their own Orchard-to-Ironwood migration code is correct before shipping it to users, plus public reviews of real integrations to prove the kit catches real bugs.
### Project Description
Ironwood introduces a turnstile accounting mechanism that lets anyone verify Zcash's circulating supply is sound. The consensus-level design has already been reviewed and formally verified. The part that has not been addressed is the application layer: every wallet, exchange, and SDK that builds migration support has to write its own code to construct turnstile-aware transactions, track which funds have moved, and handle edge cases like partial migrations or retries.
This is exactly the layer where integration bugs happen, not because the protocol is wrong, but because each team implements the client side independently under time pressure. Shielded Labs already flagged this as a readiness risk before the July 28 activation.
This project builds a reusable, drop-in Rust crate and CLI that any team integrating Ironwood migration can run against their own code to catch these bugs early: value not conserved across the migration, funds silently stuck, replay of already-migrated notes, or incorrect handling of the turnstile cap. It also includes a public checklist in plain language for teams that are not deep into Rust internals.
### Proposed Problem
Wallets, exchanges, and SDKs integrating Orchard-to-Ironwood migration each write their own client-side logic for constructing and tracking migration transactions. There is no shared, tested reference for the common failure modes: value leaks, stuck funds, double-migration, or incorrect handling of turnstile limits. Teams under time pressure (the activation timeline was already extended once due to ecosystem readiness concerns) are likely to ship subtly incorrect migration code, discovered only after user funds are affected.
### Proposed Solution
A small, focused Rust crate (zcash-migration-invariants) with:
1. Property-based tests and fuzz harnesses for turnstile-aware transaction construction and parsing.
2. Reusable invariant assertions - value conservation, no double-migration, no stuck funds - that any team can import into their own test suite.
3. A public, plain-language integration checklist covering the same failure modes for teams that just need to know what to check manually.
4. Public reviews of 2-3 real wallet/exchange migration integrations (recruited via the forum) using the kit, published as case studies.
This does not touch consensus code and does not overlap with the approved Zebra fuzzing grant or the Ironwood soundness fuzzing proposal, both of which work at the consensus/circuit level. This project works one layer up, at the client integration level, which nobody has proposed yet.
### Solution Format
Open-source Rust crate + CLI, published on GitHub under an MIT/Apache license. Public test-vector set. Public markdown checklist. Three public write-ups from real integration reviews.
### Dependencies
Rust toolchain, cargo-fuzz, proptest. Read access to librustzcash and Zebra source for the Orchard/Ironwood transaction types. No paid services required. For milestone 3, needs 2-3 volunteer wallet/exchange teams willing to have their migration code reviewed - will recruit via the ZCG forum, no pre-arranged partnership needed to start the grant.
### Technical Approach
Milestone 1 builds fuzz and property-test harnesses in the same style as my existing BDK fuzz crate (apply_update, create_tx, descriptor_parse targets): arbitrary-input harnesses feeding turnstile-aware transaction construction and parsing paths, run under cargo-fuzz with a CI workflow.
Milestone 2 turns the recurring failure patterns from milestone 1 into a small reusable crate of invariant assertions (value conservation, no double-migration, stuck-fund detection), documented with usage examples, so a wallet team can add three lines to their own test suite instead of building this from scratch.
Milestone 3 applies the full kit to real integrations. I review volunteer wallet/exchange migration code, run the kit against it, and publish findings the same way I publish audit contest findings on Sherlock/C4 - clear severity, clear reproduction steps, clear fix.
### Upstream Merge Opportunities
This project does not fork or modify librustzcash, Zebra, or any consensus repository. It is a standalone crate that depends on their public APIs. If specific edge cases are found that trace back to ambiguity in the reference implementations, I will file upstream issues with reproduction cases, but no merge into core repos is required for this project to deliver its value. No coordination with core maintainers is needed to start; I will loop in maintainers if an upstream issue is found.
### Hardware/Software Costs (USD)
$300
### Hardware/Software Justification
Testnet/mainnet node sync storage and compute on existing Oracle Cloud infra, plus CI minutes for fuzz runs over the grant period.
### Service Costs (USD)
$0
### Service Costs Justification
No external paid services required. All tools used are open source.
### Compensation Costs (USD)
$19,200
### Compensation Costs Justification
Solo developer, ~10 weeks of focused work across 3 milestones, roughly 30-35 hours/week, blended rate reflecting independent security research work (comparable to other solo technical grants in this program, e.g. Arbitrum Foundation Stylus grant at $16,000 for a similar scope).
### Total Budget (USD)
$19,500
### Previous Funding
No
### Previous Funding Details
_No response_
### Other Funding Sources
No
### Other Funding Sources Details
_No response_
### Implementation Risks
Volunteer wallet/exchange teams for milestone 3 may be slow to respond or unwilling to have code reviewed publicly. Mitigation: recruit early via the forum starting in milestone 1, and if no volunteers are found, apply the kit to open-source wallet code directly (Zashi/Zodl, Ywallet, Zenith) instead, since the code is public.
Ironwood's exact client-side migration APIs may still be settling post-activation. Mitigation: build against the stabilized post-July-28 mainnet APIs rather than pre-activation testnet code, so there is less risk of chasing a moving target.
Solo delivery means no backup if I'm unavailable for a stretch. Mitigation: milestones are scoped small enough (3-4 weeks each) that a short delay doesn't cascade, and all work is committed to a public repo as it progresses, not held back until the end.
### Potential Side Effects
None expected. This is a testing and review tool, not a change to any production system. Findings published from milestone 3 will follow responsible disclosure norms - private report to the affected team first, public write-up only after they've had time to fix or respond. No user funds are handled or held at any point.
### Success Metrics
1. zcash-migration-invariants crate published, documented, with test coverage for at least 5 distinct failure modes.
2. At least one real bug found and reported in a live wallet/exchange integration through milestone 3 reviews.
3. Checklist adopted or referenced by at least one wallet/exchange team building Ironwood migration support.
4. All code, test vectors, and write-ups public and reproducible on GitHub.
### Startup Funding (USD)
$4,000
### Startup Funding Justification
Covers milestone 1 (fuzz/property-test harness development), which needs to start immediately to be useful while wallets and exchanges are still actively building out migration support.
### Milestone Details
```milestones.yaml
- Milestone: 1
Amount (USD): 5,000
Expected Completion Date: 2026-09-05
User Stories:
- "As a wallet developer building Ironwood migration support, I want a ready-made fuzz/property-test harness for turnstile transaction construction, so I don't have to build test infrastructure from scratch under time pressure"
Deliverables:
- Fuzz harnesses (cargo-fuzz) covering turnstile-aware transaction construction and parsing
- Public test-vector set for common migration edge cases
- CI workflow that runs the fuzz suite on every commit
Acceptance Criteria: Harnesses run clean in CI, test vectors are documented and reproducible by a third party, repo is public.
- Milestone: 2
Amount (USD): 5,500
Expected Completion Date: 2026-09-30
User Stories:
- "As a wallet or exchange developer, I want a small crate I can import into my own test suite, so I can check my migration code for value leaks or stuck funds without writing my own invariant tests"
Deliverables:
- zcash-migration-invariants crate: value conservation, no double-migration, stuck-fund detection assertions
- Usage documentation with real code examples
- Plain-language integration checklist for non-Rust teams
Acceptance Criteria: Crate published to crates.io or as a GitHub package, at least one working example integration in the docs, checklist reviewed by at least one community member on the forum.
- Milestone: 3
Amount (USD): 5,000
Expected Completion Date: 2026-11-15
User Stories:
- "As a Zcash user migrating funds to Ironwood, I want the wallet or exchange I use to have had its migration code independently checked, so I trust my funds will move correctly"
Deliverables:
- Kit applied to 2-3 real wallet/exchange/SDK migration integrations
- Public write-ups of findings, following responsible disclosure
- Final summary report posted to the ZCG forum thread
Acceptance Criteria: At least 2 integrations reviewed and written up, any findings reported privately first, forum thread updated with final summary.
```