Peg-in / Peg-out

Peg-in (Deposit)

Transfers from Bitcoin to the Botanix EVM, or peg-ins, consist of two transactions. First a transaction on the Bitcoin network is created which transfers custody of some amount of Bitcoin to the multisig secured by Botanix Federation. Next, a transaction is created on the Botanix EVM which claims this transfer, mints an equal amount of Bitcoin on the Botanix EVM and transfers it to the user's EVM address. The amount received is equal to the deposited amount minus the fees for the bitcoin transaction and the EVM transaction

Botanix utilizes the internal taproot key to encode the Layer 2 address where the funds should be directed. As a result, a taproot address is generated, allowing users to repeatedly send funds to it. Following confirmation(s), a pegin proof can be constructed to verify that the funds have been successfully sent.

Participants

• Alice: user that wants to peg in

• Botanix Bridge: dApp offering the bridging functionality and user interface

• SideCar: dapp server that helps users with pegins and has access to an index of the bitcoin chain (like electrs)

• Minting contract on the Spiderchain EVM

• Såiderchain validators: federation nodes

Steps

1. Alice creates her ethereum public key.

2. Alice sends [ethAddress] to SideCar. SideCar will query the Botanix network via RPC to get the current aggregated public key i.e FROST pubkey.

3. SideCar will send all necessary components for a Gateway Address (GA) to Botanix via RPC to get a GA. Note that the RPC to get a GA is purely a utility that abstracts away the complexity of generating the taproot address. To verify, SideCar can generate the same taproot address.

4. Botanix Protocol will combine this info with the FROST pubkey to create the internal key for her taproot gateway address: I = FROST + H(FROST | ethAddress ) * G. The taproot would then be calculated using the taproot equation Q = I + TapTweak(I | S) * G.

5. Alice sends her sats to her gateway address using her preferred wallet.

6. Alice uses the Botanix Bridge to enter her bitcoin pegin transaction id and register her pegin. Once the pegin has enough confirmations, she can click the Claim button for her pegin. The Bridge calls SideCar to initiate the transaction (call the mint method in the minting contract).

7. Upon receiving the pegin request from the Bridge, SideCar constructs the pegin proof by combining the block it was confirmed in (merkle proof), the block height at which the transaction was confirmed and the most recent block headers between the block the transaction got confirmed in and the tip.

8. The SideCar generates a Botanix pegin transaction calling into the Minting contract providing Alice's information and the pegin proof. SideCar will manage its own Botanix ETH account and provide the gas for the pegin tx.

   NOTE: It's important to note that the above two steps could be done by Alice, but the helper just makes it so that Alice doesn't have to construct her pegin proof, doesn't need a Bitcoin node and doesn't need to know how to call into the Minting contract. Advanced peginners might want to do this themselves, but in this simple UX flow, some stateless helper can easily do it. Sidecar will get refunded the pegin amount from the user's total.

9. The contract will check if the pegin increments Alice's pegin block height. It will calculate the gas cost for the transaction, deduct it from the pegin amount, and refund the cost to the SideCar wallet. Then the contract will emit a Mint event containing the pegin data on success. Finally, it will mint the amount to Alice.

10. Any chain validator monitors for events of this type from this contract and performs a check to validate the proof. This happens outside of EVM execution right after a block is built and executed and before it is sealed and communicated to the network.

The Botanix pegin proof will be structured as follows:

Field	Description	Size
Pegin Message Version		4 byte
txId		4 byte
Vout		4 byte
Ethereum Address		20 bytes
Aggregate Public Key	Compressed public key	33 bytes
Number of Block	Bitcoin style var int	1-3 bytes
Headers	Variable number of 80-byte blocks headers	80 * num of blocks
** The rest of the payload is the merkle inclusion proof **
Number of transactions represented by merkle root	Uint32	4 byte
Number of hashes	Bitcoin style var int	1-3 bytes
Merkle Hashes	hash pairings	32 bytes * number of hashes
Number of bytes of Inclusion bits	Bitcoin style var int	1-3 bytes
Inclusion bits		num of transaction / 8 bytes

Peg-out (Withdraw)

Just like peg-ins, peg-outs consist of two transactions but in the opposite order. This time, first an EVM transaction is executed, burning the pegout amount minus the gas fee for this transaction. Secondly, a bitcoin transaction is executed transferring the pegout from the multisig wallet to your chosen bitcoin address. The received amount will hence be the pegout amount minus the fees for the EVM transaction and the bitcoin transaction.

Peg-outs are handled every epoch block which is approximately every 10 minutes.

Side car server

The process of pegging into the Botanix system is inherently complex, involving access to various resources such as a block source and a Botanix RPC server. To streamline and simplify this intricate pegging procedure, the Side Car Server plays a pivotal role. This component exposes several of RESTful endpoints to facilitate the peg in/out process.