Nerd of the Month #4: Frostpunk
In cold storage we trust.
This installment of Nerd of the Month comes to us from Spiral grantee @siv2r, who is diving deep into FROST, the threshold signing protocol making bitcoin custody more private, scalable, and secure. From drafting the BIP to reviewing implementations like ChillDKG, he’s at multisig’s forefront and future.
I'll never forget the first time I wrote down my 24-word seed phrase. It was an amazing feeling, knowing that I truly owned my Bitcoin. But, honestly, I was a little nervous, too. After all, that single note holds everything, and there are far too many stories of lost keys: forgotten passwords, accidentally discarded hard drives, or the untimely death of the only person who knew the secret. At the end of the day, bitcoin comes down to how you custody and control your private keys.
Fortunately, bitcoin supports much more than simple single-key control. Its scripting opcodes provide a powerful toolkit for secure and flexible custody, allowing you to share control, enforce time-based rules, and create conditional spending paths.
Multisig Works, But…
One of the most powerful features is multisig, enabled by opcodes like OP_CHECKMULTISIG (legacy) and OP_CHECKSIGADD (Taproot). Multisig lets you spread control across multiple keys so no single person has full access. For example, a 2-of-3 multisig setup means any two out of three participants must sign to move funds. That means your funds remain secure even if one participant’s key is lost or compromised. This t-of-n model forms the foundation for collaborative custody.
The Taproot upgrade brought Schnorr signatures to bitcoin, opening the door to more advanced threshold signing protocols like FROST. In a t-of-n FROST setup, any t signers can collaborate to produce a Schnorr signature that appears identical to one created by a single person. On the bitcoin blockchain, it gets verified using the standard OP_CHECKSIG opcode like any other signature, so no observer can tell it came from a group. This makes FROST excellent for privacy, and since it only produces one signature, transactions are smaller, cheaper, and more scalable than traditional multisig setups.
Where FROST Stands Today
There exists an IETF specification, RFC 9591, that defines the FROST threshold signing protocol for various curves and hash functions. But that spec isn’t directly compatible with Bitcoin’s Taproot rules, which use x-only public keys and involve key tweaking. To bridge that gap, I've been working on a draft BIP that adapts FROST signing specifically for bitcoin's requirements.
Meanwhile, there are already some bitcoin-compatible FROST implementations out there. Jesse Posner built an experimental module for libsecp256k1-zkp, and the Zcash Foundation created their ZF-FROST library.
There's also the ChillDKG BIP draft from Blockstream Research, which introduces a standalone distributed key generation protocol designed specifically for FROST. What sets it apart is that it doesn't depend on external secure channels or separate consensus layers. Instead, ChillDKG handles secure communication and agreement internally, making the protocol more self-contained and easier to implement in practice.
Between the existing implementations and the work on standardization, FROST is finally becoming practical for real-world Bitcoin applications.
What I've Been Building
Over the past year, I've spent most of my time working on FROST-related projects in the bitcoin space. My main focus has been drafting the BIP for FROST signing, which is currently at version 0.2. Since FROST and MuSig2 share similar signing algorithms, I leaned heavily on BIP327 (the MuSig2 spec) as a reference. That deep dive turned out to be a nice bonus: it helped shape the FROST signing spec and also led me to spot and help fix an error in BIP327's test vectors.
I thoroughly reviewed Jesse Posner's FROST pull request to ensure the implementation aligns with the signing BIP. I've also been collaborating with the authors of ChillDKG. After an initial review of their spec, I'm now creating comprehensive test vectors.
I've also had the chance to get my hands dirty with a few other interesting projects. I took over the work on Schnorr adaptor signatures in libsecp256k1-zkp, rebasing the old code, adding new test vectors, and creating Rust bindings for it. It's been rewarding to see external interest in this module.
Plenty More to Explore
I've got an interesting roadmap ahead. First, I'll polish the FROST Signing BIP and release it as version 1.0. I'll also continue to support ChillDKG and the FROST pull request in libsecp256k1-zkp. On the research side, I'll be looking into share repair and refresh protocols to make threshold schemes even more resilient. Beyond FROST, I'm planning to revive my batch verification work. There's plenty to explore, and I'm excited to see where it all leads.