Token swap between EOS mainnet and Telos, using escrow contract

The escrowescrow smart contract development is sponsored by EOS Geneva (BP name: switzerlanda). The contract is deployed on EOS Mainnet and Telos.

This article illustrates how a token swap can be executed between the two networks. EATCOIN on EOS mainnet and TEACH on Telos are tokens belonging to the same project, Education And Technology, led by Mina Bebawy. The whitepaper is available for downloading.

The swap is performed by using escrowescrow smart contract which is designed to be used for any kind of e-commerce in eosio blockchain. The article illustrates the procedure using command-line cleos command, and a web UI will likely be developed soon.

We use Bourne shell aliases in order to send transactions to both networks. The article assumes that the corresponding wallets are already unlocked.

alias mcleos='cleos -v -u https://api.eossweden.se'
alias tcleos='cleos -v -u https://api.telosuk.io'

First, arbiters need to register themselves both networks. An arbiter is an account that is only used in dispute resolution. Both parties in a deal should recognize the arbiter as an authority.

mcleos push action escrowescrow setarbiter '["eatschools11", "Mina Bebawy", "minabebawy@hotmail.com", "Education and technology", "https://eatschools.com/", "", "EG"]"' -p eatschools11@active
tcleos push action escrowescrow setarbiter '["eatschools11", "Mina Bebawy", "minabebawy@hotmail.com", "Education and technology", "https://teachology.io/", "", "EG"]"' -p eatschools11@active

In this exercise, we use the following accounts. Account names are the same in both networks for simplicity, but they can also be different names belonging to different users:

• cc32dninexxx is used as a treasury. The account has enough tokens for swapping in both networks. This is a liquidity provider for performing the swap. In this example the swap has zero commission.
• The user has an account name lunarcrawler in both networks. The mainnet account has 1000 EATCOIN, and the user wants to convert them to 1000 TEACH on Telos.

The recipient in Telos can be a different user, and in this case this would be a cross-chain payment.

# lunarcrawler in both networks requests a transfer. 
# The execution term is set to 3 days in both deals.
tcleos push action escrowescrow newdeal '["lunarcrawler", "lunarcrawler@eos sends 1k EATCOIN to cc32dninexxx@eos, then cc32dninexxx@telos sends 1k TEACH to lunarcrawler@telos", "teachology14", "1000.0000 TEACH", "cc32dninexxx", "lunarcrawler", "eatschools11", 3]"' -p lunarcrawler@active
# returned "deal_id":3938512920
mcleos push action escrowescrow newdeal '["lunarcrawler", "lunarcrawler@eos sends 1k EATCOIN to cc32dninexxx@eos, then cc32dninexxx@telos sends 1k TEACH to lunarcrawler@telos", "eatscience14", "1000.0000 EATCOIN", "lunarcrawler", "cc32dninexxx", "eatschools11", 3]"' -p lunarcrawler@active
# returned "deal_id":246854833

As the deals are created, the other party needs to accept them:

# cc32dninexxx in both networks accepts the deals
tcleos push action escrowescrow accept '["cc32dninexxx", "3938512920"]' -p cc32dninexxx@active
mcleos push action escrowescrow accept '["cc32dninexxx", "246854833"]' -p cc32dninexxx@active

First, the treasury account on Telos places a deposit of TEACH tokens, and then the user places a deposit of EATCOIN on mainnet:

# cc32dninexxx@telos places a deposit on Telos
tcleos push action teachology14 transfer '["cc32dninexxx", "escrowescrow", "1000.0000 TEACH", "3938512920"]' -p cc32dninexxx@active
# lunarcrawler@eos sees that the Telos deal is funded and 
# places a deposit on Mainnet
mcleos push action eatscience14 transfer '["lunarcrawler", "escrowescrow", "1000.0000 EATCOIN", "246854833"]' -p lunarcrawler@active

At this moment, the deal can still be canceled: the user on Telos has the right to cancel it, as well as treasury on mainnet. If either party cancels the deal, the other one has the possibility to cancel the corresponding deal in the other network.

The user on Telos sees that the treasury on mainnet has placed the deposit, so he or she locks the funds on Telos:

# lunarcrawler@telos locks the funds on Telos
tcleos push action escrowescrow delivered '["3938512920", "Mainnet deal ID 246854833 is funded"]' -p lunarcrawler@active

At this moment, the treasury is still able to cancel the deal on mainnet. If it happens, the deal on Telos is locked: the treasury would not want to release TEACH to the user, and the user is unable to cancel the deal. So, after 3 days the arbitration starts, and the arbiter would return the TEACH token to the treasury account.

The situation would be similar, but opposite, if cc32dninexxx@eos sends the delivered action first. Then the Telos user would be able to cancel the deal, and the deal on EOS would wait for arbitration.

So, in a normal workflow, the treasury on mainnet locks the deal as well:

# cc32dninexxx@eos locks the funds on Mainnet
mcleos push action escrowescrow delivered '["246854833", "Telos deal ID 3938512920 is funded"]' -p cc32dninexxx@active

At this point, both deals are secured. The only thing that needs to be done is calling goodsrcvd action in both networks. If either party skips this step, the deal goes into arbitration after 3 days:

# lunarcrawler@eos releases the payment toward cc32dninexxx@eos
mcleos push action escrowescrow goodsrcvd '["246854833"]' -p lunarcrawler@active
# cc32dninexxx@telos releases the payment toward lunarcrawler@telos
tcleos push action escrowescrow goodsrcvd '["3938512920"]' -p cc32dninexxx@active

As illustrated, the process is atomic and decentralized. No server-side infrastructure is required. In order to simplify the procedure for a normal user, a proper web UI needs to be developed.