How Botanix Prevents Double Spending

Author: Botanix Chinese

One of the main challenges for Bitcoin Chains is maintaining a balance of funds flowing in and out between the chain and the Bitcoin mainnet. This applies to both peg-in and peg-out transactions. If these fund flows are not properly managed, the system will quickly face asset imbalances, leading to issues such as double-spending transactions and conflicting inputs. Botanix elegantly addresses this challenge through Spiderchain. Spiderchain is a federated proof-of-stake Bitcoin chain built by Botanix based on a rotating multi-signature wallet structure.

As a result, this design creates two types of transactions: peg-in (locking Bitcoin) and peg-out (unlocking Bitcoin). A peg-in operation involves sending BTC to the current multi-signature wallet and minting a corresponding BTC representation asset on Botanix. In a peg-out operation, users will destroy the BTC representation asset on Botanix, and Spiderchain will use the unspent transaction outputs (UTXO) in its multi-signature wallet as inputs to return actual BTC to the users. On Botanix, this Bitcoin transaction is signed by a multi-signature group composed of the current rotating Spiderchain coordinators.

Another key mechanism is that Botanix links each transaction to the previous one and embeds any potentially "conflicting" inputs, ensuring that any attempts at duplication or replay will be automatically rejected by the Bitcoin consensus mechanism.

What does multi-signature mean in this context?

In this context, "multi-signature" is a key concept. Web3 users may be familiar with this term, which typically refers to the ability for multiple users to jointly manage the same wallet and sign transactions. Here, "multisig" (an abbreviation for multi-signature) refers to a type of Bitcoin address that can only execute transactions when multiple key holders (usually in an n-of-m configuration, meaning at least n signatures out of m) jointly authorize it.

In Botanix, each Spiderchain epoch creates a new Bitcoin multi-signature wallet, currently in a 2-of-3 format (with plans to expand to 12-of-16 in the future, meaning more than two-thirds of signers), controlled by orchestrator nodes. This means that any transaction initiated from that address (such as a peg-out withdrawal) must obtain signatures from at least 67% of the coordinator nodes. These multi-signature wallets rotate with each Bitcoin block, forming a custodial chain for BTC deposits and withdrawals.

Thus, "multi-signature" here is not just a shared wallet; it is the cornerstone of Botanix's trustless design and serves as a bridge between it and the Bitcoin mainnet. It ensures that no single party can unilaterally withdraw BTC while implementing a peg-in/peg-out process secured by a verifiable, rotating group of signers. A seemingly common mechanism plays an extremely important role in the Bitcoin context.

Conflict Input Mechanism

The core idea of this mechanism is that the input (UTXO) used in the previous peg-out has already been spent in the current transaction. In Bitcoin's UTXO model, once a UTXO is confirmed as an input for a transaction, it cannot be used again. Botanix leverages this feature: each new peg-out uses the remaining output (change UTXO) from the last peg-out as an input for the current transaction, ensuring that any duplicate broadcasted peg-out transactions will violate Bitcoin's double-spending rules and be rejected.

If a coordinator or user attempts to perform a peg-out operation using the same UTXO again, the generated transaction will contain "conflicting inputs" (i.e., two transactions attempting to spend the same UTXO), rendering the transaction invalid. In other words, already spent multi-signature UTXOs cannot be reused, and the system will detect the conflict and reject the duplicate operation.

For example:

Assume TXₙ is the Bitcoin transaction from the last peg-out, and its output contains an unspent change UTXO, denoted as Uₙ (this change UTXO is used for the next round of multi-signature wallets). In the next peg-out, Botanix's coordinator will construct TXₙ₊₁ and use Uₙ as one of the inputs. At this point, Uₙ has been spent by TXₙ₊₁. If a malicious actor or an error broadcasts a copy of TXₙ₊₁ again or creates a new transaction that also uses Uₙ, the network will recognize that Uₙ has already been used by the previous TXₙ₊₁ and will treat subsequent transactions as double-spending transactions. This transaction cannot be packed into a block and is unlikely to be successfully broadcasted in the network because Bitcoin's consensus rules prohibit the repeated spending of the same UTXO.

