Threshold (FROST) custody for shielded ZEC

1. Executive summary and decision snapshot

Aria Naraghi, applying as an individual and sole developer, requests $47,000 to build organization-oriented threshold custody for shielded ZEC using rerandomized FROST, distributed key generation (DKG), PCZT-based transaction signing, recovery/backup handling, a coordinator service, audit-oriented viewing-key access, and Keystone hardware-signer integration. The proposal targets Ironwood-compatible shielded custody. [1][12]

The strongest capability evidence is a claimed end-to-end reproduction of a 2-of-3 rerandomized-FROST authorization for an Ironwood shielded testnet spend, plus the applicant’s stated intention to upstream an Ironwood signing-path fix. Committee minutes also record that the applicant had reproduced the flow on Ironwood testnet and filed an upstream fix without charging it to the grant. [4][12]

The central decision issue is whether this $47,000 solo-developer project can turn demonstrated cryptographic integration into an organization-grade custody product with a credible recovery, messaging, hardware, audit, and maintenance model. Similar FROST SDK and signing-kit proposals were declined when adoption need, application fit, secure coordination, recovery, and duplication with existing tooling were unclear. [15][16]

Inference: The proposal is potentially more differentiated than a generic wallet SDK because it focuses on treasury ceremony, recovery, audit, and hardware workflows. Its value nonetheless depends on proving that these workflows are both technically secure and wanted by a defined organizational user group. [5][7][15]

2. Applicant and team track record

The applicant is Aria Naraghi, an individual applicant and solo researcher/engineer responsible for research, implementation, interoperability feedback, documentation, and milestone delivery. No additional team members are listed. [1]

The applicant self-reports more than seven years of blockchain and applied-cryptography research experience, a current senior research-specialist role at Rango Exchange, authorship or co-authorship of several Ethereum standards proposals, and prior work on cryptographic libraries and zero-knowledge-related implementations. These are applicant-provided credentials; no independent performance record or prior ZCG delivery record is supplied in the evidence. [1]

The most directly relevant demonstrated work is the claimed Ironwood testnet FROST-over-PCZT reproduction. The applicant also identified incompatibilities between existing Zcash development and signing tools and described creating temporary tools to bridge the gap for the demonstration. [4]

Material limitation: No grounded evidence found of completed prior grants, independent security audits of the applicant’s code, organizational custody deployments, or a second engineer able to cover cryptographic review, operational security, hardware integration, or continuity risk. [1]

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

Documented scope includes:

• COCKTAIL-DKG-based key generation intended to conform to ZIP-2005 expectations. [12]
• Backup and recovery handling for quantum-recovery key material (“qsk”). [12]
• Rerandomized FROST signing over PCZTs for Ironwood shielded transactions. [12]
• A coordinator service, Keystone hardware-signer integration, and viewing-key-based audit capabilities such as balance, memo, and ledger access. [5][12]
• An initial desktop/CLI-oriented approach, with an embeddable core rather than a complete wallet. [5][7]

The request is $47,000. After being challenged about a calculation, the applicant stated that the startup and milestone budget totaled $47,000, but the supplied evidence does not provide the milestone amounts, schedule, payment tranches, acceptance criteria, or detailed budget breakdown. [1][11]

Key dependencies include draft DKG interoperability work, possible ZIP-312 changes, ZIP-2005 recovery design, upstream FROST tooling, Keystone’s shielded-PCZT support, and a secure participant-coordination transport. [5][6][7]

A material scope ambiguity remains: the applicant told a community respondent that the Ironwood tooling-version update itself was removed from the proposal, while the committee’s summary includes Ironwood FROST-over-PCZT signing in scope. The committee should establish whether grant deliverables include upstream Ironwood compatibility work, only product-level integration, or both. [7][12]

4. Community discussion, arguments, responses, and resolution

Strongest arguments for

• Existing FROST components appear available, while organization-grade assembly—ceremony, recovery, hardware signing, auditing, and coordination—remains incomplete. [4][5]
• The applicant presented a claimed working Ironwood testnet signing demonstration rather than only a design proposal. [4][12]
• The applicant adjusted the proposed role after technical feedback, framing DKG work as implementation support for evolving specifications rather than competing specification authorship. [6][7]

Strongest arguments against

• Secure authenticated messaging, participant coordination, backup of additional key material, malicious-participant handling, threshold reconfiguration, and recovery are difficult product-security problems rather than simple SDK features. [6][8][15]
• Existing FROST implementations already provide DKG and GUI functionality, although Ironwood support and portable recovery are incomplete. This raises both duplication and differentiation questions. [7][8]
• A committee recently declined a FROST SDK because generic APIs may not fit real application needs and lacked committed adopters; it also declined a signing kit whose usefulness relative to Foundation tooling was unclear. [15][16]

Responses and resolution

• The applicant acknowledged Zkool’s existing work, narrowed the intended product toward organizational custody, and proposed an embeddable crate rather than competing directly as a wallet. [7][9]
• The applicant proposed QR-based hardware-signing rounds and considered Tor-backed coordinator transport rather than building a general-purpose transport protocol. [7]
• The discussion clarified that trusted-dealer setup is not the desired custody model and that recovery portability is an unresolved ecosystem issue. [6][8][9]

Disagreement remains over demand, product boundaries relative to existing tools, and whether the proposed funding level can securely cover the full operational custody workflow. [8][15][16]

