This article is provided by Botanix and does not represent the views of Wu Blockchain
One of the main challenges for Bitcoin Chains is maintaining a balance of funds flowing in and out of the chain to the Bitcoin mainnet. This applies to both peg-in and peg-out transactions. If these flows are not managed properly, the system will quickly become imbalanced, leading to issues with double spend transactions and conflicting inputs. Botanix elegantly solves this problem with Spiderchain, a federated Proof-of-Stake Bitcoin chain built by Botanix based on a rotating multi-signature wallet structure.
Therefore, the design forms two types of transactions: peg-in (locking Bitcoin) and peg-out (unlocking Bitcoin). The peg-in operation is to send BTC to the current multi-signature wallet and mint the corresponding BTC representation asset on Botanix. In the peg-out operation, the user will destroy the BTC representation asset on Botanix, and Spiderchain will use the unspent transaction output (UTXO) in its multi-signature wallet as input to return the actual BTC to the user. On Botanix, this Bitcoin transaction is signed by a multi-signature group consisting of the current rotating Spiderchain coordinator.
Another key mechanism is that Botanix links each transaction to the previous one and embeds any potentially “conflicting” inputs, ensuring that any attempt to copy or replay is automatically rejected by the Bitcoin consensus mechanism.
In this context, "multi-signature" is the key concept. Web3 users may be familiar with this term, which usually refers to the ability of multiple users to jointly manage the same wallet and sign transactions. In this context, "multisig" (short for multi-signature) refers to a type of Bitcoin address that can only execute transactions if multiple key holders (usually n-of-m, that is, at least n signatures out of m) jointly authorize it.
In Botanix, a new Bitcoin multi-signature wallet is created for each Spiderchain epoch, currently in the form of more than 2-of-3 (planned to expand to 12-of-16 in the future, i.e. more than two-thirds of the signers), controlled by the orchestrator node. This means that any transaction initiated from this address (such as 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 access.
Therefore, the "multi-signature" here is not only a shared wallet, but also the cornerstone of Botanix's trustless design and a bridge between it and the Bitcoin mainnet. It ensures that no single party can withdraw BTC without authorization, while realizing the peg-in/peg-out process guaranteed by a verifiable and rotating group of signers. A seemingly common mechanism plays an extremely important role in the Bitcoin scenario.
The core idea of this mechanism is that the input (UTXO) used in the previous peg-out has been spent in the current transaction. In Bitcoin's UTXO model, once a UTXO is used as an input in a confirmed transaction, it cannot be used again. Botanix takes advantage of this feature: each new peg-out uses the remaining output (change UTXO) of the previous peg-out as the input of the current transaction, ensuring that any repeated broadcast peg-out transactions will violate Bitcoin's double-spending rules and be rejected.
If a coordinator or user attempts to perform repeated peg-out operations with the same UTXO, the resulting transaction will contain "conflicting inputs" (i.e. two transactions attempting to spend the same UTXO), and therefore the transaction will be invalid. In other words, a multi-signature UTXO that has already been spent cannot be reused, and the system will detect the conflict and reject the repeated operation.
For example:
Assume that TXₙ is the last pegged-out Bitcoin transaction, and its output contains an unspent change UTXO, denoted as Uₙ (this change UTXO is used for the next round of multi-signature wallets). At the next peg-out, the coordinator of Botanix will construct TXₙ₊₁ and use Uₙ as one of the inputs. At this time, Uₙ is spent by TXₙ₊₁. If a malicious person or mistakenly broadcasts a copy of TXₙ₊₁ again at this time, or creates a new transaction that also uses Uₙ, the network will recognize that Uₙ has been used by the previous TXₙ₊₁ and will treat subsequent transactions as double-spending transactions. This transaction cannot be packaged into a block and is difficult to successfully broadcast on the network because Bitcoin's consensus rules prohibit repeated spending of the same UTXO.
Essentially, a peg-out transaction is inherently “non-replayable” because it uses 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 (identical) transactions cannot be confirmed again, and any new transaction that attempts to use the same input will be considered invalid.
In short, Spiderchain leverages Bitcoin's UTXO model to enforce the uniqueness of each peg-out.
The following is a schematic diagram of the logic of the peg-out transaction input and 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 of the next peg-out.
● If there is a duplicate peg-out transaction trying to spend M2 again, the attempt will fail because M2 has already been used.
By design, no two peg-out transactions can use the same Bitcoin output, because each transaction references the previous output as input. Bitcoin network nodes automatically reject any transaction that reuses the input, so neither accidental nor malicious replay can succeed.
The "conflicting input" mechanism not only prevents malicious attacks, but also effectively deals with unintentional repeated operations by users or nodes.
In unexpected circumstances, a user or node cannot create two identical peg-out transactions, as the second attempt would conflict because it uses an already spent input, rendering the transaction invalid.
In a malicious attack scenario, the coordinator or external attacker cannot forge a second withdrawal transaction for the same funds. In order to perform a double spend attack, the attacker must create a Bitcoin transaction that attempts to spend the same UTXO again ; but because the UTXO has been used by a valid transaction, any second transaction using the same input will be recognized by the Bitcoin network as a double spend and marked as invalid.
In addition, Botanix’s governance mechanism penalizes any coordinator who attempts to sign or broadcast a conflicting peg-out transaction. The system rules consider “improperly signing a multi-signature transaction in Spiderchain — whether signing an incorrect withdrawal transaction or engaging in double spending” as a slashing violation.
Since the cross-chain bridge code will deterministically construct a complete transaction (including input, output, amount, etc.) through on-chain consensus, the operating node cannot privately tamper with the transaction input. Therefore, if a coordinator deliberately signs a transaction that conflicts with another transaction (such as attempting to double spend), his node will face the risk of having the pledged assets confiscated.
Through this mechanism, Botanix not only relies on Bitcoin's own consensus mechanism (automatically rejecting double-spending transactions) to ensure security, but also further strengthens the strong constraints on unique peg-out behavior through its own consensus and punishment mechanisms (such as slashing).
After understanding the overall logic of the Botanix mechanism, let's sort out the Peg-In (recharge) and Peg-Out (withdrawal) processes in more specific steps. Although each step involves multiple technical modules, from a macro perspective, the operation of this system is actually quite clear:
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 a multi-signature address
The user deposits BTC into the gateway address generated above. In essence, these BTC are sent to the Spiderchain federated multi-signature wallet controlled by orchestrators. At this time, BTC does not leave the Bitcoin mainnet, but is locked in the multi-signature address.
3. Minting synthetic BTC on EVM
Once the deposit transaction receives enough confirmations, the Sidecar (or the user through the bridge) generates a Merkle inclusion proof and calls the Botanix minting contract on the Spiderchain EVM. The EVM transaction consumes the deposit "proof" and triggers the Mint event, and the system then distributes the synthetic BTC to the user's EVM account at a 1:1 ratio (minus Bitcoin and EVM fuel fees).
Result : Users receive an equivalent value of synthetic BTC on the Botanix EVM, backed by real BTC locked in the Spiderchain multi-signature wallet.
Botanix validators run independent Bitcoin nodes to track the UTXO status on the chain and verify transaction proofs to ensure that tokens are minted only once for each deposit.
1. Destroy tokens on EVM
The user initiates a transaction through Spiderchain EVM to destroy the synthetic BTC he holds. This transaction will deduct the corresponding amount from the user's balance (minus the EVM gas fee).
2. Construct Bitcoin withdrawal transaction
Now, the real BTC corresponding to this part of the destroyed synthetic BTC needs to be released from the Bitcoin mainnet. The coordinator node detects the destruction event (because they are also EVM validators), and at the beginning of the next Bitcoin epoch, the rotating coordinator will collect all pending withdrawal requests.
According to Spiderchain's design, it selects the corresponding UTXO from the available UTXO pool. Botanix uses a "last in, first out" (LIFO) strategy , which gives priority to the most recently deposited UTXO, thereby protecting earlier deposited assets from potential malicious behavior.
3. Constructing a raw Bitcoin transaction
The coordinator will continue to select UTXO until its total amount is enough to cover the user's withdrawal amount and mining fees. Then a Bitcoin original transaction is constructed, and the transaction structure is as follows:
● Input : Selected UTXO
Output :
○ User’s BTC address (withdrawal amount)
○ Change address (newly generated Spiderchain multi-signature address)
4. Threshold Signature and Broadcast
After the transaction is constructed, all federation members will use their respective FROST key shares to jointly sign. When t-of-n (for example, 12-of-16) signatures are completed, the transaction is fully signed and broadcast to the Bitcoin network.
Final result : After the user's Spiderchain synthesized BTC is destroyed, the corresponding BTC is released from the multi-signature wallet and sent to the Bitcoin address specified by the user. The amount of BTC received by the user is equal to the destroyed amount minus the Bitcoin network mining fee.
This process ensures that Botanix's two-way bridge operations are both secure and verifiable. Combining the flexibility of the EVM and the immutability of Bitcoin's UTXO model, it provides a cross-chain asset system with a clear structure and reliable mechanism.
In order to maintain a trusted 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 enhances overall security by combining "simplicity" with "complexity".
On the one hand, Botanix does not need to introduce any special Bitcoin consensus rules, but directly relies on Bitcoin's native UTXO rule: "Once a UTXO is spent, it cannot be used again."
This is a basic verification logic in the Bitcoin consensus mechanism, so Botanix's "conflicting input mechanism" can be naturally built on this rule. As long as the coordinator always includes the UTXO of the previous peg-out as input in each new peg-out transaction, the Bitcoin network will automatically reject any replay or duplicate transactions and judge them as invalid.
On the other hand, if the coordinator behaves maliciously (for example, attempting to sign a second conflicting transaction, destroying the multi-signature logic), Botanix's PoS protocol and slashing mechanism will punish the coordinator. This mechanism effectively suppresses potential malicious behavior from an incentive perspective.
Essentially, the “conflicting inputs ” mechanism leverages Bitcoin’s UTXO model to enforce the “one-time withdrawal” rule. By linking each peg-out input to the previous peg-out output, Botanix ensures that only the first valid transaction can be successfully executed, and any duplicate transactions will be considered double spend and automatically rejected by the Bitcoin network.
This mechanism elegantly prevents both accidental duplicate transactions and malicious replay attacks, with security relying on Bitcoin’s native consensus rules on the one hand and reinforced by Botanix’s internal Proof-of-Stake (PoS) consensus and penalty system on the other .
One of the main challenges for Bitcoin Chains is maintaining a balance of funds flowing in and out of the chain to the Bitcoin mainnet. This applies to both peg-in and peg-out transactions. If these flows are not managed properly, the system will quickly become imbalanced, leading to issues with double spend transactions and conflicting inputs. Botanix elegantly solves this problem with Spiderchain, a federated Proof-of-Stake Bitcoin chain built by Botanix based on a rotating multi-signature wallet structure.
Therefore, the design forms two types of transactions: peg-in (locking Bitcoin) and peg-out (unlocking Bitcoin). The peg-in operation is to send BTC to the current multi-signature wallet and mint the corresponding BTC representation asset on Botanix. In the peg-out operation, the user will destroy the BTC representation asset on Botanix, and Spiderchain will use the unspent transaction output (UTXO) in its multi-signature wallet as input to return the actual BTC to the user. On Botanix, this Bitcoin transaction is signed by a multi-signature group consisting of the current rotating Spiderchain coordinator.
Another key mechanism is that Botanix links each transaction to the previous one and embeds any potentially “conflicting” inputs, ensuring that any attempt to copy or replay is automatically rejected by the Bitcoin consensus mechanism.
What does multi-signature mean in the context of this article?
In this context, "multi-signature" is the key concept. Web3 users may be familiar with this term, which usually refers to the ability of multiple users to jointly manage the same wallet and sign transactions. In this context, "multisig" (short for multi-signature) refers to a type of Bitcoin address that can only execute transactions if multiple key holders (usually n-of-m, that is, at least n signatures out of m) jointly authorize it.
In Botanix, a new Bitcoin multi-signature wallet is created for each Spiderchain epoch, currently in the form of more than 2-of-3 (planned to expand to 12-of-16 in the future, i.e. more than two-thirds of the signers), controlled by the orchestrator node. This means that any transaction initiated from this address (such as 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 access.
Therefore, the "multi-signature" here is not only a shared wallet, but also the cornerstone of Botanix's trustless design and a bridge between it and the Bitcoin mainnet. It ensures that no single party can withdraw BTC without authorization, while realizing the peg-in/peg-out process guaranteed by a verifiable and rotating group of signers. A seemingly common mechanism plays an extremely important role in the Bitcoin scenario.
Conflict Input Mechanism
The core idea of this mechanism is that the input (UTXO) used in the previous peg-out has been spent in the current transaction. In Bitcoin's UTXO model, once a UTXO is used as an input in a confirmed transaction, it cannot be used again. Botanix takes advantage of this feature: each new peg-out uses the remaining output (change UTXO) of the previous peg-out as the input of the current transaction, ensuring that any repeated broadcast peg-out transactions will violate Bitcoin's double-spending rules and be rejected.
If a coordinator or user attempts to perform repeated peg-out operations with the same UTXO, the resulting transaction will contain "conflicting inputs" (i.e. two transactions attempting to spend the same UTXO), and therefore the transaction will be invalid. In other words, a multi-signature UTXO that has already been spent cannot be reused, and the system will detect the conflict and reject the repeated operation.
For example:
Assume that TXₙ is the last pegged-out Bitcoin transaction, and its output contains an unspent change UTXO, denoted as Uₙ (this change UTXO is used for the next round of multi-signature wallets). At the next peg-out, the coordinator of Botanix will construct TXₙ₊₁ and use Uₙ as one of the inputs. At this time, Uₙ is spent by TXₙ₊₁. If a malicious person or mistakenly broadcasts a copy of TXₙ₊₁ again at this time, or creates a new transaction that also uses Uₙ, the network will recognize that Uₙ has been used by the previous TXₙ₊₁ and will treat subsequent transactions as double-spending transactions. This transaction cannot be packaged into a block and is difficult to successfully broadcast on the network because Bitcoin's consensus rules prohibit repeated spending of the same UTXO.
Essentially, a peg-out transaction is inherently “non-replayable” because it uses 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 (identical) transactions cannot be confirmed again, and any new transaction that attempts to use the same input will be considered invalid.
In short, Spiderchain leverages Bitcoin's UTXO model to enforce the uniqueness of each peg-out.
The following is a schematic diagram of the logic of the peg-out transaction input and 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 of the next peg-out.
● If there is a duplicate peg-out transaction trying to spend M2 again, the attempt will fail because M2 has already been used.
By design, no two peg-out transactions can use the same Bitcoin output, because each transaction references the previous output as input. Bitcoin network nodes automatically reject any transaction that reuses the input, so neither accidental nor malicious replay can succeed.
Prevent accidental or malicious replay
The "conflicting input" mechanism not only prevents malicious attacks, but also effectively deals with unintentional repeated operations by users or nodes.
In unexpected circumstances, a user or node cannot create two identical peg-out transactions, as the second attempt would conflict because it uses an already spent input, rendering the transaction invalid.
In a malicious attack scenario, the coordinator or external attacker cannot forge a second withdrawal transaction for the same funds. In order to perform a double spend attack, the attacker must create a Bitcoin transaction that attempts to spend the same UTXO again ; but because the UTXO has been used by a valid transaction, any second transaction using the same input will be recognized by the Bitcoin network as a double spend and marked as invalid.
In addition, Botanix’s governance mechanism penalizes any coordinator who attempts to sign or broadcast a conflicting peg-out transaction. The system rules consider “improperly signing a multi-signature transaction in Spiderchain — whether signing an incorrect withdrawal transaction or engaging in double spending” as a slashing violation.
Since the cross-chain bridge code will deterministically construct a complete transaction (including input, output, amount, etc.) through on-chain consensus, the operating node cannot privately tamper with the transaction input. Therefore, if a coordinator deliberately signs a transaction that conflicts with another transaction (such as attempting to double spend), his node will face the risk of having the pledged assets confiscated.
Through this mechanism, Botanix not only relies on Bitcoin's own consensus mechanism (automatically rejecting double-spending transactions) to ensure security, but also further strengthens the strong constraints on unique peg-out behavior through its own consensus and punishment mechanisms (such as slashing).
Working principle step by step analysis
After understanding the overall logic of the Botanix mechanism, let's sort out the Peg-In (recharge) and Peg-Out (withdrawal) processes in more specific steps. Although each step involves multiple technical modules, from a macro perspective, the operation of this system is actually quite clear:
Peg-In (recharge 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 a multi-signature address
The user deposits BTC into the gateway address generated above. In essence, these BTC are sent to the Spiderchain federated multi-signature wallet controlled by orchestrators. At this time, BTC does not leave the Bitcoin mainnet, but is locked in the multi-signature address.
3. Minting synthetic BTC on EVM
Once the deposit transaction receives enough confirmations, the Sidecar (or the user through the bridge) generates a Merkle inclusion proof and calls the Botanix minting contract on the Spiderchain EVM. The EVM transaction consumes the deposit "proof" and triggers the Mint event, and the system then distributes the synthetic BTC to the user's EVM account at a 1:1 ratio (minus Bitcoin and EVM fuel fees).
Result : Users receive an equivalent value of synthetic BTC on the Botanix EVM, backed by real BTC locked in the Spiderchain multi-signature wallet.
Botanix validators run independent Bitcoin nodes to track the UTXO status on the chain and verify transaction proofs to ensure that tokens are minted only once for each deposit.
Peg-Out
1. Destroy tokens on EVM
The user initiates a transaction through Spiderchain EVM to destroy the synthetic BTC he holds. This transaction will deduct the corresponding amount from the user's balance (minus the EVM gas fee).
2. Construct Bitcoin withdrawal transaction
Now, the real BTC corresponding to this part of the destroyed synthetic BTC needs to be released from the Bitcoin mainnet. The coordinator node detects the destruction event (because they are also EVM validators), and at the beginning of the next Bitcoin epoch, the rotating coordinator will collect all pending withdrawal requests.
According to Spiderchain's design, it selects the corresponding UTXO from the available UTXO pool. Botanix uses a "last in, first out" (LIFO) strategy , which gives priority to the most recently deposited UTXO, thereby protecting earlier deposited assets from potential malicious behavior.
3. Constructing a raw Bitcoin transaction
The coordinator will continue to select UTXO until its total amount is enough to cover the user's withdrawal amount and mining fees. Then a Bitcoin original transaction is constructed, and the transaction structure is as follows:
● Input : Selected UTXO
Output :
○ User’s BTC address (withdrawal amount)
○ Change address (newly generated Spiderchain multi-signature address)
4. Threshold Signature and Broadcast
After the transaction is constructed, all federation members will use their respective FROST key shares to jointly sign. When t-of-n (for example, 12-of-16) signatures are completed, the transaction is fully signed and broadcast to the Bitcoin network.
Final result : After the user's Spiderchain synthesized BTC is destroyed, the corresponding BTC is released from the multi-signature wallet and sent to the Bitcoin address specified by the user. The amount of BTC received by the user is equal to the destroyed amount minus the Bitcoin network mining fee.
This process ensures that Botanix's two-way bridge operations are both secure and verifiable. Combining the flexibility of the EVM and the immutability of Bitcoin's UTXO model, it provides a cross-chain asset system with a clear structure and reliable mechanism.
Consensus guarantee and punishment mechanism
In order to maintain a trusted 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 enhances overall security by combining "simplicity" with "complexity".
On the one hand, Botanix does not need to introduce any special Bitcoin consensus rules, but directly relies on Bitcoin's native UTXO rule: "Once a UTXO is spent, it cannot be used again."
This is a basic verification logic in the Bitcoin consensus mechanism, so Botanix's "conflicting input mechanism" can be naturally built on this rule. As long as the coordinator always includes the UTXO of the previous peg-out as input in each new peg-out transaction, the Bitcoin network will automatically reject any replay or duplicate transactions and judge them as invalid.
On the other hand, if the coordinator behaves maliciously (for example, attempting to sign a second conflicting transaction, destroying the multi-signature logic), Botanix's PoS protocol and slashing mechanism will punish the coordinator. This mechanism effectively suppresses potential malicious behavior from an incentive perspective.
Essentially, the “conflicting inputs ” mechanism leverages Bitcoin’s UTXO model to enforce the “one-time withdrawal” rule. By linking each peg-out input to the previous peg-out output, Botanix ensures that only the first valid transaction can be successfully executed, and any duplicate transactions will be considered double spend and automatically rejected by the Bitcoin network.
This mechanism elegantly prevents both accidental duplicate transactions and malicious replay attacks, with security relying on Bitcoin’s native consensus rules on the one hand and reinforced by Botanix’s internal Proof-of-Stake (PoS) consensus and penalty system on the other .
