Atomic Swap with USDT: Swap Online solution in two hundred lines of code

Published in

SwapOnline

7 min readAug 15, 2018

On the eve of the release on the mainnet, the team of the cross-chain wallet Swap Online is publishing a research study and the code of the atomic swap using USDT.

USD Tether — the equivalent of the dollar on Omni Layer

The solution described above with the protocol “over” the Bitcoin network gave life to one of the most controversial cryptocurrency projects of the last two years — Tether. Tether (symbol Tether — ₮, ticker — USDT) is a hybrid cryptocurrency with a rate binding to one US dollar. Moreover, according to the assurances of Tether Limited, the issuer of the given tokens, the “binding” is to be understood literally, as each purchased token of USDT corresponds to one US dollar available at the disposal of the company.

If we take the three largest exchanges based on their daily turnover of transactions at the time of writing (Binance, OKEx and HuObi), and then track the five most popular trading pairs for each, we will encounter USDT in 13 out of 15 cases.

USDT — the token with the largest capitalization in the world.

All this generates great community interest in faster, safer and cheaper solutions for exchanging Tether into other currencies. Obviously, such a solution could be atomic swaps, which are instant, decentralized cross-chain exchanges. The Komodo laboratory, the main headliners of this technology, who presented it in the autumn of 2017, reported on the successful exchange of KMD to USDT carried out on the BarterDEX platform, Komodo’s own exchanger.

At the same time, according to our data, the developers of Komodo made a swap on the ERC20-a version of Tether, which is only available in 3% of cases. Approximately 60 million USDT from global turnover can thus be exchanged using this method, which, obviously, cannot be considered as a solution to the problem. Striking examples of imperfections of existing solutions can be found even on Etherscan.

This user of the Ethereum network was never able to buy USDT.

This fall, the team of Swap Online is ready to present an atomic swap with Tether. And here’s how we did it.

How Omni conducts transactions

To carry out the Omni transaction, a user needs to create a regular Bitcoin transaction-transfer of 546 satoshi (minimum) with an additional output storing payload using the OP_RETURN op-code. An example of such a transaction. The payload is a mandatory part of any Omni transaction, as it is a sequence of bytes containing all the necessary information about the transaction.

Let us consider what information is stored in the payload itself

transaction marker — 4 bytes, the mandatory part of any Omni payload is always equal to 0x6f6d6e69 — ASCII code omni. If the first 4 bytes of the sequence are not equal to 0x6f6d6e69, then this sequence is not a payload of Omni.

version — 2 bytes, an analog version of the transaction in Bitcoin. For the described algorithm to work, version 0 is used, or that is the same as 0x0000.

transaction type — 2 bytes, transaction type, for an atomic swap it is sufficient to use only “Simple send” transactions, as simple send is the usual sending of omni currency from its address to the address of the recipient. Simple send corresponds to the transaction type code 0, that is, the next 2 bytes 0x0000. Other possible types of transactions exist in Omni.

token identifier — 4 bytes, identifier of the currency used. For example TetherUS has the identifier 31 or 0x0000001f. All tokens created by the Omni protocol at this time can be seen via the following link.

amount — 8 bytes, for a transaction of type Simple send, this is the amount of the sent currency.

As you can see, payload does not store the addresses of senders and recipients of the transactions, these addresses are determined by the Bitcoin transaction in which the payload output was detected. By scanning inputs, the Omni protocol determines who makes the transfer by finding the output of the corresponding address from among the inputs of the transaction p2pkh.

Thus, for a transfer from Alice to Bob of, for example, 50,000,000 TetherUS, we need to create a Bitcoin transaction where one of the inputs will refer to the p2pkh output corresponding to the Alice address. It is also important that this entry be the first in this transaction (the index of this entry in the received transaction would be is minimal or none at all). One of the outputs of this transaction should be the output of p2pkh to Bob’s address, and another output must have been one of the outputs with the following payload:

Example 1

Example 2

Atomic Swap on Omni Layer

Suppose that Alice and Bob are willing to make an inter-blockchain exchange of cryptocurrencies. Alice wants to exchange the units of any Omni currency, for example TetherUS (the given currency has the currency identifier # 31 in the Mainnet, then in the text we will only talk about this currency of the Omni protocol, since it is the most popular at the moment, but the algorithm below will work for any currency of the Omni protocol as well) for b units of a cryptocurrency working on another blockchain. (Omni works on top of the Bitcoin blockchain, of course, according to the algorithm below it is possible to exchange TetherUS for Bitcoins, but due to their work on one and the same blockchain, this exchange can be done in a different, more efficient way).

Glossary

A — blockchain of Bitcoin.

B — the blockchain of the cryptocurrency for which TetherUS is being exchanged.

a — the sum of TetherUS, which Alice wants to exchange.

b — the sum of the cryptocurrency of the adjoining blockchain B, to which Alice wants to exchange her a TetherUS.

Creating a Transaction

1) Bob generates a random value secret.

2) Bob calculates the secretHash by performing the following operation: secretHash = RIPEMD160 (secret)

3) Bob creates and sends an htlc transaction sealed by secretHash

4) Bob sends Alice a secretHash value, and a hash of the hrlc transaction he created in the previous paragraph in order for Alice to make sure that the correct htlc transaction is actually present in the B blockchain.

5) Alice received from Bob the secretHash and hash of the htlc-transaction Bob created, and is convinced that such a transaction is really present in the B blockchain, and that this is indeed a htlc-transaction sealed by the secretHash value.

6) using the received secretHash, Alice creates the following transaction and translates it into the Bitcoin blockchain:

Let us call such a transaction financing_tx. In fact, it is almost an ordinary Bitcoin htlc transaction that is used in atomic swap with the only difference that in the amount field, 546 satoshi is the minimum number of Bitcoins that can be at the output of the transaction, below this value, Bitcoin counts the transaction as dust and does not conduct it.

7) Alice creates a transaction according to the following scheme:

Let us call this transaction redeem_tx. Alice creates such a transaction with two inputs: the first is the input referencing the output of funding_tx, which contains the htlc script. Alice does not sign this script, that is, the SigScript field remains completely empty. The second input is the input referring to any unspent exits of Alice, the main condition is that at this output stage there are enough Bitcoins to pay the transaction fee, and this entry is signed by Alice with her private key with the signature type SIGHASH_ALL (that is, she signs the entire transaction except for SigScript fields on the inputs transaction, which makes this transaction immutable. The outputs of the same transaction are the elementary Simple Send and a TetherUS from Alice to Bob (details of what Simple Send, payload is and how it works can be found in another section).

8) Alice sends Bob the redeem_tx created in the previous paragraph and the one she signed herself.

9) Bob got the redeem_tx sent by Alice, checks it, just looks through the inputs and outputs, making sure that this is really a transaction that Alice should have created using the real algorithm. After that, Bob signs the transaction with his private key and provides the secret value in the SigScript of the corresponding redeem_tx entry.

10) Bob sends the signed redeem_tx transaction to the blockchain, thereby transferring the TetherUS currency from Alice to himself. Note — before carrying out this step, we still need to check that Alice’s address has the necessary amount of TetherUS.

11) Alice looks through blockchain A and gets the value secret and uses it in the B blockchain to transfer the funds using the htlc transaction Bob created in point 3. The exchange ends here.

Stating the obvious: naturally the timelock value used by Bob when creating the htlc-transaction must be significantly longer than the timelock that Alice uses, since her htlc transaction should be spent earlier than the htlc created by Bob. This is necessary so that Bob cannot manage to spend both htlc.