Introduction

Botanix is a Bitcoin-based chain that introduces Spiderchain—a protocol that provides security by a series of decentralized multisignature wallets that run consecutively one after the other. We partially described the workings of multisig in the article How Botanix Protects Against Double-Spending and Conflicting Inputs. The roles of the main participants in Spiderchain (orchestrators) in the peg-in and peg-out processes were also discussed in that article in general terms.

Now, we dive even deeper—layer by layer—much like transitioning from studying anatomy to exploring cellular and biochemical processes. In this article, we’ll take a detailed look at how Botanix implements primitives like DKG and FROST within Spiderchain: the technical architecture, the custom DKG State Machine built to withstand high network latency and packet loss, the integration of FROST into signing and transaction verification operations, and a comparison with traditional multisig approaches in Bitcoin and Ethereum.

As previously mentioned, unlike a traditional federated sidechain, Spiderchain is designed to be permissionless and trust-minimized, using advanced threshold cryptography to secure Bitcoin assets. In the context of Botanix, Multisig is a general process that incorporates cryptographic components such as Distributed Key Generation (DKG) and FROST (Flexible Round-Optimized Schnorr Threshold Signatures). For users deeply embedded in the crypto space, these terms may already be familiar:

• DKG is a cryptographic process that allows multiple participants to jointly generate a secret key without any single party knowing the complete key. In the context of Botanix, this enables an arbitrary subset of validators (Orchestrators) to jointly generate new multisig keys, with no party having full knowledge of the private key.

• FROST is a cryptographic protocol used to produce digital signatures involving multiple participants while maintaining efficiency and privacy. In the case of Botanix, this mechanism allows orchestrators to create a single aggregated signature for transactions, even when multiple parties are involved.

Now let’s take a closer look at how orchestrators work with these cryptographic primitives, and how this process functions in peg-in and peg-out scenarios at a deeper technical level.

Spiderchain and Orchestrators: Why Are DKG and FROST Needed?

To understand why DKG and FROST are necessary, let’s recall how orchestrators work. As we may remember from previous materials, with each Bitcoin block, a new threshold multisig address is created, controlled by a random subset of Orchestrator nodes selected using a verifiable random function (VRF). This means that each deposit (and any UTXO change during a withdrawal) lives on its own unique multisig address, with signers (orchestrators) randomly chosen for that blockchain block. It's worth digressing here that Spiderchain currently uses only one fixed multisig address for the entire duration. This is because the frequency of generation and rotation of multisigs in a dynamic federation is still in the modeling and research phase.

Furthermore, in the current configuration, moving funds typically requires about 12 out of 16 signers. This adds an additional layer of security on top of the random selection of orchestrators. If a subset of orchestrators happens to be malicious—which is unlikely—the threshold signature prevents them from gaining majority control. Even in the unlikely case that many orchestrators are malicious, the required 12/16 threshold would not be met, simply freezing the multisig and triggering a new VRF round.

Also, since we are diving deeper into the technical workings of Spiderchain, it’s important to make another key point regarding an additional security layer: Spiderchain uses a Last-In-First-Out (LIFO) approach for spending deposits during withdrawals. This means the most recent deposit UTXOs are spent first when processing withdrawals, while older UTXOs remain untouched until needed (this is also currently in the modeling and research phase). This adds another layer of protection: all BTC deposited before an attacker gains influence remain locked behind older multisig keys—keys the attacker did not help create—so even if they somehow control 12 out of 16 signers, they cannot access earlier-deposited funds.

And this entire mechanism hinges on what is known as threshold cryptography.

Threshold cryptography is a field of cryptography where a certain minimum number of participants is required to perform a given cryptographic operation (such as signing or encryption).

All the security relies on the fact that threshold cryptography enables the generation and usage of keys among a group of Orchestrators in such a way that no single Orchestrator ever knows the full private key, but the group can still collectively sign transactions. FROST and DKG are both mechanisms that fall under threshold cryptography. The Spiderchain mechanism is based first on distributed key generation (for decentralized setup of each multisig address key), and then on threshold signing (FROST) to produce valid Bitcoin transaction signatures from those addresses.

Now let’s take a closer look at each of these mechanisms.

DKG State Machine in Botanix’s Spiderchain

Distributed Key Generation (DKG) is the process by which a group of participants jointly generate a public/private keypair without any trusted intermediaries (you can read more about DKG for example here). In Spiderchain, every time a new multisig address is needed – which is essentially for every Bitcoin block epoch – the randomly selected Orchestrators for that “slot” run a DKG protocol to create a fresh threshold key. The result of a successful DKG is that each of the ‘n’ chosen Orchestrators holds a secret share of the private key, and they collectively know the corresponding public key (the multisig address). No Orchestrator learns anyone else’s share or the full key, yet any threshold of t shares (e.g. 12/16 of n) can later be used to sign a transaction. This splitting of keys into shares is exactly what the DKG protocol accomplishes before any signing can happen. In this case, Botanix offers not just a DKG, but a DKG State Machine.

