Introducing Taproot Swaps: Putting the "Fun" Back into Refunds! 🥕🔁

Today we are stoked to announce Taproot Swaps, a long anticipated upgrade that enables more private swaps with a smaller chain footprint and finally does away with the annoying wait time for refunds.

After the availability of Taproot on the Bitcoin mainchain in late 2021 and the Liquid Network in early 2022, today we are launching Taproot Swaps. This upgrade leverages Taproot’s Schnorr signatures to enable cheaper and more private swaps. Taproot’s features also allowed us to implement Immediate Cooperative Refunds, our flagship feature for this release, which dramatically improves UX as now users can get their locked bitcoin back immediately if a swap fails.

Let’s dive in.

Bitcoin, a place where carrots go really well with electric charges and water.

Immediate Cooperative Refunds 🤝

These refunds, as the name suggests, allow for immediate refunding. No biggie, right? Well, it actually is because it does away with one of the most pressing pain points for our users. But let’s take two steps back and first digest the concept of refunds at Boltz:

What are refunds?

In the context of Boltz swaps, refunds are the process of users reclaiming chain bitcoin, like L-BTC or mainchain BTC, of a failed swap. Refunds only apply to Chain → Lightning swaps, whereas Lightning → Chain swaps do not require refunds, because here Lightning funds automatically bounce back to users if something goes wrong.

Bitcoin which are locked in a failed Chain → Lightning swap cannot “bounce back” or even get “refunded automatically”, as Boltz does not have control over the locked bitcoins. The user is in control, which is why refunds need to be actively triggered by e.g. using the “Refund” tab on boltz.exchange:

The reasons why Chain → Lightning swaps can fail are multifold, but the two major failure reasons are:

• Users sending too little. Which often happens by accident as wallets deduct network fees from the send amount without making this very clear.

• Boltz can’t pay the user’s lightning invoice. Which itself can happen for a number of reasons, for instance:

  • Swapping to a small personal node which doesn’t have enough inbound liquidity or just isn’t well connected enough for us to find a route.

  • Swapping to a mobile lightning wallet and LSP failed to open channels or splice-in on-the-fly or the costs for this service were exceeding user-set limits.

  • User doesn’t open mobile lightning wallet in time.

  • Swapping to a very popular node, like a lightning deposit on a CEX, and we didn’t find a route within our generous (currently 3000ppm) fee limits.

Moving on.

Why the wait time until now?

To successfully claim a refund, up until today two crucial conditions needed to be met:

1. Possession of the private key to claim the refund

2. Timeout block height of the swap reached

It was the second condition that drove us and our users crazy and we absolutely understand that after the frustrating experience of a failed swap, a wait time of a day or even up to 4 (!) days before one could get the locked bitcoin back, is simply adding insult to injury. But why did one need to wait until refunds could be claimed?

Boltz uses a pretty standard Atomic Swap Protocol, leveraging Hash Time Locked Contracts or HTLCs for short. This means, swaps are secured by a time-lock and a hash-lock. The hash-lock, used when everything goes as planned, unlocks both swap transactions with a secret that the user controls. Here a video for the ones interested in more details and a hands-on demo:

But the crucial element for the wait time is the time-lock. It secures the atomic swap by giving both parties timeouts. These timeouts are important as they give both sides enough time to complete their part of the swap protocol. The algorithm outlined here describes this with an example. In conclusion:

It’s the previously agreed-upon timeouts that Boltz users needed to wait before they could claim their refund.

How Cooperation Enables Immediate Refunds

Taproot Swaps to the rescue! Today, we are excited to finally do away with waiting 🥳

How? Let’s start with the insight that all Atomic Swap primitives described above still hold true. With Taproot Swaps we simply added one additional way to refund, based on the idea:

“What if both parties talk to each other and agree on an earlier refund?”

We can already derive that the requirement for the concept to work is for both parties, users and Boltz, to have a way to exchange information. As Boltz is always online and ready to talk via its API, it just needs the user to do so via a Boltz client like our Web App. Here is how it works:

When a new Taproot Swap is created, we use Musig2 to aggregate a Schnorr public key by combining a public key from the user with one of Boltz. This aggregated public key then gets tweaked with the hash of scripts. As of today, we are using two scripts: one to claim bitcoins for successful swaps and one to refund for failed swaps. This structure allows for three ways of spending:

1. The claim script

2. The refund script

3. An aggregated signature created by the two private keys of the public keys with which the aggregated public key was created

Using an aggregated signature to spend is called key path spend in the context of Taproot. This can be done when all parties, in our case the user and us, agree on spending bitcoins this way. This is precisely what Cooperative Immediate Refunds do.

Stating the obvious, if Boltz should disappear or refuse to cooperate in a refund, the previously described time-lock applies, and users can safely get their bitcoin back via the refund script path after the timeout block height was reached.

Increased Swap Reliability

Now that users can refund immediately, we can safely increase swap timeouts from previously 1-4 days to now 7 days. But why do that?

