๐Ÿงช
atomiq.exchange
  • ๐ŸŒŸIntroduction
  • โš—๏ธLiquidity provider nodes (LPs)
    • ๐Ÿƒโ€โ™‚๏ธRunning LP node
    • โŒRunning LP node (deprecated)
  • ๐Ÿ”“Security
  • ๐Ÿ”ฑSubmarine swaps (lightning)
    • ๐ŸŒฉ๏ธSolana -> Bitcoin Lightning
    • โšกBitcoin Lightning -> Solana
  • ๐ŸชถBitcoin light client (on-chain)
    • ๐Ÿ”—Solana -> Bitcoin on-chain
    • โ›“๏ธBitcoin on-chain -> Solana
  • SPV swaps (on-chain)
Powered by GitBook
On this page
  • Parties
  • Process
  • Successful payment
  • Failed payment
  • LP node went offline
  • Diagram
  1. Bitcoin light client (on-chain)

Solana -> Bitcoin on-chain

Parties

  • payer - the one paying in solana or spl token and using intermediary to do the swap

  • LP node - handling the swap receives solana or spl token and sends on-chain bitcoin

  • payee - recipient of the bitcoin on-chain payment

Process

  1. Payer queries the LP node off-chain, sending the payee's bitcoin address and an amount he wishes to send, LP node returns the network fee along with his swap fee needed for the swap

  2. Payer reviews the returned fees and sends a transaction to construct a PTLC on Solana (this also increments a nonce N in the contract state):

    • paying the funds to LP node if he can prove that he sent a pre-agreed amount to payee's address in a bitcoin transaction (tagged with nonce N to prevent replay attacks) that has >=6 confirmations

    • refunding the payer, but only after locktime T

    • refunding the payer, but only with a specific message Mr (refund) signed by LP node (for co-operative close, when payment fails for any reason)

    NOTE: If payer tries to send same amount to same address twice, even though bitcoin addresses should not be reused this can't be avoided as payee's wallet implementation is out of our influence, in this case LP node could use the same transaction proof to claim both of the PTLCs and paying bitcoin transaction just once. To prevent this, it is required that each transaction is tagged with the 7-byte nonce N with least significant 3 bytes prefixed with 0xFF being written as nSequence field for ALL inputs and rest - 4 most significant bytes being treated as integer, adding 500,000,000 to that integer and writing it as locktime field for the transaction.

  3. LP node observes the creation of PTLC on Solana and proceeds to send a bitcoin transaction.

Successful payment

  1. Transaction confirms on bitcoin chain (has >=6 confirmations) LP node proves this via bitcoin relay and claims the funds from the PTLC

Failed payment

  1. The payment was unsuccessful, maybe LP node ran out of funds in the meantime, or LP node thinks it's not possible to safely send the transaction with pre-agreed fee and have it confirm in under locktime T.

  2. Upon request by payer, LP node creates a specific signed message Mr (refund), allowing the payer to refund his funds from the PTLC (cooperative close)

LP node went offline

  1. Payer waits till the expiry of locktime T and then refunds his funds back from the PTLC

Diagram

PreviousBitcoin light client (on-chain)NextBitcoin on-chain -> Solana

Last updated 2 months ago

Solana -> Bitcoin on-chain swap process (Intermediary = LP Node, Smart chain = Solana)
๐Ÿชถ
๐Ÿ”—