Skip to content

Latest commit

 

History

History
85 lines (56 loc) · 3.15 KB

uc-client-7_accept_swap_offer.md

File metadata and controls

85 lines (56 loc) · 3.15 KB
Raw

UC-Client-7: Accept swap offer

A buyer finalizes the atomic swap by adding one or more inputs to the swap offer transaction, carrying enough value to pay for the payment output, and by adding a payload and reference output to the transaction, to transfer the tokens to the buyer. A change output can optionally be added. Once the transaction is signed, it can be broadcasted, which "executes" the swap, transfering bitcoins to the seller, and tokens to the buyer.

This use-case describes the process of accepting an atomic swap offer and finalizing the trade.

Scope:
  • Swap client
Level:
  • User-goal
Primary actor:
  • Buyer
Supporting actors:
  • None
Preconditions:
  1. The buyer configured the system's settings to connect to a running Omni Core RPC server
  2. The buyer received an unfinalized swap offer transaction from the seller (UC-Client-6)
Main success scenario:
  1. The buyer requests to accept and finalize an atomic swap
  2. The buyer provides the transaction stub from the seller (UC-Client-6), it's transaction inputs (i.e. the hash of the signed funding transaction, the index of the funding output to the script lock destination, the corresponding scriptPubKey and the redeemScript for the locked destination), a destination to send the tokens to, and a source address to pay for the swap
  3. The system determines the identifier and amount of locked tokens
  4. The system adds a payload to the transaction stub, sending the previously determined amount of tokens (either as "simple send" or "send all")
  5. The system determines the total output value including transaction fees of the transaction
  6. The system adds sufficient inputs to the transaction, spending from the specified source to pay from
  7. The system adds a reference output to the transaction stub, with the buyer's specified destination, whereby the reference amount also serves to carry change
  8. The system signs the transaction with the signature hash flag "ALL"
  9. The system broadcasts the signed transaction
  10. The system returns the hash of the broadcasted transaction
Extensions:

3a. The system determines the locked destination has a zero balance

  1. The system indicates the failure
  2. The use-case ends

6a. The system determines the buyer has not enough coins to pay for the transaction

  1. The system indicates the failure
  2. The use-case ends

8a. The system fails to sign the transaction

  1. The system indicates the failure
  2. The use-case ends

9a. The system fails to broadcast the funding transaction

  1. The system indicates the failure
  2. The use-case ends
Success guarantee:
  1. The tokens are transferred to the buyer
  2. The coins are transferred to the seller as payment
Notes:
  • Alternatively the buyer may provide a set of unspent outputs, instead of a source address to pay from
  • Alternatively the buyer may provide the payload to add to the transaction, to reduce the need for a fully synchronized chain