But Bitcoin doesn’t exist in a vacuum. People need to move between Bitcoin and dollar-denominated stable value to pay clients, employees or hedge volatility. Until now, that meant switching to an entirely separate ecosystem - centralized exchanges, new custody assumptions, new counterparty risk. Not anymore.

With USDT Swaps, Boltz bridges Bitcoin and traditional finance via USDT directly. Send sats on Lightning, receive USDT. Send USDT, receive sats over Lightning. Move between U.S. Dollar and Bitcoin value on your terms: unruggable, in seconds.

Here are some of the use cases this unlocks:

• Top up your favorite crypto debit card with Lightning. Most support USDT natively, yet Lightning is nowhere to be found. With Boltz you can now swap Lightning into USDT and load your card in seconds.

• Send Lightning straight into your bank account. Move from Lightning directly into USD in your FV Bank, Revolut, or Xapo account. The entire flow from sats to spendable fiat stays non-custodial until your Bank credits the USD.

• Hedge volatility on your terms. Markets dipping? Swap Lightning into USDT and hold USD-stable value without surrendering control to anyone. When you’re ready to stack sats again, swap back just as easily.

• Accept Lightning, settle in USDT. A coffee shop running a Lightning POS can sweep daily revenue into USDT or even directly split the settlement between USDT and Bitcoin with the upcoming integration of USDT swaps in our popular Boltz BTCPay Plugin.

There are probably many more use cases that we can’t think of just yet.

What’s the deal with USDT0? 🌐

USDT exists on dozens of chains: Ethereum, Polygon, Arbitrum, Optimism and many more. If Boltz had to support each network individually, we’d need to integrate every one of them and maintain liquidity across all of them too. That’s neither practical nor scalable. USDT0 changes that.

USDT0 is the omnichain version of Tether, built on LayerZero’s Omnichain Fungible Token (OFT) standard. It allows USDT to move natively across connected networks using LayerZero’s messaging protocol: one token, one liquidity layer, all chains.

For Boltz, this is a game-changer. By concentrating liquidity on Arbitrum and leveraging the OFT protocol, we can efficiently serve users across every USDT0-connected network while maintaining our liquidity and integration efforts focused - in one place. You can find the full list of supported networks, along with contract addresses, here and here.

Frankly, without USDT0, and without the incredible team behind it, today’s launch would not have been possible. 🙏

The Architecture: Routed Swaps 🔀

USDT Swaps introduce a new concept in Boltz: routed swaps. Unlike direct swaps (e.g. Bitcoin ↔ Lightning), a USDT swap is composed of at least two hops: a Boltz Swap leg and a DEX Swap leg stitched together seamlessly behind the scenes by a swap client like boltz.exchange.

The reason for this architecture is explained easily: we tried before and failed miserably. 🤕 The Free Options Problem is not theoretical but very much a real-world problem whenever HTLCs are involved. You can get a primer on the Free Option Problem in this article from our friend Roy.

The second key insight is tBTC. With this launch, Boltz natively supports atomic swaps between Lightning and tBTC on Arbitrum. tBTC is Threshold’s ERC20 wrapper for Bitcoin. Similar to WBTC, but open to mint, unmint and use for anyone. By adding a DEX Swap hop between tBTC and USDT0 on Arbitrum, a form of atomic swap that is designed to handle assets of different denominations, Boltz can offer Lightning ↔ USDT swaps.

From user perspective, both hops execute as a unified flow. The user selects “Lightning” and “USDT”, enters an amount, and the routing engine handles everything else. If no direct pair exists, the system automatically discovers the multi-hop route through tBTC, constructs the DEX path, and presents a single end-to-end quote.

It goes without saying: this architecture is extensible. Adding other stablecoins like USDC is as simple as a new configuration entry that points at an intermediate asset with a router.

Tech Deep Dive: Arbitrum, The Router Contract and the Quote Engine 🔧

At the heart of every Lightning -> USDT swap is the router contract on Arbitrum. Since USDT swaps are routed through tBTC as an intermediate asset, the same Router contract that serves tBTC swaps handles USDT.

The Router’s job is atomicity: it combines the Boltz swap claim and the DEX trade into a single, all-or-nothing transaction. Here’s the claimERC20Execute function, the core of what powers USDT claims, simplified from boltz-core:

// Router.sol (simplified)
function claimERC20Execute(...) external nonReentrant {
    // 1. Claim tBTC from ERC20Swap using the swap preimage
    claimERC20Swap(claim);

    // 2. Swap tBTC -> USDT0 via DEX (e.g. Uniswap on Arbitrum)
    executeCalls(calls);

    // 3. Send USDT0 to the user, revert if below minAmountOut
    sweep(destination, token, minAmountOut);
}

Three steps, one transaction:

1. Claim: The Router claims tBTC from the ERC20Swap contract using the swap preimage and an EIP-712 signature that authorizes the claim-and-execute combination.

2. Execute: It runs the DEX calls that swap tBTC for USDT0 on Uniswap. The calldata is constructed server-side. The user doesn’t need to interact with the DEX directly.

3. Sweep: The resulting USDT0 is sent to the user’s wallet. If the output amount falls below minAmountOut, the entire transaction reverts - protecting the user from unfavorable slippage.

Reaching other chains via OFT: If the user's destination is not Arbitrum, there is one additional step. After the swap completes, the USDT0 is bridged from Arbitrum to the target chain via LayerZero's OFT protocol. Because USDT on Arbitrum is natively USDT0, an OFT, bridging is a direct cross-chain transfer. This is what allows Boltz to concentrate all swap liquidity on Arbitrum while serving Ethereum, Unichain, Optimism, Polygon, Rootstock, and more from a single pool.

Tl;dr: One signature from the user. One transaction on-chain. The DEX swap and the Boltz lockup/claim happen atomically - either everything succeeds or nothing does.

The DEX leg is powered by Boltz’s quote API, which fetches real-time pricing for the tBTC ↔ USDT0 pair on Arbitrum. Quotes are requested with the exact token addresses and amounts, ensuring users see accurate end-to-end pricing before confirming a swap. If the DEX quote moves beyond the configured tolerance between swap creation and claim execution, the system pauses and asks the user to approve the new rate before proceeding. Slippage protection is built in.

One question left: Why Arbitrum? In short: Low gas fees, fast transfer-out times for USDT0’s protocol, and decent liquidity for both tBTC and USDT. This made it the ideal execution layer for Boltz USDT Swaps. We compared it to many other options and, for now, it’s the best tool for the job.

And what's the best validation of a sound architecture? Others adopting it.

Our Router Contract was already adopted, other parts of our other contracts were adopted, and the tBTC-on-Arbitrum combination we pioneered is being picked up too.

Open Source FTW! 💪

Gas Abstraction: No ETH Required 🔮

One of the biggest UX wins and especially relevant for our Bitcoiner userbase: users don’t need to hold or deal with ETH on Arbitrum. The gas abstraction system uses a dedicated signer that handles gas on behalf of the user. For USDT0 receives, the claim address is set to the gas abstraction signer, which submits the claim transaction and forwards the USDT0 to the user’s wallet.

When it makes sense, a small portion of the received tBTC is automatically swapped for native gas tokens via the DEX during the claim, so the user ends up with enough gas to move their USDT onward.

Prefer Simplicity? Go ₿itcoin-Only.

If the growing list of assets and layers feels overwhelming, flip on "Bitcoin-Only Mode" in the settings menu. It strips the interface down to Bitcoin and Lightning - a clean swap experience for Bitcoiners.

What’s Next ⏭️

• Crunch numerous bugs and issues

• Enable all our other layers like Bitcoin on-chain ↔ USDT

• Integrate Legacy Mesh: enabling swaps ↔ USDT on Tron, Solana and more

• Integration of USDT swaps for merchants using our BTCPay Plugin

• Various SDK integrations

• USDC via CCTP using the same routed swap mechanism

• More chains as USDT0 extends its supported networks

Try it out!

USDT Swaps are live at 👉 beta.boltz.exchange 👈

Subscribe now

Boltz Pro is our bold approach to combining liquidity management with a non-custodial way for users to earn sats by making swaps. Here’s the game-changer: users can earn sats by swapping in the directions we need most. In other words, when you swap in a direction that helps us rebalance our liquidity, we pay you. 🤯

Why Are We Paying You? 💸

Running a non-custodial Bitcoin bridge means constantly juggling liquidity! 🤹‍♂️

Sometimes, everyone wants to swap from Lightning to Bitcoin, draining our mainchain wallet. Other times, we run low on Liquid Bitcoin. On layers like Liquid, capital can be locked up for hours in “peg-ins”, which are required to refill our wallet.

That’s a real opportunity cost—and a headache we thought we could solve together: If you help us rebalance, you earn sats for it.

Who is Boltz Pro For? ⚡

Boltz Pro is open to everyone, but it comes with limits and shines for professionals with specific use cases.

First, let’s make it clear who Boltz Pro is not for:

• Boltz Pro is not designed for time-critical use cases such as paying with Lightning in a coffee shop. Boltz Pro Lightning payments are optimized for cost, not for speed.

• Boltz Pro is also not built for payment reliability to expensive destinations. For instance, some nodes are very costly to route to and can exceed Boltz Pro’s routing fee limits.

Instead, Boltz Pro is perfect for:

• Lightning Node Operators looking to decrease excess inbound liquidity and earn sats.

• Professionals collaborating with external node operators to manage liquidity and earn sats.

• Users who want to top up their Lightning wallets (like Phoenix), which is not time critical and still within Boltz Pro’s routing limits.

How Does Boltz Pro Work? ⚙️

Here’s the play-by-play:

1. Watch for Opportunities: When we need liquidity, Boltz Pro offers negative fees in the beneficial direction. You can spot these on pro.boltz.exchange or get alerts via our Boltz Pro Telegram bot.

2. Swap. Earn. Repeat: Execute a swap in the highlighted direction and instantly earn sats as shown (negative fee), minus network fees.

3. Dynamic Rates: Once things balance out, rates return to normal. Earning windows are dynamic and updated in real time.

How to Automate Boltz Pro? 🤖

Over the past few months, we've stepped up efforts to allow professionals to programmatically interact with Boltz Pro—checking for fee discounts, identifying earning opportunities, and triggering swaps. This primarily involved making Boltz Client compatible with Boltz Pro.

Boltz Client can now be used via its powerful gRPC interface or CLI to automatically create and monitor swaps on Boltz Pro based on current Pro fee rates. It offers various operational modes, such as connecting to your own Lightning node or paying an external invoice, and funding from Bitcoin or Liquid wallets, and more.

Guide available 👉 here 👈!

Start Earning Sats NOW! 🫰

