The first FROST Round Table occurred on November 8, 2023. Almost a dozen experts in the field, including the designers of the protocol, members of the ZF Frost team, and members of the secp-zkp FROST team came together to talk about their experience with FROST and answer questions about its usage.

For an intro to FROST, see the FROST page and “A Layperson’s Intro to Schnorr”.



For more, also see the rough summary or the raw transcript of the event.

Key Quotes

Quotes are drawn from raw transcripts and may not be entirely precise as a result, but convey many of the major themes of the meeting. See the video for more.

Initial Thoughts

Simplicity: “It’s fairly straightforward to implement, but the hard part is getting deployed.”

Community: “I’m excited to see the community coalescing and finding FROST to be useful.”

UI: “my biggest concern … is the user experience of this and what the user workflows are going to be.”

Distributed Key Generation (DKG)

Difficulty: “I think the most difficult part is the DKG.”

Possibilities: “Several people have talked about … rekeying and other different types of things that might be possible with distributed key generation.”

Trusted Dealer Generation

Usefulness (I): “I think my take on Trusted Dealer Generation is that it’s not really worth the effort. I mean, if you’re going to add so much complexity because you add a threshold scheme, then I think DKG really, really makes sense.”

Usefulness (II): “I think Trusted Dealers can be useful for some custodians.”

Usefulness (III): “The ability to do VSS and be able to have the shareholders sign different types of things without necessarily restoring is just really useful for wallet resilience of legacy keys, personal data, etc.”

Resilience & Trust

Backups: “In the case of Frost, it’s a bit tricky … You need to share in the group key and the identifier and maybe other people’s identifiers. So it’s more information that you need to back up or save.”

Restoration: “If you have a threshold of people come together, they can restore another person’s share.”


Variety: “The IETF draft covers a range of curves.”

Efficiency: “[25519] is a bit less efficient than Ristretto because FROST needs a prime order group and 25519 is not a prime order.”

Conversion: “If you compare Ristretto and SecP, I don’t think they are any compatible because they are different groups, right? … So I don’t see how you could do a single DKG for both. But if you talk about Ristretto and 25519, they’re kind of related, so maybe there’s some way to make it work, but I would need to also think about it.”

Trusted Channels

Privacy: “If your system wants to have secure channels for privacy reasons … then I guess you would use them. You would run DKG over the secure channel. You would also run signing over the secure channel.”


Signing: “You can use a low power device to generate the shares. And then anyone on any computer anywhere can combine them into the final signature.”

Wild Card Uses of FROST

Nesting: “There’s an interesting cryptographic piece of this that I don’t think has been fully explored, which is the notion of nesting FROST. So for example, if you have a MuSig construction, like in Lightning with a two of two MuSig for lightning channel … to what extent can you nest FROST inside of one or two of the MuSig keys?


About ROAST: “It’s supposed to provide robustness so you can guarantee to get a signature and of course you if you implement it wrongly, then it won’t work and you won’t get a signature in the end.”

FROST Quorums

Creating Accountability: “The easiest thing to do would be you publish your FROST signature and then you have some ledger or something where you persist information. … You publish that and then you could either persist the T individual signature shares or we have this nice multi signature scheme called MuSig.”