Threshold Shielded Signing Kit (TSSK) - FROST-powered multisig for Zcash

[Creativesonchain]

Organization Name

Creatives Onchain

How did you learn about Zcash Community Grants

Grant website

Requested Grant Amount (USD)

$25,000

Category

Infrastructure

Project Lead

Name: Akeem Adelanke Role: Project Manager & Developer Onboarding Specialist Background: Experience in developer onboarding, crypto programs, and community ops with NEAR, Creatives DAO, Mintbase, and Arbitrum. Responsibilities: Delivery planning, stakeholder coordination, pilot integrator support, documentation quality, community updates. Social Links: https://x.com/cr8tivesonchain

Additional Team Members

Name: Timilehin Olowu

Role: Full-Stack Developer & Tooling Engineer Background: 4+ years building secure, scalable apps across fintech, AI, and blockchain; author of Methane CLI and Esher developer tools.

Responsibilities: SDK architecture, API design, language binding, developer documentation.

Social Links: LinkedIn: https://www.linkedin.com/in/timilehin-olowu-9a7832271/

Name: Michael Afolabi
Role: Infrastructure & Automation Engineer Background: Focus on AI-assisted infrastructure and secure distributed backends; built Vault (DeFi yield optimizer) and Eclipse (interface for Dimension.xyz).

Responsibilities: frostd packaging, Helm/containerization, CI/CD, observability, staging relay operations.

Social Links: LinkedIn: https://www.linkedin.com/in/ifeoluwa-afolabi-2a8932162 GitHub: Afoxcute · GitHub

Name: Victory Osato

Role: Blockchain Developer Background: Trained 100+ developers and supported multiple dApp launches; deep familiarity with Arbitrum tooling.

Responsibilities: Vault-CLI implementation, end-to-end tests, negative-case scenarios (signer drop/retry), QA support.

Social Links: GitHub: OsatoVicTory (Tory) · GitHub

Project Summary

Threshold Shielded Signing Kit (TSSK) enables threshold spend authorization (t-of-n) for Zcash shielded addresses by packaging a developer SDK based on FROST, a packaged frostd relay, and a reference CLI. It lets wallets and custodians add N-of-M control to Unified Addresses while consuming ZF’s FROST crates and frostd, aligned with Zebra + lightwalletd, and with no zcashd dependencies.

Project Description

Threshold Shielded Signing Kit (TSSK) is a developer toolkit that enables threshold spend authorization (t-of-n) for Zcash shielded addresses using FROST. Today, teams that need multi-party approval often fall back to transparent addresses or single-key shielded wallets. TSSK addresses that gap by providing a small integration layer so wallets and custody systems can add FROST-based co-signing without re-implementing complex flows, consuming ZF’s FROST crates and frostd rather than replacing them

What we will do:

• Upstream alignment: use the ZF FROST crates and the frostd relay from ZcashFoundation/frost-tools; where ops/usability improvements are welcome, propose PRs upstream rather than fork

• SDK (Rust + one minimal binding): High-level APIs for distributed key generation/reshare, threshold signing rounds, and shielded transaction assembly compatible with Unified Addresses (Sapling/Orchard). The SDK wraps established Zcash crates and exposes a clear, documented interface.

• Ops-hardened relay (frostd package): Production artifacts for the signer coordination relay: authentication/TLS, persistence, metrics/logging, Docker images, a Helm chart, and an operator runbook. The relay forwards end-to-end-encrypted signer messages and does not handle spend keys.

• Reference CLI (“Vault-CLI”): An auditable tool that demonstrates the end-to-end flow—set up N-of-M keys, derive a Unified Address and viewing key, propose a spend, coordinate signatures via the relay, broadcast, and confirm. It also serves as the project’s test harness.

Stack and compatibility:

Designed to run with Zebra as the node and lightwalletd as the light-client backend (Zaino as it matures), following the documented Zebra path; uses librustzcash / zcash_client_backend for address and transaction handling; no reliance on the legacy zcashd wallet.

Primary users:

• Wallet teams: add threshold-authorized shielded sends using a focused SDK and example code.

• Custody providers / PSPs / treasuries: use the CLI for controlled outflows and integrate the SDK when ready.

• Organizations and communities: hold ZEC in shielded pools with multi-party control.

Goals and measurable outcomes