Essentially, a peg-out transaction is inherently "non-replayable" because it uses a spent UTXO as input, ensuring that each withdrawal can only be used once.

This mechanism is similar to Bitcoin's transaction chain structure: each output explicitly spends the previous output. Duplicate (exactly the same) transactions cannot be confirmed again, and any new transaction attempting to use the same input will also be deemed invalid.

In short, Spiderchain utilizes Bitcoin's UTXO model to enforce the uniqueness of each peg-out.

Here is a logical illustration of the peg-out transaction input-output chain:
● Previous multi-signature wallet output (M1) → [peg-out transaction] → User address (withdrawal amount) + New multi-signature wallet output (M2)
● In the next block, M2 becomes "the output of the previous peg-out" and serves as the input for the next peg-out.
● If there is a duplicate peg-out transaction attempting to spend M2 again, the attempt will fail since M2 has already been used.
With this design, no two peg-out transactions can use the same Bitcoin output because each transaction references the previous output as input. Bitcoin network nodes will automatically reject any transactions that attempt to reuse that input, so whether accidental or malicious replay actions cannot succeed.

Preventing Accidental or Malicious Replay

The "conflicting input" mechanism not only prevents malicious attacks but also effectively addresses unintentional duplicate operations by users or nodes.

In accidental situations, users or nodes cannot create two identical withdrawal (peg-out) transactions because the second attempt will conflict due to its use of already spent inputs, rendering the transaction invalid.

In malicious attack scenarios, coordinators or external attackers cannot forge a second withdrawal transaction targeting the same funds. To execute a double-spending attack, an attacker must create a Bitcoin transaction attempting to spend the same UTXO again; however, since that UTXO has already been used in a valid transaction, any second transaction using the same input will be recognized by the Bitcoin network as double-spending and marked as invalid.

Additionally, Botanix's governance mechanism will penalize any coordinator attempting to sign or broadcast conflicting peg-out transactions. The system rules consider "improperly signing multi-signature transactions in Spiderchain—whether signing incorrect withdrawal transactions or participating in double-spending behavior" as punishable (slashing) violations.

Since the cross-chain bridge code deterministically constructs complete transactions (including inputs, outputs, amounts, etc.) through on-chain consensus, operating nodes cannot privately tamper with transaction inputs. Therefore, if a coordinator intentionally signs a transaction that conflicts with another transaction (for example, attempting to double-spend), their node will face the risk of having their staked assets forfeited.

Through this mechanism, Botanix not only relies on Bitcoin's consensus mechanism (which automatically rejects double-spending transactions) to ensure security but also strengthens the strong constraints on unique peg-out behavior through its own consensus and penalty mechanisms (such as slashing).

Step-by-Step Analysis of How It Works

After understanding the overall logic of the Botanix mechanism, let’s outline the Peg-In (deposit) and Peg-Out (withdrawal) processes in more specific steps. Although multiple technical modules are involved in each step, the operation of this system is quite clear from a macro perspective:

Peg-In (Deposit Process)

1. Generate Gateway Address

The Botanix protocol derives a unique Taproot gateway address by combining the federated FROST public key with the user's Ethereum address.

2. Transfer BTC to Multi-Signature Address

Users deposit BTC into the generated gateway address. Essentially, this BTC is sent to a Spiderchain federated multi-signature wallet controlled by orchestrators. At this point, the BTC has not left the Bitcoin mainnet but is locked in the multi-signature address.

3. Mint Synthetic BTC on EVM

Once the deposit transaction receives sufficient confirmations, Sidecar (or the user through the bridge) generates a Merkle proof and calls the Botanix minting contract on the Spiderchain EVM. This EVM transaction consumes the deposit "proof" and triggers a Mint event, after which the system issues synthetic BTC to the user's EVM account at a 1:1 ratio (minus Bitcoin and EVM gas fees).

