# 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:** 9\ **Page:** 1
**Author:** ![aryaethn](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/aryaethn/32/46620_2.png) [@aryaethn](https://forum.zcashcommunity.com/u/aryaethn)\ **Post date:** [July 13, 2026, 10:04pm UTC](https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660/1 "2026-07-13T22:04:42Z")
Hi all. I’m an independent dev with an applied-cryptography background (ZK and lattice work, mostly), and I’ve been circling the shielded-custody gap on Zcash for a while. Before I write a ZCG application around it, I want to sanity-check the scope with this community, mostly because I’d rather find out now if I’m missing something or stepping on work that’s already in flight. The thing that bugs me: an org that wants to hold shielded ZEC today basically can’t do it without either a single key or a single custodian. Even the dev-fund lockbox (ZIP-271) sits in a transparent 2-of-3 P2SH, and the largest corporate holder keeps ~290k ZEC with one custodian. Meanwhile the pieces to fix this have quietly come together: FROST 3.0 shipped, frost-rerandomized handles Orchard-style spend auth, PCZT gives you multi-party tx assembly, and the Hackmas work wired zcash-devtool and frost-client together for a signing session. ZF’s own “State of FROST” post said the missing piece is wallet adoption, and “easy multi-sig tools for shielded addresses” is on the ZCG wishlist. So the primitives exist. What’s missing is someone assembling them into something an org would actually trust. Before writing any of this up I wanted to be sure the primitives hold together on the current network and not just in the demo. So this past week I reproduced the FROST-over-PCZT flow end to end on testnet, and then pushed it onto the Ironwood pool. Short version: I have a 2-of-3 rerandomized-FROST signature authorizing a real Ironwood shielded spend, mined on testnet (txid [`a5533fe7...487d`](https://testnet.cipherscan.app/tx/a5533fe75575b09d8986a05005d2c0528cf45a1a7e4cc71b304ae76a9e14487d), height [4164791](https://testnet.cipherscan.app/block/4164791)). I’m happy to share the full reproduction. The public testnet explorers are lagging badly right now (the one I checked is a month behind the tip), so the repro is honestly more useful than the txid if anyone wants to verify. Getting there surfaced two things I think matter for scoping: 1. zcash-devtool (pczt 0.7 / orchard 0.15) and frost-tools’ zcash-sign (pczt 0.5/orchard 0.11) don’t interoperate anymore. zcash-sign can’t even parse a devtool PCZT. The two ZF tools have drifted apart since Hackmas. 2. On post-NU6.3 testnet everything lands in Ironwood, and the FROST tooling only knows Orchard. zcash-sign injects into the Orchard bundle, and devtool’s own `pczt update-with-signature` has the shielded path stubbed with a literal `TODO: Maybe support this` for both Orchard and Ironwood. Ironwood spend auth is still RedPallas and rerandomizable (devtool’s source even calls Ironwood spends “Orchard-shaped”), so FROST is clearly the right primitive. But as far as I can tell nothing ships that actually signs an Ironwood spend. I bridged it with two throwaway tools (an Ironwood-aware external-sig injector and a small non-interactive rerandomized signer) purely to prove the point. They’re demo glue, not a product. But they made the gap concrete: this works on the pool that becomes mainnet default on July 28, and nothing assembles it. Roughly what I’d want to build, three milestones: 1. A real DKG ceremony (not trusted-dealer, which rather defeats the purpose) plus rerandomized signing over PCZTs, targeting Ironwood, and a DKG interoperability spec drafted together with ZF. 2. A coordinator service and hardware-signer integration. Keystone first, since its shielded PCZT signing actually shipped; Ledger’s Orchard path is merged to their dev branch but not in a release yet. 3. A viewing-key audit layer: UFVK read access to balances, memos, an exportable ledger. The boring middle that no org-grade tool covers. Desktop/CLI first, and honest about the trust model: no party moves funds, everything auditable through viewing keys. Two things I want to get ahead of: - There have been a couple of multisig-for-shielded proposals before that didn’t ship. I don’t want to relitigate those. I think the difference this time is that I’m showing up with working code on the current pool and a concrete spec contribution rather than a plan, but if people think those earlier attempts stalled for some other reason (scope, trust model, long-term maintenance), I’d genuinely rather hear it now than after I apply. - Also, @mahmudsudo recently posted a [FROST shielded multi-sig SDK](https://forum.zcashcommunity.com/t/frost-shielded-multi-sig-sdk-easy-threshold-custody-for-zcash-wallets-grant-application/56608) proposal. I don’t see that as competing. A clean SDK over the ZF stack is useful, and I’d rather build on top of it than reinvent that layer. My scope is the product and service around it (the ceremony, coordinator, hardware, audit), plus the Ironwood and interop work that layer would need too. Glad to coordinate so we’re not duplicating effort. Where I’d most like input, especially from @conradoplg and anyone at ZF: - 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? - 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. - 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. - Anything here that overlaps with ZODL / ECC / ZF roadmap work I’m not seeing. If this is broadly the right shape I’ll turn it into a proper ZCG application with milestones and a budget. Mostly I want to make sure I’m scoping something the protocol folks actually want. Thanks for reading, and I’ll happily post the reproduction steps if there’s interest. P.S. The application GitHub link as per Alex’s request: [Grant Application - Threshold (FROST) custody for shielded ZEC · Issue #358 · ZcashCommunityGrants/zcashcommunitygrants · GitHub](https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/358) ---
**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) ---
**Author:** ![dismad](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/dismad/32/18432_2.png) [@dismad](https://forum.zcashcommunity.com/u/dismad)\ **Post date:** [July 14, 2026, 10:19pm UTC](https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660/3 "2026-07-14T22:19:41Z")
> [@conradoplg](#): > > 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) Just want to point out its been working for a while and I am a fan. We also have _multiple_ Frost hackathon submissions in route, stay tuned. (Check ZecHub PR’s for the goods ) ---
**Author:** ![aryaethn](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/aryaethn/32/46620_2.png) [@aryaethn](https://forum.zcashcommunity.com/u/aryaethn)\ **Post date:** [July 15, 2026, 5:27am UTC](https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660/4 "2026-07-15T05:27:08Z")
> [@conradoplg](#): > > 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. Agreed, and taken. It was multiple lines once I found the seam, so it’s out of the proposal. I’ll clean the injector up and PR it to frost-tools this week. If you’d rather write it yourself, say so and I’ll stay out of your way, genuinely no ego about it. > [@conradoplg](#): > > 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) since it allows generating additional key material required for Zcash use This changed my thinking most. I’d assumed the key-generation gap was open and that I could help draft something; it isn’t, so I’d rather be the implementation that helps #895 and #1032 move than another author. One question from reading ZIP-2005 and cocktail-dkg together. ZIP-2005 has the participants agree on `sk` and each retain `qsk`, and says losing `qsk` loses the funds once Orchard is disabled. The `sk` contributions look like they belong in COCKTAIL’s optional application payloads, with the extension derived from them so the transcript enforces agreement. But recovery’s output is only `x_i`, `Y` and the verification shares: step 6 decrypts the whole plaintext and keeps just the leading scalar, so the payload sits right there and gets dropped. Read literally, recovery hands back a signing share and quietly loses `qsk`. And ZIP-2005’s answer for `qsk` backup is ZIP-32 re-derivation from the seed, then it says a deployment not using ZIP-32 is on its own. A DKG group is exactly that deployment, with no seed to fall back on, which is rather the point. So: should recovery return the payloads, or is the application meant to dig them out itself? Happy to write it up on the C2SP issue if it’s real and I’m not misreading. > [@conradoplg](#): > > IMO trusted dealer is kinda of useless since it defeats the main security gain of FROST (never having the key in memory ever) Agreed. It was only ever how I got a first signature out of the stack. > [@conradoplg](#): > > Also be aware that Zkool already supports FROST I hadn’t clocked that, which is a hole in my homework, so I read it before replying rather than after. Credit where it’s due: real DKG, no trusted dealer, a GUI, mainnet since last July. Further along than I’d assumed anyone was. @hanh, a sanity check if you have a minute. As far as I can tell the FROST signing path only walks the Orchard actions and calls `sign_orchard_with`, and DKG mints an Orchard-only UA; `ironwood_indices` turns up in the Ledger builder but not in `frost/`. So Zkool’s threshold accounts are Orchard accounts. Have I got that right, or is there an Ironwood path I’ve missed? > [@conradoplg](#): > > 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. You’re right that it’s the hard part, though I’d argue about where it lives. “My savings need two of my three devices” belongs in a wallet, and Zkool is most of the way there. “Five people, a policy, an auditor, hardware, and a recovery drill” is a different animal, whose hard parts are the ceremony, the recovery and the audit trail, not send and receive. What convinced me it isn’t just polish is your own recommendation. COCKTAIL says you MUST NOT use the group key for critical operations, naming long-lived asset custody, until every participant confirms they’ve stored their recovery material, and the round-1 ciphertexts must survive somewhere durable, coordinator included. Those are ceremony obligations no library discharges for you; for this use case the UI _is_ the security work. So I’d rather the core be an embeddable crate than a wallet feature. Then nobody writes a grant against anyone else’s roadmap, and if Zodl or Zkool wants it later it’s there. Zodl being mobile-only is a fit problem anyway: a treasury ceremony wants a desk, several people and a hardware signer on the table. > [@conradoplg](#): > > we have FROST server but for real world usage it needs integration with e.g. Tor; a full P2P solution would be best (but harder) Agreed, and I can’t solve it in general. One narrowing for my case: with hardware signers the signing round can go over QR, which Keystone does anyway and devtool already has to-qr/from-qr for, so network privacy doesn’t arise for the round that authorizes money. The ceremony is the awkward one, three rounds across n participants being a lot of QR codes. My instinct is frostd behind an onion rather than inventing a transport. Would you take a Tor transport in frostd upstream, or does that belong client side? @dismad, thanks, I looked. Found Steward in the PRs, close enough that I’m glad I read it. If the rest are visible once voting opens I’d like to go through them; I’d rather find out I’m duplicating someone this week than after I apply. ---
**Author:** ![hanh](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/hanh/32/27853_2.png) [@hanh](https://forum.zcashcommunity.com/u/hanh)\ **Post date:** [July 15, 2026, 8:03am UTC](https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660/5 "2026-07-15T08:03:29Z")
> [@aryaethn](#): > > I hadn’t clocked that, which is a hole in my homework, so I read it before replying rather than after. Credit where it’s due: real DKG, no trusted dealer, a GUI, mainnet since last July. Further along than I’d assumed anyone was. > > @hanh, a sanity check if you have a minute. > As far as I can tell the FROST signing path only walks the Orchard actions and calls `sign_orchard_with`, and DKG mints an Orchard-only UA; `ironwood_indices` turns up in the Ledger builder but not in `frost/`. So Zkool’s threshold accounts are Orchard accounts. Have I got that right, or is there an Ironwood path I’ve missed? Mainnet was ~May 2025. Ironwood isn’t fully supported yet. But it shouldn’t be too hard The hardest parts were: - secure and authenticated encrypted messaging p2p and p2g. Zcash memos gets us nearly there but authentication was added (following L/A audit report) - backing up all the added key material. There is no standard for it. I choose a way that makes it restorable on Zkool only. One day, someone will write a ZIP. But for now, unlike seed phrases, FROST accounts use a proprietary format. - there are areas I don’t cover that the FROST protocol does such as detecting malicious actors, reconfiguring the threshold, etc. - But for your use case, I think it should work. ---
**Author:** ![aryaethn](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/aryaethn/32/46620_2.png) [@aryaethn](https://forum.zcashcommunity.com/u/aryaethn)\ **Post date:** [July 15, 2026, 8:39am UTC](https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660/6 "2026-07-15T08:39:49Z")
Mainnet ~May 2025, noted, my mistake. I’d taken July from the workshop thread and should have asked you rather than read around you. 😅 > [@hanh](#): > > Ironwood isn’t fully supported yet. But it shouldn’t be too hard Thanks, that’s what I needed to know. PR on frost-tools this week regardless. > [@hanh](#): > > backing up all the added key material. There is no standard for it. I choose a way that makes it restorable on Zkool only. One day, someone will write a ZIP. But for now, unlike seed phrases, FROST accounts use a proprietary format. This is the part I’d like to pick up, and it’s the same hole @conradoplg and I were circling from the other side. ZIP-2005 has the participants agree on `sk` and each keep `qsk` forever, and its answer for backing `qsk` up is “re-derive it from your seed phrase”, which a DKG group hasn’t got. So you hit it from the wallet end and it turns up again from the quantum-recoverability end, and both times the answer is that there’s no format. “Restorable on Zkool only” is understandable, because you had to ship something. But it’s also the specific thing an org can’t sign off on, because the recovery path for a treasury can’t be one implementation. The funds have to outlive the tool. So if you’re willing: what’s in your format? If someone writes that ZIP it should start from whoever already had to invent one, not from a blank page. I’ll do the drafting legwork, and your name goes on it if it goes anywhere. > [@hanh](#): > > But for your use case, I think it should work. For two to five people holding Orchard today, I think you’re right, and I’d point them at Zkool. Where it stops for me is the org case: shares on hardware rather than in the app, an auditor with read access and no spend authority, Ironwood after the 28th (hopefully), and a recovery story that isn’t tied to one wallet. And the two you say you don’t cover, malicious-actor detection and reconfiguring the threshold, are the ones a treasury leans on hardest, since rotation is what you do when someone leaves. ---
**Author:** ![aryaethn](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/aryaethn/32/46620_2.png) [@aryaethn](https://forum.zcashcommunity.com/u/aryaethn)\ **Post date:** [July 17, 2026, 11:07am UTC](https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660/7 "2026-07-17T11:07:14Z")
Quick one, nothing new to reply to yet, just flagging two things. @conradoplg the issue’s up: [zcash-sign: Ironwood (NU6.3 / v6) external signing — scoping, and the orchard FVK blocker · Issue #591 · ZcashFoundation/frost-tools · GitHub](https://github.com/ZcashFoundation/frost-tools/issues/591). Laid out where the version bump lands, orchard included. Still happy to do it if you’d rather point me at a branch than write it yourself. @hanh separately, I’m filling out the application now. Fingers crossed it lands somewhere, and if it does I’d still take you up on the format question whenever you get a minute. ---
**Author:** ![ZCG](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zcg/32/33712_2.png) [@ZCG](https://forum.zcashcommunity.com/u/ZCG)\ **Post date:** [August 5, 2026, 12:51pm UTC](https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660/8 "2026-08-05T12:51:27Z")
Thank you for your submission. After consideration from ZCG[](https://forum.zcashcommunity.com/groups/zcashgrants)and sufficient time for the community to provide feedback on the forum, the committee has decided to reject this proposal. The committee appreciates your grant submission efforts and encourages you to continue as an active member of the Zcash community going forward! [Meeting Minutes](https://forum.zcashcommunity.com/t/zcash-community-grants-meeting-minutes-8-3-2026/56909) ---
**Author:** ![aryaethn](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/aryaethn/32/46620_2.png) [@aryaethn](https://forum.zcashcommunity.com/u/aryaethn)\ **Post date:** [August 5, 2026, 3:59pm UTC](https://forum.zcashcommunity.com/t/threshold-frost-custody-for-shielded-zec-design-check-before-a-zcg-application/56660/9 "2026-08-05T15:59:43Z")
Thanks for the consideration. No hard feelings on the outcome, and the design-thread discussion was genuinely useful either way, so thanks to everyone who dug in, @conradoplg and @hanh especially. A couple of the concrete pieces are worth doing on their own, so I’ll carry on with them regardless of the grant: - The Ironwood external-signing path for frost-tools (issue #591). I’ll get that PR up. - The qsk backup/recovery gap. Both Conrado (through COCKTAIL-DKG recovery) and Hanh flagged that there’s no standard for the added key material, and it’s the one piece an org can’t safely tie to a single implementation. I’d like to help turn that into a ZIP, starting from the format Hanh already had to invent rather than a blank page. I’ll stick around the FROST corner of the ecosystem either way. Thanks again.