Taking the order and swap execution
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.
info
In this section we focus on the taker side and work on taker.ts
info
It is assumed that the maker application is finished at this stage, and running in a separate terminal.
In this section we take the order triggering the swap execution.
Taker takes the order
In the previous section we have retrieved an order that was handed to the taker as TakerOrder
.
The taker can not take the order:
When taking an order several things will be handled by the comit-sdk:
- The maker is notified that the order has been taken through the maker's order HTTP service.
- The taker's cnd node will trigger a swap request to the maker. The maker is still listening for incoming swaps as described earlier.
- When sending a swap request to the maker, the taker cnd will initialise the swap on the taker's side.
The taker gets an instance of a Swap
back which will be used for executing the swap.
Let's log some information on the taken order before moving on to the execution of the swap:
The maker's Order is stored as rawOrder
inside the TakerOrder
class of the taker.
Taker Swap Execution
As for the maker, the taker application will also use the comit-sdk to handle fund
and redeem
of the swap.
The taker also has to specify the polling interval to be used by the comit-sdk to check if an action for a certain swap is already available in cnd; as well as a timeout:
The code for handling the fund and redeem transaction is the same as for the maker. But, the taker funds ether and redeems bitcoin, thus the taker will receive an Ethereum transaction ID from the comit-sdk:
Note that the taker's fund transaction will actually be the first transaction that will be available (on the taker cnd), because the taker is in the role of Alice and has to fund first. Meanwhile, on the maker side, the fund action will only become available (in the maker's cnd) once the taker's fund transaction (sent by the taker's comit-sdk using the taker's wallet) was observed. The same accounts for redeeming. The relatively complex ping-pong between taker and maker is handled by the comit-sdk.
Redeeming will yield a Bitcoin transaction id for the taker:
As for the maker we want to print the final balance after the successful swap. Additionally we also add wait for two seconds to be sure the transaction was observed by the wallet, so the balance is printed correctly:
At this point the taker application is done as well. Let's swap!
Summary
The complete taker application:
Make sure:
- The environment is running! (you can trigger is with:
yarn start-env
) - The maker application is running! (you can start it with:
yarn maker
)
When running the taker application with yarn taker
you should see output like this for the taker:
Since the taker now triggers the swap execution, the maker application will also finish after swap execution. You should see output like this for the maker:
tip
This tutorial is a slightly simplified version of the btc_eth
example that can be found in the examples
folder of the project you created with create-comit-app.
If you have trouble with the code you wrote you can also have a look at the example as a complete reference.
Extending this tutorial
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.
Furthermore, there are various features that can be improved or added, e.g. adding a (decentral) order-book.
Future tutorials may introduce more advanced topics.