• Ship a thin SDK, an ops-ready relay package, and a working CLI with clear documentation.

• Provide deterministic test vectors and negative-case tests (e.g., signer drop/retry).

• Publish a recorded end-to-end demo and collect external confirmations of successful runs via issue templates.

• Support at least one public pilot branch (wallet or custody) within the first 90 days after release.

Scope boundaries

Out of scope: new wallet UI, new indexer, consensus changes, or any dependence on zcashd.

• The design leaves room for future extensions (e.g., additional language bindings or policy modules) without affecting the initial interfaces.

Proposed Problem

1. Limited wallet support and no reusable toolkit: While FROST exists and some projects have integrated it, the ecosystem lacks a Zebra-aligned SDK plus ops package that other wallets and services can adopt quickly, slowing broader support for threshold authorization in shielded flows.

2. Policy mismatch for institutions: Custodians/exchanges/treasuries require dual control and audit trails; without shielded multisig they’re forced into transparent flows or single-key shielded wallets.

3. Single-key = single point of failure: A lost or compromised shielded spend key means total loss; there’s no quorum-based recovery/rotation pattern in shielded workflows.

4. Stack transition gap: The ecosystem is moving to Zebra + lightwalletd (with Zaino maturing), but there’s no drop-in, Zebra-aligned shielded multisig toolkit to adopt.

5. High integration risk: Implementing FROST, DKG, and signer coordination from scratch is specialized, error-prone work; most teams won’t ship it or will ship brittle code.

6. Service on-ramps stall: Many services keep ZEC in transparent flows because they can’t enforce multi-party controls while staying shielded; blocking shielded deposits/holdings policies.

7. No ops playbook: There’s no hardened signer-relay package (auth/TLS, persistence, metrics) or clear runbook for safe threshold signing in production, so pilots don’t progress.

Proposed Solution

The Threshold Shielded Signing Kit is a compact integration kit that adds threshold spend authorization (t-of-n with FROST) to Zcash shielded addresses. It provides a Rust SDK with one minimal binding that handles distributed key generation and resharing, FROST signing for Sapling and Orchard, Unified Address derivation, and shielded transaction assembly; using the Zcash wallet libraries and the FROST crates provided by ZF. There is no dependency on the legacy

To make operations straightforward, the kit packages the signer coordination relay frostd with authentication, TLS, persistence, basic metrics, container images, Helm charts, and an operator guide. The relay forwards encrypted signer messages and never handles spend keys. A reference command line tool called Vault CLI demonstrates the full workflow from forming an N of M group and deriving a Unified Address and viewing key through proposing and co signing a spend, coordinating signatures through the relay, broadcasting, and confirming, and it also serves as a test harness. Together these pieces let wallet and custody teams adopt shielded multisignature with minimal custom work.

Solution Format

It is an open-source software deliverable with code, binaries, and ready-to-deploy ops artifacts. Everything will be versioned and published with reproducible builds.

Deliverables

• SDK crate in Rust plus one minimal language binding (Python or Node/WASM).

• Packaged signer relay based on frostd, including container image, Helm chart, configuration examples, and an operator runbook.

• Vault CLI reference tool that exercises the full threshold signing flow and serves as an end-to-end test harness.

• Documentation set: developer guide, API reference, quick starts, threat model, and deployment guide.

• Test assets: deterministic test vectors, negative case scenarios, CI setup, and a recorded end-to-end demo.

• Release packaging: tagged releases, checksums, and a short maintenance window for fixes discovered during pilot integrations.

Dependencies

Technical

• Zebra full node and a reachable light-client backend such as lightwalletd; Zaino may be used where available but is optional.

• Zcash libraries: librustzcash, zcash_client_backend, ZF FROST crates, and the frostd reference relay (all pinned to known-good versions).

• Rust toolchain/Cargo; OCI-compatible container runtime.

• TLS certificates for the relay; basic metrics/logging.

• Testnet access and small amounts of test ZEC.

• No reliance on the deprecated zcashd wallet or its RPCs.

Resources

• CI runner for automated tests and reproducible builds.

• Small VM or Kubernetes namespace to host a staging relay.

• Code-signing keys for release artifacts.

Collaborations

• As-needed coordination with Zcash Foundation engineers for FROST versioning guidance.

• Compatibility check-ins with Zebra/lightwalletd maintainers via public channels (no special support required).