5. Relevant precedents and documented outcomes

Ledger shielded support — approved, $300,000. This is relevant because the current proposal depends on hardware-signing usability. The approved Ledger grant covered audited shielded transaction support, device clear-signing, Unified Addresses, testing, and wallet integration; committee discussion cited collaboration with Ledger and ECC review. It demonstrates that committee support for production-grade shielded hardware integration has been linked to established delivery partners and external technical review. [14]

FROST Shielded Multi-Sig SDK — declined, $22,000. This is the closest recent precedent. It was declined because the committee questioned whether a general wallet API would fit specific applications, lacked evidence of developer adoption, and did not adequately address secure messaging, transaction delivery, share backup, and participant recovery. Those concerns directly overlap with this request’s coordinator, recovery, and adoption risks. [15]

Threshold Shielded Signing Kit — declined, $25,000. This proposed an SDK, relay, and CLI for shielded FROST multisignature. It was declined because feedback indicated that the proposal’s utility beyond existing Foundation tooling was unclear. The present proposal’s differentiator must therefore be demonstrated organizational workflows and interoperability, not merely another FROST integration layer. [16]

6. Material risks and execution considerations

• Single-person execution: One developer would deliver cryptography-adjacent code, recovery flows, hardware integration, coordinator operations, documentation, and user validation. [1]
• Recovery and portability: Existing FROST recovery formats may be implementation-specific, and a standard portable backup format is not established in the supplied discussion. Failure here could create long-lived custody lock-in. [8][9]
• Security model: Secure messaging, authentication, malicious-participant behavior, threshold changes, and durable ceremony records remain material operational-security requirements. [6][8]
• Adoption and duplication: Existing FROST tools and Zkool functionality reduce the case for funding unless a distinct organizational user need and integration path are evidenced. [7][8][15][16]
• Dependency risk: Draft specifications and upstream tooling may change; the applicant’s product could be blocked or require rework if those interfaces are not stable. [6][7]

7. Material gaps and questions for the applicant

1. Which organizations, treasuries, DAOs, or custodians have committed to test or adopt the tool, and what exact workflows do they require?
2. Provide milestone-by-milestone deliverables, dates, payment amounts, acceptance tests, and named validators for the $47,000 request.
3. Define the exact recovery architecture: what material is backed up, how it is encrypted and restored, how portability across implementations is ensured, and what happens when a participant loses or compromises recovery material.
4. Clarify the Ironwood boundary: does the grant include upstream signing support, application-layer integration only, or both?
5. State the coordinator’s threat model, authentication method, metadata/privacy properties, availability assumptions, and fallback process if it is unavailable.
6. Specify Keystone integration status and contingency plans if required shielded PCZT functions change or prove insufficient.
7. Identify planned independent cryptographic and security review, including what code and operational procedures would be reviewed.

8. Neutral decision considerations

Potential value lies in addressing a concrete shielded-custody gap for organizations: avoiding single-key control while adding hardware participation, auditable viewing access, and recovery procedures. The applicant has supplied more technical specificity and a claimed testnet proof than a generic FROST SDK proposal. [4][5][12]

Countervailing considerations are that the project combines protocol-adjacent integration with high-consequence operational security, lacks supplied milestone detail and adopter commitments, relies on unresolved recovery interoperability, and concentrates delivery in one person. [1][8][15]

Inference: Funding conditions, if the committee considers them, could focus on independently verifiable Ironwood signing, a documented and portable recovery design, explicit security/threat-model documentation, defined organizational pilot users, and milestone acceptance tied to end-to-end hardware-backed recovery and signing exercises. This inference follows the documented shortcomings in comparable declined proposals and the proposal’s stated organizational-custody goals. [5][15][16]

9. Numbered source list

• [1] Grant Application - Threshold (FROST) custody for shielded ZEC — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/358
• [12] Zcash Community Grants (ZCG) Meeting Minutes 7/20/2026 — posts 1–5, part 9 — https://forum.zcashcommunity.com/t/zcash-community-grants-zcg-meeting-minutes-7-20-2026/56763/1
• [4] Threshold (FROST) custody for shielded ZEC: design check before a ZCG application — posts 1–5, part 1 — https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660/1
• [15] FROST Shielded Multi-Sig SDK: Easy Threshold Custody for Zcash Wallets — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/351
• [16] Threshold Shielded Signing Kit (TSSK) - FROST-powered multisig for Zcash — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/123
• [5] Threshold (FROST) custody for shielded ZEC: design check before a ZCG application — posts 1–5, part 2 — https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660/1
• [7] Threshold (FROST) custody for shielded ZEC: design check before a ZCG application — posts 1–5, part 4 — https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660/4
• [11] Comment on #358: Grant Application - Threshold (FROST) custody for shielded ZEC — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/358#issuecomment-5017248382
• [6] Threshold (FROST) custody for shielded ZEC: design check before a ZCG application — posts 1–5, part 3 — https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660/2
• [8] Threshold (FROST) custody for shielded ZEC: design check before a ZCG application — posts 1–5, part 5 — https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660/5
• [9] Threshold (FROST) custody for shielded ZEC: design check before a ZCG application — posts 6–10 — https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660/6
• [14] Zcash Shielded support in Ledger Wallet and Ledger devices — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/152