Skip to content

Latest commit

 

History

History
90 lines (64 loc) · 6.84 KB

sol-onchain-singleuseseals-swaps.md

File metadata and controls

90 lines (64 loc) · 6.84 KB
Raw

On-chain swaps between bitcoin single-use-seals/tokens (RGB & Taro) and Solana utilizing bitcoin relay

Describes a trustless swap between single-use-seal based bitcoin tokens (such as RGB & Taro) and Solana.

Uses bitcoin relay for proofs that a bitcoin transaction was really sent and confirmed on bitcoin blockchain. This works by storing SPV (simplified payment verification) copy of the bitcoin blockchain on Solana, meaning bitcoin blockheaders (with merkle roots) are verified and stored on Solana. Anyone can then prove that he sent a bitcoin transaction with a merkle proof.

PTLC (proof-time locked contract)

Contract similar to HTLC (hash-time locked contract), where claimer needs to provide a proof instead of a secret for a hash. In this case the proof is transaction verification through bitcoin relay.

Solana -> Bitcoin single-use-seal/token

Parties

  • payer - the one paying in solana or spl token and using intermediary to do the swap
  • intermediary - handling the swap receives solana or spl token and sends single-use-seal/token on bitcoin
  • payee - recipient of the bitcoin's single-use-seal/token

Process

  1. Payer queries the intermediary off-chain, sending the payee's bitcoin address/UTXO/Blinded UTXO and an amount he wishes to send

  2. Intermediary creates state transition and consignment, and returns the consignment, the network fee along with his swap fee needed for the swap

  3. Payer verifies the consignment, reviews the returned fees and sends a transaction to construct a PTLC on Solana:

    • paying the funds to intermediary if he can prove that he sent a bitcoin transaction, spending his single-use-seal (as set in the consignment), commiting to the consignment (either through OP_RET or TAP_RET), 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 intermediary (for co-operative close, when payment fails for any reason)

  4. Intermediary observes the creation of PTLC on Solana and proceeds to send a desired bitcoin transaction.

Successful payment
  1. Transaction confirms on bitcoin chain (has >=6 confirmations) intermediary proves this via bitcoin relay and claims the funds from the PTLC
Failed payment
  1. The payment was unsuccessful, maybe intermediary ran out of funds in the meantime, or intermediary 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, intermediary creates a specific signed message Mr (refund), allowing the payer to refund his funds from the PTLC (cooperative close)
Intermediary went offline
  1. Payer waits till the expiry of locktime T and then refunds his funds back from the PTLC

Bitcoin single-use-seal/token -> Solana

Requirements

  • for abslute maximum security payee should be online till bitcoin transaction confirms otherwise he could lose funds

Parties

  • payee - recipient of the solana/spl token, using intermediary to do the swap
  • intermediary - handling the swap, sends solana or spl token and receives bitcoin single-use-seal/token payment
  • payer - the one paying bitcoin single-use-seal/token (RGB & Taro)

Process

  1. Payee queries the intermediary off-chain, with an amount he wishes the receive and locktime T he wishes to use, intermediary returns his swap fee along with a blinded UTXO to use.
  2. Payee creates an RGB/Taro invoice using the blinded UTXO as a destination and specifying his public key as a required signer for consignment receipt.
  3. Payer initiates a payment to the invoice generated by payee, creates a consignment which is then sent to intermediary
  4. Intermediary contacts the payee with the consignment and a signed message Mi (initialize) allowing payee to create a PTLC on Solana
  5. Payee reviews the returned Mi (initialize) message and sends a transaction creating PTLC on Solana using message Mi (initialize) signed by intermediary to pull funds from his vault:
    • paying the funds to payee if he can prove that a consignment witness bitcoin transaction was confirmed and has >=6 confirmations
    • refunding the intermediary, but only after locktime T
  6. Payee signs the receipt of the consignment with his key and returns it to intermediary, which in turn returns it to payee who then commits to the consignment by sending a witness bitcoin transaction.
Successful payment
  1. Transaction confirms on bitcoin chain (has >=6 confirmations) payee proves this via bitcoin relay and claims the funds from the PTLC
Failed payment
  1. No payment arrived in intermediary's wallet address until the locktime T, therefore intermediary can refund his funds back from the PTLC, keeping the non-refundable fee

Watchtowers

For Bitcoin on-chain -> Solana swaps, the payee needs to be online in time after the bitcoin transaction confirms on bitcoin blockchain, should he wait too long before claiming the funds, the PTLC might expire and he looses the funds.

Solutions

  1. Having the locktimes for the PTLCs very long (1 week or 1 month)
    • not ideal, since it will make the swaps very capital inefficient for intermediaries.
  2. Delegate this act of claiming to a third party, a Watchtower, which will be always online and claims the swap for us as soon as it confirms on bitcoin chain
    • requires us to trust the watchtower we use and also somehow incentivize it

An approach for using watchtower was choosen for SolLightning.

We can reduce the trust aspect by using multiple watchtowers, further we can incentivize watchtowers by letting them claim the Solana in a PTLC PDA (needed for the account to be rent exempt ~0.0027 SOL). We can then merge this watchtower implementation with BTC Relay implementation, allowing the relayers to earn fees by claiming the swaps on behalf of the clients.

Parties

  • claimer - recipient of the solana/spl token from PTLC
  • watchtower - claiming the tokens to claimer's account, on claimer's behalf

Process

  1. Observes an event of creation of PTLC on-chain (PTLC creator/claimer must explicitly opt-in for this feature)
  2. Starts checking if subsequent bitcoin blocks contain the required transaction
  3. If the transaction was found, the watchtower waits till that transaction gets required number of confirmations on bitcoin blockchain
  4. Claims the funds from the PTLC to the claimer's account, and receives ~0.0027 SOL as a fee (which was initially paid by the creator/claimer to create the PTLC).

Security considerations

Requires at least 1 honest relayer in the network to be online before the PTLC expires, otherwise the claimer may lose his funds if he doesn't claim them himself.