• One pilot integrator (wallet, custody provider, or PSP) preferred for validation but not required for v1 delivery.

• Independent light security review focused on SDK usage and relay hardening.

Technical Approach

We will deliver a thin SDK, a packaged signer-relay, and a reference CLI built on maintained Zcash components. The SDK uses librustzcash and zcash_client_backend for Unified Address (ZIP-316) handling and shielded transaction construction, and consumes ZF’s FROST crates for threshold key generation, re-share, and signing. It targets Zebra for node connectivity with lightwalletd as the light-client backend; an optional adapter will support Zaino as it becomes available. No zcashd wallet dependencies are used.

1. SDK architecture: Modules for UA derivation, distributed key generation and re-share, FROST signing for Sapling (RedJubjub) and Orchard (RedPallas), and transaction assembly. A small, documented public API is exposed, plus one minimal language binding for quick adoption.

2. Key generation and signing flow: Default to distributed key generation, with a trusted-dealer mode for test setups. Each partial signature is verified before aggregation. The coordinator relays the rounds, and the SDK returns a single spend-authorization signature suitable for inclusion in a standard shielded transaction.

3. Signer relay operations: Package the reference frostd with authentication and TLS, restart-safe persistence, basic metrics, container images, a Helm chart, and an operator runbook. Messages remain end-to-end encrypted, and the relay never handles spend keys.

4. Security practices: Pin crate versions; rely on upstream constant-time primitives; zeroize sensitive memory where applicable; minimize logs and identifiers; document Tor as an option to reduce metadata exposure.

5. Testing and CI: Deterministic test vectors; end-to-end testnet runs for 2-of-3 and 3-of-5 on Sapling and Orchard; negative cases (signer drop and retry); reproducible builds and cross-platform CI.

6. Packaging and docs: Tagged releases with checksums; SDK and CLI guides, quick starts, a concise threat model, and a recorded end-to-end demo to support pilots.

Upstream Merge Opportunities

Repositories

• FROST tooling (Zcash Foundation): frostd relay and example CLI.

• Docs/examples only (no code changes planned): librustzcash, zcash_client_backend, zebra, lightwalletd.

Planned changes

• frostd (ops-focused, optional): propose additions for authentication, TLS, restart-safe persistence, basic metrics endpoints, container image, Helm chart, and sample configs. Features will be optional or disabled by default to avoid changing current behavior.

• Documentation/examples: propose small PRs adding multisig usage notes and deployment examples that link Zebra + lightwalletd + a signer relay. No protocol or wallet logic changes.

Ecosystem benefit if merged

• Lower-friction deployment of a signer relay and clearer examples for integrators.

• Reusable ops artifacts that reduce one-off packaging across projects.

Coordination

• Open issues and design notes with FROST maintainers before PRs; follow normal review processes.

• Submit docs/example PRs to the relevant repos and iterate on maintainer feedback.

Timeline considerations

• File issues early in the project, submit PRs once features are stable, and adjust based on maintainer review cycles. If changes are not accepted upstream, we will keep the ops packaging and guides in our repository without blocking v1 delivery.

Hardware/Software Costs (USD)

$0

Hardware/Software Justification

n/a

Service Costs (USD)

$4,000

Service Costs Justification

• $3,000 for an independent light security review focused on SDK usage and relay hardening.

• $1,000 for time-boxed cloud resources: CI minutes, an ephemeral staging relay VM, artifact storage, and hosting the recorded demo.

Compensation Costs (USD)

$21,000

Compensation Costs Justification

Covers engineering, DevOps, and documentation for the SDK, packaged relay, and reference CLI.

• Rust engineer: ~160 hours at $75/hour = $12,000 (SDK core, Vault-CLI, tests).

• DevOps engineer: ~100 hours at $70/hour = $7,000 (relay packaging, TLS/auth, Helm, CI).

• Technical writer/PM: ~20 hours at $100/hour = $2,000 (developer guide, operator runbook, coordination).

Total Budget (USD)

$25,000

Previous Funding

No

Previous Funding Details

No response

Other Funding Sources

No

Other Funding Sources Details

No response

Implementation Risks

1. ZIP-312 draft status
   The FROST spend-auth spec is still Draft, so interfaces may shift. Mitigation: keep signing/key-gen modules modular, track ZIP updates, version public APIs, and document any changes.

