Grant Application - Turnstile Migration Integration Kit

[soloking]

Hello everyone,

I’m Maheswaran Velmurugan, known as soloking1412. I work as an independent developer and security researcher: 20+ confirmed High/Medium findings across EVM protocols on Sherlock, Code4rena, Cantina, and Immunefi, and I’ve completed grants from Arbitrum Foundation (Stylus gas benchmarking toolkit, both milestones accepted) and Stacks Foundation (SatoshiYield). I also contributed a fuzz-testing crate to Bitcoin Development Kit (BDK), which is the closest prior art to what I’m proposing here.

GitHub: soloking1412 (Maheswaran Velmurugan) · GitHub

GitHub Proposal

Grant Application - Turnstile Migration Integration Kit

Why this, why now

Ironwood introduces a turnstile mechanism so anyone can verify Zcash’s circulating supply by running a node. That part is solid, it’s been reviewed and formally verified at the consensus level.

What hasn’t been addressed is the layer above it: every wallet, exchange, and SDK integrating migration support has to write its own client-side code to construct and track these transactions. Shielded Labs already flagged that some of these teams might not have enough time to prepare. That’s exactly the kind of gap where bugs slip through, not because the protocol is wrong, but because each integration is built independently under time pressure.

This proposal is not about fuzzing Zebra or the Ironwood circuit itself. The approved Zebra Coverage-Guided Fuzzing grant and the Batch-vs-Single Verification soundness fuzzing proposal already cover that layer, and I don’t want to duplicate either. This sits one layer up: a Rust crate and CLI that wallet/exchange/SDK teams can run against their own migration code to catch value leaks, stuck funds, double-migration, and turnstile-cap handling bugs before shipping. Plus a plain-language checklist for teams that don’t want to touch Rust directly.

Why me

I don’t just write about security, I ship into production codebases. I currently have open and merged contributions to paritytech/polkadot-sdk, on pallet-revive’s Ethereum JSON-RPC layer (the pallet that gives Polkadot parachains EVM compatibility), fixing exactly the kind of edge-case bugs this grant is about: null values, empty filter lists, boundary block tags, and spec-compliance gaps that don’t show up until something hits a corner case.

Full list here: Pull requests · paritytech/polkadot-sdk · GitHub

On the Zcash-adjacent side:

• Stylus-Toolkit (GitHub - soloking1412/Stylus-Toolkit: Build, deploy, and profile Stylus contracts with simple commands. · GitHub, 20 stars) - built and shipped through an Arbitrum Foundation grant, both milestones accepted.
• avaguard-avax (GitHub - soloking1412/avaguard-avax: Circuit breaker and invariant monitoring for Avalanche L1s. · GitHub) - circuit breaker and invariant monitoring for Avalanche L1s. Same shape of tool as what I’m proposing here, just a different chain.
• BDK fuzz crate (bitcoindevkit/bdk) - cargo-fuzz harnesses for apply_update, create_tx, descriptor_parse, referencing issue #61. Closest prior art to the harnesses I’d build for turnstile migration.
• 20+ confirmed High/Medium findings on Sherlock, Code4rena, Cantina, Immunefi.

soloking1412 (Maheswaran Velmurugan) · GitHub has the full history if you want to check any of it yourself before deciding.

I’m doing this solo, no team, so budget and scope are kept tight on purpose: $19,500 across a $4,000 startup advance and 3 milestones ($5,000 / $5,500 / $5,000), roughly 10 weeks.

Happy to answer anything, including if you think this overlaps with something I’ve missed or if the scope should be narrower or wider.

[ZKZeek]

Alongside value conservation and no double migration, could an invariant also flag a wallet that migrates correctly but in a pattern distinctive enough to fingerprint the user, or is that out of scope? A shared correctness kit for the migration layer is the gap teams hit before July 28.

[soloking]

Good question, and it’s a genuinely different kind of check than the ones I’ve scoped.

Value conservation and no-double-migration are local invariants. You can check them on a single transaction in isolation: does the amount in match the amount out, has this note already moved. Binary, checkable, no comparison needed.

Fingerprinting is a different class of property. A wallet can pass every correctness check and still leak information through how it constructs the migration: note selection order, batch size, timing relative to other wallets, fee rounding. To flag that as distinctive you need a reference or baseline to compare against, not just the transaction itself. That’s closer to the kind of wallet-fingerprinting research that’s been done on Bitcoin UTXO selection than to an invariant check.

As scoped right now (solo, 3 milestones, ~10 weeks), I’ve kept this to correctness invariants so the core kit actually ships on time. But if the reviewers or the community feel a fingerprinting/linkability check belongs in this grant rather than as separate work, I’m open to building it. It would likely mean either a 4th milestone or reshaping milestone 2, and I’d want to scope it properly first rather than bolt it on loosely. Let me know if that’s the direction you’d want, and I’ll write up what that milestone would look like.

[ZKZeek]

Agree it is separate work, a fingerprinting baseline only matters once wallets converge on a shared correctness kit to measure against. Shipping the invariants for July 28 is the higher priority, and a linkability check reads like its own grant once there are real migrations to profile.

[soloking]

Exactly, that’s the right sequencing. A correctness baseline has to exist first before a fingerprinting check has anything meaningful to measure against.

Keeping this scoped to invariants and shipping before/around July 28. Will flag on the forum if a linkability follow-up makes sense once there’s real migration data to work with. Thanks for pushing on this, good to have it explicitly out of scope rather than implied.

[ZCG]

Thank you for your submission. After consideration from ZCG and sufficient time for the community to provide feedback on the forum, the committee has decided to reject this proposal.

The committee appreciates your grant submission efforts and encourages you to continue as an active member of the Zcash community going forward!