Threshold (FROST) custody for shielded ZEC: design check before a ZCG application

Mainnet ~May 2025, noted, my mistake. I’d taken July from the workshop thread and should have asked you rather than read around you. :sweat_smile:

Thanks, that’s what I needed to know. PR on frost-tools this week regardless.

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.

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.

1 Like