Result: The user receives an equivalent amount of synthetic BTC on the Botanix EVM, backed by the real BTC locked in the Spiderchain multi-signature wallet.

Botanix's validators run independent Bitcoin nodes to track the on-chain UTXO status and verify transaction proofs, ensuring that each deposit mints tokens only once.

Peg-Out (Withdrawal Process)

1. Destroy Tokens on EVM

Users initiate a transaction through the Spiderchain EVM to destroy their held synthetic BTC. This transaction will deduct the corresponding amount from the user's balance (minus EVM gas fees).

2. Construct Bitcoin Withdrawal Transaction

Now, the real BTC corresponding to the destroyed synthetic BTC needs to be released from the Bitcoin mainnet. The coordinator nodes monitor the destruction event (as they are also EVM validators), and at the start of the next Bitcoin epoch, the rotating coordinator will collect all pending withdrawal requests.

According to Spiderchain's design, it will select the corresponding UTXO from the available UTXO pool. Botanix uses a "last in, first out" (LIFO) strategy, prioritizing the most recently deposited UTXO to protect earlier deposited assets from potential malicious actions.

3. Construct Raw Bitcoin Transaction

The coordinator will continue selecting UTXOs until their total is sufficient to cover the user's withdrawal amount and miner fees. Then, a raw Bitcoin transaction is constructed with the following structure:
● Inputs: Selected UTXOs
● Outputs:
○ User's BTC address (withdrawal amount)
○ Change address (newly generated Spiderchain multi-signature address)

4. Threshold Signing and Broadcasting

Once the transaction is constructed, all federated members will use their respective FROST key shares to jointly sign it. When t-of-n (for example, 12-of-16) signatures are completed, the transaction is fully signed and broadcasted to the Bitcoin network.

Final Result: After the user's Spiderchain synthetic BTC is destroyed, the corresponding BTC is released from the multi-signature wallet and sent to the user's specified Bitcoin address. The amount of BTC received by the user equals the destroyed amount minus the Bitcoin network miner fees.

This process ensures that Botanix's bidirectional bridge operation is both secure and verifiable, combining the flexibility of the EVM with the immutability of the Bitcoin UTXO model to provide a clear structure and reliable mechanism for cross-chain asset systems.

Consensus Assurance and Penalty Mechanism

To maintain a trustworthy operating environment and ensure the robustness of the entire mechanism, Botanix combines the simplicity and reliability of Bitcoin with the advanced capabilities of modern systems. This hybrid design significantly enhances overall security by combining "simplicity" with "complexity."

On one hand, Botanix does not need to introduce any special Bitcoin consensus rules but directly relies on Bitcoin's native UTXO rules: "Once a UTXO is spent, it cannot be used again."
This is a fundamental validation logic in Bitcoin's consensus mechanism, so Botanix's "conflicting input mechanism" can naturally build upon this rule. As long as coordinators always include the UTXO from the last peg-out as input in each new peg-out transaction, the Bitcoin network will automatically reject any replayed or duplicate transactions, deeming them invalid.

On the other hand, if a coordinator behaves maliciously (for example, attempting to sign a second conflicting transaction that disrupts the multi-signature logic), Botanix's PoS protocol and slashing mechanism will penalize that coordinator. This mechanism effectively suppresses potential malicious behavior from an incentive perspective.

Essentially, the conflict input mechanism leverages Bitcoin's UTXO model to enforce the "one-time withdrawal" rule. By linking each peg-out's input to the output of the previous peg-out, Botanix ensures that only the first valid transaction can be successfully executed, while any duplicate transactions will be treated as double-spending and automatically rejected by the Bitcoin network.

This mechanism elegantly prevents both accidental duplicate transactions and malicious replay attacks, with its security relying on Bitcoin's native consensus rules on one hand and being reinforced by Botanix's internal proof-of-stake (PoS) consensus and penalty system on the other.