Even Spider-Man can't prevent the "double spending" attack? Botanix weaves a security net with spider chains.

Original Title: How Botanix Secures against Double-Spends

Original author: botanixlabs

Source:

Compiled by: Daisy, Mars Finance

How does Botanix prevent double spending attacks?

One of the main challenges facing Bitcoin sidechains is maintaining the balance of capital inflows and outflows between the sidechain and the Bitcoin network. This principle applies to both deposit (anchored in) transactions and withdrawal (anchored out) transactions. Without effective management, the system will quickly fall into asset imbalance due to the occurrence of double-spending transactions and conflicting inputs. Botanix elegantly addresses this issue through Spiderchain— a consortium proof-of-stake chain designed for Bitcoin, based on a rotating multi-signature wallet architecture.

This design naturally gives rise to two types of transactions: anchored deposits and anchored withdrawals. The operation of anchored deposits involves sending BTC to the current multi-signature wallet while minting the corresponding BTC representation asset on Botanix. For anchored withdrawals, users destroy the BTC representation asset on Botanix, and Spiderchain will return the actual BTC using multi-signature UTXO as input. On Botanix, such Bitcoin transactions need to be verified by the multi-signature of the current rotating Spiderchain coordinator. Another key design is that Botanix binds each transaction to the previous transaction and embeds all "conflicting" input data, ensuring that any attempts at duplication or replay will be automatically rejected by the Bitcoin consensus mechanism.

What does "multisignature" mean in this context?

The core here is "multisig". Most web3 users should be familiar with this term—it usually refers to the ability for multiple users to jointly sign a wallet transaction. However, in the context of Botanix, "multisig" (short for multi-signature) specifically refers to Bitcoin addresses that require joint authorization from multiple parties (typically using an n-of-k key model) to execute a transaction.

Each Spiderchain cycle of Botanix creates a new "3 out of 2+" Bitcoin multi-signature wallet (future plans to adjust to 12/16 mode while still maintaining a ratio of over 2/3), jointly controlled by the coordinator nodes. This means that any transaction initiated from this address (e.g., anchor withdrawal) requires signatures from at least 67% of the designated coordinators. These multi-signature wallets will be updated with each Bitcoin block rotation, thus constructing a chain structure for managing BTC deposits and withdrawals.

Therefore, the "multisignature" here is not just a shared wallet—it is also the foundation of Botanix's minimal trust design and a bridge between Bitcoin and its sidechains. This mechanism prevents the possibility of unilateral BTC withdrawals while ensuring the security of the anchoring access process through a rotating pool of verifiable signers. A function that seems simple and even commonplace on other chains plays a crucial role in the Bitcoin ecosystem.

Analysis of the "Conflict Input" Mechanism

The core principle of this mechanism is: the input generated by the previous anchor withdrawal transaction has been spent in the current transaction. According to Bitcoin's UTXO model, once a UTXO is included as an input in a confirmed transaction, it cannot be used again. Botanix takes advantage of this feature—using the output of the previously spent anchor withdrawal as the input for a new anchor withdrawal transaction. Any attempt to broadcast a duplicate anchor withdrawal will violate Bitcoin's double-spending rule and be rejected.

If the coordinator or user attempts to anchor out using the same UTXO repeatedly, the generated transaction will contain "conflicting inputs" (i.e., two transactions trying to spend the same UTXO), rendering it invalid. In other words, spent multi-signature UTXOs cannot be reused, and the system will detect the conflict and reject the repeated transaction.

Specific example:

Let's say the TXn is the last Bitcoin transaction that was pegged out, and its output contains unspent change UTXO Un (for funding the next multisig wallet). When the next anchor takeout occurs, the Botanix coordinator will build a TXn₊₁ transaction with Un as one of the inputs. At this point, Un has been consumed by TXn₊₁. If either party (whether malicious or not) attempts to rebroadcast a copy of TXn₊₁, or construct another transaction that costs Un, the network will recognize that Un has been spent by the first TXn₊₁ and treat subsequent copies as double-spends. Not only can these duplicate transactions not be packaged on-chain, but they can't even be reliably propagated between nodes because Bitcoin's consensus mechanism prohibits secondary spending of the same UTXO. Essentially, the design of using the spent UTXO as input makes all anchor take-out transactions naturally anti-replay, and mechanically ensures the principle of single use.

The mechanism is similar to the Bitcoin transaction chain: each new transaction explicitly spends the outputs of the previous transaction. Identical transactions cannot be confirmed twice, and any new transaction attempting to reuse the same input will be considered invalid. In short, Spiderchain enforces the uniqueness of each anchoring withdrawal through the UTXO model.

Transaction Chain Logic Demonstration:

Previous multi-signature UTXO (M1) → [Anchor Withdrawal Transaction] → User Address (Amount) + New Multi-signature UTXO (M2)

In the next block, M2 becomes the "previously anchored UTXO" and is consumed by the next anchored withdrawal transaction.

Any repeated anchor withdrawal transaction that attempts to spend M2 again will fail because M2 has already been spent.

With this design, two anchored withdrawal transactions cannot spend the same Bitcoin output—since each transaction must include the latest output as an input. Bitcoin nodes will automatically reject any attempts to double-spend that input, whether due to accidental or malicious triggering of a replay transaction, which will immediately become invalid.

Prevent accidental or malicious replay attacks