2. Key-generation interoperability
   Projects may differ on FROST DKG/reshare conventions. Mitigation: follow ZF/ECC guidance, version key-gen artifacts, supply migration notes and tests.

3. Relay security and operations
   Misconfiguration could weaken auth/TLS or persistence. Mitigation: ship secure defaults, minimal logs, health checks/metrics, restart-safe storage, and a short operator checklist.

4. Participant availability / coordination
   Rounds can stall if a signer drops or messages lag. Mitigation: retries, timeouts, round recovery, documented re-share, and clear escalation steps.

5. SDK correctness / misuse
   Incorrect API use could yield invalid transactions or weak flows. Mitigation: deterministic vectors, negative tests, typed APIs with safe defaults, and a light external review focused on usage.

6. Dependency drift (Zebra, lightwalletd, Zaino)
   Upstream changes can affect builds/behavior. Mitigation: pin versions, test against a known matrix, keep Zaino optional/behind a feature flag, and publish upgrade notes.

7. Performance & UX
   Threshold signing adds latency versus single-signer. Mitigation: measure end-to-end timing, document expected round-trip budgets, and provide guidance on batching and signer locality.

8. Key-share lifecycle risk:
   Loss/exposure of shares remains possible. Mitigation: documented backup/rotation/reshare patterns, zeroize sensitive memory where applicable, and recommend hardware separation.

9. Deprecated stack contamination:
   Teams might copy legacy zcashd wallet/RPC examples. Mitigation: explicitly forbid zcashd wallet/RPC usage in docs, add CI/static checks in examples, and reference Zebra + lightwalletd paths only.

Potential Side Effects

1. Coordination metadata or logging leaks:
   Even with end-to-end encryption, relay timing patterns or verbose logs can reveal sensitive context if operators don’t use TLS, minimal logs, or privacy tooling.

2. Relay availability dependence:
   If the chosen relay is down or misconfigured, threshold signing pauses and time-sensitive spends may be delayed.

3. Quorum and key-share mismanagement:
   Setting thresholds too low weakens control; too high increases liveness risk. Poor backup, rotation, or re-share can lock funds.

4. Compliance and audit gaps:
   Without clear signer-event records and approvals, internal audits and investigations are harder.

5. Added latency and resource use:
   Multi-party rounds are slower than single-signer flows and the relay consumes CPU, storage, and bandwidth under load.

6. False sense of security:
   Multisig reduces single-key risk but does not prevent collusion or social-engineering of signers.

Success Metrics

1. Adoption
   At least one public pilot branch (wallet, custody, or PSP) using the SDK, and at least ten external end-to-end confirmations submitted via the project’s issue template within 90 days of v1.

2. Reliability and correctness
   CI matrix covers Linux and macOS, Sapling and Orchard, 2-of-3 and 3-of-5. Thirty consecutive nightly runs with a 100% pass rate, including a reorg simulation test.

3. Security
   Independent light review completed. Zero high-severity findings remaining after remediation. All medium findings either fixed or documented with mitigations.

4. Operations
   Staging relay shows at least 99% availability over any continuous 14-day window. Restart recovers state and resumes rounds in under 60 seconds. A basic metrics dashboard is included.

5. Performance
   In a single-region test, median end-to-end threshold signing time for a 3-of-5 group is three seconds or less, and the 95th percentile is eight seconds or less. Under five concurrent sessions, relay baseline memory is 150 MB or less and CPU usage is at or below one vCPU.

6. Developer experience
   A new user following the quick start can complete a testnet threshold send in 30 minutes or less. All public APIs are documented with runnable examples.

7. Reproducibility and release quality
   Tagged releases with checksums are published, a recorded end-to-end demo is available, and reproducible builds run in CI with artifacts attached to releases.

Startup Funding (USD)

n/a

Startup Funding Justification

n/a

Milestone Details

Milestone 1

Amount (USD): $0
Expected Completion Date: 2025-11-20

User Stories

• As a wallet developer, I want a clear SDK/API and data flow so that I can plan integration.
• As a DevOps lead, I want an operations plan for the signer relay so that I can deploy it in staging.
• As a security reviewer, I want a concise threat model so that I can assess risk.

Deliverables

