One of the most important questions in crypto is the security of funds. This concerns not only user actions but also the security of the protocols themselves and how their architecture is designed. Botanix is built in such a way that user funds are secure at the native level. We designed the Spiderchain architecture with self-sustaining security as a top priority. That’s why we decided to release an article that explores our solution specifically from a security perspective, using plain language instead of dry audit reports or lists of complex technical primitives.

This article consolidates information from previous publications and research to completely answer the question every user cares about: “How does Botanix keep your BTC safe?” To do this, we will first give a high-level overview of what Botanix is and why Bitcoin storage security matters, and then we’ll dive into the details of how Spiderchain works - including orchestrators, multi-signature wallets with advanced threshold cryptography (DKG and FROST), federation and signers rotation.

What Is Botanix and Why Security Matters in Bitcoin Storage

Botanix is an EVM-compatible (Ethereum Virtual Machine) chain built on Bitcoin. Essentially, it brings smart contracts to Bitcoin while inheriting Bitcoin’s native security. We achieve this through a technology we call Spiderchain. It uses a series of decentralized multi-signature wallets to secure funds. Simply put, Botanix allows you to move your BTC into the Botanix environment, where you can use it in DeFi and decentralized applications without compromising on security. Moving Bitcoin is a well-known source of risk if done incorrectly. After all, Bitcoin’s strength lies in its bulletproof security, and we don’t want to lose that advantage. That’s why we designed Botanix from the ground up to protect your deposited BTC as if it were still stored in Bitcoin’s own vault.

You can think of the Bitcoin network as a massive, extremely reliable, ultra-secure vault for your BTC, but one with limited functionality. Botanix’s Spiderchain is like a series of smaller vaults (multi-signature wallets) linked together, each requiring multiple keys to open. No single person or organization holds all the keys, so the chain of vaults remains secure. The security of most protocols can be compared to a complex electronic security system. Botanix security, on the other hand, is more like a physical safe with mechanical safeguards that function independently without needing an external power source.

Additionally, Bitcoin is considered a store of value for a reason. Organizations can go bankrupt, centralized structures are subject to censorship and compromise. But Bitcoin is a self-sustaining system in which user funds are always available. This same idea of antifragility is realized in the design of Botanix.

Spiderchain Security Model: Orchestrators, Multisigs, and the Two-Way Peg

In short, Spiderchain by Botanix is a trustless proof-of-stake system for Bitcoin, built around rotating multi-signature wallets. These wallets act as the storage mechanism for all BTC that enters Botanix. Instead of having a single custodian or address hold your Bitcoin, a group of independent nodes collectively hold it. We call these nodes Orchestrators. Orchestrators form a decentralized network of signers who jointly secure the multisig wallets. These wallets contain the Bitcoin that has been bridged into the network. Since multiple signatures are required to move any funds, no single Orchestrator can run off with the BTC because they must collaborate to execute any transaction.

It’s also important to note that Orchestrators are required to stake collateral in order to participate - this stake acts as a security guarantee. Anyone can become an Orchestrator by staking the required amount of BTC, which means the set of Orchestrators is permissionless and open, not a closed cartel. This design ensures a decentralized community of independent entities managing multisig wallets, rather than a single company or fixed group. Additionally, the stake acts as a deterrent against dishonest behavior. For more details on orchestrators and how the peg-in and peg-out mechanisms work, see the dedicated article “How Botanix Secures against Double-Spends.”

In this way, our Spiderchain functions like a vault with multiple keys. When you deposit BTC, it goes into a vault where the keys are held by several participants (Orchestrators), not by a single custodian. When you withdraw funds, these entities must cooperate to unlock the vault and return your BTC. This federated model, combined with dynamic participation, ensures that no single party ever controls your Bitcoin.

Let’s now discuss one of the most critical challenges for any bridge system: preventing double-spending and ensuring that the BTC pegged to Botanix always corresponds to real BTC held in the vault.

Native Security Level: Preventing Double-Spending via Bitcoin's UTXO Rules

One of the primary risks for bridges and technologies that use wrapped assets is the challenge of preserving the immutability of the underlying asset’s supply. If 100 BTC are deposited into a sidechain or L2, that capacity must remain unchanged. Any event that reduces the amount of BTC would not only cause a depeg but also trigger distrust and cascading user withdrawals from the system. That’s why, as mentioned above, Botanix relies on Bitcoin’s native tools and processes.

One of Bitcoin’s core security guarantees is that no one can spend the same coin twice - double-spend is prevented by Bitcoin’s consensus rules. Botanix extends this guarantee to our peg-in/peg-out process by directly leveraging Bitcoin’s rules. In short, we structure everything so that any attempt to cheat via double-spending a deposit or withdrawal is automatically rejected by Bitcoin itself. We achieve this through a mechanism we call “conflicting input prevention,” or the UTXO chain.

