Skip to content

Instantly share code, notes, and snippets.

What would you like to do?

SAS: Succinct Atomic Swap

Works today with single signer ECDSA adaptor signatures, or with Schnorr + MuSig.
Other than the explanation below, there's also a diagram and a video.


  • Requires merely two on-chain transactions for successful completion, as opposed to four
  • Scriptless, and one of the chains doesn't need to support timelocks
  • Can be used for efficient privacy swaps, e.g. Payswap


  • Access to money is contingent on remembering secrets (backup complexity)
  • Online/watchtower requirement for the timelock supporting chain (not needed with 3 tx protocol)

Protocol steps:

0.) Alice & Bob pre-sign the following transactions, with exception of the signatures in [brackets]:

  • success_tx (money to Bob): [sigSuccessAlice] + [sigSuccessBob]
  • revoke_tx (timelock): sigRevokeAlice + sigRevokeBob, which must then be spent by:
    • refund_tx (relative timelock, refund to Alice): [sigRefundAlice] + {sigRefundBob}
    • timeout_tx (longer relative timelock, money to Bob): sigTimeoutAlice + [sigTimeoutBob]

{sigRefundBob} is an adaptor signature, which requires secretAlice to complete

1.) Alice proceeds to lock up 1 BTC with Bob, using keyAlice & keyBob as pubkeys

If protocol is aborted after step 1:

  • Alice publishes the revoke_tx, followed by the refund_tx & sigRefundBob, to get her BTC back
  • If Alice neglects to publish the refund_tx in time, Bob will claim the BTC with the timeout_tx

2.) Bob locks up altcoins with Alice, using secretAlice & secretBob as pubkeys

If protocol is aborted after step 2:

  • Once Alice publishes sigRefundBob, Bob learns secretAlice and regains control over the altcoins

3.) Protocol completion:

  • Alice hands adaptor signature {sigSuccessAlice} to Bob, which requires secretBob to complete
  • Bob could now claim the BTC via the success_tx, reveal secretBob, and thus give Alice control over the altcoins (= 3 tx protocol)
  • Instead, Bob simply hands secretBob to Alice
  • Likewise, Alice hands keyAlice to Bob to forego her claim on the refund_tx
  • Bob continues to monitor the chain, because he'll have to respond if Alice ever publishes the revoke_tx

More graceful protocol failure:

If the protocol aborts after step 1, Alice would have been forced to make three transactions in total, while Bob has made none. We can reduce that to two by introducing a second refund_tx with timelock that can be published ahead of the revoke_tx and directly spends from the funding transaction. Publishing this transaction would also reveal secretAlice to Bob via an adaptor signature. In the 3 tx protocol, this output can go directly to Alice. In the 2 tx protocol with online/watchtower requirement, this output needs a script: spendable by Alice + Bob right away OR by Alice after a relative timelock. It is important to note that this transaction must NOT be published during step 3. Once Bob can complete the success_tx, the revoke_tx is needed to invalidate the success_tx prior to revealing secretAlice.


  • Why not allow Alice to still claim the altcoins if she accidentally lets Bob publish the timeout_tx?

    Alice could send the revoke_tx at the same time, revealing both secrets and causing likely losses. This can be solved by adding yet another transaction, but it wouldn't be efficient and wouldn't motivate Alice to behave.

  • Is it possible to implement this protocol on chains which only support absolute timelocks?

    Yes, but then Bob must spend his swapped coins before the timelock expires (or use the 3 tx protocol). Be aware that the revoke_tx MUST confirm before the timeout_tx becomes valid, which may become a problem if fees suddenly rise. The refund_tx can also not be allowed to CPFP the timeout_tx, as they must confirm independently in order to invalidate the success_tx first.

  • Can't Alice just publish the revoke_tx after protocol completion?

    Yes, she'd first have to move the altcoins (to invalidate secretAlice), and could then try to claim the BTC by publishing the revoke_tx, forcing Bob to react on-chain before the refund_tx becomes valid. The eltoo method of paying for fees (requires sighash_anyprevout) or a second CPFP-able output may be an improvement here (and also mitigates fee rising issues), but note that this also increases the required amount of tx data if the protocol doesn't complete successfully.

  • Can this be made to work with hash locks?

    Yes, by making the altcoins spendable via sigAlice + preimageBob OR sigBob + preimageAlice, and ensuring the contracts on the BTC side reveal either pre-image. Do note that this is not scriptless and will thus increase the transaction size.

Open questions:

  • Perhaps it's possible to perform an atomic swap in and out of Lightning with only a single on-chain transaction. This would require some kind of secondary set of HTLCs, allowing the sender to cancel a Lightning payment by revealing a secret after a certain period of time.

-- Ruben Somsen

Thanks to Lloyd Fournier for feedback and review.

Related work:

Tier Nolan Atomic Swap:
Monero Atomic Swap:
Private Key Turnover:  

Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

This comment has been minimized.

Copy link

@mt2Qx3R mt2Qx3R commented Sep 19, 2020

I think it is not so succinct. Since you should transfer 1 BTC first. I think this step should count. If so, it still needs four transactions.


This comment has been minimized.

Copy link
Owner Author

@RubenSomsen RubenSomsen commented Sep 19, 2020

@mt2Qx3R that step does count. The on-chain steps are:

  1. Alice locks up money.
  2. Bob locks up money.
  3. Bob watches the blockchain and reacts if Alice tries to claim a refund.

Depending on what Alice does, step 3 may or may not occur. Bob can also just perform step 3 if he does not wish to keep watching.

Alice does not have to watch anything. Her side of the swap is instantly settled.


This comment has been minimized.

Copy link

@fresheneesz fresheneesz commented May 12, 2021

I went through all the cases, and after some clarification, convinced myself that it all should work. For anyone that's interested, I wrote up all different edge cases here. I also wrote a node.js script that runs through and validates all the steps (and prints out the state of things after each step). Read the readme for how to run it.

A couple things that tripped me up in my understanding of the cases:

  • I misread that Alice gives Bob serectAlice at the end, when the actual protocol is that Alice gives Bob AliceKey. I think my mindset was that "secrets" were something that could be shared, and keys were private. However, I think the real distinction is that secrets are revealed upon use, whereas keys are not revealed on use (signing).
  • I treated things a little to abstractly and forgot that at the end of the day the main outputs (Created by On-chain transaction BTC and Revoke transaction) are just 2-of-2 addresses that then have things presigned off them. By that I mean, I forgot that once Bob got AliceKey that he could spend from the outputs created by those transactions.
  • The name of the "Success Transaction" is a bit misleading. I took that to mean that in normal operation, Bob would eventually send that transaction. However that's not the case. Instead, Bob will have AliceKey and can send directly from the output created by On-chain transaction BTC to any address he wants. This was compounded by my first two misunderstandings.
  • Also, I was unsure whether refund_tx was presigned by Bob or not (I wasn't sure of the curly braces used there were considered "brackets" that meant it wasn't presigned). It turns out refund_tx is in fact presigned with the adapter signature.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment