FROST Shielded Multi-Sig SDK: Easy Threshold Custody for Zcash Wallets

1. Executive summary and decision snapshot

Mahmud requests $22,000 to deliver a standalone Rust SDK that makes Zcash Foundation FROST tooling easier for wallet developers to use for threshold-signed shielded custody. The proposed SDK would wrap key generation, signing-session coordination, signature-share submission, and network-resilience behavior around existing FROST-related tools rather than implement cryptography from scratch. The applicant proposes three milestones over three months. [1][4]

The project is to be delivered by Mahmud as sole developer. The strongest stated capability evidence is six-plus years of Rust/C++ systems and protocol work, prior CTO experience, published Rust crates, and contributions to named open-source projects; these are applicant assertions, not independently documented outcomes in the supplied evidence. [1]

The central decision question is whether this is a genuinely useful wallet-integration layer with an adoption path, rather than a duplicate of existing Zcash Foundation FROST tooling. That concern is particularly material because ZCG declined a similar $25,000 FROST shielded-signing proposal in 2025 after feedback that its usefulness beyond existing Foundation toolkits was unclear. [10]

Funding-structure concern: the initial application contained a calculation problem in which startup funding plus milestones did not equal the $22,000 request. The applicant said it would be corrected, but the supplied evidence does not show a corrected milestone budget. This prevents assessment of the proposed payment structure. [5]

Inference: A small, staged grant could be value-positive if the applicant can demonstrate compatibility with the underlying FROST stack and secure input from prospective wallet integrators. Without those conditions, the project risks producing an additional abstraction layer without demonstrated demand.

2. Applicant and team track record

Mahmud is identified as the sole developer and project lead, responsible for design, implementation, testing, and documentation. No additional team members are listed. [1]

The applicant states experience of more than six years in production Rust and C++, focused on distributed systems, protocol engineering, cryptography, and developer tooling. The application also cites former CTO experience at StreamLivr, published crates including circuit_breaker, rate_rs, daemon_rs, and agenticrs, plus contributions to several external projects. [1][4]

This background is relevant to the proposed work because the SDK is intended to be Rust-based and to handle distributed multi-party signing-session reliability. [1][4]

No grounded evidence found of:

• Prior ZCG grants delivered by the applicant;
• Completed production Zcash integrations by the applicant;
• Independent technical review of the applicant’s proposed architecture;
• A committed wallet, custodian, or other adopter.

The absence of this evidence does not establish lack of capability; it limits confidence in ecosystem-specific delivery and adoption.

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

The stated scope is a standalone Rust crate that wraps existing Zcash Foundation FROST components into a higher-level wallet-facing API. Intended functions include threshold-group generation, signing-session initiation, and signature-share submission. The proposal also describes support for trusted-dealer and distributed key generation, rerandomized signing, documentation, a CLI example, and crate publication. [1][4]

The applicant says the SDK would use existing FROST-related components—identified as frost-core, the RedPallas reddsa ciphersuite, frostd, and frost-client—rather than reimplementing signature cryptography. It would add retry, backoff, and circuit-breaking behavior around participant/coordinator interactions. [1][4]

The request is $22,000, described as three milestones over three months. [1][4] However, milestone acceptance criteria, milestone-level amounts, and a corrected allocation reconciling startup funding with milestone payments are not present in the supplied evidence. A reviewer specifically identified that the original funding arithmetic did not sum correctly; the applicant acknowledged the error and stated it would be corrected. [5]

Material dependencies include:

• Continued technical compatibility with the underlying FROST tools and Zcash-specific rerandomization requirements described by the applicant. [1][4]
• Validation that the API shape meets real wallet-integration needs; the applicant explicitly requested feedback from teams familiar with frostd, frost-client, Zashi, and YWallet. [4]
• Security and interoperability review appropriate to a custody-related abstraction layer. No review plan is documented.

4. Community discussion, arguments, responses, and resolution

Strongest argument for: The applicant identifies a plausible usability gap between low-level threshold-signature primitives and wallet-ready integration. The proposal’s limited scope—wrapping existing tools rather than replacing cryptographic implementations—could reduce duplication and make shielded threshold custody more accessible to wallet developers. [1][4]

Strongest argument against: The project may substantially overlap with existing Foundation toolkits or may lack a clear integration/adoption path. This is not merely theoretical: ZCG previously rejected a closely related FROST SDK and relay proposal because feedback from the Foundation and community did not establish that it added useful functionality beyond existing toolkits. [10]

Applicant clarification: The applicant states that an earlier idea to build FROST from scratch was abandoned specifically to avoid duplicating existing audited work, and that the revised project targets an integration-layer gap. [4]

Funding clarification: In response to a request to reconcile startup and milestone payments, the applicant said the calculation would be corrected and that they had treated startup funding as milestone one. [5]

Resolved: The applicant posted the request to the community forum, satisfying the identified discussion-posting requirement. [4][5]

