One of the main challenges for Bitcoin Chains is to keep a balance of inbound and outbound funds between Chain and Bitcoin. This applies to both deposit (peg-in) transactions and withdrawal (peg-out) transactions. If these flows are not managed - the system will quickly develop an asset imbalance with the emergence of double-spending transactions and conflicting inputs. Botanix gracefully solves this with Spiderchain. Botanix's Spiderchain is a federated Proof-of-Stake chain for Bitcoin, built on a rotating multi-signature wallet structure.

Thus, this design results in two types of transactions: peg-ins and peg-outs. Peg-ins operate by sending BTC to the current multisig wallet and minting a representation of those BTC on Botanix. For peg-outs, users burn the BTC representation on Botanix, and the Spiderchain uses the multisig UTXOs as inputs to send the actual BTC back. On Botanix, this Bitcoin transaction is signed by the current multisig of the Spiderchain coordinators. Another important aspect is that Botanix links each transaction to the previous one, embedding any “conflicting” input to ensure that any attempt at duplication or replay is automatically rejected by Bitcoin consensus.

What Does Multisig Mean in This Context?

The significant part in this case is multisig. Most likely, this term is familiar to most web3 users as the ability for multiple users to sign transactions in one wallet. In this context, “multisig” (short for multi-signature) refers to Bitcoin addresses that require joint authorization from multiple parties (typically n-of-m keys) to execute any transaction from that address.

In Botanix, each Spiderchain epoch creates a new more than 2-of-3 Bitcoin multisig wallet (In the future it is planned to change this proportion to 12/16, which will be more than 2/3), controlled by orchestrator nodes. This means that any transaction (e.g., a peg-out) spending from this address requires signatures from at least 67% of the designated orchestrators. These multisig wallets rotate with each Bitcoin block, forming a custodial chain for BTC deposits and withdrawals.

Thus, “multisig” in this case is more than just a shared wallet—it is the foundation of Botanix’s trust-minimized design and the bridge between Bitcoin and its chain. It ensures that no single party can unilaterally withdraw BTC and enables a peg-out/peg-in process secured by a rotating, verifiable group of signers. Therefore, a seemingly fairly simple and well-known feature for most chains, plays a tremendous role in the case of Bitcoin.

The "Conflicting Input" Mechanism

The key insight behind this mechanism is that the input derived from the previous peg-out is already spent in the current transaction. In Bitcoin’s UTXO model, once a UTXO is included as an input in a confirmed transaction, it cannot be spent again. Botanix leverages this property: by including the spent output from the previous peg-out as an input in the new peg-out, any attempt to broadcast a duplicate peg-out transaction would violate Bitcoin’s double-spend rules and be rejected.

If an orchestrator or user tries to repeat the peg-out using the same UTXO, the resulting transaction will contain "conflicting inputs" (i.e., two transactions attempting to spend the same UTXO) and will be invalid. In other words, a spent multisig UTXO cannot be reused; the system detects the conflict and rejects the duplicate.

For example, suppose TXₙ is the Bitcoin transaction for the last peg-out. Its output includes an unspent change UTXO Uₙ (which funds the next multisig). When the next peg-out occurs, Botanix orchestrators construct TXₙ₊₁, which includes Uₙ as one of its inputs. At this point, Uₙ is consumed by TXₙ₊₁. If any party (malicious or otherwise) attempts to rebroadcast a second copy of TXₙ₊₁—or an alternative transaction that spends Uₙ—the network will recognize that Uₙ was already spent by the first TXₙ₊₁ and will treat the second copy as a double-spend. The duplicate simply cannot be mined or even reliably propagated, as Bitcoin consensus prohibits spending the same UTXO more than once. Essentially, having an already-spent UTXO as an input makes any peg-out transaction non-replayable, enforcing single-use by design.

This mechanism is analogous to a Bitcoin transaction chain: each new output explicitly spends the previous one’s output. A duplicate (identical) transaction cannot be confirmed twice, and any new transaction attempting to reuse the same inputs will be deemed invalid under Bitcoin’s rules. In short, Spiderchain uses the UTXO model to enforce the uniqueness of each peg-out.

Below is a logic showing how inputs/outputs link peg-out transactions:

- Previous multisig UTXO (M1) → [Peg-out TX] → User address (amount) + New multisig UTXO (M2).

- In the next block, M2 becomes the "previous peg-out UTXO," which is consumed by the next peg-out TX.

- Any duplicate peg-out TX will attempt to spend M2 again, but since M2 has already been spent, the attempt will fail.

By design, two peg-out transactions cannot spend the same Bitcoin output, because each one includes the latest output as an input. Bitcoin nodes will reject any transaction that tries to double-spend this input, so accidental or malicious replays are automatically invalidated.

Preventing Accidental or Malicious Replays

The conflicting input design protects against both accidental and intentional duplicate peg-outs. Accidentally, a user or node cannot create two identical withdrawals, since the second attempt would conflict with an already-spent input. Maliciously, an orchestrator or external attacker cannot forge a second peg-out for the same funds. To attempt a double-spend, the attacker would need to create a second Bitcoin transaction that spends the same UTXO; but since the valid transaction has already consumed the UTXO from the previous peg-out, any second transaction with the same input would be treated as a double-spend and deemed invalid.

