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.
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.
- 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 on-chain bitcoin
- payee - recipient of the bitcoin on-chain payment
-
Payer queries the intermediary off-chain, sending the payee's bitcoin address and an amount he wishes to send, intermediary returns the network fee along with his swap fee needed for the swap
-
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 intermediary 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 intermediary (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 intermediary 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.
-
Intermediary observes the creation of PTLC on Solana and proceeds to send a bitcoin transaction.
- Transaction confirms on bitcoin chain (has >=6 confirmations) intermediary proves this via bitcoin relay and claims the funds from the PTLC
- 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.
- Upon request by payer, intermediary creates a specific signed message Mr (refund), allowing the payer to refund his funds from the PTLC (cooperative close)
- Payer waits till the expiry of locktime T and then refunds his funds back from the PTLC
- an amount of bitcoin to receive must be known upfront
- payee needs to be online till bitcoin transaction confirms otherwise he may lose funds
- 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 on-chain payment
- payer - the one paying bitcoin on-chain
-
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 needed for a swap along with a specific message Mi (initialize) signed by intermediary allowing payee to create a PTLC on Solana with funds pulled from intermediary's vault. Intermediary can also charge a non-refundable fee based on locktime T to disincetivize spamming.
-
Payee reviews the returned fee 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 pre-agreed amount was sent to intermediary's address in a bitcoin transaction that has >=6 confirmations
- refunding the intermediary, but only after locktime T
- refunding the intermediary, but this can only be intiated by payee, (for co-operative close, when payee wishes to cancel the payment), this way payee can get part of his non-refundable fee back
NOTE: Here the replay protection needs to be handled by the intermediary who needs to make sure to generate a new address for every swap (if he doesn't, he is the one losing money), as we cannot possibly influence fields such as nSequence and locktime in bitcoin transaction sent by payer because his wallet implementation is outside our influence.
- Transaction confirms on bitcoin chain (has >=6 confirmations) payee proves this via bitcoin relay and claims the funds from the PTLC
- 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
- Payee is sure that no bitcoin payment will come and wishes to cancel the payment (there is no going back from there), he closes the PTLC, refunding the funds back to intermediary while keeping part of the non-refundable fee
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.
- 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.
- 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.
- claimer - recipient of the solana/spl token from PTLC
- watchtower - claiming the tokens to claimer's account, on claimer's behalf
- Observes an event of creation of PTLC on-chain (PTLC creator/claimer must explicitly opt-in for this feature)
- Starts checking if subsequent bitcoin blocks contain the required transaction
- If the transaction was found, the watchtower waits till that transaction gets required number of confirmations on bitcoin blockchain
- 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).
Requires at least 1 honest relayer in the network to be online before the PTLC expires, otherwise the claimer looses funds if he doesn't claim the funds himself.
Initial idea was to use atomic swaps for Bitcoin on-chain -> Solana swaps, but those aren't the best solution and they come with their own set of drawbacks:
- higher costs and on-chain footprint on bitcoin (requires 2 transactions)
- an attack vector where client intentionally waits till bitcoin fees raise to claim the HTLC on Solana, leaving intermediary with a dilemma of either spending way too much on fees or forfeiting the value he receives on bitcoin
- possibility for either of the parties to back out in case of unfavorable exchange rates
Credits for an idea using bitcoin relay and watchtowers for Bitcoin on-chain -> Solana swaps goes to Omid Aladini.