• SDK/API spec for ZIP-316 Unified Address handling, key generation/reshare, threshold signing, and shielded transaction assembly (with request/response schemas).
• Threat model covering trust boundaries, relay metadata, auth/TLS, and key handling.
• Operations checklist and example relay configs (auth/TLS, persistence, metrics).
• Compatibility matrix with pinned versions for Zebra, lightwalletd, FROST crates, and librustzcash/zcash_client_backend.
• README linking all docs; CI skeleton for SDK and relay image.

Acceptance Criteria

• Two reviewers (wallet and ops) complete checklists with no blocking items.
• CI builds the SDK skeleton and the relay container; version pins and docs are linked from the README.

Milestone 2

Amount (USD): $9,000
Expected Completion Date: 2025-12-18

User Stories

• As a wallet developer, I want a working SDK to create keys and sign threshold shielded transactions on testnet so that I can validate feasibility.
• As a QA engineer, I want deterministic vectors and negative tests so that I can verify correctness.

Deliverables

• SDK crate implementing ZIP-316 UA derivation, DKG/reshare, FROST signing for Sapling (RedJubjub) and Orchard (RedPallas), and shielded transaction assembly.
• One minimal language binding (Python or Node/WASM) with runnable examples.
• Unit tests, deterministic vectors, developer docs, and a quick start.

Acceptance Criteria

• A 2-of-3 testnet spend completes using the example.
• Tests and vectors pass on Linux and macOS in CI; public API docs are generated.

Milestone 3

Amount (USD): $7,000
Expected Completion Date: 2026-01-08

User Stories

• As a DevOps lead, I want a packaged signer relay so that I can deploy it with TLS, auth, persistence, and metrics.
• As a signer, I want sessions to survive restarts so that coordination can resume.

Deliverables

• Packaged frostd relay with authentication, TLS, restart-safe persistence, metrics endpoints, container image, Helm chart, and sample configs.
• Operator runbook and minimal logging guidance.

Acceptance Criteria

• Relay deploys via Helm with TLS and auth; metrics are visible.
• Restart resumes rounds; CI builds the container image and runs a basic security scan.

Milestone 4

Amount (USD): $5,000
Expected Completion Date: 2026-01-22

User Stories

• As an integrator, I want a reference CLI so that I can complete an end-to-end threshold send without writing code.
• As a QA engineer, I want failure scenarios so that I can verify signer drop and retry.

Deliverables

• Vault-CLI demonstrating: create N-of-M, derive a UA and viewing key, propose spend, coordinate signatures via the relay, broadcast, and confirm.
• Negative-case tests (signer drop, retry, idempotent handling), a recorded demo, and a quick-start guide.

Acceptance Criteria

• Following the quick start, a new user completes a 2-of-3 testnet spend.
• Negative tests pass in CI; recorded demo and quick start are published.

Milestone 5

Amount (USD): $4,000
Expected Completion Date: 2026-02-05

User Stories

• As a reviewer, I want an external light security review addressed so that I can trust the release.
• As a pilot team, I want tagged releases with checksums and docs so that I can adopt them in staging.

Deliverables

• Independent light security review focused on SDK usage and relay hardening, plus remediation PRs.
• Tagged v1 releases of the SDK, relay package, and CLI with checksums; final developer and operator docs; upgrade notes.

Acceptance Criteria

• No high-severity findings remain; medium findings are fixed or documented with mitigations.
• v1 artifacts and checksums are published and linked from the README.

[kworks]

Hi CreativeonChain,

Thanks for taking the time to submit your ideas into an application.

One of the challenges facing a long list of past community members who received funding for great software solutions is getting the attention of developers to use the software solution developed.

Nowhere in your application submitted have you provided the time or resources needed to develop an action plan to get wallet developers, wallet service providers or even general users to adopt your proposed solution.

How can you have confidence that your solution is just going to be adopted?

Where is the action plan for the development of resource guides, documentation, tutorials, workshops?

How about showing that you have identified users, surveyed service providers for the need for your solution?

Thanks in advance

[conradoplg]

It’s not clear what this provides that isn’t already in GitHub - ZcashFoundation/frost-tools: Rust tools for using FROST: frostd, a server to help participants communicate; and frost-client, a CLI tools that runs FROST using frostd

[Creativesonchain]

Hi @kworks , thank you so much for the thoughtful questions. Here are answers to them:

1) Why we believe this will be adopted (demand signals)

