Interoperable FROST co-signing for shielded ZEC: open specs and a reference implementation

1. Executive summary and decision snapshot

OpenPGP Wallet requests $16,500 for interoperable shielded-ZEC FROST signing and backup specifications, a Rust crate, and a wallet reference implementation. Khadim would deliver it alone. The request is under review, with two acceptance-based payments and no startup funding. [1][5]

The strongest capability evidence is an October 15 applicant report of three mainnet spends covering every signer pair, with independent transaction checking by the second device in two spends. Inference: this supports implementation feasibility, but does not establish cross-wallet interoperability or production security. [7]

The central evaluation question is whether this becomes a genuinely shared standard rather than one wallet’s interface. External adoption, security review, upstream readiness, and solo-developer capacity are the principal delivery/value considerations. [1][4][5][7]

2. Applicant and team track record

Khadim describes a background in cybersecurity studies, penetration testing, and web development. He reports shipping 17 OpenPGP Wallet releases since September 20, 2026, using Rust/Tauri and librustzcash, with shielded-ZEC and hardware-wallet support. These are applicant-reported credentials, not independent assessments. [1]

The mainnet prototype is the most directly relevant work sample; the applicant credits aryaethn’s Ironwood signing work and testnet transaction as implementation references. [7]

Prior ZCG grant performance and independently demonstrated user adoption: No grounded evidence found. The supplied material does not establish whether the applicant has other grant history.

3. Proposal scope, milestones, budget, technical approach, and dependencies

• Milestone 1 — $9,000, six weeks: desktop FROST 2-of-3 account, test co-signer using QR messaging, reproducible testnet/mainnet Ironwood spends, and specification draft v0.1. [5]
• Milestone 2 — $7,500, five weeks: standalone crate publication, mnemonic and phrase-free share-backup profiles, recovery by sweeping to a fresh FROST account, reviewed specification v1.0, and an independent-audit scope. [5]
• Budget: entirely compensation—11 weeks at $1,500/week; hardware and services are budgeted at zero. Payments follow acceptance. Public verification is proposed through transaction IDs, specifications, and crate publication. [5][8]

The design uses existing FROST components, distributed key generation, re-randomized signing over PCZTs, and signer-side transaction checks. The updated scope describes a shared group descriptor, transport-independent envelope, and extensible backup format; QR becomes its first transport profile. The applicant says milestones and budget remain unchanged. [4][7]

A public mainnet release waits for the viewing-key standard and independent audit. An Android co-signer requires a follow-up request; other networks are excluded. The funded audit deliverable is a scope, not the audit itself. [5]

4. Community discussion, arguments, responses, and resolution

Strongest case for: the applicant argues that shared messages and backups could prevent wallet lock-in, reduce duplicated protocol work, and enable signers from different vendors. These are proposed benefits, not demonstrated outcomes. [5]

Strongest challenge raised: aryaethn directed the applicant to the rejected threshold-custody proposal. Khadim responded that its committee feedback shaped this request: an existing wallet, smaller budget, and payment only on delivery. Aryaethn offered conditional collaboration on the ZIP specification, not a firm implementation commitment. [5][6]

Clarifications and partial resolution: the applicant confirmed the budget and public deliverables. The later prototype report supersedes the initial statement that FROST was not implemented. He also reported adopting Hanh’s suggestion of a small common core with application-specific extensions. [8][5][7]

Remaining disagreement: no direct opposing technical review of this request is supplied. The adoption concern remains substantively open: cross-implementation testing is proposed “with whoever is up for it,” rather than backed by a committed wallet partner. [7]

5. Relevant precedents and documented outcomes

• ZeWiF — $121,200, approved: the closest standards precedent, covering wallet interchange specifications and Rust import/export libraries. Committee support emphasized ecosystem compatibility and favorable technical review. All five milestones are marked complete, but no demonstrated adoption or recovery outcomes are supplied; completion labels do not prove impact. Inference: its relevant lesson is stakeholder-backed standardization, not a price benchmark. [12]
• FROST Shielded Multi-Sig SDK — $22,000, declined: committee concerns centered on speculative API fit, weak developer involvement, and unresolved secure messaging, backup, and recovery. Inference: the current application addresses more of those subjects explicitly, but still needs evidence that other wallets will use the result. [13]
• Threshold custody for shielded ZEC — $47,000, declined: despite a reproduced testnet flow, concerns included adoption, maintenance, solo execution, audit needs, and upstream dependencies. Inference: an operational prototype alone did not settle the committee’s demand and sustainability concerns. [14]