Ready to get paid to swap? Head over to pro.boltz.exchange and check out the latest earning opportunities. First movers get the sats. It’s dynamic, transparent, and, like all Boltz products, fully non-custodial.

Thanks for swapping and stacking with us! 🧡

For Boltz, we established the following framework1:

1. The layer’s Bitcoin token needs to be verifiably backed 1:1 by mainchain Bitcoin

2. The layer needs to use its Bitcoin token to pay for network fees, not some alternative token

3. The layer needs to show meaningful organic growth of economic activity

We are thrilled to launch our integration with Rootstock today, a true OG among Bitcoin’s layers that checks all the boxes ✅

A Primer on Rootstock

Rootstock is the first and longest-running Bitcoin sidechain. Operating since January 2018, it combines the security of Bitcoin's proof of work via merged mining (currently >50% of the Bitcoin hashrate is participating in Rootstock), with EVM smart contract capabilities. Similar to the Liquid sidechain, which is already available on Boltz, it leverages a federated multi-sig to secure its peg between Rootstock Bitcoin (“RBTC”) and mainchain Bitcoin.

From Boltz’s perspective, the notable differences in comparison with Liquid are:

• Account vs UTXO model

• Block production on Rootstock is separated from the Bitcoin peg’s multi-sig entities and is secured by Bitcoin miners via merged mining; on Liquid both are done by the same entities called “Functionaries”

• Block time is ~30s compared to 60s on Liquid

• Rootstock’s PowPeg allows anyone to natively peg-out, no special keys required like on Liquid

• The account model on Rootstock offers less transactional privacy and does not natively allow for advanced features like Confidential Transactions on Liquid

To sum it up, Liquid and Rootstock complement each other and were created with different goals in mind. While Rootstock focuses to address the desire for advanced programmability in the Bitcoin ecosystem, Liquid focuses on its transactional and advanced asset-issuance capabilities.

Rootstock boasts a vast ecosystem of decentralized applications and open finance services that let you lend, borrow, trade, and earn interest on your Bitcoin.

Finally, Rootstock’s Co-Founder and Chief Scientist, Sergio Lerner, is spearheading BitVMX, a BitVM-inspired implementation to enable a trust-minimized bridge between the Bitcoin mainchain and Rootstock sidechain using ZK proofs.

What can I do with Rootstock Swaps?

Rootstock Swaps allow anyone to explore financial applications on Rootstock easily and quickly using the Lightning Network. Lightning is especially suited for low-value transfers and fast settlement with instant transaction finality; these characteristics have helped it establish itself as the common language between Bitcoin layers.

Starting today, users can move their Satoshis from Lightning to Rootstock using our Web App at boltz.exchange and start exploring the Rootstock ecosystem.

Here are some of the financial applications available on Rootstock:

• Money On Chain: Money On Chain (MOC) is the stablecoin protocol that issues Dollar On Chain (DOC), the only 100% Bitcoin-backed stablecoin.

• Sovryn: Sovryn is a decentralized platform for Bitcoin trading and lending.

• Tropykus: Savings and loans in dollars for Latin America.

• Sushi Swap: Sushi Swap is a community-driven decentralized exchange (DEX) for traders and liquidity providers.

An overview of Rootstock’s ecosystem is available here. Rootstock has shown resilient growth in recent months with new partnerships and increasing activity (1, 2).

One aspect we're especially excited about is the new use cases Rootstock enables in combination with Lightning leveraging its Turing-complete programming capabilities.

One problem we believe Rootstock could be the solution to, is to enable non-custodial Lightning Prisms. In short, a Lightning Prism splits one incoming payment into two or more payments to different receivers, e.g. to distribute a payment for an article behind a paywall not only to the author, but also to all authors of content that was re-used. The problem with the current solution based on lightning addresses is that it’s inherently custodial and additionally exposes the prisms to regulatory crackdowns. Rootstock could solve the custody dilemma by letting a prism smart contract on Rootstock handle the payment split. This is currently just an idea, we didn’t work on any technical implementation and there might be technical issues that might make this infeasible. Anyhow, it is just one idea; the design space on Rootstock is virtually endless. 🚀

Implementation Highlights

Rootstock Swaps leverage the same HTLC-based atomic swap principle as all other swaps on Boltz. All swap contract code can be found here and is verified on Rootstock, see e.g. here the current version of the RBTC swap contract.

When starting our integration earlier this year, we faced a deal-breaker problem: users needed RBTC in order to receive RBTC from a swap in order to pay for gas of their claim transactions. This strongly conflicted with our vision to build a tool to onboard new users to Rootstock - users that did not posses RBTC yet.

RIF Relay to the rescue! In the past months, we worked with the RIF Relay team to add support for so-called meta transactions (sometimes also called gasless transactions). Meta transactions via RIF Relay allow Boltz users to sign instructions for RIF Relay to broadcast a swap claim without directly paying for gas. Instead, users pay RIF Relay using the incoming RBTC from their swap for broadcasting the transaction on their behalf. The best part is that the user doesn’t need to worry about this, as the Boltz Web App checks at swap creation if the user has enough RBTC to pay for gas in their wallet. If not, it automatically uses a meta transaction via RIF Relay.

We are also quite proud of the new hardware wallet integration in our Web App for Rootstock swaps. It allows you to directly swap to and from your Ledger and Trezor devices 🙌

What’s Next

• Enable Chain Swaps between Rootstock and Liquid/Bitcoin.

• Native integrations with projects on Rootstock, like Money On Chain.

• Bug fixes and Improvements based on user feedback.

• ⚡ “Nodeless” mode: any merchant using BTCPay Server (even on a shared BTCPay instance) can now accept Lightning - powered by Liquid Swaps 🌊

• 🤖 Autoswap to mainchain: when using Liquid Swaps, the BTCPay Plugin allows for triggering swaps back to the mainchain based on a set of preferences

• 👛 Integrated wallet system: create or import Liquid/mainchain wallets

• 🥕 Built on Taproot: fully leveraging the power of Taproot Swaps

• 🙅‍♂️ Non-custodial: as with all Boltz products, all mentioned features are powered by Boltz Atomic Swaps, allowing merchants to stay in control of their money

🤔 The Problem

Running and managing a Lightning node is no easy feat. Or, as our CTO Michael recently put it: “Channel management is complex and inbound liquidity can be such an alien concept”. As an industry, we have slowly but surely come to accept that the Lightning Network may scale Bitcoin differently than originally anticipated. “Running your own Lightning node” is not a realistic nor a recommended goal for many individuals and even for professionals like merchants alike.

As a consequence, most applications and use cases nowadays revolve around the concept of using someone else’s professionally managed Lightning node to send and receive payments on the Lightning Network. Unfortunately, this all too often means relinquishing custody of funds. For merchants using BTCPay, choices of accepting Lightning payments that do not require operating a Lightning node, are historically limited. Various bugs of custodial solutions in the past showed that custodial risk goes both ways: the custodian can be at risk of losing funds too.

Albeit being great products, today most solutions for merchants remain custodial and require setting up accounts with the service providers, some of which are only available in specific countries.

👇 What is the Boltz BTCPay Plugin?

The Boltz BTCPay Plugin is set to change this by allowing any merchant using BTCPay Server to accept Lightning payments without operating a Lightning node. This is especially powerful for merchants using a shared BTCPay server, as the choice of decent non-custodial options for accepting Lightning payments is very limited.

From a technical perspective, the Boltz BTCPay Plugin acts as an advanced UI to control and monitor Boltz Client, our proven swap client, which it uses under the hood.

After installation, the plugin offers users two modi operandi:

“Rebalance”, the first mode of Boltz BTCPay plugin, is currently still in closed beta (message us if you are interested in participating) and only available to merchants running their own BTCPay instance with their own Lightning node connected to it. It walks you through setting up Boltz Client’s Autoswap in a visual setup flow and finally takes over managing your Lightning node’s liquidity based on your configuration. Next to regular mainchain Submarine Swaps, users have the option to use Liquid Swaps combined with Chain Swaps for increased cost efficiency.

“Nodeless”, the second mode of the plugin and the flagship feature of today’s launch, uses Boltz’s well connected Lightning nodes for processing incoming Lightning payments and swaps the funds to a Liquid wallet controlled by the merchant. It offers great cost planning security as swap fees rarely change and network fees on the Liquid network are reliably low (usually around 40 sats per swap). Finally, it avoids typical Lightning channel management issues like running out of inbound liquidity or unforeseen channel force closes or even potentially catastrophic events like corrupted channel state.

We don’t want to draw any preliminary conclusions today as only time will tell, but we strongly believe that, from a cost-perspective, “nodeless” mode can be very competitive compared to the total costs of operating a Lightning node.

🚧 WIP

We labeled today’s launch “Open Beta”. Even though we tested meticulously and disabled features that were either known to have issues or not well-tested enough, we can’t guarantee absence of bugs. Do not install and run the plugin if you expect things to be perfect. As a cautious approach, we recommend starting off by only enabling the plugin to take over Lightning payments while the behavior can be monitored and only enable it permanently once a certain confidence level is reached. You can find an overview of known limitations here.

If you have feedback or questions, please join our 👉BTCPay Boltz Plugin Beta Telegram group👈 and please let us know if you are interested in helping us test “Rebalance” mode.

🏅Credits

Big shout-out to Alan, CEO of strainly.io, who tirelessly tested the Boltz BTCPay Plugin for several weeks and proved brave enough to run the plugin on mainnet in a pretty early stage and helped us to iron out numerous bugs.

We are proud to announce, that strainly is running the Boltz BTCPay Plugin in production today. This wouldn’t have been possible without you, Alan! 🙌

Furthermore, a big thank you to the amazing BTCPay Server team, which helped us navigate writing and publishing our first BTCPay Server Plugin to get us where we are today. 🙏

⏭️ What’s Next for the Boltz BTCPay Plugin?

• Full support of Liquid read-only wallets to improve security for merchants using a shared BTCPay instance

• Finalize testing and enable “Rebalancing” mode for merchants operating their own Lightning node

• Many more issues to be crunched and bugs to be fixed

• Prepare for compatibility with BTCPay Server v2

That’s a wrap, thank you for reading ‘til the very end!

Today we released Boltz Client 2.1.0 “Autoswap”, which delivers “Lightning that just works” for your own Lightning node, featuring our “unfairly cheap” Liquid Swaps. This release implements the Liquid Rebalancing Triangle in an automated fashion, meaning, for the very popular use case to maintain inbound liquidity, it rebalances into Liquid and then, based on your settings, moves bitcoin from Liquid back to the mainchain. With which you can then open more Lightning channels.

For Whom Is This Guide?

This guide is written for tech-savvy operators of Lightning nodes that are used in a professional context, like merchants accepting Lightning payments for their goods, Bitcoin ATM operators allowing Lightning payouts, or fully-fledged exchanges that allow Lightning deposits and withdrawals.