Unresolved disagreement: No supplied discussion evidence shows technical confirmation from Zcash Foundation maintainers, wallet teams, or potential adopters that the proposed SDK is differentiated, needed, or suitably designed. Nor does it show the corrected budget. These are the principal unresolved matters.

5. Relevant precedents and documented outcomes

Threshold Shielded Signing Kit (TSSK), $25,000, declined. This is the closest precedent: it proposed a FROST-based Rust SDK, signer coordination infrastructure, and a CLI for shielded multisignature custody. ZCG declined it after Foundation and community feedback that it was unclear whether the work provided value beyond existing FROST toolkits. This directly supports requiring a clear differentiation and adopter-validated scope here. [10]

Keystone shielded-wallet integration, $60,000 recorded request / $180,900 described in committee rationale, approved. The record contains an amount inconsistency, so it is not reliable as a price comparison. Its decision rationale is nonetheless relevant: approval reflected technical engagement with ECC, a defined integration path, and a condition requiring Least Authority review of the SDK and resolution of concerns before final payout. This illustrates the value of external technical validation and a security-review gate for wallet-facing signing work. [9]

Ledger shielded support, $300,000, approved. ZCG approved a defined production wallet-and-device integration after review involving ECC personnel. The documented rationale emphasized concrete functionality, testing, compatibility, and an identified delivery team. It supports the proposition that shielded-wallet work is fundable when the deployment target and technical validation are clear; the supplied evidence does not document later delivery outcomes. [8]

6. Material risks and execution considerations

• Duplication/value risk: Existing FROST resources may already address enough of the proposed need. The closest declined precedent makes independent technical differentiation essential. [10]
• Adoption risk: The project is deliberately wallet-agnostic, but no wallet team is documented as intending to integrate it. A generic SDK may not match actual wallet architecture or operational requirements. [4]
• Custody/security risk: A high-level wrapper can introduce unsafe defaults, state-management flaws, or interoperability problems even when underlying cryptography is reused. No independent review, threat model, test plan, or release-security process is evidenced. [1][4]
• Single-person delivery risk: The sole-developer structure concentrates implementation, maintenance, documentation, and security-response responsibilities in one person. [1]
• Budget-control risk: The unreconciled milestone arithmetic means ZCG cannot yet tie payment to verified deliverables. [5]

7. Material gaps and questions for the applicant

1. Provide the corrected three-milestone budget: payment amount, deliverable, acceptance test, and total equaling $22,000.
2. Specify exactly what functionality is absent from, or materially harder to use in, existing Foundation FROST tools—and map each proposed API feature to that gap.
3. Identify at least one prospective wallet or custodian reviewer and provide their feedback on API requirements, integration feasibility, and intended use.
4. Define the security model: key-material handling, coordinator trust assumptions, participant authentication, session recovery, replay protection, and failure behavior.
5. Commit to concrete interoperability tests against the intended FROST components and representative threshold configurations.
6. State whether an independent security or architecture review will occur before release, and whether final payment can be conditioned on resolving findings.
7. Clarify post-grant maintenance ownership, version compatibility commitments, and response expectations for security issues.

8. Neutral decision considerations

Committee members may weigh the following:

• The request is modest relative to production wallet integrations and is framed as reuse of existing tools, not new cryptography. [1][4]
• The applicant presents relevant claimed Rust and distributed-systems experience, but supplied evidence does not independently verify prior Zcash delivery or adoption. [1]
• The proposal targets a potentially useful developer-experience layer, yet its core value proposition remains unvalidated by named users or maintainers. [4][10]
• The closest precedent was declined for substantially the same differentiation concern. [10]
• Before any funding structure is assessed, the payment schedule needs correction and milestone acceptance needs to be made objectively testable. [5]
• Inference: If considered further, a decision structure emphasizing an early architecture/adopter-validation milestone and a final security/interoperability gate would address the most material uncertainties without presuming project success.

9. Numbered source list

• [1] Grant Application - FROST Shielded Multi-Sig SDK: Easy Threshold Custody for Zcash Wallets — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/351
• [4] FROST Shielded Multi-Sig SDK: Easy Threshold Custody for Zcash Wallets — Grant Application — posts 1–5 — https://forum.zcashcommunity.com/t/frost-shielded-multi-sig-sdk-easy-threshold-custody-for-zcash-wallets-grant-application/56608/1
• [10] Threshold Shielded Signing Kit (TSSK) - FROST-powered multisig for Zcash — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/123
• [5] Comment on #351: Grant Application - FROST Shielded Multi-Sig SDK: Easy Threshold Custody for Zcash Wallets — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/351#issuecomment-4946220676
• [9] Zcash (Both Transparent & Shielded Address) Support for Keystone Hardware Wallet — comparison summary — https://forum.zcashcommunity.com/t/zcash-community-grants-meeting-minutes-8-19-2024/48651
• [8] Zcash Shielded support in Ledger Wallet and Ledger devices — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/152