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

**URL:** <https://forum.zcashcommunity.com/t/interoperable-frost-co-signing-for-shielded-zec-open-specs-and-a-reference-implementation/58172>\
**Category:** Community Grants\
**Created:** [October 13, 2026, 5:02pm UTC](https://forum.zcashcommunity.com/t/interoperable-frost-co-signing-for-shielded-zec-open-specs-and-a-reference-implementation/58172 "2026-10-13T17:02:58Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![Khadim](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/khadim/32/49353_2.png) [@Khadim](https://forum.zcashcommunity.com/u/Khadim)\
**Post date:** [October 15, 2026, 4:23pm UTC](https://forum.zcashcommunity.com/t/interoperable-frost-co-signing-for-shielded-zec-open-specs-and-a-reference-implementation/58172/7 "2026-10-15T16:23:55Z")

</div>

To make the scope clearer, here’s how I see the FROST projects for shielded ZEC, and how this work would connect them. Please correct anything I got wrong or missed.

| Project | What it is | How signers talk | Backup |
| --- | --- | --- | --- |
| Zkool | wallet with FROST, signs Orchard and Ironwood | shielded memos | passphrase-encrypted export (age), restores in Zkool only |
| Zafe | mobile shared vault (Android), mainnet beta | encrypted relay | passphrase-encrypted file (share, sk, vault descriptor), to cloud or file |
| Konclave | group treasury in the browser, mainnet beta | relay and a hosted helper | passphrase-encrypted export (share, viewing key, metadata) |
| Quorum | org treasury tool, hackathon build on testnet | frostd | none yet: share passphrase-encrypted on the device, lost-share repair planned |
| NoirWallet | Secure Vault design | QR or Bluetooth | one recovery phrase per share |
| OpenPGP Wallet (me) | prototype, mainnet spends | QR (files in the prototype) | 3rd share as an encrypted offline file, no phrase (design) |

They all build on the Zcash Foundation’s FROST crates (re-randomized FROST, ZIP 312), and most of them sign PCZTs. What differs is the envelope, the transport, the key derivation and the backup, so today a share made in one app can’t be used or restored in another.

The plan, with no new crypto:

1. **Keys** : derive them per ZIP 2005 (Zafe’s test vectors and mine already match), and follow the ZIP 312 key generation once zips#895 lands. I left a review note there: [[ZIP 312] Specify key generation, change randomizer handling by conradoplg · Pull Request #895 · zcash/zips · GitHub](https://github.com/zcash/zips/pull/895#issuecomment-6195693778)
2. **Messages** : a shared group descriptor and a shared envelope (Zafe’s looks like a good starting point), carried over any transport (memos, a relay, frostd), with QR as the one every app can do.
3. **Backup** : a common format with room for each app’s own data. @aryaethn said in August he’d like to help turn this into a ZIP starting from @hanh format. I’d do the drafting and the implementation, with their input.
4. **Proof** : cross-implementation signing tests with whoever is up for it. Zafe’s stack is the closest to mine.
5. **A small reference crate** for the descriptor, the envelope and the backup, so adopting them takes a few lines rather than a rewrite. It’s not a wallet SDK: each app keeps its own UX and transport.

This doesn’t change the application’s scope, milestones or budget: the QR protocol becomes the first transport profile of the shared envelope, and the backup format and the crate are the same deliverables.

If you build FROST for Zcash and want to join, or think this is the wrong approach, please say so.

---

_[View the full topic](https://forum.zcashcommunity.com/t/interoperable-frost-co-signing-for-shielded-zec-open-specs-and-a-reference-implementation/58172)._