SWIP-018: The Swingby Bridging Process for Bitcoin to Ethereum
The first article in our SWIP Deep Dive series
Background Context
The Swingby Improvement Proposal (“SWIP”) is similar in concept to Ethereum’s “EIP” and Bitcoin’s “BIP”. It’s a standard for submitting changes to Swingby protocols and can cover all technical areas such as governance, economics, protocol changes or even general performance improvements.
In this article, we will take a look into SWIP-018, which details the process used in order to achieve asset bridging to and from the Ethereum blockchain.
With this feature Swingby’s Skybridge will be able to move Bitcoin onto Ethereum and also move Ethereum assets onto other chains. SWIP-018 will be making its first appearance on a TestNet in the coming week.
How the system swaps BTC to BTC on Ethereum
Bringing Bitcoin, the most traded and liquid cryptocurrency in the world, to Ethereum is the main value add for this feature. With Swingby, users will be able to simply send their native Bitcoins to a trustless multi-signature address governed by the network’s TSS nodes in return for pegged Ethereum ERC20 Bitcoin tokens.
The steps for swapping native Bitcoin to an ERC20 pegged equivalent are as follows:
- The User wants to swap BTC to BTC on Ethereum.
- The User inputs their BTC refund address and ETH destination address.
- The System creates a swap request in the distributed “KV store”.
- The User sends their BTC to the Skybridge network address (displayed in the UI).
- The Skybridge nodes reach consensus and co-sign an outbound Ethereum wrapped BTC transaction to the users destination address.
- The User now has BTC ERC20 tokens on the Ethereum chain.
The “KV store” is simply a distributed database that all of the nodes have access to and it’s used for keeping track of the destination for each swap. Typically Swingby Skybridge uses the transaction’s “memo” field to contain this data, but not all chains support “memo” fields so the KV store method is used instead.
The “Skybridge network address” is the public key of the address controlled by the nodes. Each node has its own “key-share” and once a consensus is formed amongst a certain number of nodes, they can participate together in order to construct a signed transaction without sharing their secrets.
Communicating with the Ethereum chain
In order to swap between the two different chains the core Swingby node needs to be able to query each of the networks in order to generate a list of transactions entering and exiting the network TSS address. New inbound transactions will be processed as swaps and outbound transactions will be considered either ‘confirmed’ or ‘failed’.
To handle this interaction, the team decided to reduce code complexity and integrate with the existing and proven abstraction layer ‘Blockbook’. This indexer developed by Trezor plugs into an Ethereum or Bitcoin node and uses a standardised interface for getting transaction information. This means that code written for interacting with the Bitcoin blockchain can be shared and re-used to help integrate the Ethereum chain.
Hosting a BTC to BTC on Ethereum node may look something like this:
A fully functioning BTC to BTC on Ethereum node will require both an Ethereum and Bitcoin node each with their own blockbook instance.
Supporting ERC20 multi-send
Once a swap has been processed by the network, the nodes will begin constructing and signing an outbound mult-send transaction that will either deliver the swapped tokens or refund the original input. In the same multi-send, any nodes that helped to facilitate the swap will also receive a portion of the fees as a reward. Each multi-send can easily include over 50+ individual transactions.
In the world of Ethereum and the current ERC20 standard, multi-send is not supported by default. But due to the above, this will cause issues with the Swingby network since it requires a lot of resources to sign a single message and without multi-send support, the Swingby network would have to sign 50+ individual transactions per swap (one per active node). Not ideal.
To solve this issue, the team has designed a ‘smart-contract wallet’ that acts as an ephemeral custodian for the funds traveling through the network bridge. When a user deposits their funds for a swap, they are actually depositing into a contract and when a swap has finished processing, the funds are withdrawn from that contract.
This contract implements a ‘multiSend’ function which can be used by the nodes to process multiple transactions in a single signing round.
The Swingby Skybridge network address is the sole owner of this contract. This means that the nodes still have to form the appropriate threshold-consensus in order to withdraw from the contract wallet.
Keep your eyes on Swingby Protocol’s Twitter for the official BTC to BTC on Ethereum launch into TestNet. Thanks for reading!
References
SWIP-018: https://github.com/SwingbyProtocol/swips/blob/master/specs/skybridge-v1/SWIP-018.md
Multi-Send Wallet Contract: https://github.com/SwingbyProtocol/BEP20Token/blob/master/contracts/MultiSendWallet.sol
Want to trade Swingby? Check us out on CoinGecko or CoinMarketCap.
Get Rewards! Stake your Swingby Token to earn up to 52% annualized (67% compounded) in rewards, airdropped to your wallet weekly. Use the Staking Portal or BitMax.
TestNet Explorer: bridge-testnet.swingby.network/explorer
Staking Program: https://swingby.network/earn
Telegram: https://swingby.network/telegram
Twitter: https://swingby.network/twitter
Reddit: https://swingby.network/reddit
Discord: https://swingby.network/discord
Github: https://swingby.network/github