• Funder priority: The Zcash Community Grants wishlist explicitly calls for “easy multi-sig tools for Shielded Addresses (e.g., an implementation of FROST in user-facing wallets).” That’s a direct, first-party demand signal for this exact capability.

• Core maintainer guidance: The Zcash Foundation states it has completed the FROST reference implementation and that “the next step is for wallets to integrate FROST,” offering guidance and even a production frostd if needed. Our project executes that next step (SDK + ops packaging + E2E) rather than duplicating the demo. Zcash Foundation

• Stack alignment: The ecosystem is deprecating zcashd and migrating to Zebra, so we’ll target Zebra + lightwalletd.; the documented, supported path today.

2) Identified Users:

• Wallet teams: Zashi (ECC), Nighthawk, YWallet (or its successor “Zkool”). These teams build and maintain shielded wallets and rely on lightwalletd.
• Service providers / custody & PSPs: Teams that already run or consume lightwalletd and Zebra can adopt a packaged signer-relay plus SDK to offer shielded multisig workflows.

3) What we will ship for enablement (time & resources included)

Within the same 10–12 week project window, we reserve dedicated hours for developer enablement and ops onboarding. Concretely:

• Quick-start (≤30 min) & template repo: copy-paste steps to create a group, derive a ZIP-316 UA, and complete a 2-of-3 testnet spend; minimal repo template wired to Zebra + lightwalletd.
• Playbook (8–10 task recipes): rotate a signer, recover after a signer drop, switch pools, re-share keys, etc.
• Operator runbook for frostd: auth/TLS, restart-safe persistence, basic metrics, container image, Helm chart, and health checks. (The ZF repo positions its tools as demos; we will package them for deployment.
• Workshops & office hours: two 60-minute live sessions (recorded) and weekly office hours during the pilot window, so integrators get unblocked quickly.
• Compatibility matrix: pinned versions for Zebra, lightwalletd, FROST crates, and wallet libraries, updated with each release.

4) Outreach & pilots (survey + guided adoption)

• Week 1–2 survey: ten-question needs survey sent to wallet teams and service operators; we’ll publish aggregated results and use them to prioritize cookbook items.
• Two guided pilots (Weeks 7–11): one wallet and one custody/PSP complete a 2-of-3 testnet flow using our quick-start; we upstream issues/fixes before v1.
• Community channels: forum post (launch + demo + quick-start), Q&A thread, and consistent responses during the pilot period.

5) How we will measure success:

• Adoption: ≥1 public pilot branch (wallet or custody) and ≥10 external end-to-end confirmations via our issue template.
• Reliability: CI matrix on Linux/macOS; 2-of-3 and 3-of-5 for Sapling and Orchard; 30 consecutive nightly passes including a reorg test.
• Operations: staging relay ≥99% availability over any 14-day window; restart resumes rounds in <60 seconds; dashboard included.
• Developer experience: a new user completes the quick-start testnet send in ≤30 minutes.

6) Why we can execute (our distribution & onboarding track record)

• Arbitrum Stylus: We delivered outcomes, not just events. In the Arbitrum Creative Hub program we ran:
• 46 hackathon project submissions; 12 deployed on Stylus
• 400+ participation certificates issued
• 8 weeks of hands-on training
  These results are documented in the final report on the Arbitrum forum. Arbitrum
  We also ran pre-event training (bootcamps) to seed the funnel into the hackathon. Luma
• Hedera Africa Hackathon - network to reach builders at scale.
  Creative Onchain is listed as a partner on the official site of the $1M+ Hedera Africa Hackathon (a continent-wide program with training and certification). We’ll leverage that partner channel to route cohorts into our Zcash workshops and share our quick-start/ops guides. link.

Adoption is planned, resourced, and measurable: enablement assets, two guided pilots, public workshops and office hours, and clear post-v1 metrics. We are aligning with the current node/light-client stack and following the maintainers’ stated “next step” of wallet integration; turning FROST from demos into deployable tooling.

We hope the above comments clarifies your concerns. Kindly let us know if you have any more questions. We look forward to hearing from you again.

Thank you.

[Creativesonchain]

Hi @conradoplg , thank you so much for your comment. ZcashFoundation/frost-tools is a valuable reference that demonstrates how FROST works: it includes a communication relay (frostd) and a sample CLI that exercise threshold signing. What teams still lack is a deployable, wallet-facing integration kit that connects those primitives to Zcash’s wallet libraries and the current node/light-client stack (Zebra with lightwalletd), with operational packaging and acceptance tests. That is precisely what this proposal (TSSK) aims to deliver.

