A Truly Decentralized Cross-Chain Atomic Swap Exchange

Atomic Swaps were designed to be automated, self-enforcing crypto-currency exchange contracts that allow crypto-currencies to be traded peer-to-peer without the need for a trusted third party or centralized service. Even though Atomic Swap by nature is decentralized, most of the exchanges that provide Atomic Swap services usually depend on some central server. This server is used mostly for swap pair matching and swap request or order book management.

Over the last 8 weeks I have been working on True Swap, which tries to remove these dependencies of a centralized trusted server by completely shifting the swap pair matching and order book management to the blockchain and the client application itself.

How True Swap Works

True Swap is a complete decentralized exchange where users can come and place their Swap requests either in Ethereum or Tezos and get their assets exchanged without any centralized server facilitating the swap process. True Swap currently supports Ethereum and Tezos and is deployed on the testnets - Goerli and Carthagenet.

True Swap provides two options, a user can either create a new swap request or respond to an existing request. When a new swap request is created by a user(also called the initiator) the client app directly places the request into the corresponding blockchain contract, the funds are also locked in for a specified period of time with that request. Unlike normal swap contracts this request swap doesn’t not have the counter-party details when it is initiated.

Another user(also called the counter-party) can now query the blockchain directly to get a list of all the valid swap requests and respond to a request that suits their needs, similar to the swap request creation the client app generates a swap response in the blockchain contract and locks in the assets.

Once a response is found the initiator and counter-party fill in the details of the participants in their respective swaps after which the client app proceeds with the actual swap and finally completes the exchange.

All the stages of the swap from the beginning to the end are performed through the client application itself, after the swap request and responses are created the client app will automatically take over and complete the swap on behalf of the user.

If a suitable response is not found the swap will be automatically refunded after the specified expiry time by the client app.

Limitations

Currently the only way to complete a swap is to wait for a peer to respond to the swap directly, this can take some time, the client app automation helps in this by taking over the swap after it’s creation by the user and automatically redeeming or refunding the assets. Another way to overcome this time barrier is to introduce liquidity pools, the users can then instantly swap assets with the pool in exchange for some specified fee(reward for liquidity provider).

Besides the time duration, it is a requirement for the client app to be online throughout the swap process because all transactions are carried out by the application itself, if the app goes offline during an active swap currently it is not possible to resume.

This project was created as a part of the Tezos India Fellowship 2020, I would like to thank the whole Tezos India team for providing this opportunity and for their constant support. I would also like to thank my mentor Mike Radin and the Cryptonomic team for providing their guidance and support.

Links

  1. Code Repository : https://github.com/gdsoumya/AtomicSwap
  2. Live Application : https://gdsoumya.github.io/AtomicSwap
  3. Demo Video: https://www.youtube.com/watch?v=7Sm22k-VLBM&t
8 Likes

Congratulations on all your hard work and also for using the native Harbinger oracle in the process. I’m looking forward to trying it out. I also hope that you are getting good feedback in some other venue(s) since this one has been a bit quiet of late.

4 Likes

What does this look like, architecturally?

1 Like

Hi @faddat, I don’t have an architecture diagram right now but I’ll try to explain the best I can.

TrueSwap doesn’t require any dedicated backend, what happens is that when a user opens the client app they directly query the blockchain(ethereum or tezos) for all the information. The state of a swap request/response is stored directly into the chain itself. There are 2 modes as you must’ve read in the above post, the first one is Creating a Swap Request, here the user directly creates an entry for a swap request which is basically just containing the initiator details, the swap amount requested and nothing else. So the request is basically an entry in a map structure of a contract, the key is the hashedSecret of the Atomic Swap.

Now another user uses the Client app to Respond to the Swap, in this case they can query the contract storage directly and find swap requests that haven’t yet been responded. The user can now choose from a list of these swaps and basically create a response swap in the other chain, this response swap is very similar to what the initial request swap looked. This swap will also use the same HashedSecret as the key for the swap entry in the other chain, this hashedSecret is basically used to match the swaps.

Once the 2 swaps are created the corresponding clients now monitor the swap in the other chain using the hashedSecret and with every change in state the client also updates the state of it’s own swap. For example in the beginning the 2 swaps just had only the initiator details but not the counter-party details, so once a response swap is detected by the first client, the client app updates it’s own swap and includes the details of the counter-party who created the response swap in the other chain. Once that happens the second client detects the change and does the same with their swap. Once both the details of the initiator and counter-party are stored in the swap record the actual swap can take place. The first client goes ahead and redeems the fund from the response swap and after which the second client can redeem the funds from the request swap too.

Unlike traditional swaps TrueSwap does not fill the details of the counterparty at the initiation of the swap, but rather waits for the response swap. This is how TrueSwap manages to double the Swap Contract as an order-book too.

(I did not go into the details of how the atomic swap happens if you don’t already know how it works you can read about it here)