What Is the Goal of This Guide?

The goal of this guide is to create a setup that keeps Lightning channels in a configured balance range to allow for reliable operations with predictably cheap rebalancing costs using Liquid Swaps. The idea is to perform many rebalancing swaps using Liquid and only periodically swap back to the mainchain, e.g. based on the accumulated amount of L-BTC or mainchain miner fee level.

But how does one go about installation, setup and configuration?

Grab a cup of coffee and let’s dive in 👇

Installation

Boltz Client is available for Linux amd64 and arm64 platforms, the two platforms almost all Lightning nodes are running on nowadays. Head over to the Boltz Client release page and download the latest release binaries for your platform, extract the binaries, verify them, and place them in a folder of your choice. If you are doing all this via terminal, these are the commands you want to use:

• wget https://github.com/BoltzExchange/boltz-client/releases/download/v2.1.0/boltz-client-linux-amd64-v2.1.0.tar.gz

• tar -xvzf boltz-client-linux-amd64-v2.1.0.tar.gz

• mv the binaries to your preferred permanent location, e.g. ~/boltz-client

• add the binaries to your PATH by adding the line export PATH="/home/satoshi/boltz-client:$PATH" to the end of your .bashrc file (don’t forget to source .bashrc afterwards)

Give it a test spin by running boltzd, which will terminate with an error but proves that Boltz Client works on your system and conveniently creates the default data directory ~/.boltz already.

We recommend creating a systemd boltzd.service file to launch Boltz Client:

# A sample systemd service file for Boltz Client

[Unit]
Description=Boltz Client Daemon

[Service]
ExecStart=/home/satoshi/boltz-client/boltzd
ExecStop=/home/satoshi/boltz-client/boltzcli stop

# Replace these with the user:group that will run Boltz Client
User=satoshi
Group=satoshi

# Try restarting Boltz Client if it stops due to a failure
Restart=on-failure
RestartSec=60

[Install]
WantedBy=multi-user.target

If you prefer building from source or using docker, refer to the docs.

Setup

Next up is connecting Boltz Client to your Lightning node. Change to the Boltz Client data directory (~/.boltz by default) and create a new configuration file called boltz.toml with the following content

If you are running CLN:

[CLN]
datadir = "~/.lightning"

If you are running LND:

[LND]
datadir = "~/.lnd"

Pointing Boltz Client to your Lightning node’s data directory is all it should take to successfully connect. Should you be running your node with non-default ports, certificate locations or on a different machine, check our sample config file for advanced connection configuration options.1

Now we are ready to start Boltz Client via sudo systemctl start boltzd. boltzcli getinfo should print an output similar to the following showing the connected Lightning node’s public key:

$ boltzcli getinfo
{
  "version": "v2.1.0-daac977",
  "node": "LND",
  "network": "mainnet",
  "nodePubkey": "020d9126d568b8f0605ed65eda28c4b843bb66282a0921d721f88b8a46cbd4e221",
  "autoSwapStatus": "disabled",
  "blockHeights": {
    "btc": 849707,
    "liquid": 2919031
  },
  "tenant": {
    "id": "1",
    "name": "admin"
  }
}

If the command returns an error instead, you can follow the logs for the root cause with e.g. journalctl -n 100 -f -u boltzd or by simply opening boltz.log located in the Boltz Client data directory. If you need help with debugging, feel free to reach out in the #help channel on our Discord Server.

For an overview of all available cli commands, simply run boltzcli.

Autoswap Configuration

Congrats, now that we have Boltz Client running and connected to our Lightning node, we can start configuring Autoswap! 🙌

Before we start though, let’s record our current channel and wallet balances:

$ boltzcli wallet list
{
  "wallets":  [
    {
      "id":  "2",
      "name":  "LND",
      "currency":  "BTC",
      "readonly":  false,
      "balance":  {
        "total":  "2990606",
        "confirmed":  "2990606",
        "unconfirmed":  "0"
      },
      "tenantId":  "1"
    },
  ]
}
$ lncli channelbalance
{
    "balance":  "3073517",
    "pending_open_balance":  "0",
    "local_balance":  {
        "sat":  "3073517",
        "msat":  "3073517340"
    },
    "remote_balance":  {
        "sat":  "42488",
        "msat":  "42488660"
    }
}

As one can see, we currently hold a bit less than 3 million sats in LND’s internal mainchain wallet and have a very imbalanced channel balance with about 3 million sats local outbound and only 42488 sats remote inbound liquidity.

To familiarize ourselves with the available Autoswap options, we run boltzcli autoswap. The command we are looking for is called setup, the interactive setup flow to configure Autoswap.

The first decision boltzcli autoswap setup asks us to take is if we want to:

• maintain inbound liquidity via reverse, e.g. if you are a merchant and need to be able to receive Lightning payments reliably,

• maintain outbound liquidity via normal, e.g. if you are running a Bitcoin ATM that accepts FIAT and needs to be able to send Lightning payments reliably,

• maintain both, e.g. if you are operating a Bitcoin exchange and offer Lightning deposits and withdrawals and need to be able to send and receive reliably

Let’s now imagine we are operating an online merchant selling amazing hats for sats and need to be able to reliably receive Lightning payments. We do not have the need to send Lightning payments out. Our current channel balance is not great for this use case as we currently only can receive up to 42488 sats, which is barely the price of one hat. Our desired channel balance is basically the exact opposite - all of our channel balance on the remote side of the channel as inbound liquidity. Consequently, we are continuing with the first option “reverse” to manage our inbound liquidity.

Next up is selecting the destination wallet, which also determines if we are swapping to Liquid or to the mainchain (both are supported by Boltz Client). We want to swap to Liquid to benefit from reliably cheap network fees and avoid rebalancing costs spiraling out of control when mainchain miner fees rise. As Boltz Client ships with an integrated Liquid wallet system, it let’s us create a new Liquid wallet right within the setup flow:

? Select wallet which should be used for swaps Create New
? Select wallet which should be used for swaps LBTC
? Enter a name for the new wallet liquid
? Do you want to provide a wallet password to encrypt your wallet, which will be required on startup? No
New wallet created!

Mnemonic:
dragon minute height hurry oil power must imitate twice brick term festival

