# Skypools deep dive

## What is involved in the Skypools update?

#### 1. CMP FROST
CMP (ECDSA) and Frost (EdDSA & Taproot) vastly improve the performance of the underlying cryptography that powers Skybridge. By implementing both CMP and Frost, we have:

* Massively reduced the number of signing rounds required to form a consensus.
* Reduced the amount of overhead.
* Added support for parallel processing, significantly speeding up singing rounds.

#### 2. BIP32
BIP32 (link) enables Skybridge to create unique Bitcoin deposit addresses for each swap. Although this doesn't sound like much, it improves the user experience of the bridge. Ever tried to swap some Bitcoin and noticed that the bridge asks you to send slightly less? Well, that's to help the bridge identify your swap. With BIP32 this identity method would not be needed anymore, improving user experience and reducing the complexity of the Metanode.

#### 3. SMART Contract invocation

The 3rd and most important update that will be shipped with the Skypools launch is the ability for Skybridge to interact directly with Smart contracts. This means that Metanodes will be able to sign transactions that invoke smart-contract functions once a consensus is formed.

Initially, this feature will be used to enable the Skypools any-to-any coin swap platform (see below), but in the future, you can imagine a world where Bitcoin can be directly used with all DeFi applications.

## How Skypools Swap Works

Skypools allows users to directly interact with the existing Skybridge in ways that more directly allow native Bitcoin to participate in existing decentralized finance protocols in ways that were not possible before. Two major flows make up the primary features of Skypools. The first is a flow that allows native BTC to be converted to wrapped BTC tokens (BTCt) on the applicable EVM network (wBTC on Ethereum). To execute this flow, the user must request the nodes in a similar fashion to the original Skybridge flow. This request includes the user’s wallet address to allow the receipt of tokens.

Once the nodes have executed the cross-chain conversion to BTCt, the BTCt will be placed into a balance on the smart contract allocated to the user’s wallet address. The user can then either withdraw the BTCt directly to their wallet, or they can then execute a swap without withdrawing, saving gas if they planned to do this anyway. The swapped token will be sent to the user’s wallet directly.

This swap is executed using Paraswap. Our smart contract utilizes the Paraswap V5 interface. The flow for a swap as replicated in the tests is as follows:

1. Make GET request to Paraswap API V5 to get pricing data for token pair
2. Use data from GET request to make PUT request to Paraswap API V5to get the full transaction data. This should be every parameter needed to execute the swap using the Paraswap smart contract interface.
- The Skypools user interface will execute these calls send the data to the contract once the user has executed the function call
3. User calls the external function on our smart contract to execute the swap using the data from the API PUT response. At this time, the swap is executed using liquidity from Paraswap, and the resulting tokens are sent directly to the user’s wallet

The second flow works in the opposite direction from the first and allows a user to deposit any ERC-20 token to the swap contract, and in a single transaction swap it to native BTC. The deposited tokens are held and assigned to the depositing wallet address. At this time, the sequence of events as replicated in the tests is as follows:

1. The same sequence as flow 1, including the two Paraswap V5 API calls to get pricing to swap the deposited token to BTCt (wBTC on ethereum), as well as the user calling the external function to execute the swap using the Paraswap interface.
- In this case, however, the BTCt tokens are sent to the swap contract rather than the user’s wallet
2. Once the swap has been confirmed, the contract calculates the exact amount received, and stores this information as a pending swap along with any other information associated with this transaction, such as the receiving native BTC wallet address. This is to allow the Skybridge nodes to pick up pending transactions so the user can be sent their native BTC.
- At the time this is recorded, the contract also cleans up any old pending transactions (to native BTC) that have already been executed by the Skybridge nodes
A SwapTokensToBTC event is emitted, this allows the Skybridge nodes to know a new swap has occurred
In the event of a failed Skypools transaction, such as with an invalid receiving native BTC address, the user will be refunded with BTCt (wBTC on ethereum)