# Threshold (FROST) custody for shielded ZEC: design check before a ZCG application **URL:** \ **Category:** Applications\ **Created:** [July 13, 2026, 10:04pm UTC](https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660 "2026-07-13T22:04:42Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![conradoplg](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/conradoplg/32/42878_2.png) [@conradoplg](https://forum.zcashcommunity.com/u/conradoplg)\ **Post date:** [July 14, 2026, 10:07pm UTC](https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660/2 "2026-07-14T22:07:36Z")
> [@aryaethn](#): > > - The DKG interop spec. “State of FROST” flagged the missing key-generation standard as > the thing limiting interoperability, and ZIP-312’s non-requirements explicitly leave DKG > out of scope. Is anyone already drafting this? Would ZF be open to co-authoring, and is > ZIP-312 the right home or is this a new ZIP? The intent is to change ZIP-312 to bring DKG into scope, mostly due to quantum recoverability, see [ZIP 2005: Ironwood Quantum Recoverability](https://zips.z.cash/zip-2005#usagewithfrost) , the idea is to also use [C2SP/cocktail-dkg.md at main · C2SP/C2SP · GitHub](https://c2sp.org/cocktail-dkg) for the DKG ([draft PR](https://github.com/ZcashFoundation/frost/pull/1032)) since it allows generating additional key material required for Zcash use, but that spec is still a draft and [I’ve been providing feedback to it](https://github.com/C2SP/C2SP/issues/299) and it looks almost close to be deployable IMO. The ZIP work was being done in [https://github.com/zcash/zips/pull/895](https://github.com/zcash/zips/pull/895) , I need to try to get that moving again. > [@aryaethn](#): > > - Ironwood. Is there work in flight to bring frost-tools / zcash-sign up to v6 and the > Ironwood pool that I should build on instead of my throwaway injector? I’d much rather > the real signing path live upstream than in my code. No one is working on this currently, but it should be easy. I might work on it in the upcoming future, IMO it’s nothing something worth being part of a grant proposal. > [@aryaethn](#): > > - Trusted-dealer vs DKG for the ceremony. ZIP-312 notes DKG precludes seed-phrase > recovery. For org custody I lean toward DKG with a documented recovery story, but I’d > like a reality check. Look at the [share recovery flow](https://github.com/C2SP/C2SP/blob/main/cocktail-dkg.md#share-recovery) from COCKTAIL-DKG, that seems the way to go. IMO trusted dealer is kinda of useless since it defeats the main security gain of FROST (never having the key in memory ever) > [@aryaethn](#): > > - Anything here that overlaps with ZODL / ECC / ZF roadmap work I’m not seeing. Nothing that I am aware of. I think the biggest challenge is simply the UI part of it all. In my mind the ideal solution would be to Zodl wallet to support FROST, but that might be tricky to write a grant proposal for. Other approaches might be do a specific wallet from scratch, or try with other wallet. Also be aware that Zkool already supports FROST, though I am not a fan of their specific messaging approach which is neat but super slow (it uses the Zcash blockchain itself) and does not have the polished UI that Zodl has. BTW, the messaging is also another tricky part, we have [FROST server](https://frost.zfnd.org/zcash/server.html) but for real world usage it needs integration with e.g. Tor; a full P2P solution would be best (but harder) --- _[View the full topic](https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660)._