This page is part of the typescript tutorial for creating your first COMIT-app, that builds two simple command-line application using the COMIT protocol to execute a Bitcoin to Ethereum atomic swap locally on your machine.
In this section we focus on the maker side and work on
In this section we add code for the execution of the swap on the maker side.
In the previous section we already added the code for listening for incoming swaps on the maker side.
This provides us with the comit-sdk
Swap that helps us to execute the swap.
In this tutorial we only focus on a scenario where both parties actually redeem the swap, thus we use these two functions:
fund()for locking up our asset.
redeem()for retrieving the asset of the counterparty to our account.
Swap helps us with the swap execution in cnd and sending transactions to the Bitcoin and Ethereum wallet.
When we call
Swap.fund() the comit-sdk starts polling the maker's cnd until the fund action is available for the swap.
The same applies to calling
Note that we have to provide parameters that specify the poll interval that the comit-sdk will use to query cnd for the respective action and a timeout after which we would stop trying to execute
In this tutorial we just set the parameters to poll every second and time-out after 10 minutes.
When moving towards a more advanced application, these values should be aligned with the expiry times set for the swap, and further error handling would have to be implemented.
The maker defaults to the cryptographic role of Bob, meaning he has to wait for the taker (defaulting to Alice, who holds the actual secret) to fund first. Once the taker has funded the swap, the maker can fund. The maker's cnd node will notice the taker's fund transaction and make the fund transaction available on the maker's side. The comit-sdk will then send the necessary fund transaction using the maker's Bitcoin wallet, returning the transaction-id.
All this functionality is packed into one simple line:
Once we retrieve the transaction ID, the maker's fund transaction was sent, locking up his Bitcoin for the taker side to be redeemed. Let's log the transaction ID, so we know that funding was done:
Redeeming is handled the same way:
Once the redeem transaction was sent, we can expect the asset locked up by the taker in the maker's wallet. Since this swap is a regtest swap the asset will appear almost instant, and there won't be any transaction fee.
To prove that the asset was swapped, we can print the final balance of the maker's wallets after waiting shortly (to be sure that the wallet has picked up the transaction):
At this point the maker application is done and we move on to the taker side.
The complete maker application:
Running the maker application will publish the order and wait for a taker to take it so it can be executed. With the maker application being finished we can now move on to the taker side so the maker's order is actually taken and the execution is triggered.
The maker COMIT-app is finished! Keep it running in a separate terminal, waiting for the taker to take the order and start swap execution!
Extending the maker-app
In this tutorial we only focus on the happy-path, meaning that we assume that we always have a
redeem scenario, where the other party properly funds and
redeems the funds.
For a complete solution the maker and taker applications would have to deal with
refund scenarios as well.
These are scenarios where the the counterparty does not fund the swap in time, and the maker would take the locked up funds back.
Here is come inspiration what can be done to extend the maker application:
- Implementing proper time constraints for redeem and adding the refund scenario,
- Properly handling multiple swaps with different parties,
- Adding actual market making strategies,
- Adding a more advanced (decentral) order-book,
- Changing to use external wallets rather than using the comit-sdk wallet.
Future tutorials may tackle some of these points.