Let’s start by embracing the fact that atomic swaps technically do not have one single timeout, but two. These timeouts are mostly called expiry in a technical context. And one expiry in a swap depends on the other.

Atomic Swap HTLC expiry gotchas in a nutshell Source: COMIT

As illustrated in these great slides by the COMIT team (🫡

Philipp Hoenisch

), we have a shorter yellow, and a longer blue expiry. For Boltz Swaps, users have the longer blue expiry and Boltz the shorter yellow expiry.

This is where it gets interesting: For Chain → Lightning swaps, Boltz’s shorter yellow expiry corresponds to the lightning payment. And this lightning payment is heavily restricted: Boltz has to find a route to deliver the payment within the so-called CLTV limit, the limit that makes sure that the expiry of the lightning route is within the swaps (yellow) expiry! If we take, for example, the minimum 24h swap expiry, Boltz is restricted to routes within a CLTV of 22h or less. Which is fine, if there are decent two-hop routes or even a direct channel to the destination (by default most nodes add around 13h per hop). But it’s an issue with most 3-hop routes already. That’s why, so far, Boltz dynamically chose swap expiry. Swap expiry is set longer the worse the connectivity to the destination is, to increase chances of finding a route within CLTV limits. So, the trade-off was: payment success probability vs. user wait time for refunds if the swap fails.

No more trade-offs with Taproot Swaps. Because users can refund immediately, we could substantially increase swap expiry, without annoying users with long wait times for refunds. This greatly increases the selection of routes available to our nodes to deliver payments and thus greatly improves payment success rate and overall reliability of Chain → Lightning swaps.

Please note: Refunding immediately is optional, users can refund at any time after the expiry just like pre-Taproot Swaps.

Cheaper Network Fees 🫰

The reduction in network fees of Taproot Swaps, is partly because of the smaller on-chain footprint of Schnorr Signatures (64 instead of 72 bytes) but mainly because now it is a single signature instead of script + preimage + signature that is pushed on-chain.

But screenshots speak louder than words:

Fees before and after: a ~10% reduction, depending on swap type

Increased Privacy 🥸

The privacy gains of Taproot Swaps are directly inherited from Taproot itself: all successful swaps look the same on-chain. For the vast majority of swaps, key path spends don’t reveal any script at all and appear to be single signature spends. Previously, an advanced entity could scan the chain for atomic swap scripts and like this find transactions that were involved in an atomic swap.

Adding onto above explanation of key path spends, spending with a script is called script path spend in Taproot. It is effectively the same concept as the Pay-to-Witness-Script-Hash address we used to have. A script is pushed on-chain and that script needs to evaluate to true to be able to be spent. The advantage of Taproot is that not all the possible spend conditions have to be in this script and separated by if/else, but different conditions can be in different scripts. When spending, only the script you want to execute has to be revealed on-chain. So even when Boltz is offline or not cooperating, Taproot still provides increased privacy compared to P2WSH. Nice, right?

Here a sample of how our new taproot swaps look on the chain compared to legacy swaps:

Before P2WSH, now P2TR

Easier Upgrades 💪

The new script path of Taproot Swaps enables us to deploy more upgrades in future by adding new script paths, and most notably without increasing costs for users as only the used script is pushed on-chain. For instance, one idea we are pursuing is to leverage covenants to improve a rare, but very ugly kind of refund: users overpaying in Chain → Lightning swaps. There is no way one can prevent this for chain payments. Making things worse, users usually overpay a lot (e.g. adding an additional zero) and so far we are relying on them contacting us and manually return the overpaid amount. Covenants, which can be added in additional script paths and are already available on Liquid, would allow for making this refund process completely non-custodial without our involvement.

So, we are actually excited about “covenants on the Bitcoin mainchain”, but not because of “Vaults” or “Lightning” but because they have the potential to improve UX for our users.

Release Details 🤓

Backend Release 3.4.0

• Changelog summary:

  • Taproot Swaps with MuSig

  • APIv2 basic calls & Swagger specs

  • Move backend to PostgreSQL database

  • Enable CLN mpay payments for swaps

  • Fix LND payment edge cases

• Code highlights:

  • SwapTree

  • MuSig Wrapper Class

  • Integration Tests for Key Path Spend

Web App Release 1.3.0

• Changelog summary:

  • Integrate APIv2 & Taproot Swaps

  • Immediate Cooperative Refunds flow

  • Add QR code scanner for mobile

  • TypeScript refactor

As one can see, we are in the process of moving to a new API v2, which structures things a bit better and, most notably, will support Taproot Swaps - only. And while we are committed to fully maintain our existing API v1 endpoints as-is, Taproot Swaps and other new features will only be available on v2 going forward.

Next up ⏭️

• 🤖 Finalize APIv2

• ⛓️ L-BTC/BTC swaps, our first chain-to-chain pair

• ⚡ RBTC/LN swaps (already available on testnet)

• 🌊 Advanced tools for channel rebalancing using Liquid Swaps

• 🏪 Merchant/POS integration of Liquid Swaps