Hi everyone!
I’m applying for a retroactive “bug bounty” coinholder grant for discovering and responsibly disclosing the Orchard counterfeiting vulnerability, which I found while doing Zcash security auditing work for Shielded Labs.
I believe that funding this grant will set a precedent that creates a “pressure relief valve”, giving anyone who ends up in the position I was in—finding a vulnerability that could be used to inflate the supply of ZEC within a shielded pool—a strong incentive to report the issue honestly, and less incentive to exploit it maliciously.
Below is a copy of my grant proposal, which has been cut down a little bit from the full version on GitHub to make it more readable here.
Organization or Individual Name
Taylor Hornby
Additional Team Members
I am requesting this bounty as an individual, however my work was made possible thanks to Shielded Labs funding my LLM-assisted auditing research as well as the audit that found this bug. ZODL’s and Zcash Foundation’s teams and leadership deserve an immense amount of credit for patching the vulnerability in an unprecedented security response (really the best I have ever seen in my career!).
Requested Grant Amount (USD)
$750,000
Project Summary
I am requesting a bug bounty for responsibly disclosing the Orchard counterfeiting vulnerability, which likely prevented the loss of $2.3B USD worth of ZEC. Funding this bounty supports Zcash’s long-term security: it sends a message to security researchers that they can report potentially-devastating counterfeiting vulnerabilities and have a good chance of getting paid legitimately, reducing the incentive to exploit counterfeiting vulnerabilities maliciously.
Project Description
I am applying for a bug bounty as a result of finding and responsibly disclosing the recent Orchard counterfeiting vulnerability. I found the bug while developing AI-assisted security auditing tools and performing Zcash security audits as a contractor for Shielded Labs, though I am applying for the grant as an individual.
If the vulnerability had been exploited, it would have allowed an unlimited amount of ZEC to be minted within the Orchard pool. If an attacker exploited the bug, they could have effectively “stolen” all of the funds in the Orchard pool. At the time, Orchard contained around 4.2M ZEC, worth $2.3B USD. Without my timely disclosure, the bug could have been found and exploited by a malicious actor using AI tools.
Funding this bounty is important for Zcash’s long-term security. It sends a message to security researchers: if you find a catastrophic counterfeiting bug in Zcash, you can report it honestly, request a bounty through a retroactive grant (even though there isn’t a formal bug bounty program), and have a good chance of getting paid legitimately.
Funding this bounty reduces the incentive to attack Zcash. This is especially important as a fallback in the absence of a formal bug bounty program; ZCG’s bounty program was closed just days before I discovered the bug! Hopefully this was the last counterfeiting vulnerability Zcash will ever have, but just in case it isn’t, this precedent will help encourage future bug-discoverers to do the right thing.
Asking for $750,000 is a lot, so it’s important to justify that number. The bounty programs of several major projects suggest an award of 10% of the affected funds up to maximums of around $1M-$2M (e.g. 1, 2):
“Critical bug bounty payouts should be priced as a percentage of the economic damage they would have caused, so that even blackhats are incentivized to review code and disclose vulnerabilities, thereby reducing malicious exploits. For most DeFi projects, that’s 10% of TVL at risk.” — Immunefi
I’d rather keep my ask below industry norms, and I’ve already received some gifts, so I am asking for an amount that’s reasonable in proportion to the harms that were prevented, and which will help me continue to expand the ways I can contribute to Zcash. The following table will help you compare my ask to a sampling of similar cases:
| Precedent | Vulnerability / impact | Funds at risk (approx.) | Bounty | Ratio (approx.) |
|---|---|---|---|---|
| Wormhole, 2022 — satya0x | Uninitialized implementation contract allowed an attacker-controlled Guardian set and SELFDESTRUCT of the implementation, bricking the Ethereum bridge and locking its assets | $1.8B in the contract at time of submission | $10,000,000 | 0.56% |
| Aurora, 2022 — pwning.eth | “Infinite spend” allowing repeated balance doubling; effectively infinite ETH creation in the Aurora Engine | 70,000 ETH ($204M) plus $200M in other assets | $6,000,000 | 1.48% |
| Optimism, 2022 — Jay Freeman (saurik) | Unlimited creation of OETH; counterfeit OETH could drain DEXes and bridged assets | $322.5M TVL | $2,000,042 | 0.62% |
| Polygon, 2021 — Gerhard Wagner | Plasma Bridge replay/double-spend allowing one burn transaction to be exited up to 223 times | $850M | $2,000,000 | 0.24% |
| Belt Finance, 2021 — Alexander Schlindwein | Logic error produced excess shares; repeatable until the contract was drained | $60M (single iteration $10M) | $1,050,000 total ($1M Belt + $50k BSC match) | 1.75% |
| My request | Unlimited, undetectable creation of counterfeit ZEC within Orchard | $2.29B (4.2M ZEC at $545) | $750,000 | 0.033% |
Comparing funds-at-risk to bounty reward ratios, the reward ratio I am asking for is 1/7th of the smallest ratio in the table above.
Technical Approach
In September of 2025, I started developing tools for security auditing using LLMs. My intention was to automate as much of my manual security audit process as possible. The models that existed at the time weren’t that smart, so this took a lot of prompt engineering, but it worked.
I continued developing the tools throughout 2026 and started running them against Zcash-adjacent software like the Keystone hardware wallet and found some bugs. I’ve open-sourced this general-purpose AI auditing framework on GitHub: defuse/auditician (this is not a deliverable for this grant).
Later on, Shielded Labs hired me as a contractor to continue this work and audit more Zcash-related software. I ended up developing a new set of agents specifically for auditing Zcash. Using those agents to audit Orchard’s balance integrity properties, with Opus 4.8 the day after it was released, was what ultimately found this bug.
In brief, the agent framework that found the bug is based on the principle that a bug becomes transparent to an LLM when it has everything it needs to spot the bug right there in its context window: the security property that’s violated, good ideas for how that security property can be attacked, and all of the relevant code and specification text. To make that happen, the tool:
- First helps you clearly define the security property you’re trying to attack (in this case, Orchard balance integrity).
- Then it enumerates all relevant statements in the protocol specification and ZIPs, all relevant security sub-properties, all possible failure modes (attack ideas), and all relevant code locations. This requires running several rounds of expansion to find everything.
- Then it passes small batches of the enumerated items to agents designed for specific auditing purposes: A design-auditor checks if the specification itself contains any vulnerabilities, a failure-mode-auditor checks if any of the attack ideas actually work, a code-auditor spends time looking for vulnerabilities in a region of code, and a security-property-auditor exhaustively checks whether a claimed security property is true or false.
- Finally, an issue validator agent then validates and tries to expand on all of the security issues that come out of this process.
The day after Opus 4.8 was released, I set this framework running to audit Orchard’s balance integrity. A few hours later it found the vulnerability, which had been missed by all of my prior AI-assisted (and manual) audits of Orchard.
At first I couldn’t believe the bug was real, but Claude’s explanation sounded correct. I used Claude to help me develop a series of proof of concepts, starting by writing a small circuit that just used the vulnerable component, which proved to me that a critical circuit constraint was actually missing.
I immediately reported the issue to ZODL, then, working overnight, I had Claude develop a full proof of concept as an RPC test within zcashd. The RPC test proved the issue was exploitable by creating millions of “regtest” ZEC on my local node (regtest is zcashd’s testing mode, none of this ever hit a live chain). Having the ability to create infinite ZEC right in front of me was honestly the craziest emotional experience of my life; while I’d like to think that I’d do the right thing in any case, my shared history with and love for the Zcash engineers, who pretty much raised me intellectually and morally, and the possibility of applying for this grant, made it a lot easier to make the right choice.
I spent the next weeks helping the ZODL and ZF engineers by reviewing and testing the patches that temporarily disabled the Orchard pool to close off the vulnerability, as well as the changes that eventually re-enabled a secure Orchard pool.
The full details can be found in Shielded Labs’ blog post and my work log.
Previous Funding Details
I have not received any prior funding from the Zcash Coinholder Grants Program. In 2022-2023, I received funding from ZCG for my Zcash Ecosystem Security Lead grant.
Other Funding Sources
I received one substantial gift as well as some smaller ones in response to this tweet. Shielded Labs paid me at my regular consulting rate for the Zcash-specific research and auditing work. I have chosen to request an amount below the industry norms cited above.
Success Metrics
Assuming the bug was not exploited during the four-year period of vulnerability (it looks like it wasn’t), this work prevented unbounded inflation within the Orchard pool, possibly resulting in the loss of all Orchard ZEC. This would have been devastating not only to everyone who held Orchard ZEC but also to Zcash’s reputation as a safe, private store of value.
The discovery of this bug also led the community to develop and deploy the formally-verified Ironwood pool, which aims to mathematically close off the possibility of similar bugs being found in that pool as well as the current Orchard pool. (I did not contribute to Ironwood’s development, aside from some security review.)
Proof of completion
A full writeup, as well as my work log, is available in Shielded Labs’ blog post.
See also ZODL’s post and Zcash Foundation’s post about the vulnerability.
Conflict of Interest Disclosure
I’m a board member of the Zcash Foundation, I am an independent contractor doing work for Shielded Labs, and I own various stocks and cryptocurrencies, including ZEC. The Zcash Foundation is one of the keyholders for the disbursement of funds from this grant program, as is Shielded Labs, so I will recuse myself from any discussion around supporting/vetoing/funding grants in this round, as well as anything else related to coinholder grants voting. I will not vote for my proposal with my own coins. I’ve reviewed ZIP-1016 and I believe I am eligible to apply for this grant as an individual.
