Support atomic swap between chains

[DylanVerstraete]

To be specced

[LeeSmet]

There is 2 functional parts to this issue:

• A way to find someone who is selling TFT (note that it has been decided to only implement 1 side of an order book, sell orders. A buyer must fill in an existing sell order in order for a trade to happen, opening a buy order is thus not supported. This mainly serves to prevent automated bots from manipulating too much)
• The actual swap after an agreement to trade has been done. This requires support for setting up an atomic swap on the required blockchains.

To list and find sales, we will use NIP15. This protocol on top of nostr allows to list items for sale with a configurable price and currency. By reusing this (at least to post sales), existing nostr compliant clients will be able to see sale offers as well.

It should be noted that we could implement buy offers by inverting the currency and price. In the current setup currency will be the token for which the TFT are sold and TFT will always be the product. If buys offers are required, we can set currency to TFT and the product to the currency we are trading against.

Listing a sell offer

In order to list a sell offer for some TFT, the seller first creates a stall. By creating this stall with a well known custom TAG, the protocol can easily filter stalls selling TFT on the connected relay(s).

Then, the seller creates the product, which is the actual sell order. Here, the currency field will be set to the currency code the seller wants to receive for the TFT. Price is set to the price in said currency for 1 TFT, and quantity is set to the amount of TFT the seller is willing to sell. Unfortunately the quantity field is an integer and not a float according to the spec. However because of the relatively low value of a TFT (compared to BTC/ETH), it is fine to restrict trades to only whole TFT. The buyer is free to buy any amount of TFT, up to the listed amount for sale . The amount of TFT bought is negotiated in the next phase.

Negotiating a sale

If a client wants to buy tokens, we will have to diverge a bit from the spec. The first part, asking for the amount of tokens, can still be implemented according to spec. At this point, the seller can accept or reject the request. If the request is rejected (maybe another swap is in progress or has just completed), the seller SHOULD send back a structured message indicating it doesn't want to accept the offer from the buyer. If it is accepted, the seller should notify the buyer and start setting up the swap. The TFT address of the buyer can be communicated in the order message from the buyer to the seller. Likewise the address on the payment chain can be added by the seller in the item listing. This makes sure no further messages are needed to communicate this.

Swap details

todo

Atomic swap on Ethereum

This is fairly straightforward. A contract is deployed which exposes function to setup, claim, and refund a swap. To setup a swap, some ETH is locked in the contract, a hashed secret is set, a timeout after which funds can be reclaimed, and an address of the person the funds need to go to. To claim the funds, a claim call is done identifying the locked ETH, as well as the secret. The contract checks and makes sure the secret, once hashed, matches the hash set. Reclaim can be done after the time has passed, to the person who locked the ETH.

Atomic swap on stellar

todo

[LeeSmet]

swap driver is code complete, still needs to be exposed and tested

Current logic is made for the demo, i.e. it has a very specific set of constraints: Goerli Eth vs Stellar Testnet TFT, the sell order MUST be placed before attempting a buy, you MUST but at most the size of the sell order, and there is only one swap for the sell order ,even if it isn't completely filled.

Specs on how to improve the driver and make it generic to follow

[LeeSmet]

Managed a swap between stellar TFT and ethereum as POC, now need to consider how the code is generalized