What exists vs. what we would add:

Area	ZF frost-tools provides	This project (TSSK) would add
Purpose	Reference demos that show FROST rounds and relay communication.	A production-oriented integration kit intended for adoption by wallets and custody backends.
Wallet integration	Example CLI to drive the protocol; not focused on assembling full shielded transactions via wallet crates.	A wallet-facing SDK that uses librustzcash and zcash_client_backend to build Unified Address (ZIP-316) Sapling/Orchard transactions and coordinate FROST signing (with one minimal language binding).
Stack alignment	Protocol demonstrations without a specific deployment path.	A Zebra + lightwalletd quick start and compatibility matrix, with Zaino optional where available, so implementers follow a supported stack today.
Operations	Source code for the relay and examples; no deployment bundle.	An ops-packaged relay (authentication, TLS, restart-safe persistence, metrics, container image, Helm chart) plus an operator runbook.
End-to-end workflow	Sample commands to exercise the demo.	A reference CLI (Vault-CLI) that completes an end-to-end shielded N-of-M send, including negative tests such as signer drop and retry; doubles as a test harness.
Upstream posture	Maintained reference components.	Consume, do not fork: rely on the FROST crates and frostd; propose ops improvements upstream where welcome; keep any remaining packaging downstream without changing protocol logic.

Why this is not duplication

• We are not re-implementing FROST or replacing frostd. We are connecting those components to the Zcash wallet libraries, aligning them with the current node/light-client stack, and packaging the relay so teams can deploy safely.
• The deliverables are narrowly scoped to what downstream implementers need to adopt FROST in practice: an SDK, an ops bundle, and an end-to-end reference flow with acceptance tests.

In short, frost-tools shows how FROST works; this project makes it usable in products. We hope this makes sense and also clarifies your concerns. Please kindly let us know if you have more question.

Thank you once again for your comment.

[gcsfred1]

Why are you using TSS and multisig together? FROST as a TSS makes shares s_i of one secret key s. It seems that you are using FROST incorrectly if you want to have multisig.

[hanh]

zkool supports Frost without a central server

ZecHub

[Creativesonchain]

Hi @gcsfred1, Thank you for the great question. We’re not mixing two different schemes; we’re using a threshold signature scheme (TSS) to implement the user-visible requirement people call “multisig.” In FROST, any ttt of nnn participants holding shares of a single secret key jointly produce one Schnorr-style signature that verifies under one public key which is the standard definition of a threshold multisignature. That protocol is formally specified by the IETF as RFC 9591

For Zcash, this is exactly what the spec calls for. ZIP-312 adapts FROST so the threshold signature is compatible with Zcash spend-authorization (the Schnorr-style signatures used in Sapling and Orchard), i.e., it verifies with the existing spend-auth verifier and does not reveal which subset signed. In Zcash terminology, Sapling uses RedJubjub and Orchard uses RedPallas; ZIP-312 pins a variant that produces signatures compatible with those schemes. In short, the crypto primitive is TSS (FROST) and the product behavior is N-of-M “multisig,” exactly as the Zcash spec intends. Using FROST TSS to realize application-level multisig in Zcash is correct and standards-aligned (RFC 9591) and matches the Zcash design in ZIP-312

Please let us know if this is clear to you.
Thank you once again for the question.

[Creativesonchain]

Hi @hanh, thank you so much for your comment.

Why our proposal is not a duplicate and how it complements Zkool:

• Different product layer: Zkool is an end-user wallet. Our project is a developer integration kit (SDK + reference CLI + ops guidance) so other wallets and service providers can add FROST without reverse-engineering a specific app. We wire FROST into the Zcash wallet libraries (ZIP-316 Unified Addresses; Sapling/Orchard) and document how to run against the current stack (Zebra + lightwalletd)

Deployment options, not prescriptions: Zkool demonstrates server-less coordination is possible; we keep transport pluggable (packaged relay for ops teams, or direct/P2P if preferred), so implementers can choose the model that fits their environment. The goal is to broaden adoption beyond one wallet, not replace it.