Moreover, Botanix governance penalizes any orchestrator that attempts to sign or broadcast conflicting peg-out transactions. The system rules treat “improper multisig signing in the Spiderchain—either signing the wrong peg-out transaction or participating in a double-spend”—as a slashable offense. Since the bridge code deterministically constructs the complete transaction (inputs, outputs, amounts) via on-chain consensus, operators cannot secretly alter the inputs. Therefore, if an orchestrator deliberately signs a transaction that conflicts with another (e.g., an attempted double-spend), that node risks forfeiting its collateral. In this way, Botanix enforces the unique-peg-out constraint both through Bitcoin consensus (which rejects double-spends) and through its own mining and slashing rules.

How it works step-by-step:

At this point, having explored the inner workings of this mechanism and gained a high-level understanding, let’s take a closer look at how it functions step by step. Despite the many interconnected technical processes, the overall picture becomes surprisingly straightforward when seen in broader terms:

Peg-In (Deposit)

1. Generate a Gateway Address. The Botanix protocol derives a unique taproot “gateway” address for the user by combining the federation’s FROST public key with the user’s Ethereum address.

2. Send BTC to the MultiSig. The user funds this gateway address with BTC. In reality this sends the BTC into the Spiderchain’s federated multi-signature wallet controlled by the orchestrators.. The original BTC remains locked in these Bitcoin multisig addresses; nothing is transferred out of Bitcoin yet.

3. Mint Synthetic BTC on EVM. Once the deposit transaction has sufficient confirmations, the Sidecar (or the user via the Bridge) builds a Merkle inclusion proof and calls the Botanix Minting contract on the Spiderchain EVM. This EVM transaction burns the on-chain peg-in “proof” call and emits a Mint event, after which the system mints an equal amount of synthetic BTC (minus the Bitcoin and EVM gas fees) to the user’s EVM account.

The result is that the user now holds synthetic BTC on the Botanix EVM, backed 1:1 by the locked Bitcoin in the Spiderchain multisig. The spent BTC appears as new UTXOs in the multisig wallet’s UTXO set. Botanix validators have their own Bitcoin instance to monitor the Bitcoin and update their UTXOs set accordingly. and verifying the proofs so that the corresponding EVM tokens are only minted once per deposit

Peg-Out (Withdraw)

1. Burn on EVM. The user initiates a peg-out by sending a transaction on the Spiderchain EVM to burn their synthetic BTC. This EVM tx deducts (burns) the requested amount (minus the EVM gas fee) from the user’s balance.

2. Build Bitcoin TX. The orphaned synthetic BTC value now needs to be unlocked on Bitcoin. The orchestrators detect the burn event (since orchestrators are also EVM validators, so they can see this data). At the next Bitcoin epoch, a designated epoch leader orchestrator gathers all pending peg-out requests. Following the Spiderchain design, it selects which UTXOs from the pool to spend. Botanix uses a Last-In-First-Out (LIFO) strategy: it will spend the most recently deposited (youngest) UTXOs first. This protects older deposits against a hypothetical malicious takeover.

3. In practice, the orchestrator keeps selecting UTXOs until their total value covers the withdrawal amount plus the Bitcoin miner fee. It then constructs a raw Bitcoin transaction: the inputs are the selected UTXOs, and the outputs include (a) the user’s target Bitcoin address for the withdrawal amount, and (b) a change output sending any leftover back into a new Spiderchain multisig address (ensuring the change remains in the Spiderchain).

4. Threshold Signing & Broadcast. Once the transaction is constructed, all federation members jointly sign it using their FROST key shares. With ≥t-of-n signatures completed, the fully-signed Bitcoin transaction is broadcast to the Bitcoin network. At that point, the burn of BTC in the Spiderchain has been realized as an on-chain Bitcoin spend. The user ultimately receives the requested BTC minus the combined fees: specifically, the net peg-out amount is the burned amount on EVM, minus the Bitcoin network fee.

Ensuring Consensus and Slashing

To maintain a trustworthy environment and ensure the robustness of the mechanism, Botanix leverages both the simplicity and reliability of Bitcoin and the advanced capabilities of more modern systems. This hybrid approach strengthens security by combining the simple with the sophisticated.

On the one hand, no special Bitcoin consensus rules are required beyond the standard UTXO/spending rule: “Once a UTXO is spent, it cannot be spent again.” This is a fundamental check within Bitcoin’s consensus, so the conflicting input mechanism simply relies on Bitcoin’s existing rules. As long as orchestrators include the previous peg-out UTXO in each new peg-out transaction, Bitcoin nodes will automatically reject any replay or duplication as invalid.

On the other hand, if an orchestrator behaves maliciously (e.g., signs a second, conflicting transaction to subvert the multisig), Botanix’s PoS protocol and slashing conditions will penalize that orchestrator. This is a good incentive to rule out possible malicious behavior. In essence, the "conflicting input" strategy leverages the UTXO model itself to enforce one-time peg-outs. By chaining each peg-out’s input to the output of the previous peg-out, Botanix guarantees that only the first valid transaction can succeed; any duplicate is a double-spend and naturally rejected by the Bitcoin network. This elegantly prevents both accidental duplicate transactions and malicious replay attacks, with security backed by both Bitcoin’s consensus rules and Botanix’s internal slashing incentives.