We highly recommend to import the mnemonic shown above into an external wallet like Blockstream Green (https://blockstream.com/green). This serves as backup and allows you to view transactions and control your funds.

Next, we install Blockstream Green on a different computer (or phone) and import the mnemonic from the output.

As the CLI response stated, importing the mnemonic into Green is important for two reasons:

1. The second device serves as backup of your Liquid wallet should something happen to your Boltz Client installation or device

2. Green enables you to see wallet transactions and manually send to or receive from this wallet, features which Boltz Client doesn’t support.

Next, setup asks us to decide if we want to specify our minimum inbound liquidity in sats or in percentage of our total channel capacity. We choose percentage and go with the default 25% threshold. This means that once our inbound liquidity hit the minimum threshold of 25% inbound liquidity (or, in nominal terms, a bit more than 750k sats of our 3 million sats channel), Boltz Client starts rebalancing our channel.

Next we set a budget, the maximum amount we want to spend on fees, applicable for a certain budget period. We are going with 50k sats over 7 days rolling. Lastly, Boltz Client informs us that the target when executing swaps is 100% inbound liquidity, which is exactly what we want as an online merchant, have all our liquidity available as inbound liquidity.

Here the summary of our config:

? Which type of swaps should be executed? reverse
? Select wallet which should be used for swaps liquid
? How do you want to specify values? percentage
? What is the minimum percentage of total capacity you want to keep as your inbound balance? 25
? In which interval should the fee budget of the auto swapper be reset? (days) 7
? How many sats do you want to spend max on fees per budget interval? 50000

Config was saved successfully!
Autoswap will target 100% inbound balance when executing swaps.

That’s it for Liquid Swaps - the configuration of the first edge of the Liquid Rebalancing Triangle is done!

Setup now asks us if we want to configure the second edge of the triangle, Chain Swaps from Liquid back to the mainchain too. We do, and apply the following config:

? Do you want to setup chain swaps as well? Yes
? Select source wallet liquid
? Select target wallet LND
? What is the maximum amount of sats you want to accumulate before a chain swap is started? 1000000
? In which interval should the fee budget of the auto swapper be reset? (days) 7
? How many sats do you want to spend max on fees per budget interval? 50000

Config was saved successfully!

This config instructs Autoswap to swap all L-BTC back to our LND’s internal mainchain wallet once our Liquid balance reaches 1 million sats. We set the maximum fee budget to the same 50k sats per 7-day rolling period.

Finally, Autoswap informs us about the swap immediately being executed after enabling. Quick check of the numbers shows us, that the swap amount of 3011144 is slightly less than our current 3073520 sats outbound liqudity. This is because Autoswap has to account for Lightning’s channel reserve. We enable Autoswap.

Based on above config the following swaps will be performed:
{
  "lightning": [
    {
      "amount": "3011144",
      "feeEstimate": "7528",
      "dismissedReasons": [],
      "type": "reverse",
      "channel": null
    }
  ],
  "chain": []
}

? Do you want to enable autoswap now? (y/N) y

That’s it for Chain Swaps - the configuration of the second edge of the Liquid Rebalancing Triangle is done too!

We start monitoring ongoing swaps via boltzcli swapinfostream to receive updates about the upcoming swap we were informed about. One can also follow Boltz Client’s logs via journalctl -f -u boltzd for a more detailed trace.

While monitoring progress of the swap, we can see that after the swap was executed successfully, our Lightning channel balance pracically inverted, which is precisely what we wanted. We now have >3 million sats available as inbound liquidity and only a little remainder of 62373 sats left as outbound liquidity. Our imaginary online shop is ready to sell hats 🤠

$ lncli channelbalance
{
    "balance":  "62373",
    "pending_open_balance":  "0",
    "local_balance":  {
        "sat":  "62373",
        "msat":  "62373340"
    },
    "remote_balance":  {
        "sat":  "3053632",
        "msat":  "3053632660"
    }
}

The Liquid part of the swap was sent to our newly created Liquid wallet and since it’s about 3 million sats in value, the balance of our Liquid wallet now exceeds the previously set 1 million sats threshold and a chain swap is triggered, moving our Bitcoin from Liquid back to the mainchain. boltzcli listswaps shows us the summary after both swaps went through:

In Green we can confirm an incoming Liquid transaction of about 3 million sats from the first reverse swap from Lightning to Liquid and an outgoing transaction of a little bit less than 3 million sats of the second swap, moving our funds from Liquid back to the mainchain. Boltz Client is currently configured to leave a buffer of about 10000 sats in our Liquid wallet, but it’ll be able to swap everything down to the last satoshi soon. You can follow the implementation of this feature on GitHub here.

Finally, we confirm that LND’s internal mainchain wallet successfully received about 3 million sats as the final destination.

$ lncli walletbalance
{
    "total_balance":  "5979386",
    "confirmed_balance":  "5979386",

We are now free to use our mainchain Bitcoin to open new channels, completing the third leg of the Liquid Rebalancing Triangle.

What’s Next for Boltz Client?

• Many more issues to be crunched and bugs to be fixed as we are rolling out this release.

• Decreasing Liquid network fees even further.

• Monitoring mainchain miner fee levels to automatically swap back to the mainchain when it’s cheap.

• Boltz Client flagship feature: our upcoming BTCPay plugin. It’ll enable all of this directly from within the BTCPay UI and even allow to accept Lightning payments without running a Lightning node.

The Problem 🤔

Liquid is a great interim place to hold funds, to “batch channel rebalances” so to speak. It is especially popular to obtain Lightning inbound liquidity via Liquid swaps, moving from Lightning into Liquid, inevitably leading to an accumulation of L-BTC in Liquid. Once a certain amount of L-BTC is reached, one would want to move back to the mainchain. To open new Lightning channels, for instance.

But how to get back to the mainchain?

Going back via Lightning doesn’t make much sense, as this would undo all previous rebalancing, so the only meaningful way is to go directly from Liquid to the mainchain. There are three ways to do so currently:

1. The official peg-out mechanism. Problem: it’s an involved, technical process and only available to Liquid Federation members.

2. The “peg-out” service, offered by SideSwap. Problem: it’s custodial for the duration of the peg-out and might take an hour or more to complete.

3. An exchange like Bitfinex or BTSE. Problem: it’s custodial and requires KYCed accounts on these exchanges.

In summary, there is a need for an equally convenient, openly available and non-custodial way to move directly between Liquid and the mainchain.

The Solution 🤝

Chain Swaps to the rescue! Today’s launch adds the missing edge to what we call the Liquid Rebalancing Triangle:

With Chain Swaps, Lightning node runners are able to keep channels balanced, while conserving the main property that makes Boltz special: never giving up custody of funds.

Under the hood, Chain Swaps are based on Taproot, thus inheriting all Taproot Swaps advantages:

• Immediate Cooperative Refunds for failed swaps, doing away with any wait time.

• Cheaper Network Fees as cooperative swaps are as small as single-sig spends.

• Increased Privacy through key path spends that don’t reveal any swap info and hide unused script path spending conditions

Release Details 🤓

Backend Release 3.7.0:

As part of our new backend release for this launch, we finalized our move to APIv2, accounting for the new Chain Swap type. It features the following three swap types now: Submarine Swaps, Reverse Swaps and Chain Swaps. You can checkout the main PR of this release here (beware, it’s a monster!).

Changelog Summary:

• Chain Swaps across multiple feature commits (02906af, f444b11, 86fc8b7, 2ba0a92, d90c7b4, 3319205, c1f72d3) and bug fixes (c1f72d3, 48bd28a, 1eb62d8, 21ae1f4, ddc6878)

• Cooperative chain swap claims & refunds - (9ba1065 & 9dbcbf6)

• EVM chain swaps - (25ef8dd)

Web App Release 1.4.0

Our new web app release, which we deployed today, allows for spontaneous Chain Swaps between Liquid and the mainchain. It includes a major refactor to prepare for more pairs and swap types in future. You can checkout the main PR of this release here.

Changelog Summary:

• Chain Swaps (caffdda)

• Show amount on success page (dc5150d)

• Optionally play sound on success (caa861a)

• Optional Browser Notification (e5461f7)

Boltz Client

Boltz Client is geared towards Lightning node runners looking to automate the above mentioned Liquid Rebalancing Triangle. It brings its own Liquid wallet system, allows for fine-grained control and full automation of the entire rebalancing flow via its autoswap feature. We didn’t tag an official release for Chain Swaps in Boltz Client yet, but the main PR is merged and autoswap features are pretty far along too. Follow our socials to not miss the release!

More Use Cases 💪

In the past year, Liquid Swaps evolved far beyond the channel rebalancing use case. One of the most prominent examples is Aqua, which is a Liquid wallet that allows for sending to and receiving from Lightning via Boltz Liquid Swaps, abstracting away the complexity of managing channel liquidity or backing up channel state. Chain Swaps will allow wallets like Aqua to let users non-custodially move funds between internal wallets, pay to mainchain addresses and top up Liquid spending balance with mainchain bitcoin.

While publicly available to anyone, Liquid Pegins, the official mechanism to convert mainchain BTC to L-BTC, have been a notorious pain point in the past. The process is fairly complex and involves a 102 block wait time before funds can be used on the Liquid side. The only alternatives are custodial. Chain Swaps abstract away the technical complexity, do away with the wait time and allow users to stay fully in control of their funds at all times. Finally, Chain Swaps lay the foundation for more Chain Swap pairs like between Rootstock and the mainchain or Liquid and Rootstock in the future.

Exchange → Bridge

We also took today’s launch as an opportunity to change how we describe ourselves:

Non-Custodial Bitcoin Exchange → Non-Custodial Bitcoin Bridge

We are very optimistic and excited about the recent surge in development efforts of new Bitcoin Layers. Our vision is to be the bridge between all Bitcoin Layers that fulfill our requirements:

• Verifiably 1:1 backed by mainchain bitcoin

• Fees denominated in bitcoin

• Strong security and ecosystem

It was also important to us to do away with the stigma around the term “exchange”, which is usually associated with KYCed, custodial platforms and altcoins.

Next up ⏭️

• Finalize Chain Swap integration in Boltz Client

• Integrate Boltz Client into BTCPay and other UIs

• Rootstock Swaps

  That's it, that’s all! Subscribe to not miss anything important about Boltz!

• ⚡ CLN-first: first-class citizen support for CLN in addition to LND

• 🌊 Liquid-first: optimized UX for channel rebalancing using Liquid swaps

• 🥕 Taproot-first: full support of Taproot Swaps and Boltz API v2

• 👛 Integrated Liquid & mainchain wallets: create, import & swap to cold wallets

• 🤖 Autoswap: fine-grained control for automated channel rebalancing

• ⬆️ Backward compatible: Upgrade from Boltz LND

What is Boltz Client?

History

Boltz Client is based on Boltz LND and written in go. Boltz LND was our go-to swap client for LND runners est 2020. It was built for a very simple purpose: let LND runners swap between Lightning and the Bitcoin mainchain on demand to rebalance channels.

Initially, Boltz LND was a standalone CLI-based client, but later it was integrated in UI-based tools like the popular Ride The Lightning node management software.

CLN & The Path to Multi-Implementation

With CLN gaining popularity for its focus on performance and stability, along with the support in popular lightning tooling, we are excited to add Boltz Client to the growing CLN ecosystem today. Boltz Client uses CLN’s gRPC (missing calls were swiftly added by the CLN team 🙌), and the upcoming 0.15.1 release of Ride The Lightning will fully support Boltz Swaps for CLN nodes through its UI. This lays the foundation for integration of more Lightning implementations in the future.

Liquid & Taproot

Boltz Client ships with full support of Liquid & Taproot Swaps and the brand-new Boltz API v2. This means all Taproot Swaps-inherited features like immediate cooperative refunds, increased swap reliability, cheaper network fees & increased privacy are directly available in Boltz Client from the get-go.

Also, Boltz Client brings its own wallet system for Liquid and the Bitcoin mainchain, powered by Blockstream’s GDK. This gives users an extensive set of options:

• Use the connected Lightning node’s internal wallet for mainchain swaps

• Import an existing Liquid/mainchain wallet seed, e.g. from Blockstream Green

• Create a new Liquid/mainchain wallet

• Import a cold wallet xpub/descriptor as swap destination

• Swap from/to external addresses

A very nice side-effect of the integrated wallet system is that Boltz Client can automate refunds for Chain → Lightning swaps now, as it has access to wallets to pull addresses for refunds. Automating refunds is the last missing piece for a polished UX of Boltz Swaps: if something goes wrong, funds return automatically and immediately.

Autoswap

The flagship feature of Boltz Client is called Autoswap. As the name suggests, it let’s Lightning node runners set up a configuration for which swaps will be performed automatically to keep channels balanced:

In the basic example above, we instructed Autoswap to rebalance our total channel balances to 37.5% outbound with a maximum total of 100k sats to be spent on fees within 7 days if our total outbound capacity exceeds 75%.

Download

Today we are making Boltz Client available to the general public. Big shout-out to our newest team member Jackstar who brought Boltz Client to life 👊

Docs are available here and you can grab the latest release 👉 here 👈 !

What's Next

• Release full CLN support for Boltz Swaps in RTL, deploy to Umbrel, Start9 etc.

• Taproot-based L-BTC/BTC ⛓️-to-⛓️ swaps, which will allow Autoswap to unleash Liquid’s full potential for channel rebalancing by periodically moving funds back to the Bitcoin mainchain either based on amount accumulated in Liquid or based on the current Bitcoin mainchain miner fee level.

• A UI. We are aware that, while powerful, CLI is not for everyone. That’s why we started working on a native UI for Boltz Client with a tailored UX for rebalancing nodes and controlling Autoswap.

  

We’d love to hear from you!

We acknowledge that perfection is elusive, and Boltz Client is no exception. We value your feedback, bug reports, and feature requests, which can be shared through GitHub, X, Nostr, or our Discord server!

Let’s dive in.

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:

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.

As illustrated in these great slides by the COMIT team (🫡 ), 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.

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:

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:

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

• 🏠 United Liquid & mainchain swaps: one web app to swap them all

• ⬆️ Increased Liquid swap limits: Now up to 0.1 BTC

• 🥕 Swap to Taproot addresses: now supporting bech32m

• 🧅 Enhanced privacy: Liquid swaps available via onion domain

• 📱App Store censorship resistance: install as Progressive Web App

• 🧮 Exact on-chain amounts: swap to pay with precision down to the satoshi

History

Let's take a trip down memory lane. This marks the release of our third major web app version, and boy, have times changed. Here's a glimpse of how our web app looked when we first released Boltz back in April 2019:

We let michael1011’s comment on his work speak for itself: “This is what happens if you force a backend developer to write a frontend because you have no one else to do it”. However, it served its purpose at the time: a functional proof of concept that made submarine swaps easy and accessible for non-technical users.

In 2020, we made the leap to version two, collaborating with an actual frontend developer this time 👨‍💻. This update significantly enhanced reliability, introduced a dedicated mobile version, and much more. This web app has been powering Boltz ever since—until today.

All-New

Today, we're excited to unveil the third edition of our web app. Designed for the future, it's highly extensible and utilizes modern web frameworks like SolidJS. It also leverages state-of-the-art cryptographic libraries such as secp256k1-zkp which is integrated via WebAssembly and runs directly in your browser.

Don’t trust, verify!

We encourage our technical users to exercise caution by not solely relying on the web app served from our domain. Verify that the code does exactly what we claim and run the web app directly from source.

What's Next

• 🌊 Dedicated "Liquidity" Tab: Obtain a specific amount of inbound or outbound liquidity via our web app, along with numerous other features and subtle improvements.

• 🥕 Taproot Native Swaps: Enhancing privacy and significantly reducing on-chain footprint, particularly for mainchain swaps.

• ⛓️ Taproot-based L-BTC/BTC chain-to-chain swaps.

We’d love to hear from you!

We acknowledge that perfection is elusive, and our web app is no exception. We value your feedback, bug reports, and feature requests, which can be shared through GitHub or our Discord server!

That's all for today! Stay updated by subscribing to our Substack newsletter.

Subscribe now

TL;DR of how we got there (for the long version check this thread):

Beginning May 4th, fees rose, dramatically and continuously. Block by block. One of the main problems encountered during this extreme week-long fee hike were fee estimations. In other words, when submitting transactions with mempool.space’s “High Priority” fee, transactions were consistently lagging behind the next block’s fee rate and didn't get mined. At least not in time for swaps to complete, in our case. Once a swap timed out, the situation worsened: locked-up on-chain coins needed to be claimed back with yet another on-chain transaction that, you guessed it, failed to get mined for a long time too. Atomic swaps ftw. 😶

On May 8th, we finally ended up with all our UTXOs, all our working capital, stuck in the mempool with fee rates nowhere near current rates, and we had to pull the trigger and switch off.

The Problem

Not solely high, but volatile fees. This is not only a problem for us as a LSP, but for everyone operating a Lightning node. Whether it be individual routing node runners or businesses that depend on sufficient inbound capacity to accept payments or deposits. Most of these parties rely on some sort of⚡ ⇄ ⛓️ swaps to keep their channels balanced and functioning, either as a main strategy or fallback. It’s the only thing that works reliably. Until now.

Rebalancing costs via mainchain swaps can easily double or even go 10x within an hour in a high-fee environment. Most business models make it impractical to dynamically pass these costs on to users, let it be the PPM setting in a routing node or charging users of your Lightning PoS terminal.

The Solution

Liquid to the rescue! Shifting rebalancing chain footprint to the Liquid Network, one of Bitcoin’s longest-running sidechains, not only makes sense economically, but it also makes Lightning more reliable and independent from Bitcoin’s mempool. 💪

Liquid’s feature list is long: fast 1-minute block times, transaction finality within 2 minutes, confidential transactions, asset issuance, Liquid Bitcoin (L-BTC) provably backed 1:1 by mainchain Bitcoin and more. But really important for us are these:

• It’s Bitcoin.

• It’s battle-tested.

• It’s grossly underutilized.

This makes it the perfect base for reliable and cheap Lightning channel rebalancing.

How Does it Work?

Let’s say you are a merchant accepting Lightning payments and need to rebalance your channels to make sure you have enough inbound capacity. What we’ll do to get inbound capacity is swap Lightning Bitcoin for Liquid Bitcoin - moving Lightning Bitcoin to the inbound side of the channel. Let’s walk through the steps one-by-one:

1. Head to 👉 boltz.exchange 👈 and enter the amount of inbound capacity you want to obtain in the upper “Lightning” field.

   

2. Enter a Liquid address to receive L-BTC and press “Create Atomic Swap”

   

3. Pay the Lightning hold invoice of about 100,000 sats in the next step and wait for your L-BTC to arrive. This should take ~2 minutes since the atomic swap protocol consists of two transactions on Liquid: first locking your L-BTC and then atomically unlocking it together with your Lightning payment. And… that’s it!

   

And YES, these are actual atomic swaps! This means no trust in Boltz is required as we never have custody over your funds, not even for a split-second. It is deeply-rooted in Boltz’s DNA to build the best possible UX non-custodial products.

Talking UX. The current swap box interface can merely serve as a proof of concept for rebalancing channels. What we are considering adding next is a “Liquidity” tab that provides an optimized UI to obtain a certain inbound/outbound liquidity or an entire channel with a configurable amount of inbound liquidity.

Running the Numbers

So how much can we expect to save compared to rebalancing with regular mainchain swaps? Some of our beta users were quick to come up with fee comparisons. Let’s give it a closer look using a specific scenario:

Scenario: 100,000 sats inbound liquidity at 50 sats/vB on mainchain:

Mainchain:
291 bytes * 50 sat/vbyte + 500 sats Boltz fee (0.5%) = 15050 sats

Liquid:
3881 bytes * 0.11 sat/vbyte + 100 sats Boltz fee (0.1%) = 527 sats
==========
96% savings

*Please note that fee values on boltz.exchange can slightly differ because of how rounding is applied.

In a 500 sat/vB fee environment, like we had it earlier this month on Bitcoin’s mainchain, savings are >99%. A similar picture for obtaining outbound liquidity. Some quick math also tells us that mainchain miner fees had to permanently go back to 1 sat/vB to compete with Liquid swaps fees. We strongly believe they won’t.

So even though we decided for the much larger confidential transactions on Liquid for the privacy gain, the reliably ultra-low fees of 0.11 sat/vB beat Bitcoin’s mainchain easily. Here is why we think we can rely on 0.11 sat/vB on Liquid in the foreseeable future: because of the shorter block times Liquid’s transaction capacity is actually greater than Bitcoin’s. So until Liquid attracts more activity than the Bitcoin mainchain, we can rely on low fees. 🥹

Completing the Circle: Converting L-BTC Back to BTC

Experience with our mainchain swap product tells us that we should expect most users to use Liquid Swaps to obtain inbound liquidity and thus accumulate L-BTC. Those users will want to go back to mainchain BTC at some point (to open more channels or use BTC otherwise) and that is fine, of course. Naturally these users would need a different way than Lightning to go back to the mainchain since this would otherwise reverse all rebalancing.

Only Liquid Federation members have keys to use the official peg-out mechanism, so we must refer to the custodial “peg-out” service offered by SideSwap for the time being. But we are well aware that this needs an equally convenient and non-custodial way back, so we are going to build it: L-BTC/BTC chain-to-chain atomic swaps.

Next up

• 👨‍💻 We’ll continue to improve UX for rebalancing and bring our new web app live on boltz.exchange.

• 🌊 Depending on feedback, we’ll prioritize a dedicated “Liquidity” tab in our WebApp or a solution for automated/unattended rebalancing.

• 🥕 We’re working on moving to Taproot native swaps for enhanced privacy and significantly reducing on-chain footprint of swaps, especially important for mainchain swaps.

• ⛓️ Taproot-based L-BTC/BTC chain to chain swaps.

That’s it for today, stay tuned by subscribing to our Substack!

Subscribe now

2020 has been a rather taxing year in every sense of the word, and we are all looking forward to a better 2021. But when it comes to the lightning ecosystem, the pace of progress didn’t halt. Lightning is considerably more robust and secure now than before. Fulgur ventures published a detailed overview on the state of lightning ecosystem — Infrastructure projects like Boltz along with #LiFi are the largest categories. It further consolidates our hope that slowly but surely, we are moving in the right direction. Ryan Gentry from Lightning labs tweeted a great year-in-review thread on lightning’s 2020 progress:

Without further ado, let us dive right into how the year has been for Boltz and what we hope to achieve in 2021. For the uninitiated, Boltz product offerings has two facets — First, we are a privacy first, account-free crypto exchange. And second, we are a LSP (Lightning service provider). Various apps like Breez, Thunderhub, and Electrum have integrated Boltz lightning services in their apps — which enabled a frictionless user experience for their end users. With the release of landmark features like on-the-fly channel creation swaps, we focused on LSP offering in the first half of 2020. The second half of of the year we worked hard on bringing more assets to the exchange side of Boltz offering. We added Tether(USDT) — which enabled our users to atomically swap USDT and lightning Bitcoin. While we grew together with the lightning ecosystem and learned a lot in the process, we have few more goodies to unwrap from our roadmap in coming months that we are excited to share with you guys:

• Ether Integration: We have now added support for Ether in the current Boltz release. You can hop on to https://boltz.exchange and swap your lightning Bitcoins with Ether and vice versa. The integration of second largest crypto by market capitalization will increase optionality for our users and as an exchange service, that’s one of our main value proposition.

• RTL Integration: This has been long in works and after months of efforts sorting out every single little detail — we are psyched to announce that next RTL release will feature an optional opt-in Boltz support. We’d like to thank Suheb and Shahana from the RTL team for escalating this RTL release. It further manifests what is possible when teams with shared values collaborate together.

• No Ether required to claim: For account-based chain like Ethereum, the luxury of being able to store the state on-chain means that we can build tools with better user experience. Our current architecture requires that user should already have some ether in their Metamask wallet to pay for miner fee when receiving Ether or USDT from a Boltz swap. During the swap process, Boltz client does a sanity check for if the wallet has enough Ether or not. We have been brainstorming better ways to tackle this, including small custodial invoice (worth $1 for instance) that the user can pay to cover the fee before the swap process resumes. This protocol will make swapping on Boltz an even more seamless experience.

• WalletConnect: Adding more Web3 providers is also something we are looking forward to in coming months. This would make swapping ETH and USDT on mobile phones easier.

• Support for c-lightning: Boltz is a lightning node implementation agnostic project and we plan to add support for c-lightning and Eclair down the line in our boltz-lnd cli tool. We hear our users are most excited for this so rest assured, we are sure to push this up on our priority list.

• Chain to Chain swaps: For Boltz to become a fully fledged digital asset exchange platform, it’s important that we do offer cross chain layer one swaps. Once shipped, Boltz would be a full blown viable alternative to current custodial exchanges like Shapeshift.

Did we miss anything? Would you like to suggest a feature that you’d like us to work on? Feel free to hop on our Discord. We are all ears.

We wish everyone a happy new year! Stay safe and happy swapping!

Rewind

Boltz started as a simple submarine swap service that allowed users to refill and withdraw from their Bitcoin lightning channels across layers in a self custodial manner. This naturally attracted lots of early lightning adopters to use our service. We slowly added API support, which enabled apps like Breez to integrate Boltz reverse swap service, and also launched Channel Creation swaps, which made it easy for new users of lightning to get a fully balanced ready-to-transact lightning channel with inbound liquidity. Over time Boltz had evolved into a full fledged lightning service provider (LSP for short). While we will continue to work on other LSP features and integrations with various lightning apps that are currently in the pipeline, we felt it was time to give the “exchange” side of the Boltz offering some attention. We are starting this today by adding Tether (USDT).

The Tether conundrum

Tether has been a controversial topic of debate in the Bitcoin community. Many are apprehensive of it, and rightly so. After all, how could an inherently pro privacy and economically libertarian community endorse Tether? The entity behind the Tether cryptocurrency is accused of freezing assets and issuing tokens on a whim, which according to many is an antithesis of what the community stands for. But for the better or worse, Tether has proven to be quite successful and resilient to regulations. In this ongoing crypto bull run, Tether’s commutative transaction volume went above $600B. With first mover advantage, Tether has benefited from building a network effect around its stablecoin before anyone else even got started. The rationale behind us deciding to add it is that Boltz is an exchange service and it cannot function as one without offering popular asset pairs. The popularity and adoption of the BTC/USDT pair has been able to garner in the past few years is evident by the success of companies like Binance. As a privacy first and lightning first project, we enabled the LN-BTC/USDT pair only with one particular use case in mind: providing our users an option to refill their lightning channels with USDT.

Technology

Since inception, we at Boltz have worked towards building a cross chain and cross layer atomic swap solution using native assets. It is not only practical but also adheres with the core principals of privacy and self-custodianship. Tether offering adds another feather to the cap. BTC-LN to USDT and USDT to BTC-LN swaps on Boltz uses the same HTLC powered concept prevalent in other cross layer swaps already offered by Boltz. HTLCs, or hashed timelocked contracts, are integral to the architecture of the lightning network, and are standardized on the Bitcoin blockchain. This doesn’t hold true for account-based blockchains like the Ethereum network — which means to add support for ERC20 tokens like Tether, you guessed it — we needed to write a smart contract.

Building a smart contract for Boltz swaps required us to focus on two main aspects: security and transaction costs. Security of the user’s funds is of utmost importance to us. We were obsessed about making sure that the smart contract is written with industry grade best practices. We also undertook rounds of in-house penetration testing. These steps were important for making sure that the smart contract is production ready before deployment. With all these frequent DeFi hack news, we are proud to say that we don’t test in prod.

The second important aspect of our focus was the transaction cost. With heavily fluctuating gas prices on the Ethereum network, it’s important for us to optimize our smart contract for gas use, so that our users can save on transaction fee. There’s a simple rule when it comes to gas costs on the account based blockchains: computation is cheap, storage is expensive. We were able to considerably bring down the transaction fees by storing as little data in the global state of the Ethereum network as possible.

The novelty of the Ethereum smart contract allowed us to eradicate the need for users to download the refund files for USDT to LN-BTC swaps — which is a necessity for swaps UTXO based chains. All the data needed to refund the locked coins from the contract can be queried via an Ethereum node. This resulted in a smart contract that not only offers great user experience on Boltz but is also secure, cheap, and easily auditable with rudimentary understanding of the Solidity language.

In the spirit of open source and complete transparency, here is the Boltz contract for the swap that is verified on Etherscan. The code is publicly available in the Boltz Github repo.

Demo

The following is the video demonstration of how users can use their USDT to refill their lightning channels using Boltz

Summary

USDT integration was in the works for quite a while now and we couldn’t be more stoked to finally ship this. We hope that our users would be as excited as we are for this new asset that can be used to refill and rebalance lightning channels. Like always, hit us up on Discord if you have any feedback or just want to say Hi. Stay healthy and Boltz on ⚡

Bitcoin is a decentralised monetary protocol. All on-chain Bitcoin transactions are public, traceable, and permanently stored in the blockchain. Anyone can see the balance and all transactions of any address. While this transparency is great for lots of stuff that makes Bitcoin valuable, like transaction verifiability, privacy isn’t one of them. Once a Bitcoin address is used, it becomes tainted with the history of all transactions it was ever involved with. All Bitcoin transactions are composed of at least one input (where the BTC come from) and at least one output (where the BTC are sent to). Additionally, Bitcoin transactions are constructed in such a way that it includes the information about previous transactions. For example, if you received 1 BTC in an address, and intend to send 0.4 BTC to your friend, you’d need to construct a Bitcoin transaction of 1 BTC, where 0.4 BTC will be sent as payment and remaining 0.6 BTC will be returned to you as a change. This means that every single Bitcoin transaction leaves a trail that can be exploited to trace the movement of Bitcoin across the blockchain. The unspent transaction output (UTXO), as the name suggests, is the result of a transaction that a user receives and can spend in the future. Learn more about UTXOs here.

Cometh CoinJoin..

CoinJoin, which was first proposed by Gregory Maxwell in 2013, attempts to improve the privacy of Bitcoin transactions. Using CoinJoin, multiple users combine their UTXO into one large transaction with multiple inputs and multiple outputs. Each CoinJoin mixed outputs are of a fixed same amount. This breaks the traceability of the transactions and makes them indistinguishable on the blockchain, so that Uncle Sam can’t spy on you. The three main ready-to-use software CoinJoin implementations are Wasabi Wallet , JoinMarket, and Samurai Whirlpool.

Problem: Unmixed CoinJoin Change

While CoinJoin helps to increase the anonymity of a Bitcoin transaction, it comes with a caveat — change outputs, that are not of a fixed same amount, remain unmixed and can potentially break the anonymity. As explained in previous section, change output is the fundamental part of how Bitcoin transactions work. However, when you send the coins which are the change from a previous transaction, receivers and blockchain observers can easily deduce that you were involved in the previous transaction that generated the change. Identifying change based of such heuristics is one of the many methods surveillance companies like Chainalysis use to spy on users. A common pitfall is sending unmixed coins and mixed ones to the same address, which can effectively result in user’s identity getting leaked. There are few different ways to deal with unmixed Bitcoin change, we will focus on how Boltz can be used as a tool to counter this risk.

Solution: Swap unmixed change using Boltz

Boltz submarine swap service offering can help users mitigate the risk caused by the unmixed CoinJoin change. By atomically swapping the CoinJoin change for refilling lightning channels using Boltz, the user can eliminate the risk of clean coins getting tainted by accident. The Lightning network has relatively potent privacy properties. And it is not yet being tracked to the extent that on-chain coins are, this makes Boltz swaps an easy and effective way to deal with CoinJoin changes. Since the user is creating the lightning invoice that Boltz will pay in this swap process, Boltz will know the user’s node public key and the lightning channel Boltz sent the funds to. Hence, this is not a perfect solution since Boltz could cluster your change output and your lightning node. We do however hope that rendezvous routing, when integrated to the lightning spec, will make this an even more effective solution.

Demo

Below is the demonstration of swapping unmixed CoinJoin change from Wasabi (marked with a red shield) to lightning Bitcoin through Boltz.

Related Readings:

• Bitcoin Wiki — CoinJoin

• Wasabi docs — CoinJoin

• CoinJoin Sudoku

A lot has happened in these past months. Amidst the world going through a pandemic, FED brrrinting money like it’s nobody’s business, stocks making the crypto market look like a day at grandma’s house, and Kanye running for president, 2020 continues to bemuse us. The Bitcoin lightning community, however, knows that it’s time to build, and has made silent, but significant progress. There are more than 13k public LN nodes now with about 1k BTC in channel capacity. These numbers inspire confidence for the future of the Lightning network and motivate many like us to continue building towards the common goal to create the money and payment system of the future.

Make measurable progress in reasonable time

Measuring progress is an important part of a startup’s journey. If we can quantify and analyze our progress, we can precisely gauge our efficiency and holistically judge how far off we are from achieving our goals. To do so in a transparent manner, we’ve listed six major achievements we have unlocked in the past six months.

1. Boltz.exchange got a facelift 🎉

We shipped a new and revamped frontend for Boltz with a much-improved user interface across desktop and mobile platforms. This was one of our main focuses in the past few months. One of the support issues we had to repeatedly deal with was users not being able to immediately refund in case of a swap failure. The lightning network is still in its nascent stage and routing errors are a common cause of failed swaps. In such cases of failed normal submarine swaps (on-chain to LN), the user could use the refund file downloaded during the swap to claim back the on-chain coins that they sent. Due to the nature of hashed time-locked contracts, the refund could only be triggered after a certain number of blocks were mined, which resulted in confused users trying to refund a swap immediately after the failure, but to no avail. We fixed this in our revamped website, where the users are now acutely made aware of the number of blocks and approximate time they need to wait before they can initiate a refund. The frontend also saves the refund files of the latest swaps in localstorage of the browser. We ironed out many prevalent issues like these and other points of friction in the user journey — which significantly improves our net NPS score. The revamped Boltz website is a progressive web app, which makes using Boltz on mobile a native app-like experience. We will continue to iterate on the feedback we have received to build on our promise of providing the best user experience while retaining the non-custodial and private nature of Boltz swaps.

2. RTL integration of Boltz — PR ready 🥳

WIP: Add Boltz as additional swap provider by dejankocev · Pull Request #361 ·…
WIP: This PR adds Boltz as an additional swap provider alongside Loop. From UI perspective, Loop in (submarine swaps)…github.com

As a Lightning Service Provider, one of our goals is to partner with projects in the space and provide value to their end-users. Ride the Lightning (RTL) is a full-function, device-agnostic, web user interface to help manage lightning node operations. People running LND, c-lightning, or eclair node implementation of the lightning network can access their node via a web interface to actively manage it. We realized that Boltz can add a lot of value to these lightning power users who want an easy way to on and off-ramp themselves from the lightning economy in a self-custodial and trust minimized manner. Our integration with RTL adds the Boltz channel deposit and withdrawal feature and as an additional choice to the lightning loop integration. Channel creation swaps, our novel, and self-custodial way to obtain a balanced lightning channel with a simple on-chain transaction is coming to RTL soon as well. See #6.

3. Electrum integrates Boltz ✌

Electrum, one of the oldest Bitcoin wallets, released a new version of the wallet, which supports Boltz submarine swaps out of the box. This is a huge win for privacy in Bitcoin. We worked closely with the Electrum team to get this shipped by adding needed features and improving documentation on the way. Our API is now more robust than ever before and ready for devs to hack around with.

4. We were featured on Fulmo’s PotzBlitz podcast 👁️

Fulmo’s PotzBlitz is a weekly lightning talk podcast while the world is in lockdown. Its purpose is to create a sense of community, update the viewers on the latest developments in the lightning world, and give creators a platform to showcase their project. We were honored to be invited to talk about running a privacy first, account-free crypto exchange. We talked about everything from our vision to technology and went deep into the architecture of submarine swaps. We would like to thank Jeff from Fulmo and Dennis from Bitwala for hosting us. Here are the slides from this talk.

5. Decentralized liquidity aggregator Exchange Union’s daemon integrates Boltz — making it default choice to power lightning deposits 😎

feat: add Boltz daemon (#532) · ExchangeUnion/xud-docker@c81ecf4
Permalink Browse files feat: add Boltz daemon (#532) * feat: add Boltz daemon * chore(boltz): add shortcuts for…github.com

Exchange Union, is an open-source project building xud — the reference implementation powering OpenDEX, which is a decentralized exchange built on top of the Lightning and Connext network. xud brings individual traders, market makers, and exchanges onto OpenDEX to form a single global trading network and liquidity pool, in a bid to counter fragmented liquidity problem persistent across modern-day exchanges.

Using Boltz, market makers running the XUD docker environment can directly get balanced channels and deposit or withdraw from their lightning channels using a simple command or upcoming WebUI interface.

6. An epic feat: Channel Creation Swaps 🎊

Our latest Boltz Ragnarok release bundles a landmark feature: Channel Creation swaps. We published a detailed post on it. The fact that the user can now get a balanced lightning channel from the get-go while retaining the self custodial and private nature of the Boltz swaps is quite revolutionary in itself. Channel creation swaps are a type of normal submarine swap — which means that lapp developers can build a seamless user experience on top of the same API endpoint primitive. Some wallets and projects are in the final stages of integrating it, which makes this feat a highlight of our past few months at Boltz.

What’s next

As the world recovers from the pandemic and the economy bounce back, we are hopeful that the lightning projects will gain even more momentum. This building streak of the past few months has given us lots of headways and we plan to capitalize on it by carrying on with the shipping mode. Our next major release will feature the integration of a BTC/USDT pair. This will increase our targeted userbase as an exchange. A stablecoin integration means Boltz traders will be able to use Boltz to shield themselves from the volatility of the market. If you have any questions, feel free to hit us up on Twitter or Discord.

Until next time, happy swapping!

Team Boltz

Primer

Bitcoin’s lightning network has been under constant limelight since it was conceptualized by Poon et al. in a 2015 paper. It’s touted as a solution to the scaling problem of the Bitcoin network. By acting as a second layer, the lightning network enables faster settlements of transactions without compromising with the censorship-resistant properties of the underlying blockchain. But it comes with a fair share of tradeoffs. Lightning skeptics have long argued that the Lightning Network is essentially hard to use and the way it is architectured results in a user experience that doesn’t pave a friendly road for users who want to take part in the lightning economy.

By building products and tools that help improve its usability for lightning users, we at Boltz as a Lightning service provider (LSP) have contributed towards fixing these aforementioned issues. Our new flagship offering: Channel Creation Swaps, is another step towards that goal.

Introduction

As the name implies, Boltz Channel Creation Swap is another tool in the ever-growing Boltz arsenal that allows the users to get a balanced lightning channel in the easiest and most frictionless way possible. This is an important landmark for Boltz and the lightning ecosystem at large because it makes it easy for users to get up and running with lightning in a matter of minutes. There are few other providers that offer such a channel creation swap server, namely: Bitrefill’s Thor and Eclair’s Pheonix wallet, but Boltz offering distinguishes itself by keeping the self custodial and atomic nature of the channel creation service intact. This is revolutionary because there’s always a fine line between trading off the trustless nature or letting users deal with the UX friction. Boltz Channel Creation Swap finds a great balance between the two — which makes this offering an attractive proposition for developers trying to onboard users to their lightning wallets and apps, without worrying about which service to trust as these swaps retain the atomicity principle, i.e, swaps either complete in full or the user funds get refunded.

User Story

A normal user flow of setting up a self-custodial lightning wallet comes riddled with friction. After downloading the wallet and funding it with on-chain coins, the user has to open a channel and find a way to get inbound liquidity to the nodes he intends to transact with. This increases the user churn as it is the antithesis of promised fast payments via the lightning network.

By using a wallet or app that integrates Boltz Channel Creation service, end-users can now send the on-chain funds to Boltz, and in return, Boltz opens a fully balanced ready-to-transact lightning channel to the user’s node with inbound liquidity. This adheres to the ubiquitous and intuitive deposit flow in Bitcoin wallets that users are already familiar with — making this whole experience of going from installing the wallet to doing the first transaction as seamless as possible.

At the architectural level, Boltz Channel Creation Swaps are a kind of normal submarine swap (on-chain to off-chain) but with an additional feature — If there exists no route between the user and Boltz node, Boltz will open a channel on the fly and deposit the amount that the user sent on-chain minus the fee, to the newly created channel. This means that for a Channel Creation Swap to get triggered: There shouldn’t be an existing route between the user and Boltz with a cumulative inbound capacity greater than or equal to the intended on-chain deposit amount. The perk of channel creation swap being a type of normal submarine atomic swap is that the user doesn’t need to trust Boltz or any other lightning service provider offering this service — making it a truly transformative UX improvement for people using the lightning network.

Demo

This is a step-by-step demo of the channel creation swap.

Summary

Boltz channel creation swap is an important milestone for Boltz and the lightning ecosystem. It’s planned integration with popular node management tools and wallets would further bring down the UX barrier. We plan to continue working on building tools that will enable more users to partake in the lightning economy and empower them to join the movement of reclaiming our financial sovereignty.

Until next time, Boltz on!

Team Boltz.

Cutting the Jargon

An altruist reader of our blog rightly pointed out that lightning to on-chain swaps on Boltz has one major flaw, which we were aware of and actively working to counter.

What prevents a user from locking up all of the boltz funds by opening a lot of reverse swaps…
It won’t cost the customer (they just add their btc address) but will cost boltz because they’re locking up on chain…medium.com

To summarize the issue in layman’s terms — Boltz was locking funds (the coins the user intended to buy) before the user paid the invoice (the coins the user intended to sell). It opened up Boltz to a spam vector, wherein, any motivated malicious third party could repeatedly start a swap and bail out before paying the invoice. This would result in Boltz locking up on-chain funds over and over again while losing a few satoshis on on-chain fee every single time. Moreover, Boltz also pays the opportunity cost of locked-up funds for the duration of the swap timeout.

When it rains, it pours

As if these vulnerabilities weren’t enough of the trouble already, the reverse swap flow also had an inherent design flaw: the sweeping, or the claiming of funds by the user client had to work, or the user could lose funds.

We encountered many instances where we had to manually refund back the coins to the user because their browser failed to claim the fund. It could be caused by an unstable internet connection, browser crash, or any of the million things gone wrong on the client-side. For a non-custodial crypto exchange like Boltz, safeguarding the user fund is the bread and butter, so solving this issue was extremely important. We brainstormed many methods to counter this, including now-defunct Protocol 11, but we wanted a solution that didn’t break the atomicity of the swap, so we kept looking.

Till it finally dawned on us

A different kind of lightning invoice — hold invoice, have the potential to solve our problem. Folks at lightning labs were quick to detail the new swap architecture enabled by hold invoices in a blogpost.

Hold invoice is simply a lightning invoice with an added quirk: instead of locking and settling the HTLC (hashed time-locked contracts) immediately when the payment arrives, the HTLC is only locked, not settled. This enables an interesting flow on the receiver’s end — they can choose whether to settle or cancel the HTLC. From the sender’s perspective, a hold invoice looks identical to a regular lightning invoice, which makes it compatible with all existing lightning wallets. There have been many interesting use cases of hold invoice now in production — that extended the lightning implementation to accommodate new flows, which in turn improved the user experience by orders of magnitude. For example, our friends at Breez used hold invoices to build Lightning Rod, which enables asynchronous lightning payments.

Let Bob send the preimage first

Cutting to the chase, our new reverse submarine swap architecture made use of hold invoices in such a manner that the user now creates the preimage and locks up the lightning funds before Boltz, which means there is now a non-negligible cost of locked funds when deciding to bail out from a swap. This significantly reduces the spam attack vector, since it’s simply not for free anymore to bail out from a swap. The following picture depicts our new swap flow and gives a high-level idea of the process.

Step 1: Bob creates a hash of the locally generated preimage and sends it with the “start swap” HTTP request to the Boltz server.

Step 2: Boltz makes use of the said hash to create a hold invoice. Boltz then sends the invoice to Bob.

Step 3: Bob receives the invoice and pays it with her lightning wallet. What really happens is, that the signed HTLC from Bob’s wallet is sent to Boltz, but the payment is held by Boltz and not executed at this point because it is still missing Bob’s preimage to do so.

Step 4: Boltz then locks up the on-chain coins using a swap script that requires Bob to reveal the preimage when claiming.

Step 5: Bob claims the locked on-chain funds that subsequently reveals the preimage.

Step 6: Boltz then uses that preimage to unlock the lightning payment.

This new reverse submarine swap dramatically reduces the spam attack vector and also eradicates the problem of the user losing funds when claiming fails client-side. It substantially improves the user experience of Boltz. If you are a developer, you can look at our documentation for the new swap flow lifecycle. You can also hack around with our new endpoint for creating reverse swaps. Shoutout to our friends at Breez for helping us to test and improve our new endpoint!

What’s brewing next

A lot is happening at Boltz, and we cannot wait to reveal what’s next. We have some exciting announcements to make, which will be huge for the community as a whole and us. Non-custodial and private trading of digital assets remains our core ethos, and we will continue to work towards making it a reality.

Till next time, Adios and happy swapping!

Team Boltz.

We believe that developers are very core to what makes a platform and the ecosystem as a whole succeed. So today, we couldn’t be more proud to announce the official release of the Boltz API with the associated documentation. Let’s go through some use cases to hack around with the Boltz API, shall we?

⛓ ⚡ Trust-minimized on-chain on-ramp

Integrating Boltz with your lightning app enables you to on-board users who might not be using any lightning wallets yet. Boltz will provide a trust minimized way to use lightning apps with on-chain coins, which will curb the UX friction by enabling your lapp users to get outbound liquidity with an on-chain deposit.

⚖ ⚡ ️Balancing or Rebalancing Lightning Channels

Developers of different wallets can provide a native and trust-minimized way to balance or rebalance their user’s lightning channels with the Boltz API.

💸 ⚡ Withdrawing from Lightning Channels

Wallet developers can also use the Boltz API to provide an option for the user to withdraw from their lightning channels.

💰 ⚡ ️Depositing into Lightning Channels

In times of high fees, Boltz integration will allow you to empower your lapp users with the choice of using on-chain Litecoin to deposit into your ⚡-Bitcoin channels, as described by Charlie Lee. All this without trading off the non-custodial nature of your lightning app.

📥 ⚡ Bootstrapping initial inbound liquidity

For people not having enough inbound liquidity or new users having no lightning channels, a trust-minimized channel opening service can be built on the top of Boltz, similar to Bitrefill’s Thor. The service can account for the channel opening and service fee in the on-chain amount received from the user during the swap.

🔁 ⚡️ Trading LTC/BTC

By integrating Boltz, developers can also add the feature to swap different assets in their lightning apps, akin to Shapeshift but without all the baggage of KYC and different trust assumptions. This will, however, get even more interesting with new assets being added to Boltz.

Check the documentation of the Boltz API 👉 here 👈

Our endpoints are stable and no breaking changes are planned. In an unlikely situation where we have to change the endpoints for any reason, we will be quick to give developers advanced notice so they have adequate time to make updates. Stay tuned to our Twitter feed or chat with us on Discord!

Stay #reckless and happy hacking!

We are excited to announce a new feature update which will make the trading experience on Boltz as seamless and instant as ever. User experience is paramount to our cultural ethos at Boltz and when our users speak, we ardently listen; based on the feedback we decided to empower our users with an option to fast track the trade using 0 confirmation if certain preconditions are met, which are further described in this article.

Introduction

As the name implies, 0-confirmations are transactions that have been broadcasted but did not receive any confirmations yet i.e. the state where the transaction is yet to be included in a block. In the current architecture, an on-chain bitcoin to lightning-bitcoin swap flow follows these intuitive steps:

1. The user enters the swap amount and initiates the trade. In the successive window, she pastes the lightning invoice of the ⚡bitcoin she is ought to receive.

2. User is prompted to download the refund.json file and is successively presented with a bitcoin on-chain address to send the funds to.

3. After one confirmation on the Bitcoin’s blockchain, which takes ~10 minutes, the user receives the equivalent ⚡bitcoin in her lightning wallet.

It is rather apparent why, in many cases, the current flow might not make for ideal user experience. The user often wouldn’t have the patience to wait for 10 minutes to receive her funds and she could, in principle, choose to use any of the centralized alternatives for this very reason. We found that empowering the end-user with an option to receive the funds even before the transaction receives one-confirmation, by trading off a small amount of trust, results in orders of magnitude improvement of swap experience and therefore helps us avoid user churn.

In the famous quote replying to now EOS CTO Daniel Larimer (not sure he got it) Satoshi provided a framework and reinforced that a payment processor can verify the payments “well enough” in 10 seconds or less. This also reinforces the notion that if handled properly, low-value 0-conf transactions are not only safe but encouraged.

Caveats

We will start by explaining a very important feature of the Bitcoin protocol — Replace-by-Fee (RBF)

In laymen terms, it allows for the replacement of a transaction with a new version of the transaction, which is useful if the first transaction is stuck in the mempool because of low fees. The new version of the transaction can (and has to) pay more fees which will increase the probability of being included in a block. While this may be very useful for the free market that the Bitcoin protocol is hedging for, it comes with a serious drawback — a malicious actor can hypothetically double-spend the unconfirmed transaction using RBF. Because when a transaction is replaced with RBF it can not only change the amounts it is sending to the outputs but also change the outputs completely and redirect the unconfirmed transaction that way.

Consider a hypothetical scenario where Alice is a malicious actor who decides to scam Boltz. Alice initiates the swap of one ⚡bitcoin for one on-chain bitcoin. As explained in the Introduction section of this article, Alice sends the on-chain bitcoin to Boltz’s bitcoin address with a 0.0005 bitcoin as transaction fee. Boltz’s server notices the unconfirmed transaction and pays the user’s ⚡bitcoin invoice. Alice receives the ln payment and then goes forward and replaces the transaction from her wallet with her own address but with a higher fee of 0.001 bitcoin. Now since this replaced transaction has higher fees, miners are incentivized to include it in the block before the legitimate transaction. This results in Alice swapping 1 ⚡bitcoin from Boltz for merely 0.0015 bitcoin in transaction fees instead of the actual 1 bitcoin.

How does Boltz hedges against this risk?

To avoid the swindle as described in the aforementioned hypothetical case, Boltz employs a couple of precautionary measures: It checks for whether the transaction is signaling RBF (inherited or otherwise), in which case, the Boltz server would not pay the lightning invoice unless the legitimate transaction at least gets one confirmation. With the tradeoff for waiting longer (10 minutes in this case), Boltz could protect itself from malicious behavior from Alice. The second precautionary measure that would potentially discourage the use of this attack vector is a check by the Boltz server to concur if the fees are high enough for the transaction to be included in the next block. This eliminates the possibility where the attacker doesn’t even need to double-spend, but just send the transaction with very low fees that stay in mempool forever without getting mined.

Are users at risk?

As described before, when using Boltz for swapping on-chain coins for ⚡ lightning coins, the risk while very small, is on side of Boltz. If however, when the user decides to swap lightning coins for the on-chain coins, the minimal risk switches to the side of the user. Boltz also has a maximum threshold in place, which is currently 1 million satoshis and 125 million litoshis (currently ~100 USD), it further mitigates the risk as users sending transactions above these amounts won’t have an option to use the 0-conf feature.

Summary

The 0-conf feature allows us to empower users with a choice, a choice to trade off a small risk with a roughly 600x improvement in speed. Users who are not comfortable with this trade-off; stick with regular 1-confirmation on-chain transactions.

Further readings

1. BIP 125: Opt-in Full Replace-by-Fee Signaling

2. Bitcointalk discussion on RBF (Replace-by-Fee)

3. A breakdown of the infamous bitcoin ATM hack that exploited 0-conf attack vector

Introduction

Suppose that Alice agrees to sell 10 Litecoin for 1 ⚡Bitcoin to Bob, so the trade gets executed in the following steps:

Step 1)Bob will create an invoice for 1 ⚡Bitcoin and sends it to Alice

Step 2)Alice will generate a redeem script and address based on the hash of the preimage of the invoice

Step 3)Bob will send the on-chain Litecoin to this address

Step 4)Alice will pay the aforementioned invoice of Bob to get the preimage in order to be able to claim those 10 Litecoin