We can say Zkool proves FROST works for users; our project makes FROST easy for the rest of the ecosystem to adopt by providing a reusable SDK and operational guidance aligned with the supported node/light-client path today.

Thank you once again for your comment. We hope the above response clarifies. Let us know if you have any more concerns. Thank you.

[hanh]

If you mean you are in between Zkool and the ZF/Frost libs, I don’t really see much happening there. It feels that you have used AI to generate this proposal at places because though it “kinda” makes sense in general, when we try to understand the specifics, it’s so confusing.

[Creativesonchain]

Hi @hanh, Please can you further elaborate on the part of the proposal that is confusing to you? Perhaps we can jump on a quick call this week to shed more light so we can both be on the same page.
Thank you.

[gcsfred1]

Multisig implies multiple signatures. And we also use m-of-n like in TSS. But differently from TSS, multisig implies multiple keys. TSS uses secret sharing for one key. Yes, with t < n, but with one key. That assumption is throughout the paper. I suggest for you not to use the expression multisig, even though the technical part seems to have the right motivation.

[conradoplg]

Sorry, but frost-tools is not just a “reference” (it used to be), it’s actually a tool that people can use. (Which, granted, might need some usability improvements, but if that was the goal, the details should be fleshed out)

This proposal unfortunately reeks of AI-generated content.

[Creativesonchain]

Hi @conradoplg Thanks for your message again. This is not AI-generated, it’s us and the work is in progress. To prove to you, we have already shipped code and a short demo you can review now.

We have published a public repo with the SDK/CLI/Helm skeleton and a short quick start: https://github.com/Dynamittr/Threshold-Shielded-Signing-Kit. The repo includes ACCEPTANCE.md (2-of-3 and 3-of-5 testnet flows, signer drop/retry, relay restart-resume) and COMPATIBILITY.md pinning versions for Zebra, lightwalletd, wallet libraries, and FROST. We have also added a charts/frostd/ Helm chart with TLS/auth, persistence, and basic metrics. A brief terminal recording is here: https://asciinema.org/a/Rq83Ri6uMRHoxK0CtAKv1eF02.

You’re also right that frost-tools is usable today. We are not trying to replace it. We consume the FROST crates and frostd. What we’re adding is (1) a small wallet-library SDK that uses zcash_client_backend / librustzcash to build ZIP-316 Unified-Address Sapling/Orchard transactions and drive FROST rounds, (2) practical ops packaging for teams that prefer a relay (TLS/auth, restart-safe persistence, metrics, container/Helm, and a short runbook), and (3) a minimal reference CLI that exercises an end-to-end flow. Our examples target the documented Zebra + lightwalletd path.

We also adjusted the proposal for clarity: we use the term “threshold spend authorization (t-of-n) with FROST,” we state our upstream stance explicitly (use frost-tools; open focused usability/ops PRs rather than fork), and we’ve listed acceptance checks so the scope is verifiable at a glance.

If it’s more helpful to focus directly on usability improvements in frost-tools, we’re happy to scope that and start with small, concrete items (for example, TLS/auth deployment notes, a minimal Helm chart, and clearer error messages). If you can point us to specific pain points you’ve hit, we will definitely prioritize those next.

Thank you once again.

[Creativesonchain]

Hi @hanh, you can verify that this proposal is not AI generated by the repo history and demo we have pushed:

• Repo (SDK/CLI/Helm skeleton + quick start, acceptance & compatibility files): https://github.com/Dynamittr/Threshold-Shielded-Signing-Kit
• 90-sec terminal demo: untitled - asciinema.org

We also revamped the proposal for clarity: we now use “threshold spend authorization (t-of-n) with FROST,” state clearly that we consume ZF’s frost-tools (not replace it), and spell out our additions: a small wallet-library SDK (using zcash_client_backend/librustzcash), a minimal reference CLI, and practical frostd ops packaging (TLS/auth, persistence, metrics, container/Helm).

Please let us know if you have any other concerns. Thank you once again

[Creativesonchain]

Thank you. We’ve updated the proposal and repo to use “threshold spend authorization (t-of-n) with FROST” everywhere, and we will edit any remaining mentions to keep it consistent.

[ZCG]

Thank you for your submission. After careful consideration by ZCG and allowing sufficient time for community feedback on the forum, the committee has decided to reject this proposal.

We appreciate your efforts in submitting a grant and encourage you to stay engaged in the Zcash community.