6. Material risks and execution considerations

• Setup security exception: the design allows the phone to temporarily hold two shares during backup-participant setup, with a spare device offered as an alternative. Inference: the claimed protection against one compromised device needs an explicit setup-phase qualification and reviewed mitigation. [4]
• Network and standards readiness: the applicant says testnet’s NU7 transition prevented testing with current tools, so the prototype used mainnet. ZIP 2005 keys are reportedly implemented, while ZIP 312 key-generation changes remain pending. Inference: standards alignment in a prototype does not establish release readiness or satisfy the promised testnet demonstration. [7]
• Schedule concentration: one person owns specification, implementation, tests, releases, and reporting over 11 weeks. Inference: external review and compatibility changes could strain that schedule; acceptance-based payment limits advance-payment exposure but not delivery delay. [1][8]

Independent security-review findings, accepted milestone evidence, and cross-wallet test results: No grounded evidence found.

7. Material gaps and questions for the applicant

• Which independently maintained wallet will commit to signing and backup-restoration interoperability tests, and will passing those tests be required for acceptance?
• Who will validate each milestone, and what reproducible evidence will distinguish a functioning threshold protocol from transaction IDs alone?
• How will testnet delivery be completed if tooling remains incompatible, and what fallback requires committee approval?
• What threat model and tests cover temporary two-share custody, nonce reuse, malicious coordinators, and backup recovery?
• Who will fund and perform the independent audit, and what restrictions will prevent premature public release?
• What maintenance period, compatibility policy, and handover plan are included after the second payment?

These questions target the proposed acceptance model, current testing constraints, security design, release gates, and single-person delivery structure. [1][4][5][7][8]

8. Neutral decision considerations

Inference: the committee can distinguish three kinds of value: a functioning reference implementation, a reusable interoperability standard, and a safe consumer release. The proposed deliverables address the first two; the public release remains dependent on separately completed prerequisites. [5][7]

Possible funding conditions—not an approval recommendation—include named technical reviewers, measurable cross-wallet tests, explicit dependency fallbacks, and documented security/release boundaries. Alternatively, the committee could seek partner commitments and reproducible prototype validation before deciding whether the shared-standard value is sufficiently grounded. These conditions directly address the adoption and execution concerns documented in the FROST precedents. [13][14]

9. Numbered source list

• [1] Grant Application - Interoperable FROST co-signing for shielded ZEC: open specs and a reference implementation — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/490
• [5] Interoperable FROST co-signing for shielded ZEC: open specs and a reference implementation — posts 1–5, part 1 — https://forum.zcashcommunity.com/t/interoperable-frost-co-signing-for-shielded-zec-open-specs-and-a-reference-implementation/58172/1
• [7] Interoperable FROST co-signing for shielded ZEC: open specs and a reference implementation — posts 6–10 — https://forum.zcashcommunity.com/t/interoperable-frost-co-signing-for-shielded-zec-open-specs-and-a-reference-implementation/58172/6
• [4] FROST 2-of-3 between a user's own devices for shielded ZEC (Ironwood) — posts 1–5 — https://forum.zcashcommunity.com/t/frost-2-of-3-between-a-users-own-devices-for-shielded-zec-ironwood/58164/1
• [8] Comment on #490: Grant Application - Interoperable FROST co-signing for shielded ZEC: open specs and a reference implementation — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/490#issuecomment-6151186325
• [6] Interoperable FROST co-signing for shielded ZEC: open specs and a reference implementation — posts 1–5, part 2 — https://forum.zcashcommunity.com/t/interoperable-frost-co-signing-for-shielded-zec-open-specs-and-a-reference-implementation/58172/4
• [12] Zcash Extensible Wallet Interchange Format (ZeWiF) — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/3
• [13] FROST Shielded Multi-Sig SDK: Easy Threshold Custody for Zcash Wallets — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/351
• [14] Threshold (FROST) custody for shielded ZEC — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/358