The aforementioned steps illustrate how a submarine swap between ⚡Bitcoin and Litecoin (buying ⚡Bitcoin by sending on-chain Litecoin) works. But there’s a catch, during that period of time, Bob can choose to delay sending his Litecoin to Alice’s address, for as long as Alice is annoyed enough to bail out of the agreement because the onchain HTLC times out. If the exchange rate changes in Litecoin’s favor, Bob would wait until the onchain timelock expires and keep his “more valuable Litecoin”. If however, the exchange rate tilts in Bitcoin’s favor, Bob would settle the payment and receive the Bitcoin at a discounted rate. Evidently, this gives an unfair advantage to Bob since Alice is left prone to Bob delaying his payment and take advantage of exercising his option to let the swap expire. Completely free of charge. This proves that the method of trade described above depends on the altruism of Bob and hence isn’t a foolproof system.

This problem is well studied in modern cryptography. Many research papers like How to Use Bitcoin to Design Fair Protocols have proposed workarounds. But a solution to the free options problem, which is a subset of the broader fair exchange problem, has been found to be impossible to solve so far without the use of a trusted third party. In the context of lightning powered exchanges, Corné Plooy, a researcher who earlier created a related thread pertaining to this on Lightning-Dev mailing list, proposed a solution that lowers the amount of trust needed to be placed on the third party in this scenario. This proposed solution, according to Plooy’s own admission, is far from perfect but we think that this is a step in the right direction and departure from the belief that a multi-asset lightning network and in turn exchange of different assets via lightning may not be economically viable.

