SPV swaps (on-chain)
Bitcoin -> Smart chains (Solana, Starknet, EVM, ...) swaps based on the bitcoin light client & UTXO chaining, requiring only 2 transactions in total with no need to pre-lock liquidity.
Last updated
Bitcoin -> Smart chains (Solana, Starknet, EVM, ...) swaps based on the bitcoin light client & UTXO chaining, requiring only 2 transactions in total with no need to pre-lock liquidity.
Last updated
Bitcoin light client is an on-chain smart contract used to trustlessly verify bitcoin proof-of-work consensus and store bitcoin blockheaders on the smart chain (Solana, Starknet, EVM, etc.). This smart contract is permissionless, such that anyone can submit blockheaders as their validity is verified purely on-chain.
Bitcoin blockheaders contain a merkle root of all the transactions executed in it, this can be used to prove that any Bitcoin transaction was confirmed/included in a block by providing a merkle proof.
Here are more technical explanations about inner workings of our bitcoin light client contracts:
The core of the solution includes a deposit-only vault on the smart chain side. As the name implies, the owner of the vault can only deposit tokens to it directly on the smart chain. Withdrawals from the vault are handled purely with bitcoin transactions of a specific format.
A trivial (but insecure) solution would be to design a vault in such a way that it requires BTC sent to a specific wallet address (a specific locking script) on bitcoin. The user will then be able to get the same amount of the asset on the smart chain. This is however insecure, since the user cannot be sure that when his transaction confirms on BTC there still are enough funds available in the vault (i.e. someone else can front-run his bitcoin transaction, with one draining all the funds from the vault).
To prevent front-running there is a need to have a well-defined ordering of transactions withdrawing funds from the vault, such that users can be sure that there is still enough funds in the vault to make them whole. We accomplish this by referencing a specific bitcoin UTXO in the vault, such that the next transaction withdrawing funds from the vault needs to include this UTXO in its transaction inputs - this ensures there could only ever be a single update to the vault's state. The vault also specifies how many bitcoin confirmations are considered final and only accepts state updates from those transactions.
To make sure this construction can be used multiple times we make the bitcoin UTXO of the vault dynamic, such that it always updates to the first output of the withdrawal transaction. This allows us to chain the UTXOs indefinitely, ensuring a clear order of swaps.
We can use the deposit only vault construction for swaps between bitcoin & smart chains. To do this we make the LP (liquidity provider) create a deposit only vault on the smart chain, and referencing a small (dust) UTXO that he owns in the vault. User and LP then cooperatively sign a transaction that atomically (in a single transaction), spends the latest vault UTXO, commits to the withdrawal data and sends funds from user to the LP's wallet on the bitcoin side.
Parties (permissionless - can be anyone), that are submitting withdrawal transaction data on the smart chain on behalf of the user. This is useful when user has no balance on the smart chain and therefore has no way of submitting the withdrawal transaction data himself (no way to pay gas fees). To incentivize watchtowers there is an option to include a tip/fee to the watchtower in the additional transaction data.
In case users want to get their funds sooner than the confirmations required in the vault, they can specify a fronting fee/tip in the additional transaction data. The liquidity fronters can then process the swaps sooner (sending the assets to the user) - e.g. with the btc transaction having just 1 confirmation, and later reclaim the value they fronted (+ fronting fee) from the vault - e.g. when the bitcoin transaction gains 3 confirmations.
User - has bitcoin and smart chain wallets and wants to swap bitcoin to smart chain asset
LP node - handling the swap and providing the liquidity, needs to have a deposit only vault set up on the smart chain
Watchtower - a party submitting the bitcoin transaction data on the smart chain on behalf of the user
Liquidity fronter - a party which is willing to front the liquidity for swaps
User sends an RFQ (request for quote) to the LP indicating the requested input (or output) amount of assets
LP constructs a PSBT (not signed yet) spending the latest vault UTXO, and adds 3 outputs:
Small (dust) output as a next vault UTXO
OP_RETURN data specifying the output amount and recipient
Output to LP's wallet with the swap's input amount
User verifies the returned PSBT:
Validly spends latest vault UTXO and that UTXO is unspent
Specifies the correct (i.e. requested) output amount and recipient in the OP_RETURN data
Outputs valid input input amount to the LP's wallet
There is still enough balance in the vault on the smart chain to honor this swap
User then adds his own input UTXOs up to the amount of the outputs (user is also expected to cover the transaction fee), and optionally also adds a change output for himself
User signs this adjusted PSBT and sends it to the LP
LP verifies that the user hasn't changed any of the LP specified outputs and inputs
LP signs the transaction and broadcasts it to the bitcoin network
...the transaction confirms on the bitcoin network, but doesn't get enough confirmations to be eligible for vault withdrawal yet (i.e. gets 1 confirmation)
A Liquidity fronter fronts the liquidity (minus the fronting fee) through the smart contract to the User, the smart contract saves this fact and later redirects the claim to the Liquidity fronter
...the transaction now gets enough confirmations to be eligible for vault withdrawal (i.e. gets 3 confirmations)
A Liquidity fronter submits the bitcoin transaction data to smart chain, where it's verified and the output amount is paid out to the Liquidity fronter
...the transaction confirms on the bitcoin network and gets required number of confirmations
A User, LP or Watchtower submits the bitcoin transaction data to smart chain, where it's verified and the output amount is paid out from the vault to the User. Whoever submits the data gets the caller/watchtower tip/fee - if specified in the transaction data (i.e. can also be set to 0).