DKG State Machine

In order to understand how what is called the DKG State Machine works, we need to look at the DKG process. Under the hood, the DKG typically runs as a multi-round protocol where each Orchestrator does the following steps (at a high level):

• Share Generation: Each selected Orchestrator creates a secret polynomial and computes multiple secret shares from it, one for each participant. They also compute commitments to the polynomial’s coefficients (using cryptographic commitments) to allow others to verify consistency of shares.

• Exchange: Orchestrators exchange their commitments and encrypted secret shares with the group. This often involves broadcasting commitments and sending each share privately to its intended recipient.

• Verification: Upon receiving shares from others, each Orchestrator uses the published commitments to verify that every share they got is consistent (ensuring no one cheated by sending bad shares). If a participant detects an invalid share or missing share, the protocol can identify that participant as faulty.

• Public Key Computation: Once all shares are verified, each Orchestrator computes the group’s joint public key (which will become the multisig’s public address on Bitcoin). In Schnorr-based DKG, this is done by summing up the public commitments (or partial public keys) from each participant’s contribution. The group also agrees on the list of valid participants and their shares, excluding any detected bad actors.

Thus, the result of the entire DKG process is a shared threshold key, ready for use. In the case of Botanix, this process is repeated continuously, as each block requires new multisigs for inputs and outputs (peg-in and peg-out).

To reliably coordinate this process, the Botanix engineering team implemented a State Machine designed to the DKG process within the Orchestrator node software. They developed a reliable DKG State Machine capable of operating even under adverse network conditions—tolerating packet loss during communication rounds. In practice, this means the DKG protocol can handle lost or delayed messages without failure: orchestrators will retry, use timeouts, and continue attempting to initiate the protocol until a message quorum is reached. That is, if packets are lost, instead of interrupting processes, it will just take a little longer. This resilience is critical, as Spiderchain operates on the open internet with a permissionless set of validators, where network delays or packet loss could otherwise disrupt the key generation process.

This enables high fault tolerance for Spiderchain by allowing operation under asynchronous conditions. The implementation of the DKG State Machine, with retry logic and clear phase transitions (e.g., waiting for commitments, then transitioning to shares, etc.), allows Botanix to maintain continuous protocol operation despite asynchronous communication. This breaks the DKG process into defined stages and transitions, so orchestrators can “catch up” if messages arrive late or out of order, rather than causing a complete failure. Also, an auto-reset mechanism has recently been added to increase stability even more. The idea behind this is that the DKG process cannot be completed in a certain amount of time, the coordinator/orchestrator automatically resets the DKG process with freshly generated packages, requiring all other participants to regenerate theirs as well.

The Advantage of DKG Over Other Threshold Signature Mechanisms

Another advantage of Botanix’s DKG mechanism is that it enables seamless onboarding of new orchestrators and graceful exit of participants from the orchestrator set. For example, Pedersen DKG and ring signatures require all participants to be present during initial setup, where they perform handshakes—similar to some MPC variants. In the case of Botanix, if an orchestrator leaves or goes offline, future multisigs simply won’t include them. The term “sequential multisigs” also implies that as each new multisig is formed, the composition of Orchestrators can change over time.

As Botanix progresses toward full decentralization, DKG becomes even more critical: it eliminates the need for a trusted dealer or pre-established fixed key when moving to a permissionless orchestrator nodes set. Thus, the DKG implementation in Botanix is foundational to the security and decentralization of Spiderchain, allowing the network to continually form newm-of-n signing groups on the fly, without entrusting private keys to any single party.

Therefore, once a shared key for a group of orchestrators has been established through a DKG round, the next task is to use that key for transaction signing. This is where FROST comes into play.

FROST Signatures in Botanix Spiderchain

As mentioned above, FROST comes after DKG. FROST is a specialized protocol (originally developed from cryptographic research by Chelsea Komlo and Ian Goldberg) that optimizes Schnorr threshold signatures by requiring minimal rounds of communication and avoiding any single point of failure. Simply put, FROST allows t participants to collaboratively produce a valid Schnorr signature on a message, which can be verified against the group’s public key—just as if a single party with the full private key had signed it. This means that even if, say, 12 out of 16 orchestrators need to jointly sign a Bitcoin transaction, only a single aggregated signature will appear on-chain, indistinguishable from a standard one-party signature.

This means that once a shared key (DKG) is obtained, orchestrators can sign a Bitcoin transaction with an aggregated Schnorr signature, but the Bitcoin blockchain will have no knowledge that multiple parties were involved in producing it. Such aggregation saves block space and enhances privacy by making threshold signatures indistinguishable from other more common spending types. This elegant solution avoids the high overhead and fees associated with listing multiple public keys and signatures, as would be required in a traditional Bitcoin multisig, especially with a 12-of-16 threshold. Instead, FROST compresses it all into a single key and a single on-chain signature.