Here’s how it works: each Bitcoin deposit (peg-in) creates a UTXO which is essentially an output in a multisig wallet representing the BTC you sent. When multiple users make deposits, the multisig wallet accumulates multiple UTXOs. Then, when someone requests a withdrawal (peg-out), the Orchestrators create a Bitcoin transaction that spends one or more of these UTXOs to pay out BTC to the user.

The key point is that Botanix links each withdrawal transaction to the next by always using the last unspent output from the previous transaction. In other words, each BTC peg-out transaction includes, as one of its inputs, the change output from the previous peg-out transaction. This creates a transaction chain in which every new peg-out explicitly spends the output of the one before it.

Why do we do this? Because in Bitcoin’s UTXO model, once an output is spent in a confirmed transaction, it cannot be spent again. By linking peg-outs through a shared input/output, we make it impossible to withdraw the same BTC more than once. If an attacker (or faulty node) tries to broadcast a duplicate or conflicting withdrawal transaction, it will use the same UTXO input as the legitimate one. That is, both transactions will have a conflicting input.

Bitcoin nodes immediately recognize this as a double-spend attempt and reject it. Only one of these transactions can be confirmed. In effect, once the first transaction is confirmed, any copy or alternative spend using the same UTXO is automatically invalid. This structurally guarantees that each deposit can only be used once for a withdrawal. And this entire design provides native security without requiring third-party Guardians or any additional external entities.

Let’s look at how this works in practice. Suppose Alice withdraws 1 BTC from Botanix, and the Orchestrators create a Bitcoin transaction TX₁, which sends 1 BTC from the multisig wallet to Alice (minus the fee), and the change is returned to a new multisig address (this change is a new UTXO, let’s call it U₁). Now suppose an attacker (or even Alice herself, by mistake) tries to resend the same TX₁ or a modified version of it - they will inevitably attempt to spend U₁ again. But U₁ has already been spent in TX₂ (the next transaction in the chain, which the Orchestrators will create during the next withdrawal). So any attempt to replay or double-spend Alice’s TX₁ withdrawal is futile; Bitcoin’s consensus will reject the second spend of U₁ as invalid. In short, once a peg-out is completed, it’s final - it cannot be duplicated or replayed.

In this way, the mechanism elegantly maintains system balance: the amount of BTC represented in Botanix will always match the amount of BTC held in the multisig vault, because no UTXO can be spent twice. Double-spending or replaying a withdrawal isn’t just disallowed - it’s cryptographically prevented by Bitcoin itself. Still, we don’t rely solely on Bitcoin’s rules. Botanix adds an extra layer of protection through an incentive system. Our protocol slashes (confiscates) the stake of any Orchestrator caught even attempting to sign a conflicting or invalid withdrawal transaction. Since all withdrawal transactions are deterministically generated via on-chain consensus (Orchestrators cannot secretly craft an alternative transaction; everyone knows exactly what a valid transaction must look like), any Orchestrator who signs something else is essentially signing their own punishment. Their staked BTC can be seized if they break the rules or attempt to facilitate a double-spend. In practice, this makes malicious behavior extremely irrational. The malicious player can lose much more (their stake) than they gain.

So, on one hand, double-spends are ruled out by the enforced consensus of Bitcoin. On the other hand, by Orchestrator rotation mechanics and Botanix’s penalty system. Your BTC cannot be withdrawn unlawfully or twice, and the peg remains strictly 1:1. Now that we’ve covered how fraudulent transactions are prevented, let’s take a look at the cryptography that makes multisig secure. Specifically, how we generate and use the keys that initially control the BTC.

Federation Security: Decentralized by Design

The Spiderchain architecture uses a federated model. The term federation refers to a group of validator nodes called Orchestrators. Instead of a single custodian or a small fixed group, we launched a federation that currently consists of 16 independent node operators (with plans to scale to around 100 or more in the future). These node operators include well-known Bitcoin miners, holders, and validators. Botanix operates only one of these nodes. This approach ensures full decentralization from the very beginning. Each participant performs the standard duties of an Orchestrator, but they also collaborate to manage decentralized storage and movement of BTC. This structure guarantees that no single entity controls the bridge; from the outset, keys are distributed across diverse stakeholders, ensuring full decentralization of custody.

The uniqueness of the Botanix federation lies in its dynamic and randomly rotating nature, rather than being a static multisig group. Botanix leverages the unpredictability of Bitcoin itself (the SHA-256 block hash) as a source of randomness, using a verifiable random function (VRF) for unbiased selection of signers. This continuous reshuffling of the federation means that the “active” multisig signers are always changing. At any given moment, a majority of 12 out of 16 participants from that federation round are required to approve any BTC movement. Once funds move to the next address, the federation rotates again.

This dynamic federation model provides far greater decentralization and security compared to static or permissioned multisigs. In a traditional federated sidechain (such as Liquid), the signers are a fixed group of institutions, and adding or removing members is a manual, coordinated process - by nature, a closed and permissioned design. In contrast, the Botanix federation is open and fluid: any participant who meets the staking requirements can become an Orchestrator, and membership in each signing round is determined by algorithmic randomness, rather than by a central authority.

