Introducing: Chainflip Boosted Swaps

We’re working on a range of features and improvements on the path to Chainflip achieving $100m in daily volumes - which is our goal for this year. Last week in Dubai, I dropped some white-hot alpha on-stage during a DeFi panel with regards to one of these features. Now that we’re planning the 1.4 release, it makes no sense to hide it any longer.

For the last 6 months, we have been developing a slick feature in stealth. It is now just about ready to hit the testnet and will be added to the protocol alongside Arbitrum, and rolled out gradually after 1.4 is live.

We’ve seen some talk in the Thorchain community about an Instant Swaps feature that will speed up the overall swapping experience, seen here in this GitLab Issue.

We devised a system for this exact purpose quite some time ago, but decided to work on it in the background so as to not prematurely release a design we weren’t too sure about. But now it’s time.

Introducing BOOST!

Our partner Squid already uses this name to power a similar feature which cuts swap/bridge times down to a staggering ~20s across EVM chains. We agreed with them to re-use this name to create a unified experience when it’s ready across the protocols.

Chainflip’s BOOST feature will:

• Dramatically speed up swap times for those who choose to use it (processed as soon as the deposit is included in a block!)
• Help LPs fill JIT swaps more reliably and rebalance faster with boosted LP deposits, improving overall pricing and liquidity for big swaps
• Offer retail LPs the opportunity to provide capital to the system in a meaningful way, while still potentially generating some nice yields on native BTC and other assets.

How Boost Works

A major pain-point for users (swappers and LPs) is how slow deposits can be. Particularly for slow chains such as Bitcoin, the deposits can take 30+ minutes which can be frustrating. The majority of this deposit time comes from the fact we need to protect our liquidity from re-orgs. If the depositing chain re-orgs and we have already processed an outgoing amount the protocol can end up in a deficit.

If we can speed up the deposit times without increasing the risk to the protocol then we can improve the user experience without adding protocol risk.

The basic idea behind boost is that LPs (of any kind) can put collateral in shared Boost pools of varying fee levels to be used as collateral for incoming deposits.

When a “boost enabled” deposit is pre-witnessed (usually right after it is included in a block on the source chain), the protocol will see if there is enough collateral in the pools up to the fee limit specified by the user. If there is, the available boost collateral will be used to pay for the swap/LP deposit early (minus a boost fee) and will then be executed as normal.

The boost pools take the risk on that deposit being confirmed at a later point once the safety margin has been reached. If it goes through, the boost pool will then be credited with the deposit, and be available for use again.

If the deposit is never finalised due to a re-org which drops the deposit TX altogether, the losses associated will be socialised amongst the boost contributors.

Simple example flow

1. LP Booster decides to put their funds in a boost pool of pre-set % amounts. For argument's sake, let’s say 5bps, 10bps, 30bps (real pool fees may differ). They put 1BTC in the 5 bps pool. There is now 1BTC in the 5bps pool, and there was already 5BTC in the 10bps pool.
2. A swapper creates a channel, willing to pay up to 10bps boost fee.
3. They deposit 2 BTC to the address.
4. After being pre-witnessed on chain, the 1 BTC in the 5bps pool is used to boost, and then 1BTC of the 10bps pool is used. As a result, in aggregate, the swapper paid ~7.5bps to boost his 2 BTC deposit. Subtracting the boost fee, 1.9985 BTC is swapped.
5. Once finalised, the full 2 BTC deposit is credited and the fees are collected in the pool.

If no one boosts the deposits, then the current swapping flow is used and the deposit is credited as normal.

Pool Design

Pools are split into two amounts:

1. Available - these funds can be immediately used for boosting
2. In use - these are funds that have been used to boost a deposit and are now on the sidelines until the deposit is finalised.

When a booster B deposits into the pool the amount A is stored next to their account id (it is added to the existing amount if already a booster). We set available_amount[B] += A. The sum of these amounts gives us the total available amount.

On boost, the amount that each booster contributes (as well as the amount in boost fee they earn) is proportional to their (implicit) share in the pool. These contributions are then deducted from the booster's available amounts. Each boost is assigned a boost_id, and the amounts owed to each booster (their contribution + boost fee) are stored alongside it in pending_boosts[boost_id]. When the deposit is finalised, the recorded amounts are added back into booster’s records as active (unless a booster requested to stop boosting, which is handled below), effectively increasing the total available amount by boost_fee.

Importantly, once a deposit on a channel is boosted, no other deposits can be boosted until either the deposit is finalised, or the channel has expired (in which case the deposit is considered lost). This is done to ensure that if the same deposit is pre-witnessed twice (due to a reorg), it is not boosted the second time (as doing so would inevitably result in losing booster funds).

What if the deposit is not finalised before the channel expires?

The deposit is considered lost. However, the losses are distributed fairly, that is, in proportion to the amounts booster used to boost the said deposit (which is also proportional to the amount in fees they would receive, had the deposit been finalised). It is up to each individual LP to determine their risk tolerance, for each asset they wish to boost, and contribute to the pools according to fee levels to price in that risk tolerance.

What are we expecting this to achieve?

We think that this feature will achieve multiple benefits for the protocol and a product as a whole. It certainly gives Chainflip swaps a unique selling point in the BTC swaps market, but also achieves a number of other effects:

• Creates a retail-friendly single asset yield product within the protocol (Native BTC yields) that exposes users to both swap and LP fees without introducing new protocol risks
• Gives LPs idle capital to borrow to be used to speed up asset rebalancing and swap execution
• Improves overall pricing and asset availability by boosting those LP deposits
• Gives swappers the option of the fastest possible end-to-end execution of a swapping UX, centralised or otherwise.

With Boost, you can send BTC to be swapped and have ETH appear in your wallet seconds after it hits a block. ETH can be sent and SOL will appear in your other wallet in as little as 20 seconds. Combined with Squid’s boost feature, you could buy any memecoin on any EVM chain with native SOL and receive the tokens within 40 seconds of your deposit. It’s hard to be any faster than that. Centralised exchanges take much longer to accept deposits and for users to move stuff around, let alone execute the orders.

Similarly, a normal swapper sending 20 BTC to be swapped can be helped by Boost capital being used to help LPs have enough ETH on their accounts by the time the swap is executed to improve execution price and accelerate the rebalancing process.

What’s the rollout plan?

The basic version of Boost will be going into 1.4. Initially, it will be turned off and then gradually rolled out, firstly to Bitcoin, and then to the other chains. We estimate that BOOST will be made available to users on the Chainflip frontend (which requires extensive overhauls to keep the swapping experience smooth) in June, and our integration partners shortly afterwards.

There are some improvements we know we can make to the system already after the initial release, including:

• Contract initiated boosts
• Without this Squid and other aggregators may not be able to take full advantage of this feature. Though for Thorswap, or the Chainflip frontend, for example, it will work just fine.
• Configurable delay of swap execution after SwapScheduled event in order to be able to ensure fair markets without undue waiting times
• LPs should be allowed to execute swaps internally (with the delay in effect), which should dramatically increase the potential utility of the DEX as a trading platform for both manual and algorithmic traders (similar to THORChain synths)

Conclusion

Boost is another feature that we believe will help Chainflip achieve $100m daily volumes. It’s one of many improvements which will help the protocol become self-sustaining through genuine end users getting the most out of their cross-chain swapping experience.

That’s all for now, folks! We’ll post more info about the system as it is released.