Hot on the heels of the Bitcoin-Tari Atomic Swap implementation, we have written a RFC proposing two methods to perform Monero-Tari Atomic swaps. These atomic swaps are significantly more complex than a Bitcoin atomic swap because Monero does not include any scripting features or appropriate time-locks. This means that the majority of the complexity of the atomic swap needs to be done on the alternate chain that is being swapped with Monero.

The RFC proposes two methods; the first is inspired by the approach taken by the Farcaster project and Comit network. The second method is very similar but uses a slightly different approach to the signatures. The RFC goes into great detail. In short, let’s assume that Alice wants to send Bob some Tari in exchange for Monero.

Alice and Bob will collaborate to produce several transactions that contain aggregate keys and adaptor signatures that become valid at a staggered timeline of lock heights. The parties will then publish the transactions in an order that ensures both parties funds are safe at all times.

The gist is that Alice and Bob collaborate to produce a Monero transaction locking up Bob’s XMR that is spendable by an aggregate key. Alice and Bob both have a secret portion of this key, and the Monero transaction can only be spent once one party has both parts of the aggregate key. This will be revealed when claiming the transactions that will be placed on the Tari chain. The Tari transaction is constructed and published first because it has multiple modes of refunding.

Alice and Bob collaborate to produce a Tari transaction that locks up Alice’s portion of the swap that can be spent by three different script keys. If any of these keys are used to spend the output, information about the Monero aggregate key is revealed, allowing the correct party to claim the Monero. Usually, it allows Alice to claim the Monero once Bob claims the Tari, but there are contingencies for Bob refunding his Monero after some expiry period.

The following is the TariScript that defines how the script keys can be used to spend Alice’s portion of the swap.

   CheckHeight(height_1)
   LtZero
   IFTHEN
      PushPubkey(K_s)
   Else
      CheckHeight(height_2)
      LtZero
      IFTHEN
         PushPubkey(K_r)
      Else
         PushPubkey(K_l)
      ENDIF
   ENDIF

This script says that before height_1, the output can be spent if you can provide a signature for K_s, which will reveal Bob’s portion of the Monero key allowing Alice to claim the XMR. K_s is an aggregate key with a part that Alice needs to provide to Bob before he can claim it; she will provide this portion of the key when she sees Bob has published the Monero transaction. After height_1, but before height_2, if Bob has not claimed the XTR then Alice has an opportunity to claim a refund of her XTR via K_r. Doing this will reveal Alice’s portion of the Monero key, allowing Bob to reclaim his XMR. If Alice does not claim her refund before height_2 then Bob is able to claim the XTR via K_l, the lapse key. This, however, reveals Bob’s portion of the Monero key so that Alice now has the information required to claim the XMR when she eventually comes back online.

Once all of the aggregate keys have been constructed by the two parties, Alice will publish the Tari transaction, knowing that if Bob does not publish the Monero transaction she will be able to reclaim her funds after the time lock expires. Bob cannot claim the XTR transaction yet because Alice still needs to provide him with her portion of K_s. Bob now knows that he can safely publish the Monero transaction because either Alice will give him her portion of K_s or else she will reclaim her XTR using K_r, which will reveal her portion of the Monero key so that he can reclaim his XMR. Otherwise, enough time will pass that he can claim the XTR using K_l. Once he has published the Monero transaction, Alice will give him her portion of K_s. Bob can then claim his XTR revealing his portion of the Monero key, and then Alice can claim her XMR.

This approach to the problem requires a very complex initial negotiation between the parties. This negotiation will consist of many rounds of communication. In the RFC, a variation on this approach is proposed that does not use adaptor signatures. In theory, this will reduce the number of initial communication rounds significantly. However, this approach still needs to be reviewed. We invite the community to check out the RFC and welcome any input on the design of these protocols.