Mathematical Security: Threshold Cryptography (DKG and FROST). Many Keys, One Secure Signature

The next critical component of Botanix’s self-sustaining security is a combination of protocols that enable multisig functionality. When you hear “multisignature wallet”, you might picture something like a 2-of-3 or 3-of-5 scheme, where a few known participants hold keys. Botanix’s multisig is far more advanced. We use cutting-edge threshold cryptography to allow a large group of Orchestrators (around 100 participants) to collectively control funds, with none of them ever knowing the full private key. It’s as if each Orchestrator is given a fragment of the key, useless on its own, but which can unlock the vault only when combined with enough other fragments.

That’s why we’ve built a system that runs on pure mathematics. On one hand, it’s complex mathematical computation. On the other - it’s pure math that works on its own and requires no additional verification.

Each time we need a new multisignature address (since they are continuously rotated), the selected Orchestrator nodes for that round conduct a Distributed Key Generation (DKG) ceremony. DKG is a protocol that allows N participants to jointly generate a public/private key pair in such a way that none of them ever learns the private key itself. Instead, each Orchestrator receives a secret share of the key. For example, if there are 16 Orchestrators and the threshold is set to 12, each of the 16 gets a part of the secret, and any 12 of them together can create a valid signature. But if it turns out to be 11 or fewer parts - then simply nothing happens. At Botanix, our goal is something like a 12-of-16 multisig (i.e., at least 75% of the keys) to spend funds. DKG ensures that when a multisignature address is created, no single Orchestrator or small group possesses the full key; it is truly distributed. The corresponding Bitcoin address (the public key) is known and can be used for deposits, but the private key exists only in a threshold sense (split among participants).

After setting up the keys using DKG, the Orchestrators use another technology called FROST (Flexible Round-Optimized Schnorr Threshold Signatures) to actually sign transactions. FROST is a clever method that allows multiple parties to collaboratively produce a single aggregated digital signature on a transaction, efficiently and privately. You can explore more about how DKG and FROST work in detail in the separate article “Botanix’s Spiderchain: DKG & FROST”.

To simplify, we use threshold cryptography to make storing BTC in Botanix truly collaborative and trust-minimized:

• No single person ever holds the keys. Keys are generated collectively (via DKG), so each Orchestrator only has a fragment of the secret. Signing anything requires collective agreement. 

• Signatures are aggregated. Multiple Orchestrators collaborate to produce a single signature (using FROST), which is valid on the Bitcoin network and indistinguishable from a regular single-party signature.

• High security threshold. We require more than two-thirds (e.g., 12 out of 16, and eventually around 100 participants) of Orchestrators to sign a withdrawal. For an attacker to steal funds, they would need to compromise a supermajority of participants simultaneously, which is extremely unlikely. If only a minority is compromised, they cannot produce a valid transaction, and the BTC remains locked (honest nodes will halt operations and trigger emergency safeguards if anything abnormal happens).

• Signer rotation. The set of Orchestrators (and therefore the key shares) is continuously rotated. This means even if someone manages to get into the signer group at some point, they won’t stay there permanently. It’s like regularly changing the locks after each use. This eliminates potential attack vectors from malicious actors. Older funds are protected by keys that new attackers had no part in generating. Such rotation adds a powerful layer of security: even a group of attackers cannot sit in place and slowly erode the system. The participant set changes constantly and unpredictably.

Essentially, Botanix uses multi-party magic (or more specifically, math and cryptography) to protect your Bitcoins. BTC in the Spiderchain vault can only move if enough independent, randomly selected participants agree and cooperate using their shares of keys. If someone tries to cheat or use the wrong inputs, Bitcoin's own rules and our penalties are triggered, along with the natural mechanics of self-sustaining security to stop it. This can be compared to if you were using a mechanical watch instead of an electronic watch. Simple mechanics and physics with a subtle approach to design allows for amazing reliability.

Conclusion

In closing, we want to emphasize that at Botanix, we are Bitcoiners at heart. We know that trusting a third party or a new chain with your BTC is a big ask, so we engineered Spiderchain to minimize the trust required. By using multi-signature mechanism with a decentralized, stake-based validator set, by enforcing Bitcoin’s one-way UTXO rules to stop double-spends, and by leveraging threshold cryptography (DKG/FROST) with rotating keys and federation model, we’ve built a system where your Bitcoin is safe. No single entity can run off with the funds. And any malicious attempt is stopped both by consensus rules and by harsh economic penalties.

We hope this explainer sheds light on how Botanix keeps your BTC secure while allowing you to use it in exciting new ways on our EVM-compatible chain. Security isn’t just a feature of Botanix – it’s the foundation. We like to say that Botanix offers the best of both worlds: the innovation and flexibility of smart contracts, alongside with the robust security of the Bitcoin network. If you have any questions or want to learn more about the technical specifics, we encourage you to check out our documentation and community channels.

Thank you for reading, and we look forward to seeing what you build with Bitcoin on Botanix – confidently, knowing your BTC is safe with us.