How did this affect us at Boltz?

Simply put, WE GOT REKT

We started to observe suspicious bot trading activity on Boltz (albeit quite late) on the BTC/LTC pair. The attacker was making use of the free option exploit and waiting for the rate to sway to his favor, at which point, the attacker would go forward with the trade to churn out a profit. The Litecoin price increase in the month of May complemented this strategy and made it a lucrative exploit. We deployed our SWAT team to research this and realized that regular submarine swaps (paying ⚡ invoice via on-chain tx) on Boltz did not have a timeout. This major bug made it very easy for the malicious actor to carry out this attack as s/he could quite literally delay the release of the preimage forever. We quickly deployed a fix that made Boltz abort the normal swap when the on-chain timeout expired.

But the draining continued…

The fix proved to be inconsequential to our cause as the funds keep getting drained out. It turned out that, the block timeout, which was ~10 blocks for the Bitcoin’s blockchain, gave enough room to the attacker to continue with the offensive. In the process, a bug was discovered, which opened another attack vector: we miscalculated our fees. We were finally able to control the damage by fixing these two bugs. We decided to invest time building better internal toolings i.e robust warning system and periodic statistics updates that can help us track and deter any potential exploit earlier than we did this time around. We decided to move away from CryptoCompare for rates, and built a new rate calculation mechanism that takes the rates from the APIs of five popular exchanges, namely, Binance, Bitfinex, Coinbase Pro, Kraken, and Poloniex and averages them out to get a more “fair” rate for our users.

