A Smart Contract Scheme to Swap Tezos with any Crypto.

When we consider directly swapping cryptos, there have been a number of methods that have been developed by the crypto community over the years. Notable amongst these are;

• The use of third party escrow accounts.
• The use of smart contracts like atomic swaps and hash time locks.
• Asset (Crypto) tokenization can also be placed in this category. If BTC is tokenized on a Tezos smart contract, then buying such a token is effectively a swap.

Here we present a procedure for swapping that combines a smart contract and a traditional server. Basically, the tezos smart contract depends on the server to act as an oracle professing whether the external crypto transaction has taken place or not.

Let’s first go through the steps involved in this procedure. Suppose one wants to do an XTZ/BTC exchange, here are the steps involved.

1. Tezos owner transfers the exchange amount to a special tezos smart contract. They also provide the bitcoin address they want to use for receipt.
2. A bitcoin owner wanting to exchange Tezos queries the smart contract for available offers. When they decide to go with a particular offer, they trigger a function in the smart contract and also provide their Tezos address for receipt.
3. The bitcoin owner is now urged to transfer their bitcoin to the bitcoin account provided by the Tezos owner.
4. An oracle server is set up to periodically query the smart contract for pending bitcoin transactions. That is, it reads from the smart contract that a certain address is expected to receive a certain amount of bitcoin.
5. It then queries the Bitcoin blockchain for confirmation of receipt and sends results to the Tezos smart contract.
6. The Tezos smart contract will transfer tez to the bitcoin owner if the oracle server provides proof that the bitcoin transaction has been made.
7. In the smart contract design, the oracle server’s Tezos address has to be registered as a trusted agent or oracle.
8. This means that the smart contract can register different oracle servers.

We could adapt the smart contract to facilitate exchange for XTZ/(Any Coin) pair so long as we set up an oracle server that can alert the smart contract of transactions happening on the other block-chain.

The use of the oracle here is to confirm that the required transaction on the other block-chain has happened.

There are other ways to achieve this confirmation like using the Atomic Swap approach.

Tezos Exchange Pool

This proposal can be extended to act as a continuously available Tezos Exchange Pool. Instead of waiting to match users before the exchange begins. Tezos owners can transfer ahead of time their coins to the smart contract. This way, anytime someone wants to change bitcoin, there will already be tez available for the exchange.

Also, matching doesn’t have to be one on one. For instance, suppose someone already transferred to the smart contract an amount to be exchanged, say 100 XTZ. We don’t need to wait for a bitcoin owner in need of 100 XTZ before executing the exchange. Suppose there is a bitcoin owner in need of 40 XTZ, the exchange can still be executed leaving 60 XTZ worth to be exchanged. The remaining can be exchanged with other bitcoin owners.

Similarly, a bitcoin owner wanting to exchange say 10 BTC doesn’t have to wait for one tezos owner who also needs 10 BTC. Rather, the exchange can happen by combining the request of other tezos owners.

Implementation

Implementation would require a suitable smart contract that is able to meet the properties of what is defined above. Trusted oracle servers also need to be setup. Oracle servers need to be registered with the smart contract before communication can happen. That is, the smart contract will authenticate the oracle server based on their Tezos address. One thing that could prove tricky is the verification of external transaction since all the information the oracle server has is that a particular address expects to receive a certain amount of coins. The oracle server does not know which address the coin is going to come from. For instance, if A is to transfer bitcoin to address xyz, the oracle is only checking xyz for incoming transactions without knowing which address A is going to use. Although the chances are little that another person B will send the same amount expected to xyz in a given time frame, it is still a possibility to consider. In a future post, we will shed light on some implementation details we can use to reduce this occurrence.