.png)
This spec is primarily for internal purposes and discussion around technical aspects of this expansion.
Objective: The expansion aims to integrate Bitcoin (BTC) support into Sygma, enhancing the protocol's interoperability capabilities. This involves bridging BTC to its synthetic counterparts on the EVM networks.
The proposed solution is heterogeneous in the context of the MPC key used. The direction toward EVM networks will use the already supported ECDSA-based MPC key, and the direction toward the Bitcoin network will use the newly implemented Schnorr-based MPC key.
The technical details of implementing this on the Bitcoin network also depend on how we approach the question of deposit addresses described later in the document. These addresses will be generated as Taproot addresses with specific spending conditions. These conditions restrict transaction permissions to two entities: the MPC (Multi-Party Computation) address and a multisig (multi-signature) wallet tasked with overseeing liquidity.
**Conclusion:**
BTC deposit addresses will be generated as Taproot addresses with specific spending conditions. These conditions restrict transaction permissions to two entities: the MPC (Multi-Party Computation) address and a multisig (multi-signature) wallet tasked with overseeing liquidity. Each synthetic representation of BTC will have its own deposit address on the Bitcoin network.
We will register a separate resource for each synthetic BTC on the EVM side (separate resource ID).
Relayers listen to the specified deposit address generated through the Schnorr base keygen process. They process transactions that deposit BTC to these addresses. When making a deposit, the user is required to encode their EVM address into a transaction. This is how we will correlate their Bitcoin deposit to a specific EVM address on the destination chain.
Implementing fee collection on the BTC side would be cumbersome and limited by Bitcoin network capabilities. Because of this, we will collect fees on the EVM side (execution side). This will allow us to follow the fee-collecting logic we already use. Regular ERC20Handler will be expanded to collect fees on execution.
Relayers use the MPC ECDSA-based key to execute the signing process and pack deposit data as fungible token transfer (ERC20), which is compatible with ERC20Handler on the EVM network.
For future improvements (MS2 & MS3), relayers will be able to process metadata from the deposit and pack it as contract calls (GMP).
✅ Define encoding specification for Bitcoin deposits, as it needs to enable:
Implementation detail we will define during development.
✅ Deposit address/es: Should we have a singular deposit address, one deposit address per route, or derive a new one each time we have a new deposit (these addresses would be derived from the MPC address)? The challenge with deriving a new address for each deposit is that relayers must listen on all of these addresses, so derivation must be deterministic and easy for relayers to track.
Conclusion: Described [✅ Liquidity governance: When bridging BTC to its synthetic counterparts on various EVM networks, we must consider the optimal approach for managing liquidity. Given the heterogeneity of two sides (ECDSA && Schnorr), we propose distributing liquidity across multiple “pools” on the Bitcoin network. This strategy caters to the unique demands of each integration and enhances security by mitigating risks associated with single points of failure.
The technical details of implementing this on the Bitcoin network also depend on how we approach the question of deposit addresses described later in the document. These addresses will be generated as Taproot addresses with specific spending conditions. These conditions restrict transaction permissions to two entities: the MPC (Multi-Party Computation) address and a multisig (multi-signature) wallet tasked with overseeing liquidity.](https://www.notion.so/Liquidity-governance-When-bridging-BTC-to-its-synthetic-counterparts-on-various-EVM-networks-we-mu-ddbd2c022b8f408db402f98560797459) ☝️
✅ What MPC vote (get consensus) for: per transaction or per block header
Conclusion:
Because of the gas costs associated with execution, the initial implementation will use MPC to reach a consensus on specific deposit transactions.
Down the road, once the ZK-based approach is rolled out, MPC will also switch to operating by getting consensus on block headers. This will allow us to enable aggregated security using ZK + MPC.
.png)