How FROST works in outline:

• Commitment Round: Each of the t signing Orchestrators picks a random nonce and shares a commitment to that nonce with the others. This can often be done with a single broadcast if a coordinator is used, or via pairwise exchanges.

• Signature Round: After seeing each other’s nonce commitments, one Orchestrator (or a predefined aggregator) computes a challenge (using the message and all signers’ public nonces) and shares it. Then each signer uses their secret key share and their nonce to produce a partial signature. These partial signatures are collected and combined into the final Schnorr signature.

How FROST works in the context of Spiderchain with peg-out and peg-in:

The process starts with a deposit from the user (peg-in) and FROST is not used at this stage — it is used for peg-out.

• Peg-in transactions:
  1) Once the DKG for the new block orchestrator set is complete, then the final (“aggregated”) public key is computed, which can be used to derive a Bitcoin recipient address.
  2) When users deposit BTC (peg-in), they send Bitcoin to this Spiderchain address, which is a threshold multisig controlled by the orchestrators for that block.
  3) This does not require a Bitcoin signature at this point, but it is a critical part of the operation. FROST itself is not needed to generate the address (this is handled by DKG), but it will be required later when these funds are spent (as described below for peg-out).

• Peg-out transactions — this is where FROST is used:
  1) When users withdraw BTC from Botanix back to Bitcoin, the orchestrator group creates a Bitcoin transaction that spends one of the Spiderchain multisig UTXOs and sends BTC to the user's Bitcoin address.
  2) Since this UTXO is controlled by a threshold key (shared among the block's multisig orchestrators), these orchestrators must jointly sign the transaction.
  3) The resulting signature is valid under the multisig public key and is included in the Bitcoin transaction, enabling it to be broadcast and mined.

Comparison DKG State Machine + FROST Mechanism to Traditional Multisig (Bitcoin & Ethereum)

After reviewing the operation of the Botanix mechanism, which combines the use of an extended DKG process with State Machine and FROST, let’s summarize it in comparison with other multisig mechanisms. This represents a significantly more advanced approach compared to traditional multisignature systems on Bitcoin or Ethereum:

• On-Chain Footprint: In Bitcoin’s native multisig (e.g. P2WSH or even Taproot script multisig), a transaction spending from an m-of-n multisig typically includes all n public keys (or their hashes) and at least m distinct signatures. This makes the transaction size (and fee) grow with the number of signers. For example, a 15-of-15 multisig would have to reveal 15 public keys and 15 signatures, which is huge. In contrast, Botanix’s threshold signatures always appear as a single pubkey and a single signature on-chain, regardless of how many participants are actually involved. This is possible because the aggregation happens off-chain via FROST. The savings in block space are tremendous, enabling large groups of signers without prohibitive cost. On Ethereum, the typical multisig (like a Gnosis Safe) is a smart contract that verifies multiple ECDSA signatures. Each signature is separate data in the transaction call, so gas costs increase with the number of signers. By using threshold cryptography, one could reduce this to one signature verification, but Ethereum doesn’t natively support Schnorr for ECDSA – so projects rely on contracts. Botanix avoids such overhead entirely by doing threshold cryptography at the protocol level.

• Privacy: A traditional Bitcoin multisig reveals the exact number of signers (and in older script versions, exactly which ones signed). An Ethereum multisig contract’s events also reveal which addresses approved a transfer. In Botanix’s threshold approach, the resulting on-chain transaction is indistinguishable from a single-signer transaction. An outside observer cannot tell if the BTC was locked by 5 parties or 50, nor can they identify which validators participated. All they see is a Taproot output (in the ideal case) being spent with a valid Schnorr signature. This improves fungibility and privacy. And this is a strong contrast to federated sidechains like Liquid where anyone can see that an 11-of-15 multisig was used (because the script or control block reveals it), or to naive Bitcoin scripts where the presence of multiple signatures is obvious.

• Security Model: Traditional multisig in Bitcoin assumes each signer controls a key and you trust a threshold of them to be honest. This is the same assumption as threshold cryptography. However, threshold cryptography eliminates the need to ever trust a single device or setup with the full key. In a classic multisig, there’s at least a concept of an address that is the combination of all participants’ keys, but those keys were generated individually by each participant. There’s no single point of compromise in multisig either (since each key is separate), but if one key is stolen, the attacker still can’t spend it unless they get enough keys. In threshold schemes like FROST, if one share is stolen, the attacker is still in the same position (needs t shares). So at a high level the security against theft is similar. But threshold schemes have an advantage in ceremony and rotation: If the membership of signers changes, a normal Bitcoin multisig would require creating a brand new address with a new script (and transferring funds to it), whereas threshold setups can simply run a new DKG to re-share the key among a new set (or generate a new key for new deposits) without moving funds already locked. Botanix exploits this with the rotating multisigs per block – something impractical to do manually with classic multisig. In Ethereum, changing a multisig contract’s signers is an on-chain admin operation (costly and potentially requiring current signers’ approval). Botanix’s approach instead just naturally phases in new signers by creating new keys via DKG.

