Terms and Conditions
- I agree to the Grant Agreement terms if funded
- I agree to Provide KYC information if funded above $50,000 USD
- I agree to disclose conflicts of interest
- I understand that this grant program is only eligible for completed work, as it is a retroactive grant program. Applications for planned or partially completed work will not be considered. All completed work will be verified and accepted by its intended users or their representatives, who will confirm that the outputs meet the required quality, functionality, and usability before the work is listed as an option for Coinholder voting.
- 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
librustzcashstyle guides as a primary reference. - 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, branch, pull request, and commit guidelines as exemplified in the librustzcash repository.
- I understand all grants are valued in USD but will be disbursed in Shielded ZEC. I acknowledge and accept that disbursement amounts may fluctuate based on the ZEC/USD exchange rate at the time of payment.
Application Owners (@octocat, @octocat1)
@metaforismo
Organization or Individual Name
Individual — Independent security researcher
Additional Team Members
Francesco Giannicola (@metaforismo) — principal investigator (elliptic-curve cryptography researcher, co-author of ECDSA.Fail, secp256k1 research). AI-assisted audit methodology disclosed below; all findings human-verified with executed proofs-of-concept.
How did you learn about the Lockbox: Coinholder Retroactive Grants Program?
Through the Zcash ecosystem: following the Q3 2026 round (including the Orchard incident response and the $1.5M Hornby award), the ZIP-1016 ratification discussions, and the FROST/ZIP-312 standardization work. The retroactive model — paying for completed, verifiable security work rather than promises — is the natural vehicle for independent audit work of this kind.
Requested Grant Amount (USD)
$40,000
Category
Research & Development
Project Summary
Independent, in-depth security audit of FROST v3 (Flexible Round-Optimized Schnorr Threshold Signatures) as specified for Zcash shielded multisig in ZIP-312 — covering frost-core v3.0.0, the RedPallas/RedJubjub ciphersuites, the DKG implementation, and the frost-tools application layer. Headline result, stated honestly: no critical vulnerability was found; the codebase is in excellent shape — this audit independently confirms it across 21+ investigated leads, each chased to a documented kill reason.
Project Description
Why FROST, why now
FROST is the threshold Schnorr signature scheme selected for Zcash shielded multisig (ZIP-312, IETF standardization track). Threshold signatures are a historically subtle class — nonce handling, DKG robustness, and cheater detection are where the real bugs live. The v3 codebase (2026) is new: it has not been through the "AI bug crisis" re-auditing wave that covered Orchard and Zebra. An independent audit before wallets ship FROST signing to users is precisely the kind of preventive security work the retroactive model exists to reward.
What was audited (real code, not specs)
- ZcashFoundation/frost, frost-core v3.0.0 (0966bd1): round1 (nonces), round2 (signing), aggregate, cheater detection, DKG, refresh, identifiers
- frost-rerandomized v3.0.0: ZIP-312 re-randomization mechanism
- RedPallas/RedJubjub FROST ciphersuites (reddsa pre-removal commit 3a1533b): custom ciphersuite overrides (highest-risk zone per the Mina audit lesson)
- frost-secp256k1-tr (workspace): cross-check of sign/verify symmetry
- frost-tools (frostd, coordinator, participant, zcash-sign) main @ 2026-10-14: application layer — session management, relay, signing UX
- ywallet / Zallet / FROST Book flow HEAD Oct 2026: production wallet integration check
Methodology (AI-assisted, human-verified)
AI-assisted analysis with a strict protocol: no lead is closed without a proof-of-concept or a formal kill reason. Two Round-1 candidates were later debunked by the same methodology (documented below); this is presented as evidence of rigor, not hidden. This follows the demonstrated precedent in the ecosystem: the $1.5M Orchard finding (Q3) was produced with AI assistance. AI is the instrument; the judgment and verification are human.
Round 1 — Library audit (frost-core v3.0.0): 14 leads, all killed, code excellent
- Nonce management: hedged generation per RFC 9591 (H3(random || secret)); binding factor correctly covers (group VK || H4(msg) || H5(commitments) || id); IncorrectCommitment check in sign() blocks in-session commitment substitution by a malicious coordinator. Correction (post-publication): this check does NOT prevent cross-session reuse of the same nonce/commitment pair — the library holds no cross-session state, and fresh nonces per session remain the application's documented responsibility (RFC 9591). The original report's reasoning overstated the check's scope; the library is sound per its threat model.
- DKG robustness: Schnorr PoK with verified domain separation (FROST_RedPallasD); rogue-key defense per FROST paper; VSS share verification with culprit identification (cheater detection default-on in v3).
- Binding & context: challenge H2 verified against Zcash spec (Zcash_RedPallasH); complete domain separation across all hash contexts; serialization headers prevent cross-ciphersuite confusion; re-randomization sound. Correction (post-publication): in frost-rerandomized, the randomizer is derived from both the seed AND the signing commitments (regenerate_from_seed_and_commitments) — repeating a seed alone does not reproduce the same randomized key. The original report's reasoning on coordinator seed-reuse was imprecise; the no-forgery conclusion stands.
- Rogue-key attacks: defenses complete for DKG, trusted dealer, and Taproot (BIP-341 unspendable tweak).
- RedPallas custom ciphersuite (577 lines, recovered from pre-removal commit — the highest-risk zone): EvenY algebraic consistency verified; DKG participant coherence verified. Two robustness nits noted (an .expect() on derivable data; an undocumented-but-sound PoK skip).
Full report: https://github.com/metaforismo/frost-security-review/blob/main/reports/frost-library/AUDIT-REPORT-2026-10-17.md
Round 2 — Application layer: 1 confirmed, 2 debunked, rest negative
- frostd memory exhaustion — CONFIRMED (mechanism). Unbounded recipient buffering in send confirmed by source-code review and local fan-out test; filed as ZcashFoundation/frost-tools#611. The original report's specific RSS measurements and 29,000-recipient SIGABRT kill test are as-reported without published execution logs — the mechanism, not the exact numbers, is the verified claim. Honest caveat: frostd is explicitly demo/reference code; requires self-registered login.
- Noise_K peer impersonation — DEBUNKED (two independent verifications). Round 1 applied Noise X-pattern logic to the K pattern; in K the initiator transmits no static key and Dh(Ss) requires the victim's private key — impersonation is cryptographically impossible. The proposed fix was retracted as tautological. Residual: K-handshake replay -> slot-squat DoS (low, known).
- Missing cheater detection — DEBUNKED (Round 1 was factually wrong). cheater-detection is in frost-core 2.2.0's default features; the culprit IS identified (InvalidSignatureShare { culprit: ... }). Lesson documented: always verify default features before claiming their absence.
- Fuzzing — honest negative. ~1,270 requests against frostd (malformed inputs, state-machine sequences, races, boundaries) on release AND debug builds (overflow checks active): 0 crashes, 0 panics, 0 bypasses. Notable: the fuzzer had to construct a valid XEdDSA signer to test the real login path.
- Chaining — honest negative. Systematic composition matrix of all candidates: no chain escalates from DoS/design-gap to funds or keys. The #2 debunking kills the chains built on it.
- ywallet/Zallet integration check: neither contains FROST signing code (exhaustively verified; Zallet has it only as a transitive dependency). The FROST Book demo flow is broken in HEAD. Blind-signing gap documented: traced the sighash end-to-end — every human checkpoint (zcash-sign, coordinator, participant) displays only opaque hex. A malicious coordinator could get honest co-signers to sign an attacker-crafted PCZT. No production wallet consumes this flow today -> documented as a design gap for future integrators, not filed as a vulnerability.
Full reports: https://github.com/metaforismo/frost-security-review/tree/main/reports/frost-application-layer
What this work gives the ecosystem
- Assurance: independent confirmation that FROST v3 — the foundation of shielded multisig — is sound. This is not the team auditing itself.
- One real bug (frostd DoS) with a reproducible PoC the maintainers can fix.
- A documented design gap (blind signing) that every future FROST wallet integrator should address before shipping.
- Methodology transparency: including the debunked false positives, so the community can trust what is claimed.
What this work is NOT
- Not a critical vulnerability. Stated plainly: the $150k+ Q3 security grants were for actual vulnerabilities. This application does not claim that tier of impact.
- Not production-code findings: the confirmed DoS is in demo/reference code; no production wallet was affected.
- The amount requested ($40,000) reflects this honestly.
All reports, PoC code, and fuzzing harnesses: https://github.com/metaforismo/frost-security-review
Technical Approach (how you did it)
Audit di sicurezza indipendente con metodologia AI-assisted ma human-verified: nessun lead chiuso senza proof-of-concept eseguito o kill reason formale. Round 1: revisione manuale del codice frost-core v3.0.0 (round1/round2, aggregate, cheater detection, DKG, refresh, identifiers), frost-rerandomized, ciphersuite RedPallas/RedJubjub e application layer frost-tools. Round 2: fuzzing (~1.270 richieste contro frostd, build release e debug), test di fan-out locale, verifica end-to-end del flusso sighash/PCZT, controllo integrazione ywallet/Zallet.
Time Period of Work Completion
Q4 2026 (October 2026)
Total Budget (USD)
$40,000
Budget Breakdown
- Compensation:
- $(USD): 40000
- Justification: Independent security audit of FROST v3 (library + application layer), October 2026
- Technology/Software:
- $(USD): 0
- Justification: N/A
- Infrastructure/Hosting:
- $(USD): 0
- Justification: N/A
- Services/Contractors:
- $(USD): 0
- Justification: N/A
- Other:
- $(USD): 0
- Justification: N/A
- Total $(USD): 40000
Previous Funding
No
Previous Funding Details
N/A
Other Funding Sources
No
Other Funding Sources Details
N/A
Success Metrics
21+ lead investigati con kill reason documentate; conferma indipendente che FROST v3 è solido; 1 bug reale (frostd DoS) segnalato come ZcashFoundation/frost-tools#611 con PoC riproducibile; gap di progettazione (blind signing) documentato per i futuri integratori; tutti i report, PoC e harness di fuzzing pubblicati e verificabili.
Proof of completion
- Repository:
- Library audit report:
- Application-layer reports:
- Filed bug report:
Conflict of Interest Disclosure
None — independent researcher, no affiliation with ZcashFoundation/frost maintainers.
Community Forum Posting
- I understand it is my responsibility to post a link to this issue on the Zcash Community Forums after this application has been submitted so the community can give input. I understand this is required in order for the community to discuss and vote on this grant application. Note: If you are unable to post on the forum (for example, due to new user restrictions), please leave a comment below, and we will adjust your posting permissions.