The design of the conflict input mechanism can prevent both accidental and intentional double-spending withdrawal behaviors. From the perspective of accidental situations, users or nodes cannot create two identical withdrawal transactions, as the second attempt will conflict with the already spent input. From the perspective of malicious attacks, coordinators or external attackers cannot forge a second withdrawal transaction anchored to the same funds. If an attacker attempts to double spend, they must create another Bitcoin transaction that spends the same UTXO; however, since the previous legitimate withdrawal transaction has already consumed that UTXO, any secondary transaction using the same input will be deemed a double spend and will fail.

More importantly, the Botanix governance mechanism will impose penalties on any coordinators attempting to sign or broadcast conflicting anchor withdrawal transactions. The system rules explicitly classify "improper multi-signature on Spiderchain— including signing incorrect anchor withdrawal transactions or participating in double-spending activities" as a violation subject to confiscation of collateral. Since the cross-chain bridge code deterministically constructs complete transactions (inputs, outputs, amounts) through on-chain consensus, operators cannot privately alter the input content. Therefore, if a coordinator intentionally signs a transaction that conflicts with others (such as attempting double-spending), that node will face the risk of having its collateral confiscated.

In this way, Botanix relies on the Bitcoin consensus mechanism (automatically rejecting double-spending transactions) and, through its own mining and penalty rules, ensures the uniqueness constraint of the anchored withdrawals in a dual manner.

Step-by-step analysis of the operational process

After gaining a deep understanding of the underlying mechanisms, let's gradually break down the actual operational process. Although it involves multiple technical aspects, the overall logic is remarkably clear from a macroscopic perspective:

Anchor Deposit (Deposit)

Generate gateway address

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

Transfer BTC to a multi-signature address

Users transfer BTC to the gateway address. The actual funds are controlled by the coordinator in the Spiderchain alliance multi-signature wallet. The original BTC is always locked in the Bitcoin multi-signature address and has not really left the Bitcoin network.

Mint synthetic BTC on EVM

After the deposit transaction receives sufficient confirmations, Sidecar (or the user via the bridging contract) constructs a Merkle inclusion proof and calls the Botanix minting contract on the Spiderchain EVM. This EVM transaction will destroy the on-chain anchored deposit "proof" call and trigger the minting event, and the system will subsequently mint an equivalent amount of synthetic BTC to the user's EVM account (minus Bitcoin and EVM gas fees).

The final result is: users hold synthetic BTC backed 1:1 by BTC locked in a multi-signature wallet by Spiderchain on the Botanix EVM. The spent BTC will appear as new UTXOs in the UTXO set of the multi-signature wallet. Botanix validation nodes monitor the on-chain status through their own Bitcoin instances, update the UTXO set accordingly, and validate the proofs to ensure that each deposit triggers the minting of EVM tokens only once.

Anchor Withdrawal

Destroy on EVM

Users initiate a pegged withdrawal by sending a transaction to destroy synthetic BTC on the Spiderchain EVM. This EVM transaction will deduct (destroy) the specified amount (including EVM gas fees) from the user's balance.

Build Bitcoin trading

The value of the destroyed synthetic BTC needs to be unlocked on the Bitcoin chain. After the coordinator (which also acts as the EVM validation node to obtain this data) detects the destruction event, the designated cycle leader coordinator will aggregate all pending withdrawal requests in the next Bitcoin cycle. According to the rules designed by Spiderchain, UTXOs to be spent are selected from the fund pool - using a last-in-first-out (LIFO) strategy to prioritize the most recently deposited UTXOs, thus protecting early deposits from potential malicious takeovers.

Transaction Construction

The coordinator continuously filters UTXOs until the total value covers the withdrawal amount plus Bitcoin miner fees. It then constructs the raw Bitcoin transaction: inputs are the selected UTXOs, and outputs include (a) the user's target Bitcoin address (to receive the withdrawal amount), and (b) the change output to a new Spiderchain multi-signature address (ensuring that the remaining funds stay within the system).

Threshold Signatures and Broadcasting

After the transaction is constructed, alliance members use FROST key sharding for joint signing. When the ≥t-of-n signature threshold is reached, the complete signed Bitcoin transaction is broadcasted to the Bitcoin network. At this point, the BTC destruction on Spiderchain is officially redeemed as on-chain Bitcoin expenditure, and users ultimately receive BTC after deducting the total fees (EVM destruction amount minus Bitcoin network fees).

Consensus Guarantee and Penalty Mechanism

To ensure a trustworthy environment and maintain the robustness of the mechanism, Botanix simultaneously leverages the simplicity and reliability of Bitcoin along with the advanced capabilities of modern systems. This hybrid solution enhances security through the combination of simplicity and complexity.

On one hand, this mechanism only needs to follow the most basic UTXO/spending rules of Bitcoin: "Once a UTXO is spent, it cannot be reused." This is a fundamental principle in Bitcoin consensus, so the conflicting input mechanism essentially operates based on the existing Bitcoin rules. As long as the coordinator includes the UTXO from the previous transaction in each new anchored withdrawal transaction, Bitcoin nodes will automatically reject any replay or duplicate transactions.

On the other hand, if the coordinator engages in malicious behavior (such as signing a second conflicting transaction to undermine the multi-signature), Botanix's PoS protocol and forfeiture clauses will penalize them. This mechanism effectively curtails potential malicious operations. Essentially, the "conflicting input" strategy directly utilizes the UTXO model itself to enforce the uniqueness of anchored withdrawals—by linking each anchored withdrawal input to the output of the previous transaction, Botanix ensures that only the first valid transaction can succeed, while any duplicate transactions will be naturally rejected by the Bitcoin network due to constituting double spending. This design cleverly prevents accidental duplicate transactions and malicious replay attacks, with its security being doubly ensured by both Bitcoin's consensus rules and Botanix's internal forfeiture mechanism.