• Decentralization and Permissionlessness: The multisig used in Bitcoin’s Liquid sidechain is a static federation (entities were chosen and remain until a coordinated change). That model doesn’t allow permissionless addition of signers; it’s inherently a closed group. Similarly, Ethereum’s popular multisigs are permissioned (you decide which addresses are signers). Botanix’s threshold cryptography, combined with its stake-weighted random selection, means anyone who meets the staking requirements can become a signing Orchestrator and help control funds. There’s no central authority picking the multisig members; it’s determined by randomness and open staking. This is a major leap in decentralization compared to traditional multisigs. It effectively transforms what would be a federated custody model into a decentralized, open validator set model (much like a Proof-of-Stake chain) – all while maintaining security via cryptography. In other words, Botanix’s use of DKG+FROST turns the custodianship of Bitcoin into a decentralized consensus problem, rather than a static multisig trust assumption.

• Operational Complexity: It must be said that threshold cryptography (DKG and FROST) is more complex to implement than a basic multisig script or contract. There is overhead in running the protocols and ensuring all edge cases are handled. Traditional multisig has the advantage of simplicity (each party just signs the transaction when ready, no interaction needed except collecting signatures). However, the cost of that simplicity is paid in on-chain inefficiency and lack of dynamic flexibility. Botanix accepted the added complexity in exchange for the big gains in scalability and decentralization. Once implemented in software, the complexity is largely abstracted away from users – from a user’s perspective, depositing and withdrawing is straightforward and not much different from using a federated peg. But for the network, the behind-the-scenes cryptography is doing a lot more work. The successful Testnet and Federated phases of Botanix have demonstrated that these protocols can work in practice, and as the project moves to full mainnet, it’s paving new ground in applying threshold crypto at scale for Bitcoin sidechains.

In summary, compared to traditional multisig setups, our DKG and FROST-based approach offers far greater scalability (in number of signers), better privacy, and true decentralization, at the cost of additional protocol complexity. It represents an evolution similar to how multisig itself was an evolution over single-key custody – now threshold signatures are an evolution over explicit multisig scripts. This could be a model for future Bitcoin applications requiring many signers or dynamic signer sets.

Also threshold cryptography is the enabler of our vision of permissionless staking and decentralized validator coordination. It allows the Spiderchain to operate without a centralized custodian or fixed federation, something that earlier Bitcoin sidechains struggled with. As a result, Spiderchain can inherit security from Bitcoin’s value (because validators stake BTC) and decentralization from a wide pool of participants, all made possible by distributing trust through cryptographic keys. 

Conclusion

Thus, in this article, we've dived into the lowest-level workings of spiderchain, transitioning from a general overview in previous articles to deeper and more complex processes that, at first glance, might simultaneously appear very simple and complicated. Botanix doesn't merely employ existing DKG and FROST protocols; instead, it adapts them for the challenging conditions of a genuinely decentralized system. Botanix DKG State Machine adds practical robustness, allowing the DKG process to function reliably even in real-world network conditions characterized by high latency or packet loss. Built upon these keys, FROST provides validators with a fast and efficient method for collectively signing transactions, making threshold multisigs as straightforward to use as single-sigs from Bitcoin's perspective.

Additionally, such practical usage of DKG and FROST in the context of Bitcoin could pave the way for broader adoption of threshold cryptography in blockchain applications. This approach vividly demonstrates that even Bitcoin, without any changes or new opcodes, can support extended functionality via smart off-chain protocols without requiring serious or prolonged modifications through BIPs. And regarding projects that call themselves L2 on top of Bitcoin, which most often means uploading any proofs to Bitcoin as L1, Botanix also offers a nifty and easy solution. This approach does not require developing complex and small proofs in the pursuit of packing it into a small amount of space in Bitcoin blocks. It also does not require additional complex and expensive computations that must take into account the fact that Bitcoin as an L1 in this context cannot perform actions as Ethereum smart contracts do.

In conclusion, it can be noted that the DKG State Machine and FROST are not merely theoretical concepts but already active components powering the Spiderchain architecture. Together, they enable a new form of interaction for Bitcoin while preserving its monumentality—decentralized, efficient, and secure. This approach significantly differs from traditional multisig federations and expands the boundaries of what's possible through threshold cryptography. The combination of things that are relatively simple and don't require complex calculations with expensive hardware opens a new gateway for decentralized finance.