We apologize for any inconvenience caused by the downtime Boltz experienced in the past weeks. The code is now more robust than ever before and we are excited about a new big feature launch soon. Please watch out this space for more on it.

Further Readings on Free Option Mitigations

1. A solution on preventing transaction delays with a Lightning routing service, for preventing abuse in a Lightning-based peer-to-peer exchange.

2. Another proposal on a trusted latency monitor service

“WebLN is a library and set of specifications for lightning apps and client providers to facilitate communication between apps and users’ lightning nodes in a secure way. It provides a programmatic, permissioned interface for letting applications ask users to send payments, generate invoices to receive payments, and much more”

Source: webln.dev

Inspired by Ethereum’s web3 standard, William O’Beirne set out to make a similar standard for lightning which could improve the experience on the web. Since then, it has gained noticeable traction in the community with lots of different lightning apps like Lightning Joule now supporting it. At Boltz, we constantly obsess about user experience and brainstorm ideas around making Boltz easier to use for the end users. Integrating WebLN was a no-brainer. Boltz integrates WebLN in a client-agnostic manner and follows the recommended UX best practices. Integration of WebLN makes a lot of processes like generating and paying invoices a little easier, as depicted in the gif below.

There are, however, other attempts to standardize the use of lightning on the web, notably by W3C. Nevertheless, we believe that WebLN is best poised and ticks all the boxes as of right now.

The different lightning browser extensions, notably Joule, have been instrumental in making lightning easier to use. It lightning-charges any browser, which gives the user the ability to pay and create invoices without leaving their browser. We also like the idea of a lightning public key being used as a means of authentication on the internet, no PII required. Kwh is another WebLN powered browser extension with the same goal as Joule, but for different implementations of the lightning network: lightningd/eclair/ptarmigan. The fast-paced development of the lightning protocol and UX improvements is happening simultaneously which is opening up the floodgate of possibilities to build useful lapps. We are more excited than ever to continue taking an active part in building an exciting and easy-to-use product for end users.

Happy Swapping :)