Building for the future with Bitcoin

The latest from Strike

![](https://www.datocms-assets.com/99305/1733406867-strike-bill-pay_hero-2.png)

Yo! Today, I am beyond pumped to announce a new product that is core to our mission and has been highly requested by our customers: **Bill Pay, an easy, automatic way to pay your bills directly from your Strike account with bitcoin or cash.** Whether it’s credit card payments, phone bills, or utilities, you can now automatically pay bills with your unique Strike account and routing numbers, and [go all in on bitcoin](https://strike.me/all-in-on-bitcoin). 

We know that many of our customers prefer to store the majority of their wealth in bitcoin, keeping minimal dollars to reduce exposure to currency inflation; but managing everyday expenses in a fiat-dominant world can be complicated. Paying bills often requires selling bitcoin, transferring funds to a bank account, waiting for settlement, and finally making the payment—a time-consuming and costly process. 

Bill Pay simplifies this. By automating bill payments, you can hold your wealth in bitcoin and convert to cash only when bills are due. With all necessary tax documents provided, managing fiat obligations becomes seamless, efficient, and on your terms. 

A select group of Strike customers have already been piloting Bill Pay, and the feedback has been incredible. Bill Pay is now officially available for all eligible U.S. customers. [Learn more](https://strike.me/faq/what-is-strike-bill-pay).

![](https://www.datocms-assets.com/99305/1733406830-bill-pay-tweets.png)

## Story

Today’s financial system is buckling under unsustainable practices. With U.S. national debt surpassing $35 trillion and debt-to-GDP over 120%, these aren't just statistics—they're a warning. As the U.S. dollar weakens under record debt and inflation, everyday Americans are getting robbed of their purchasing power. People are looking for a way out to protect their wealth from fiat's inevitable failure. For the first time in history, we the people have built an alternative: a global, decentralized money that’s scarce, immutable, secure, borderless, and owned by everyone. That alternative is Bitcoin.

As an American millennial, I love our country but I oppose our money. Earlier this year, [I announced my decision to go all in on bitcoin and no longer own any U.S. dollars](https://x.com/jackmallers/status/1742313114362589634). Why bitcoin? It’s the best expression of fiat debasement. In 2024, bitcoin is up over 100%, outperforming even traditional assets like stocks, gold, and real estate. By living on bitcoin, I’ve been able to live more profitably, essentially buying goods and services at a discount. Many of our customers are on the same path, choosing bitcoin as their primary asset and seeking a trusted partner to help them acquire, manage, and use it. 

Since founding Strike, we've been relentlessly focused on being the best at Bitcoin. This means delivering exceptional experiences for buying and selling Bitcoin, DCA, getting paid in bitcoin, withdrawals, payments, and more. With Bill Pay, we’re advancing our mission of Better Money for all and solidifying Strike as the all-in-one platform for Bitcoiners. By offering a comprehensive suite of Bitcoin financial services, we make Bitcoin accessible, reliable, and fully integrated into the broader financial system—empowering people to live on the Bitcoin Standard. Today, we’re excited to continue supporting Bitcoiners on their journey.

![](https://image.mux.com/Uwrevo7QEoW8erbAEIXY5EjjSPbGi1Kf/thumbnail.jpg)

## Pay Bills Your Way
Use your bitcoin or cash balance to pay bills automatically

Pay your bills directly from Strike with your unique account and routing numbers. Choose either bitcoin or cash as your default payment source, and let your billers automatically pull funds when payments are due. 

To get started, tap the Account icon and scroll to Bill Pay:
1. **Generate payment details:** Your unique Strike account and routing numbers are automatically generated in the app.
2. **Set your payment source:** Choose cash or bitcoin as your default to pay your bill.
3. **Add to your biller:** Enter the account and routing numbers into your biller’s platform. The name on your bill must match your Strike account.
4. **Automatic payments:** Your bills are paid from your default balance when charged by your biller. You can easily switch between bitcoin and cash balances. 

Strike uses your available balance to pay bills. Since bank deposits can typically take 3-5 days to complete, ensure that you have sufficient funds to cover any bills while you wait for funds to deposit. Learn more about [Bill Pay](https://strike.me/faq/what-is-strike-bill-pay) and how to [set it up](https://strike.me/faq/how-do-i-set-up-bill-pay). 

![](https://www.datocms-assets.com/99305/1733406856-strike-bill-pay_hero.png)

## All In On Bitcoin
Stay fiat-free with automatic bitcoin sales only when bills are due

Bill Pay supports the Bitcoin-first lifestyle by enabling you to hold your wealth in bitcoin, converting to cash only when needed to pay bills. It removes friction, fees, and delays. Combined with Get paid in bitcoin, Shop with Lightning, free and automatic bitcoin withdrawals, and more, you can live fiat-free and protect yourself from inflation. 

What's more, paying bills with bitcoin counts towards your [fee level](https://strike.me/faq/what-are-the-bitcoin-trading-fees-on-strike/). This means the more you pay bills with bitcoin, the lower your fees for all bitcoin trading, including buys, sales, recurring purchases, target orders, getting paid in bitcoin, and your other bill payments with bitcoin.

![](https://www.datocms-assets.com/99305/1733406887-bill-pay_pay-bills-with-strike.png)

## Simplify Taxes
Receive detailed docs during tax season to make filing easy

Paying bills with bitcoin is a taxable event. Strike will provide the necessary tax documents, including summaries of bitcoin sales and bill payments from your bitcoin balance. These will be available in the app during tax season to make filing easy. [Learn more](https://strike.me/faq/how-are-taxes-handled-at-strike/).

![](https://www.datocms-assets.com/99305/1733406889-bill-pay_taxes.png)

## Wen Bill Pay?

[Bill Pay](https://strike.me/all-in-on-bitcoin) is now officially available for all U.S. customers whose accounts are in good standing, including your account’s deposit history, balances, and status––excluding Hawaii. You can learn more in our [FAQ](https://strike.me/faq/what-is-strike-bill-pay).

## Thanks

Thank you to our customers for your continued support and for trusting us to build for you. We’re grateful to be working on Bitcoin and sharing this journey with you.

Challenging the norm takes conviction, courage, and humility. The excitement around Bill Pay has been incredible—it’s a powerful reminder of why we do what we do. Your enthusiasm inspires us to keep building the tools that make living on Bitcoin a reality and push Bitcoin adoption even further.

Please keep sharing your thoughts, asking questions, and reaching out. We love hearing from you, learning about your experiences, and finding ways to make Strike the best it can be.

Until then. Much love.

Jack

Update (12/12/2024): Bill Pay is now rolled out to all eligible customers in the U.S., except Hawaii.

Pay bills from your Strike account and go all in on bitcoin

Announcing Strike Bill Pay

Today, we’re excited to announce the launch of Strike’s revamped referral program that’s simple, rewarding, and focused on getting you the most out of Bitcoin. Now, when your friend joins Strike and buys Bitcoin, you both get $500 (or €500) in fee-free stacking.

Referrals are now available to customers in the US and EU. Update your app to the latest version or [download Strike](https://strike.me/download/) to get started.

![](https://www.datocms-assets.com/99305/1728428108-blog_better-referrals.png)

## More Bitcoin, Less Fees
At Strike, we believe in making Bitcoin accessible to everyone, everywhere. With our new referral experience, we’re excited to empower our customers to bring more people into Bitcoin while rewarding them along the way. 

Our referral program is all about getting you the most Bitcoin—saving you on fees with each successful referral, so you can stack more sats and share Strike with others. 

**Here’s how it works:**

When a friend joins Strike with your referral code and buys bitcoin, you both get $500 (or €500) in fee-free stacking that can be applied to one-time buys, recurring purchases, or target orders.

The best part? There are no limits on referrals. You can refer as many friends as you want and keep earning fee-free stacking!

## Refer a Friend
Referring is easy, simply follow these steps:

1. Go to the Account screen, tap “Invite friends, trade without fees.”
2. Share your referral code 
3. Your friend signs up with your referral code
4. Your friend buys bitcoin from deposited cash or via linked payment method
5. You both get $500 (or €500) worth of fee-free bitcoin trades

You can track the status of your referrals anytime from your Account screen.

Check out our FAQs for more details about our [referral program](https://strike.me/faq/what-is-the-strike-referral-program/) and [how to use a referral code](https://strike.me/faq/how-do-i-use-a-referral-code/).

## Thanks

Thank you for your continued support and trust in Strike. We’re dedicated to building features that deliver real value to our customers. With this new referral program, we believe we’re creating a more seamless, Bitcoin-focused experience to help you stack more sats while sharing the Strike experience with your friends.

We’re excited to keep building and growing the Strike community. Have a feature idea? We’d love to hear from you!

Introducing our new referral program for US and EU customers

Announcing the Strike Referral Program

Strike has a mission to onboard the world to better money. The services we have built are designed for fast, low-cost, and seamless payments over the Bitcoin network. One of the core techniques we leverage to achieve this is batching bitcoin on-chain payments. 

![](https://www.datocms-assets.com/99305/1721871514-batching-on-chain-sends-hero.png)


In this article, we'll explore how our on-chain batching system operates, the nuances that make it effective, and some of the technical challenges we've overcome to ensure our users receive top-tier service.


## Tiered On-chain Payment Services<a id="tiered-on-chain-payment-services"></a>

At Strike, we offer a [tiered service](https://strike.me/faq/can-i-speed-up-my-bitcoin-send/) for sending on-chain payments:

- **Flexible (Free) Tier**: For those willing to wait 12-48 hours

- **Standard Tier**: For faster, but affordable sends

- **Priority Tier**: For transactions that cannot wait, targeting confirmation in the next block

This tiered approach allows us to cater to different user needs and preferences, balancing cost and speed effectively. Offering both unlimited free on-chain sends and next-block transactions to all our users poses a bevy of technical challenges. We need a system that can scale to a very large number of users, perform on-chain payments at enterprise-level volumes, keep fee costs affordable, and cleverly utilize the liquidity in our hot wallets.


## The Efficiency of Batching<a id="the-efficiency-of-batching"></a>

![](https://www.datocms-assets.com/99305/1722970393-batching-efficiency-visualization.png)

Batching multiple payments into a single large transaction significantly reduces our on-chain footprint and mitigates some of our scaling challenges. This approach benefits not only our users but also the Bitcoin community by minimizing the data usage of our transactions, thereby reducing network congestion and fees. It also means that one of our [UTXOs](https://strike.me/learn/what-is-a-utxo) (unspent transaction outputs, sometimes referred to as “coins”) can be used to facilitate several on-chain payments for our users, which is crucial for scaling our operations.


## Cost Savings through Batching<a id="cost-savings-through-batching"></a>

By batching payments, we can offer cheaper on-chain sends compared to what users would pay if they were to send transactions individually. On the Bitcoin network, you pay for the data size of your transaction, rather than its financial value. The savings of batching stem from the reduced byte size of batch transactions compared to publishing multiple individual transactions. All on-chain transactions contain both fixed and variable data. The fixed data includes information that is standard for all transactions, whereas the variable data includes the transaction inputs (coins to be spent in the transaction) and outputs (destination of the coins), which can vary in number and size. By combining multiple individual transactions into one large batch transaction, all outputs can share the same fixed data and input coins, thereby amortizing their costs.


## Upgrading Our Batching System<a id="upgrading-our-batching-system"></a>

Strike has been batching on-chain payments on behalf of our users for quite a while, and it has allowed us the ability to offer on-chain sends at very competitive prices (including a free tier!). However, recently we made a huge improvement to our batching system, which we think will reinforce our position as a leader in Bitcoin. In sharing our newest batching strategy with you, we’d like to set the expectations of what you can expect when you use Strike to make an on-chain payment as well as help other builders by sharing some lessons we’ve learned while iterating on our on-chain payment service.


### Append Outputs to Unconfirmed Transactions<a id="append-outputs-to-unconfirmed-transactions"></a>

The most recent upgrade to our batching system provides the ability to append more outputs (receivers / destinations) to existing unconfirmed batch transactions when feasible. This is done by leveraging a Bitcoin-native feature called Replace-By-Fee (RBF). RBF allows us to “replace” unconfirmed transactions by raising the fee they pay. Importantly, the outputs don’t have to be the same as the original transaction, enabling us to add more outputs to existing, unconfirmed transactions when needed.

Here are some links for those interested in learning more about RBF:

- [RBF Wiki](https://en.bitcoin.it/wiki/Replace_by_fee) (General info and history)

- [Opt-In Full RBF FaQ](https://bitcoincore.org/en/faq/optin_rbf/)

- [BIP 125: Opt-in Full Replace-by-Fee Signaling](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki)

This upgrade allows us to handle a surge in "Priority send" requests (our next block-targeting tier described above) without constantly creating new batch transactions. Instead, we add more outputs to our existing batch transactions that have been broadcast but are still unconfirmed. Here’s why this is a game-changer:

1. **Reduced On-chain Footprint:** By minimizing the number of new transactions created, we further reduce congestion on the Bitcoin network.

2. **Fee Cost Savings:** Fewer batch transactions for the same number of payments generally means even more savings on Bitcoin on-chain fees - we generally see between a 50-30% cost savings per transaction.

3. **Enhanced Quality of Service (QoS):** Existing, unconfirmed batches get fee-bumped to the current market rate as part of the RBF operation. This ensures that our users will experience better service quality as their transactions are more likely to be included in the next block, regardless of fee spikes on the network.

_Example of an onchain batch, using RBF to append additional outputs until it gets confirmed_
![](https://www.datocms-assets.com/99305/1722324278-engineering_09-batching-on-chain-sends_txn.png)



## Technical Challenges and Solutions<a id="technical-challenges-and-solutions"></a>

Implementing this sophisticated batching system required overcoming several technical hurdles:


### Prevent Double Send!<a id="prevent-double-send"></a>

Using RBF to add extra outputs requires careful handling to avoid double-sending issues and ensuring that all extra appended outputs are correctly accounted for. There are several reasons double sends could become an issue when you start adding outputs to transactions through RBF. This isn’t because of any problems in the Bitcoin protocol, but because there are some conceptual pitfalls that can arise. One of the main points is that you need to handle the case where miners confirm a non-latest version of your batch transaction. Any candidates you appended after that version need to be rolled over to a new batch. But if you make a mistake here, you might end up double sending!


### Guaranteeing Transaction Tracking<a id="guaranteeing-transaction-tracking"></a>

Ensuring we don’t double send involves meticulously keeping track of which transactions have been published and monitoring which version of a batch transaction gets confirmed. This careful tracking allows us to roll over candidates from unconfirmed versions to new batches accurately. 

But what if your wallet software crashes exactly at the time of publishing a new RBF transaction to the Bitcoin network? How will you know if the transaction was published? 

Some wallet software will give you the new _TxId_ as a response upon successful publishing of a new transaction. This approach is not good enough here, as it could result in us never learning the _TxId_ of a transaction that might have been published and confirmed on-chain. We might fail to receive the response containing the new _TxId_ because of e.g. network level errors, software crashes, etc, even though a new transaction was in fact broadcast. Since all our transaction versions contain a different set of outputs, it's crucial that we know which version gets confirmed so that we can decide if any appended outputs did NOT get confirmed and therefore need to be rolled over to a new batch.\
This general problem can be solved by a 2 step approach:

1. Build your transaction and store it in your DB

2. If step 1 succeeded, try to broadcast the transaction to the Bitcoin network

With this approach, step 2 can safely be retried if you encounter any problems. You will also have the ability to monitor the Bitcoin network for the _TxId_, to help determine if the transaction got published or not. The way Bitcoin transactions work is that building the transaction also means building the _TxId._ This is a completely offline process which can be done by your software without communication with the rest of the Bitcoin network.


### Chain Split & Reorganization<a id="chain-split--reorganization"></a>

Another case to look out for is when versions of your batch transaction are involved in [Bitcoin Chain Splits](https://developer.bitcoin.org/devguide/block_chain.html#block-height-and-forking) (temporary blockchain forks) and potentially the subsequent reorganization of the blockchain. Without going into the details, this could mean that a version of your batch transaction initially gets confirmed on-chain, but is shortly thereafter un-done and superseded by another version of your batch transaction!

Since all versions of our batch transactions contain a different set of outputs, and we make decisions on which outputs to roll over to a new batch based on which version got confirmed, this phenomenon also has the potential to make us double send. Chain Splits & Reorganizations are an important part of the blockchain's operation to ensure consensus, so our systems need to be able to handle this. A simple solution is to just do the same as one normally does for on-chain receives; wait until the transaction has _X_ (more than one!) confirmations on-chain before considering it as final. In Bitcoin, you will occasionally see chain splits with the depth of one block, but if your transaction was confirmed 6 blocks ago it's generally considered safe to count it as “final”.


### Appropriate Fee Estimations<a id="appropriate-fee-estimations"></a>

Using [mempool-based fee estimations](https://strike.me/blog/blended-bitcoin-fee-estimations/) as opposed to blockchain-based estimations is crucial for QoS and cost efficiency. This approach ensures that transactions can get into the next block without overpaying. Our system continuously monitors our mempool to choose an appropriate fee rate for each batch transaction and each RBF.


## Scaling On-chain Operations<a id="scaling-on-chain-operations"></a>

Our enhanced batching system positions us to scale our on-chain operations to a level where we can truly grow to be a global company with millions of active users. Our system now allows us to handle huge increases in volume from our users without compromising on speed, cost or quality of service.


### UTXOs: A Scarce Resource<a id="utxos-a-scarce-resource"></a>

One of the biggest challenges with scaling a custodial on-chain send service while still offering the “Priority send” option is the need to keep a stack of UTXOs which can be used as inputs in your transactions to facilitate on-chain payments. Imagine having to serve one “Priority send” request from your users every second, while there is a larger gap (e.g. 1 hour) between blocks getting mined on the Bitcoin network. If you need to instantly publish all these transactions, batching them wouldn’t be possible.

However, let's say we are clever and we add a slight delay of just 5 seconds between each of our batch transactions. This means we can batch 5 requests together every 5 seconds. So, during an hour where no block is mined we would need to publish 720 transactions to facilitate the requests of our users in this example. Since none of these transactions would get confirmed during that hour, the change outputs from these transactions would not be available for safe reuse, necessitating a stockpile of 720 UTXOs of appropriate sizes in our hot wallet. Without this, our service would simply halt until a new block is mined. This situation becomes even trickier during fee spikes, which might cause transactions to remain unconfirmed for an even longer period.

Moreover, maintaining UTXOs of an “appropriate size” adds another layer of complexity. For instance, if all send requests are for 1 BTC each - we would need to maintain 720 BTC in our hot wallet, broken down into UTXOs of 1 BTC each. This not only becomes complex to manage but also operationally inefficient and hard to scale. It’s of course impossible to 100% accurately predict what your users will do, so your stockpile of UTXOs needs to be even bigger than this to be ready for unforeseen spikes in demand. The foundational issue here is that we end up with many unconfirmed transactions in the mempool simultaneously, locking up numerous of our UTXOs.


### Running the System on a Single UTXO?<a id="running-the-system-on-a-single-utxo"></a>

Instead of publishing new batch transactions every 5 seconds as in the previous example, our new approach appends more outputs to our existing, unconfirmed transaction - if there are any. This provides an incredibly efficient solution to the problem mentioned above. Appending more outputs reuses the existing input UTXO of the unconfirmed transaction, provided the UTXO is large enough. This means that, in theory, our entire batching system could run on a single UTXO.

Each time one of our batch transactions gets confirmed on-chain, we receive the change output back as a new UTXO, which can then be used to fund the next batch. This approach essentially scales infinitely (or at least until the Bitcoin block size limit!), allowing us to handle a growing volume of on-chain send requests without being constrained by the number of UTXOs in our hot wallet. It also mitigates the risk associated with fee spikes, ensuring continuous operation even during network congestion.

Through this system we achieve an unprecedented level of scalability and reliability in our on-chain operations. This positions Strike to grow and serve a global user base with millions of active users, offering them the best possible service in terms of speed, cost, and reliability.


## Superior QoS<a id="superior-qos"></a>

Our commitment to providing our users with the highest quality service in the industry is evident in our approach to on-chain payment batching. Users can trust that their payments will be handled with the utmost care, efficiency, and security, whether they opt for a Flexible, Standard, or Priority send.

Fee spikes on the Bitcoin network are a common problem that plague the quality of other providers. It’s common to publish transactions with a high enough fee to target a confirmation in the next block only to then see the general fee market spike significantly. In these cases, published transactions will likely not get confirmed for several hours and could potentially end up stuck much longer or pruned. The Bitcoin protocol has solutions to let you “fee bump” your transaction to solve for this, but it's not ubiquitous to all apps and wallets, and not common for wallets to automatically fee bump your transaction in such cases without charging you more for it! Strike simplifies all of this for you, and provides flexibility for users with varying time preferences.


## Conclusion<a id="conclusion"></a>

At Strike, we continually strive to innovate and improve our services. Our advanced batching system for on-chain sends is a testament to our dedication to efficiency and high-quality service. We aim to be the best at Bitcoin and that means providing our users with the best possible experience that Bitcoin payments can offer. We truly believe that our on-chain send experience is now well on its way to how on-chain payments will, and should work in the future. We will, however, always continue to iterate on our solutions to further enhance them and to show the world how much Bitcoin has to offer.

Feel free to reach out if you have any questions or need further details about our on-chain batching system and its benefits. We're always here to help and provide the best possible service to our users.


Quality of Service (QoS), Efficiency, and Security

Batching On-chain Sends

Today, we’re announcing [Strike Business](https://strike.me/business), the new leading platform for businesses to buy and manage bitcoin. Strike Business offers world class custody, Lightning and on-chain services, developer integrations, and much more. At its core, it’s a service focused on providing your business a trusted partner for buying bitcoin affordably, reliably, and with no limits.

![](https://www.datocms-assets.com/99305/1710435557-image-2.png)

Strike Business is for all sizes and industries. We serve single-person operations, small businesses, family offices, and enterprise-scale companies alike. It’s for any business that recognizes the value of holding and operating with Bitcoin as a way to avoid arbitrary inflation, access borderless payments, and take control of their finances. 

It’s your solution for building your own Bitcoin strategy.

Whether for transacting, holding as a treasury asset, or for making payments globally using bitcoin, Strike Business provides businesses with the same best-in-class Strike experience that we provide to our individual customers. 

[Get Started](https://strike.me/business)

![](https://www.datocms-assets.com/99305/1710435582-image-5.png)

## Introducing Strike Business

Strike Business has high-quality execution and best-in-class Lightning and Bitcoin payment infrastructure. Our tiered-fee structure makes us one of the most competitive places to buy bitcoin, especially in large amounts. This is all powered by Strike’s own infrastructure including redundant banking, multiple liquidity providers, secure platform, and our best-in-class user experience and customer service. 

Whether you are a family office, small business, large enterprise, or just getting started, let Strike Business be your partner in bitcoin. 

![](https://www.datocms-assets.com/99305/1710435573-image-4.png)

### Strike Business Dashboard

Our business clients will have access to the brand new [Strike Business Dashboard](https://dashboard.strike.me/) to facilitate all Bitcoin services. Strike Business clients can wire in dollars, buy or sell bitcoin in seconds, send or receive bitcoin via on-chain or Lightning transaction, then hold or withdraw to their own custody. You can also track your trading and transaction activity, as well as generate and export detailed reports for accounting purposes.

Whatever your business needs to do with bitcoin, it’s all here. We believe we are one of the lowest-cost and best bitcoin-only services that offers Lightning capabilities and free on-chain withdrawals, and we’re just getting started.

![](https://www.datocms-assets.com/99305/1710435565-image-3.png)

You can learn more about what Strike Business has to offer in our FAQs on our [website](http://strike.me/businses). If you have any questions about partnering with us, reach out to us at onboarding@strike.me for a no-obligation conversation about how we can help your business access bitcoin.

### Tiered Fees
Businesses need transparent and affordable services. Our business customers get high-quality pricing with a scalable fee structure, designed to lower your costs the more bitcoin you buy. You can learn more about tiered fees [here](https://strike.me/blog/from-spreads-to-fees-simple-transparent-and-cheap-pricing-for-bitcoiners/). 

![](https://www.datocms-assets.com/99305/1710435589-image-6.png)

### Getting Started
Our onboarding process is designed to be simple, fast, and easy. Fill out the form on our [website](https://strike.me/business) or send an email to onboarding@strike.me and we’ll get the process started.

At Strike, we’re committed to being the best in Bitcoin and we aim to give your business access to the same high-quality service we deliver to our individual customers. We’re incredibly excited to partner with your business on your Bitcoin journey and learn more about how we can meet all of your Bitcoin needs.

Introducing the leading Bitcoin and Lightning platform for businesses to buy bitcoin

Announcing Strike Business

At Strike, we're constantly innovating to push the boundaries of Bitcoin and the Lightning Network (LN) and enhance our customers’ experience. Today, we're excited to announce our support for [BOLT 12 Offers](https://bolt12.org/), a revolutionary technology that enables a more private, versatile, and user-friendly way to send and receive sats over the Bitcoin Lightning Network.

This blog post dives deep into our journey of integrating BOLT 12 into Strike. It's a technical exploration targeted towards both Bitcoin enthusiasts and our valued customers.


## What is BOLT 12?

Introduced in September 2020 by [Rusty Russell](https://x.com/rusty_twit), the [BOLT 12 specification](https://github.com/lightning/bolts/blob/f150782106ac604b8bb056dcd0c0cbe757274e1d/12-offer-encoding.md) provides an improved version of the current [BOLT 11 standard](https://www.bolt11.org/) for LN payments. If you’re familiar with [LNURL](https://github.com/lnurl/luds) - which Strike also supports! - then BOLT 12 should sound familiar on the surface. It enables features that significantly enhance the LN experience:

* **Reusable QR Codes:** Unlike BOLT 11 Invoices, which are generally single-use, BOLT 12 Offers can be scanned and paid multiple times. This makes them ideal for static displays like on websites, flyers, or billboards, eliminating the need to constantly generate and distribute new invoices.
* **Enhanced User Security:** BOLT 12 leverages [onion messages](https://rusty-lightning.medium.com/onion-messaging-in-depth-d8e384ee4184), a cryptographic technique that conceals the path taken by payments within the LN. This improves the personal security of LN payments through increased privacy.
* **Advanced Functionality:** BOLT 12 opens doors for new native functionality like refunds or ATM-style withdrawals that were previously impossible on the Lightning Network without the use of supplementary layers such as LNURL.


## Our BOLT 12 Implementation Journey

Our exploration of BOLT 12 began with an internal research paper that we wrote back in September 2021. We were intrigued by the potential benefits that BOLT 12 had to offer for improved LN payment experiences.

We devised plans for integrating BOLT 12 functionality into Strike, but the early stage nature of the proposal at that time, the fact that it would be a long time before it would be [implemented into LND](https://github.com/lightningnetwork/lnd/issues/5594), combined with various other factors forced us to refocus efforts on other core functionality and play a wait-and-see game to give time for things to further evolve.

Between 2021 and 2022 members of the Bitcoin community continued to iterate on the BOLT 12 proposals, develop implementations, and champion the technology. Whilst some Lightning node implementations were quick off the mark to integrate, [LND](https://github.com/lightningnetwork/lnd) - the primary node implementation that we use at Strike -  took a more cautious and deliberate approach, focusing more on core system stability. The Lightning Labs team developed a comprehensive phased roadmap to implementing BOLT 12, integrating some of the fundamental building blocks bit by bit over a longer period of time. To this day, LND still does not support BOLT 12 though it does now support many of the core component parts and is well on the way to full native BOLT 12 support.

Upon the arrival of [LNDK](https://github.com/lndk-org/lndk) in March 2023, a tool spearheaded by [Carla Kirk-Cohen](https://github.com/carlaKC) and developed in conjunction with the [Spiral](https://spiral.xyz/) team, our interest in BOLT 12 was rekindled. Described as "An experimental attempt at using [LDK](https://lightningdevkit.org/) to implement BOLT 12 features for LND”, it essentially plugs into LND's existing APIs, enabling use of LDK’s built-in BOLT 12 support with LND.


## Technical Deep Dive

The integration involved several key components:

* **LND:** The gRPC API exposed by the target LND node built with the appropriate rpc subservers.
* **LDK:** Imported as a dependency in our application layer to provide BOLT 12 Offer encoding and decoding.
* **LNDK:** While LNDK’s [architectural overview](https://github.com/lndk-org/lndk/blob/master/ARCH.md) playfully refers to LNDK as "Frankeinstein's monster," it’s actually a very clever solution. LNDK acts as a [shim](https://en.wikipedia.org/wiki/Shim_$computing$), leveraging LDK's modular lightning library and connecting it to LND's gRPC API. This allowed us to reuse the existing BOLT 12 implementation within LDK.


## LNDK At a Glance

LNDK, the clever bridge that enables Strike to leverage BOLT 12 functionality within our existing LND infrastructure, deserves a closer look. Here's a high-level overview of its architecture and some key functionality that made it the tool of choice for our integration.


## Modular Design for Flexibility

As mentioned earlier, LNDK acts as a shim, connecting LND's gRPC API with the modular Lightning library from LDK. This design offers several advantages:

* **Component Reusability**: By leveraging LDK's existing BOLT 12 implementation, LNDK avoids the need to reinvent the wheel. This streamlines development and ensures compatibility with the broader Lightning Network ecosystem.
* **Clear Separation of Concerns:** The separation between LND's core functionality and LDK's BOLT 12 support provides a relatively clean implementation which simplifies some elements of maintenance.


## Onion Messaging and Offer Payments

One of the core functionalities of BOLT 12 is its use of [onion messages](https://rusty-lightning.medium.com/onion-messaging-in-depth-d8e384ee4184). These cryptographic messages enable two nodes on the Lightning Network to communicate securely and privately.

The following diagram depicts how the various components interact from a high level:

![](https://www.datocms-assets.com/99305/1722267398-engineering_09-02-onion-diagram.png)

Here's a simplified breakdown of how Strike uses LND, LDK and LNDK to facilitate onion message routing and the BOLT 12 protocol:

1. **Payment Request:** The Strike user initiates a payment by scanning a BOLT 12 Offer QR code or entering a human readable DNS address from where a BOLT 12 Offer can be fetched using [BIP 353](https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki).

2. **LDK Offer parsing:** LDK is used to parse the BOLT 12 Offer to extract payment details.

3. **Onion Message Construction:** LNDK utilizes LDK's libraries and LND’s gRPC APIs to construct onion messages containing the invoice request details.

4. **Relaying the Onion:** The constructed onion message is then relayed through the Lightning Network by LND, traversing various nodes until it reaches the destination node specified in the Offer, where the onion message is unwrapped, revealing the request embedded in the message.

5. **Retrieving a Blinded Path:** The destination node uses onion messaging to send back an Invoice that includes a blinded path detailing how it can be paid.

6. **Sending the Payment:** LNDK interacts with LND's gRPC API to initiate the payment process.

The following diagram depicts the payment flow from a high level:

![](https://www.datocms-assets.com/99305/1722267427-engineering_09-03-offers-flow.png)


## Phased Implementation Plan (3 Phases):

Given the number of moving parts, we started by outlining a three-phased approach to roll out BOLT 12 functionality within Strike. At a high level, the plan was as follows:


1. **LNDK Testing and Deployment**  
  Establish core BOLT 12 infrastructure and functionality for internal testing and observation.
2. **LNDK Platform & API Integration**  
  Extend Strike's platform and APIs to expose BOLT 12 functionality throughout our environment.
3. **Strike Apps Integration**  
  Integrate BOLT 12 payment features into the Strike products.

By following this phased approach combined with insights from our earlier investigations, we felt we could ensure a controlled and efficient integration of BOLT 12 functionality within Strike.


## Proof of Concept Implementation

The first step was to go from concept, to proof of concept and there were a number of technical hurdles we had to overcome along the way.

**BOLT 12 Playground**  
We established a development environment for testing BOLT 12 payments using various combinations of nodes (LND, CLN, Eclair, and LDK-Node) and channels (direct, single hop, multi-hop, cross-implementation). We chose to open source our new [BOLT 12 Playground](https://github.com/LN-Zap/bolt12-playground) to make it available to the wider development community. This playground proved invaluable for streamlining the testing process and facilitating collaboration.

**API Integration**  
We worked closely with the Spiral team and LNDK contributors to enhance LNDK with a gRPC server and TLS implementation that provided a well-defined and secure interface for our application to interact with the underlying BOLT 12 functionality exposed by LNDK.

**Native BOLT 12 Decoding**  
We leveraged [LDK's generated C# bindings](https://github.com/lightningdevkit/ldk-garbagecollected) to enable BOLT 12 Offer and Invoice decoding directly within our .NET codebase, enabling us to limit our interactions with the LNDK daemon in favour of native code paths where possible.

**Onwards...**  
Within a few days, we had a functional proof of concept demonstrating the ability to pay BOLT 12 Offers directly from our Strike backend systems. With this success, we were confident in moving forward with productionizing the solution.


## From Proof of Concept to Production

The next - and certainly more time consuming - challenge involved transforming the proof of concept into a robust and secure system ready for real-world use within Strike's production environment. Here, we provide some insights into that effort:

**Productionizing LNDK**  
We actively participated in shaping many features of LNDK to ensure it met our requirements and had the flexibility needed to be used in our production environment. This involved several iterations on the design, ultimately resulting in a gRPC interface secured by TLS and leveraging a tightly scoped LND macaron for authentication. We also added more granular endpoints for each phase of the BOLT 12 flow.

**Challenges and Workarounds**  
Working closely with the LDK and LNDK developers, we were able to address issues that we found along the way, helping to bring these libraries to a stable state. Multiple new releases of LNDK, LDK, and the LDK C# bindings were cut along the way, until we had all of the necessary functionality working as we needed.

**Infrastructure Deployment**   
For each LND node that we run, we deployed a LNDK sidecar, ensuring each LND instance has a dedicated LNDK counterpart for handling BOLT 12.

**Onion Messaging Support in LND**  
Our LND nodes were running on version 0.17, which lacked built-in support for onion messaging - a critical component for LNDKs BOLT 12 functionality. As we weren't ready to upgrade to LND v0.18 at the time, we opted to backport the relevant changeset from v0.18 to v0.17. This ensured compatibility with BOLT 12 while maintaining stability within our existing infrastructure. In the process, we were able to help shape the LND 0.18 release (which was in its final RC phase at the time), ensuring that it shipped with [everything needed to support onion messages](https://github.com/lightningnetwork/lnd/pull/8744) out of the box, simplifying the process for other node operators in the future.

**Production-Ready Application Code**  
Our proof-of-concept code underwent a significant transformation. The codebase was broken down into smaller, more focused components. This improved maintainability and facilitated a smoother integration with Strike's existing architecture. At a high level, this comprised of:

- Adding supporting libraries like a BOLT 12 Parser, a [DNSSEC](https://http-dns-prover.as397444.net/) implementation for secure DNS lookups, and a gRPC facade for interacting with the LNDK gRPC server.
- Integrating with our existing LND node pool for managing LND node connections and distributing load across our systems.
- Finally, integrating the entire solution with our core systems, APIs, and business and consumer products to enable BOLT 12 payments from Strike!


## Strike's BOLT 12 Future

Whilst we have successfully achieved our goal of enabling BOLT 12 payments from Strike, our initial integration only supports a basic Offer payment flow. However, it paves the way for exciting and more advanced BOLT 12 features over time.

We're committed to staying at the forefront of Bitcoin and Lightning Network innovation. We'll continue to work with the broader community to push the boundaries and provide you with the best possible experience.

We hope this blog post provides an interesting look behind the scenes of our BOLT 12 integration journey! As you can see, in our case the implementation took a fair amount of work given we were trailblazing and helping to develop LNDK in the process. However, with much of this groundwork now done and out there in the open source universe, we’ve proven that there is a viable path to deliver a BOLT 12 experience with LND, today.

If you'd live to give it a try, you can donate to the [Human Rights Foundation](https://hrf.org/)'s BOLT 12 Offer by scanning the QR Code below, or by paying to their BOLT 12 Lightning Address - [bolt12@hrf.org](lightning:bolt12@hrf.org)
![](https://www.datocms-assets.com/99305/1723462840-hrf-bolt12.png)

We’re excited to see the continued evolution of BOLT 12 as more services and node operators upgrade over the coming months and years.

If you have any questions, feel free to reach out to us!

A Look Behind the Scenes

Building BOLT 12 into Strike

Yo! I’m thrilled to announce that today, Strike launches to eligible customers in Europe, giving millions of people access to buy bitcoin with free, instant, and unlimited deposits, sell, send, and withdraw bitcoin, global payments, bitcoin and lightning wallet features, and more. 

https://www.youtube.com/watch?v=cboYEHuXwbc

Check your local iOS and Android app store to see if Strike is available in your region, and [download the app](https://strike.me/download/) to get started. 

Wen Europe, you ask? Now!

![](https://www.datocms-assets.com/99305/1713917099-eu-blog-hero-a.png)

## The Story
At Strike, we envision a future where everyone has access to Bitcoin––a truly open, global, and public digital infrastructure for money. To realize this vision, our focus has been on building a beautifully designed bitcoin-only money app that’s accessible, functional, secure, and available to billions of people all over the world. 

Over the past year, Strike has rapidly expanded its services, now reaching nearly 100 countries across the globe, from the U.S. to Latin America and Africa. Today marks a significant milestone as we introduce our services to eligible customers in Europe.

Bitcoin is reshaping the global financial landscape with its technological innovation, global interoperability, resilience, and unforgeable monetary policies. It transcends borders, enhances financial inclusion, and solves some of the world's most pressing challenges.

As the third-largest economy globally and over [440 million](https://european-union.europa.eu/principles-countries-history/key-facts-and-figures/life-eu_en) inhabitants, Europe presents vast opportunities for Bitcoin adoption. As a leading bitcoin-only app, we believe that Strike is uniquely positioned to meet the needs of millions seeking access to Bitcoin in Europe. We’ve seen the demand and heard the feedback first-hand from the community.    

![](https://www.datocms-assets.com/99305/1713917142-eu-blog-tweets.png)

## Introducing Strike Europe
We’re excited to offer European customers all of our core bitcoin and lightning wallet features our existing customers know and love. Let’s dive into all the exciting things you can do with Strike Europe. 

### The Best Way to Bitcoin

**Buy, sell, send, and withdraw bitcoin with ease**

Buy bitcoin directly with free unlimited SEPA euro deposits from your bank account. Seamlessly deposit funds from your bank account within 2 business days, or in a few seconds with instant SEPA transfers where supported. Sell your bitcoin and withdraw the funds directly to your bank account just as easily.

You can also withdraw your bitcoin to self-custody or send it to any Bitcoin or Lightning wallet instantly and without limits. 

![](https://www.datocms-assets.com/99305/1713917092-eu-blog-bitcoin.png)

**Schedule recurring purchases**

Stack sats hourly, daily, weekly, or monthly––the choice is yours. Simply set your desired frequency and the cash amount you want to buy, and we’ll handle the rest. 

[Learn more](https://strike.me/faq/how-do-i-set-up-a-recurring-purchase-eu) about recurring purchases and how to set them up. 

![](https://www.datocms-assets.com/99305/1713917127-eu-blog-recurring-purchases-a.png)

### P2P Strike Users

Strike Europe users can use Strike’s technology and the Lightning Network to send value to or receive value from any Strike user around the world instantly. This feature becomes increasingly exciting as we keep expanding globally, adding more on and off ramps, and enhancing our wallet features. 

Strike’s global P2P transfers with Lightning allow you to send from your Euro balance to a friend’s Strike account instantly anywhere Strike is available, and they can receive the value as Bitcoin, Euro (in Europe), USD (in the U.S.), or USDT (in supported global regions) in their Strike wallet.

![](https://www.datocms-assets.com/99305/1713917115-eu-blog-p2p.png)

### Send Money Globally

Send Globally enables customers to make fast, secure, low-cost local currency payouts in eligible countries using the Lightning Network as an open and global payment rail under the hood.

Strike customers in Europe can use this technology to send value across borders to supported regions including Africa (Benin, Ghana, Ivory Coast, Kenya, Nigeria, Rwanda, Senegal, Togo), Philippines, Mexico, and Vietnam. [Learn more](https://strike.me/faq/which-countries-are-available-for-send-globally-eu).

![](https://www.datocms-assets.com/99305/1713917133-eu-blog-send-globally.png)

### The Best of Bitcoin and Lightning
Strike offers all the best Bitcoin and Lightning wallet features in one app. We support free on-chain withdrawals, Lightning Address payments, and zero-value invoices. 

**Free On-Chain Withdrawals**

Strike offers free on-chain withdrawals to help you navigate the mempool and surges in on-chain fees. 

Our on-chain Bitcoin payments are designed to support Bitcoin being used at scale. When sending an on-chain payment, Strike allows you to select the delivery time of the payment and offers free bitcoin withdrawals for flexible transactions. 

* **Priority** — Targeting the next block, largest fees
* **Standard** — Targeting confirmation in about an hour, lower fees than priority
* **Flexible** — Targeting confirmation in around 24 hours, free of charge!

If you’re simply buying bitcoin and withdrawing to cold storage, feel free to select the flexible option so you can save more of your sats.

![](https://www.datocms-assets.com/99305/1713917109-eu-blog-on-chain-withdrawals.png)

**Send and receive payments with your Lightning Address**

All Strike users have a Lightning Address that allows them to receive payments from all over the world. Your Strike Lightning Address is simply your username@strike.me. It’s designed to look and feel like an email address but it has the ability to receive global payments. 

Tap your profile to view and share your Lightning Address. You can also select whether you want to receive incoming payments in Euro or bitcoin, based on your preference. If you select Euro then any incoming Lighting payments in bitcoin will be automatically converted for you by Strike and credited to your Euro balance.

Similarly, Strike users can pay a Lightning Address on Strike and have the option to send sats from their Euro balance or their bitcoin balance. A truly dynamic experience that leverages an open, global, fast, and cheap payment protocol native to the internet. 

**Send and receive payments using zero-value Lightning invoices**

Pay zero-value Lightning invoices and send any amount from your Euro or bitcoin balance to other wallets.

You can also issue zero-value Lightning invoices and receive any amount of bitcoin to either your bitcoin or Euro balances from other wallets. When receiving as your Euro balance, Strike automatically converts bitcoin to Euros upon receipt.

### Earn Referral Credits
We love the bitcoin community. As a thank you for spreading the word about Strike, we're launching a time-limited promotional program for the initial launch of the Strike app in Europe. Subject to eligibility criteria and limits. [Learn more](https://strike.me/faq/what-is-the-referral-program-eu/).

### Strike Private
Strike Private is our white glove service for HNWIs, family offices, corporations, and more.

We help our clients achieve their Bitcoin goals, such as buying or selling large amounts of bitcoin. We have custom pricing, no limits, a dedicated team for 1:1 support and guidance, and leading Bitcoin infrastructure to service our clients.

If you're in Europe and interested in being a Private client, contact us at private@strike.me.


### Strike for Business
Strike Europe is also accepting applications from eligible businesses to provide support for all their bitcoin needs! If you have a business entity and would like to open a Strike account, you can learn more and get in touch at [Strike Business](https://strike.me/business/).  

Our business customers will have access to all the same services as our individual customers - buy bitcoin, sell bitcoin, deposit or withdraw from your Euro balance using SEPA transfers, and more. In addition certain eligible customers will have access to the [Strike API](https://strike.me/learn/what-is-the-strike-api/) allowing them to automate transactions on their Strike Account.

## Thanks
Today marks another milestone in our global journey, but our work is far from over. We will continue to enter new markets, support more currencies, add payment methods, expand our services, and iterate on the experience. 

In the meantime, here is a recap of Strike Europe, with more features to come:

* Buy bitcoin directly with free unlimited SEPA euro deposits from your bank account
* Sell your bitcoin and withdraw the funds directly to your SEPA bank account 
* Withdraw your bitcoin to self-custody or send it to any Bitcoin or Lightning wallet instantly and without limits
* Strike’s global P2P transfers with Lightning allow you to send from your Euro balance to a friend’s Strike account instantly anywhere Strike is available, and they can receive the value as Bitcoin, Euro (in Europe), USD (in the U.S.), or USDT (in supported global regions) in their Strike wallet
* Use Send Globally, our cross-border payments feature, to send value across borders to supported regions
* Strike offers all the best Bitcoin and Lightning wallet features in one app. We support free on-chain withdrawals, Lightning Address payments, and zero-value invoices 

Bitcoin is the greatest innovation of our lifetime and our ambition is to be the best at giving you access to this transformative technology and a Better Money experience globally. 

Thank you for all of your support––we wouldn’t be here without you, our customers. Please continue to give us feedback, ask questions, and reach out to us. We love hearing from you and learning more about your experience and how we can make Strike the best it can be. 

Until then. Much love.

Jack


Strike launches buy bitcoin, global payments, and more to customers in Europe

Announcing Strike Europe

Make your move into bitcoin.

Blog

I am pleased to share our latest open source contribution, the [BOLT 12 Playground](https://github.com/LN-Zap/bolt12-playground). This project provides a simple to use, hands-on testing environment for those working on or interested in exploring and practically testing BOLT 12, a new payments protocol for the [Lightning Network](https://strike.me/learn/what-is-the-lightning-network/).

Check it out: [https://github.com/LN-Zap/bolt12-playground](https://github.com/LN-Zap/bolt12-playground).

![](https://www.datocms-assets.com/99305/1718994172-bolt12-hero.png)


## What is BOLT 12?

BOLT 12 is a protocol that extends the capabilities of the Lightning Network, a second-layer solution for Bitcoin that enables fast, low-cost transactions. BOLT 12 introduces a new type of [Lightning Invoice](https://strike.me/learn/what-is-a-lightning-invoice/) called "Offers," which are reusable, can be used for recurring payments, include advanced security features, and can contain additional information such as refund addresses and payer notes.

See [https://bolt12.org/](https://bolt12.org/) for more information.

## What is BOLT 12 Playground?

The BOLT 12 Playground is a [Docker](https://www.docker.com/) stack that includes support for the most popular Lightning Network implementations and related components, including [Lightning Network Daemon (LND)](https://github.com/lightningnetwork/lnd), [LNDK](https://github.com/lndk-org/lndk), [Core Lightning (CLN)](https://github.com/ElementsProject/lightning), [Eclair](https://github.com/ACINQ/eclair) and [LDK Node](https://github.com/lightningdevkit/ldk-node). It connects everything together, initializes wallets, and creates channels between the nodes. Every node in the stack supports BOLT 12, enabling easy experimentation with invoice creation, payments, and other features of BOLT 12.

[![](https://www.datocms-assets.com/99305/1718949890-bolt12-playground-stack.png)](https://github.com/LN-Zap/bolt12-playground)

## Why use BOLT 12 Playground?

The BOLT 12 Playground provides an opportunity for Bitcoin professionals and hobbyists to get hands-on experience with the BOLT 12 protocol. It's a sandbox where you can experiment, learn, and gain insights into how BOLT 12 works in practice. Whether you're a developer looking to implement BOLT 12 in your own projects, a researcher studying the Lightning Network, or a Bitcoin enthusiast curious about the latest developments, we think the BOLT 12 Playground may be a useful resource for you.

![](https://www.datocms-assets.com/99305/1718949886-bolt12-playground-tests.png)

The BOLT 12 Playground goes beyond a simple sandbox environment. It's also a powerful tool for developers and testers to ensure interoperability between different Lightning Network node implementations, complete with automated tests to prove things out.

### **The BOLT 12 Playground includes:**

#### **Cross-Implementation Testing**
The Playground facilitates testing BOLT 12 payments across various node implementations, which can help identify and address potential compatibility issues before real-world deployment.

#### **Channel Topology Testing**  
It allows testing across different channel topologies, including direct channels, multi-hop payments, and even multi-hop payments that traverse nodes from different implementations. This helps ensure BOLT 12 functions seamlessly regardless of the network structure.

#### **Automated Testing**
The project incorporates an automated integration test suite. Currently, the suite supports simulated payments with LND (via lndk), Eclair, CLN and LDK Node. This automation streamlines testing and facilitates continuous integration practices.


## Community Contributions

The BOLT 12 Playground is an open-source project, and we encourage contributions from the community. If you're working on a node implementation with BOLT 12 support, we welcome you to test it with and integrate into the BOLT 12 Playground!

## Getting Started

To get started using the BOLT 12 playground visit the project's GitHub  repository [https://github.com/LN-Zap/bolt12-playground](https://github.com/LN-Zap/bolt12-playground).

A Sandbox for Hands-On BOLT 12 Testing

The BOLT 12 Playground

The [Lightning Network](https://strike.me/learn/what-is-the-lightning-network/) is bitcoin payments network that’s instant, private, and low-to-no cost. Running a Lightning node can provide significant benefits, including financial self-sovereignty, enhancement of privacy, earning of routing fees, and/or participation in a new global financial network. However, maintaining a Lightning node requires some work, including the occasional need to migrate your operation to a new node for security, privacy, or maintenance reasons. The process of migrating to a new node, is sometimes referred to as “rotating your node’s seed”.

![](https://www.datocms-assets.com/99305/1712088217-blog-migrating-a-ln-node-01.png)

Your Lightning node's channels, through which bitcoin is sent and received, are linked directly to the node’s unique seed. This means you can't simply "copy & paste" your node’s channels to a new seed. Migrating your node for security or other reasons requires a strategic migration process.

In this post, we'll break down the steps to smoothly migrate your node's liquidity from one node to another, whilst minimizing downtime and making the transition seamless for your users and the network.

__💡NOTE: Moving your node to new hardware without changing its seed? In this scenario, you should use a simpler "lift & lay" approach: backup, transfer, & restore. This avoids complexities of seed rotation.__

Assuming that you _do_ need to migrate to a new node with a new seed, and you have the luxury of time on your side, the following sections will walk through a step-by-step approach to migrating your node's liquidity and routing activity to a new seed with minimal disruption to service.


## Preparing to migrate your Lightning node

Before beginning, it’s important to remember that if your node operates as a routing node, you’ll be restarting its reputation from zero, which can be an important consideration for channel connectivity and liquidity. Let's begin by laying the essential groundwork, setting up your new node and preparing it to take over seamlessly in the future.

![](https://www.datocms-assets.com/99305/1712088227-blog-migrating-a-ln-node-02.png)

### Step 1: Provision a new node

To begin, you’ll need to securely set up your new node with a unique, strong seed. Remember, proper seed and key management are paramount. Your new node comes with a new unique identity and pubkey.

![](https://www.datocms-assets.com/99305/1712088235-blog-migrating-a-ln-node-03.png)

### Step 2: Create a bridge

You’ll then need to establish a large channel between the old and new nodes. Remember to initiate the channel opening from the old node so that it has the capability to route payments through to the new one. This channel will act as a bridge for efficient funds transfer. On the old node, set the channel policy with a low fee (e.g. zero) and a low time lock delta (e.g. 18). Given you control both nodes, you control the routing policies at either ends of the channel. On the new node, set the routing fees for this channel higher to discourage flow in the other direction. The low fee for routing towards the new node will encourage liquidity to flow in that direction.


## Step-by-step migration

While migrating liquidity to your new node, the key is to maintain a smooth transition for your users and the network. You want your existing node to remain active and available, routing with its current liquidity, while simultaneously building up the new node to seamlessly take over.

![](https://www.datocms-assets.com/99305/1712088241-blog-migrating-a-ln-node-04.png)

### Step 3: Strategic channel closures

First, prioritize closing channels where most of the liquidity resides on your side of the channel, also known as channels with outbound liquidity. This will provide you with capital that you can use to open new channels on the new node, and the liquidity profile of those new channels will be similar to the old ones (most liquidity on your side). Channels will need to be closed individually as batching isn’t yet supported by most node implementations, so use strategic timing and appropriately low fees to keep the channel closing costs down.

![](https://www.datocms-assets.com/99305/1712088247-blog-migrating-a-ln-node-05.png)

### Step 4: Batch channel openings

As you close channels on the old node, simultaneously open new ones on the new node to the same set of peers, using batch channel opening to save fees. It’s best to open channels of a similar capacity to enable continuity of service towards those peers. Alternatively, this can be a good opportunity to rethink and reconsider your channel topology.

![](https://www.datocms-assets.com/99305/1712088252-blog-migrating-a-ln-node-06.png)

### Step 5: Controlling the flow

You’ll then need to monitor channel balances for the new node closely and use the routing fees as a lever to influence the flow of liquidity.
    
It’s a good idea to open the new channels with competitive fee rates to promote outbound flow, and gradually raise them as liquidity starts flowing through the new channels and reaches a balanced state. Consider using a tool like [charge-lnd](https://github.com/accumulator/charge-lnd) to automate fee adjustments as the liquidity profile changes over time.
    
If you originate payments form your nodes, consider that if the outbound channels on the new node have non-zero routing fees, then any outbound payments originating from your original node that pass through the bridge channel will incur those routing fees. This may or may not be desirable, depending on your use case. To avoid these extra fees, you can be selective about the first-hop channel used for payments and exclude the bridge channel if desired. Alternatively, you can set externally facing outbound routing fees to zero on the new node, or be strategic about which node you choose to originate payments from.

![](https://www.datocms-assets.com/99305/1712088259-blog-migrating-a-ln-node-07.png)

### Step 6: Rinse and repeat

Continue iterating between steps 3-5, gradually migrating batches of channels until complete.


## Additional Tips

Migrating your Lightning node's seed can sound complex, but with the right approach, it can be a manageable step towards enhanced security or an improved topology. Here are some other things to consider to further streamline the process:

- Consider using swaps such as [peerswaps](https://strike.me/blog/peerswaps/) or [loops](https://lightning.engineering/loop/) to expedite rebalancing.

- Update node policies to prevent new channels being opened towards the old node.

- Use a [blended fee estimator](https://strike.me/blog/blended-bitcoin-fee-estimations/) for good fee estimates.

- Update node aliases to indicate a migration is in progress.

- Inform node operators about the transition through online communities.

- Work with channel partners to update channel acceptor policies with your new pubkey.

- Create new on-chain addresses from the new node and update references as needed.

- Monitor on-chain addresses associated with the old node and transfer received funds.

- Adapt the process to your specific node setup and preferences.


Moving liquidity to a new Lightning node

Migrating a Lightning node

In Bitcoin, transaction fees play an important role in ensuring timely and reliable transaction confirmation. However, accurately estimating these fees can be a challenging task, given the ever-shifting market dynamics and competing transaction demands. This challenge is further compounded by the scarcity of blockspace, a finite resource that every transaction competes for.

With new blocks being mined approximately every 10 minutes, it's up to you, the transaction sender, to determine the fee you're willing to pay to secure your transaction's inclusion in the blockchain. A higher fee generally translates into a higher probability of a fast confirmation, while a lower fee may lead to delayed confirmation. But how can you accurately estimate the fee required based on your time preference?

**In this post, we'll look at some of the different ways of estimating bitcoin transaction fees, and how you can combine these into an effective fee estimation strategy.**


## Bitcoin fee estimation types

Accurately predicting future fee trends remains a challenge. While wallets and nodes employ various fee estimation methods, each approach has its strengths and limitations. 

**There are two primary fee estimation methods that we’ll look at: mempool-based and history-based.**


### Mempool-based fee estimation

Mempool-based fee estimation focuses on analyzing the current state of the mempool - the collection of unconfirmed transactions vying for block space. By examining the fee rates of transactions recently added to the mempool, this method provides real-time insights into the current fee landscape. This approach is particularly useful for situations where rapid confirmation is desired, as it can provide up-to-date estimates based on the immediate fee dynamics of the actual content of the mempool.

A good example of mempool-based fee estimation is the the [Mempool](https://mempool.space/) open source project. The team at [Muun](https://muun.com/) also use their own custom mempool-based fee estimator, which you can read more about [here](https://blog.muun.com/why-is-muuns-fee-estimator-more-efficient/). They produce this chart on their website that shows how much of a difference a mempool-based approach can make:

![](https://www.datocms-assets.com/99305/1705601134-munn-fee-chart.png)

As you can see, when it comes to accurately estimating the fee to get a transaction confirmed in the _next_ block, mempool-based estimators like this do a good job; They produce estimates that are more optimal as they are more reactive to short term changes.


### History-based fee estimation

In contrast to mempool-based estimation, history-based fee estimation uses historical data to predict future fee trends, analyzing past transaction data to identify patterns and trends in fee fluctuations. By understanding historical fee movements, history-based estimation can provide more stable and predictable fee estimates for transactions with more flexible confirmation targets.

[Bitcoin Core](https://github.com/bitcoin/bitcoin) - the most widely used Bitcoin node implementation, and the one we use at Strike - uses this history based approach. If you want to see exactly how it generates its fee estimates, you can read the [Bitcoin Core fee estimation source code](https://github.com/bitcoin/bitcoin/blob/master/src/policy/fees.h). But to break it down in simple terms, the estimation process involves:

- Grouping transactions into buckets based on similar fee rates
- Tracking how long it takes for transactions in these buckets to be mined
- Using different data sets to track this information over various time horizons (short, medium, and long)
- Applying a decay factor for each dataset to give more weight to recent transactions
- Using success thresholds for different time horizons
- Calculating estimates based on the number of transactions confirmed within the target number of blocks or less

Bitcoin Core's fee estimation uses a moving average and various parameters to provide fee rate estimates under different conditions. Within this, there are two estimation modes that you can select from: economical and conservative.

**Economical Mode:** This mode estimates fees based on recent blocks, aiming to optimize for lower fees. It is more responsive to the latest changes in the fee market, making it suitable for situations where you are willing to risk longer confirmation times for potentially lower fees.

**Conservative Mode:** This mode provides estimates that are more likely to ensure faster confirmation, as it considers a longer transaction history. However, it is less responsive to short-term drops in fee rates, often resulting in higher fee recommendations. This mode is better if you want to prioritize transaction confirmation time over fee cost.

Both modes aim to balance cost and confirmation time based on different user preferences and market conditions.


## Striking the right balance
At Strike, we make a lot of Bitcoin transactions on behalf of our users. Depending on the scenario, we have differing requirements for our confirmation times. To look at a couple of brief examples:

**Transaction batching:** When we broadcast on-chain transactions on behalf of our users, we use transaction batching in order to optimize our block space usage. Generally speaking our batching algorithm aims to broadcast a batch of transactions every block. For this to be effective, we need strong guarantees that our transaction will actually make it into the next block, so using a mempool-based fee estimator works best for this use case.

**Lightning channel opening/closing:** Conversely, when we are opening and closing lightning channels, we may be able to wait longer, and so a history based estimate, like those from Bitcoin Core, can be more appropriate as it enables us to more effectively target blocks further into the future.


## Blended fee estimation

Given the benefits and limitations of each individual approach, we use a blended fee estimation method that leverages the advantages of both mempool-based and history-based estimations.

For immediate transactions demanding prompt confirmation within the next few blocks, we prioritize mempool-based estimates for their real-time accuracy.

For transactions with more flexible confirmation targets stretching into the future, we rely on history-based estimates to provide a more stable and predictable fee range.

This blended approach strikes a balance between real-time precision and long-term predictability, enabling us to optimize transaction fees effectively across a wide spectrum of scenarios.


## Improving LND's fee estimates

**In the rest of this post, we’ll look at how we combined the two techniques - mempool-based and history-based fee estimation.**

Given we primarily use the [Lightning Network Daemon (LND)](https://github.com/lightningnetwork/lnd) for our Lightning node needs, we’ll focus on that; however, a similar approach could be taken for other node implementations.


### Custom fee estimates with LND

By default, an LND node that is connected to a Bitcoin Core instance will use the [`estimatesmartfee` RPC](https://developer.bitcoin.org/reference/rpc/estimatesmartfee.html) from Bitcoin Core to provide its fee estimates. As we saw above, this is far less than ideal in some situations as its estimates are only based on historical data.

Wouldn’t it be better if we could plug a different fee estimator into LND? Well, we’re in luck because the engineers that work on LND thought of that and, of course, already made the fee service configurable.

It might not be immediately apparent, however if you look at the [sample config file](https://github.com/lightningnetwork/lnd/blob/master/sample-lnd.conf) provided in the LND source code, you’ll find this code block:

```
; Optional URL for external fee estimation. If no URL is specified, the method
; for fee estimation will depend on the chosen backend and network. Must be set
; for neutrino on mainnet.
; Default:
;   feeurl=
; Example:
;   feeurl=https://nodes.lightning.computer/fees/v1/btc-fee-estimates.json
```

As you can see, there is a `feeurl` config option, which can be set to a URL that provides fee estimates. And if we visit the [example url](https://nodes.lightning.computer/fees/v1/btc-fee-estimates.json) from that same snippet, you’ll land on a page that serves some json that looks like this:

```
{
  "current_block_hash": "0000000000000000000075b86...6303e",
  "fee_by_block_target": {
    "2": 141428,
    "4": 96148,
    "85": 82688,
    "121": 79068
    "24": 171819,
    "25": 86680,
    "144": 58520,
    "504": 56192,
    "1008": 37896
  }
}

```

Examining this a little, what we notice is that it is providing a series of confirmation target estimates. From the example above, the estimated fee to have a transaction mined within the next 4 blocks is 96,148 (that is fee per kb - so that translates to a fee rate of ~96 sats/vbyte).

This is pretty nice. It means that we can point the `feeurl` setting to any url that returns json following this format, so in theory we could plug any fee estimation system into that, as long as it can return fee estimates in the expected format.


### Using selective mempool-based and historical-based estimates

Our goal was to use mempool-based fee estimates for transactions that should be confirmed within the next few blocks, but continue to use history-based estimates for transactions that should be confirmed further into the future.

When it comes to mempool-based fee estimators, we think the Mempool open source project is one of the better tools out there, so we wanted to use that for our short term fee estimates. And for the longer term estimates we think Bitcoin Core does a pretty good job so we wanted to continue to use that.

To achieve this, we created a [Bitcoin Blended Fee Estimator](https://github.com/LN-Zap/bitcoin-blended-fee-estimator). This is a basic service that provides a single endpoint that serves json with fee estimates in the expected format for LND.

Estimates for a confirmation target of 1 through 6 are provided by the [Mempool API](https://mempool.space/docs/api/rest), whilst estimates for confirmation targets further out into the future are provided by Bitcoin Core via the [Esplora API](https://github.com/Blockstream/esplora/blob/master/API.md).

By default it connects to the [mempool.space](https://mempool.space/) and [blockstream.info](https://github.com/Blockstream/esplora/blob/master/API.md) public APIs, however, it can be configured to connect directly to your own Mempool and Esplora instances to reduce the reliance on these hosted third party APIs.

### Running the blended fee estimation service

You can run this service in your own infrastructure alongside your LND node. Or, you can use our hosted version to get up and running quickly (read on for more details).

If you have Docker setup on your machine, you can try it out by running the [Docker image](https://hub.docker.com/repository/docker/lnzap/lnd-mempoolspace) which we provide for convenience.

```
docker run -p 3000:3000 lnzap/bitcoin-blended-fee-estimator:latest
```

After the docker image has downloaded, you should see the following output indicating that the service is up and running.

```
---
Using port: 3000
Using base URL: http://localhost:3000
Using Esplora base URL: https://blockstream.info
Using Mempool base URL: https://mempool.space
Using Mempool estimation depth: 6
Using fee multiplier: 1
Using cache stdTTL: 15
Using cache checkperiod: 20
---
Fee Estimates available at http://localhost:3000/v1/fee-estimates
```

Then, simply navigate to <http://localhost:3000/v1/fee-estimates> where you should see the the current fee estimates, nicely formatted for LND.

You can set this URL in your LND config file and restart your LND node:

```
; URL for external fee estimation.
feeurl=http://localhost:3000/v1/fee-estimates
```

With this in place, LND will now use fee estimates from Mempool for next block fee estimates, and estimates from Esplora for estimates further into the future.

### Leveraging the blended fee estimation service

Because we have plugged directly into LND, it will use this for all of its internal fee estimations that target a specific number of blocks into the future such as making on-chain transactions, opening channels, sweeps, etc. Additionally, anything that connects to or builds on LND will also benefit from the new fee estimation sources. So you’ll have a consistent approach to generating fee estimates throughout your stack.

For example, if you are using [Lightning Loop](https://lightning.engineering/loop/) to rebalance channels, the fee estimates provided by the Loop service will also be using our custom fee sources since it calls through to LND to get those estimates (we found this to drastically reduce our rebalancing costs by preventing Loop from overpaying onchain fees).

Or if you are building a wallet or other service on top of LND, that too will use the custom fee estimation sources.

Essentially, anything that calls LND’s [EstimateFee RPC](https://lightning.engineering/api-docs/api/lnd/wallet-kit/estimate-fee) - either directly or indirectly - will use the new fee estimation source.


## A Strike hosted fee estimation service for LND

Using a mix of mempool-based and history-based fee estimates in our tooling has provided us with better estimates for getting transactions mined. This helps keep costs down for our users as well as relieving fee pressure from the Bitcoin blockchain.

We figured it could be useful for other node operators, wallet service providers, or builders - so we have open sourced the code:

https://github.com/LN-Zap/bitcoin-blended-fee-estimator

Additionally, we wanted to make it super simple for you to try this out without needing to deploy an instance of the service to your own infrastructure, so we’ve setup a hosated version of the service for anyone to use. You can access it at the following URL:

https://bitcoinchainfees.strike.me

To use, simply add/update the `feeurl` setting in your lnd.conf file to point at the endpoint provided by the service:

```
feeurl=https://bitcoinchainfees.strike.me/v1/fee-estimates
```

We hope you find the blended fee estimation tool useful! Let us know if it works for you or if you have any questions or suggestions for improvements.

## Future improvements

Issues with Bitcoin Core's current history-based fee estimations are fairly well known and understood, and there are multiple efforts and proposals to improve this.

One recent proposal is the idea of Cluster Fee Estimation, emerging from discussions in the broader Bitcoin community. This approach aims to address some of the complexities of the Child Pays For Parent (CPFP) mechanism by clustering linked transactions and evaluating their collective fee rates. To understand the CPFP mechanism's impact on fee estimation and the Cluster Fee Estimation proposal in more detail, this [article from Bitcoin Optech](https://bitcoinops.org/en/topics/cluster-mempool/) is worth a read, or check out this more detailed [summary of the proposal](https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393) from Suhas Daftuar.

Though no fee estimation technique will ever be perfect given the impossible task of predicting the future, we can continue to implement more advanced, robust, and adaptive solutions that deliver overall improvements to the fee estimation problem.

**The more we collectively optimize our on-chain transaction fees, the better for everyone**; by reducing fee overpayment, we can help avoid the self-perpetuating cycle in which people paying unnecessarily high fees, can drive fee estimates further higher.

Combining mempool-based and history-based fee estimators

Blended Bitcoin Fee Estimations

[Peerswaps](https://www.peerswap.dev/) enable atomic swaps between Lightning Network and Bitcoin (BTC) or Liquid Bitcoin (L-BTC). This can enable a cost effective and capital efficient way to maintain well balanced Lightning channels.

We’ll take a practical look at how to go about performing a peerswap, and how you could add peerswaps to your channel rebalancing strategy.

## Run the Daemons
Alongside your Lightning node (peerswap currently supports [LND](https://github.com/lightningnetwork/lnd) or [CLN](https://github.com/ElementsProject/lightning)), run the [Peerswap daemon](https://github.com/ElementsProject/peerswap), and optionally the [Elements daemon](https://github.com/ElementsProject/elements) if you want to use L-BTC.

The Peerswap node will act as the swap coordinator.

The Elements node will act as a Liquid Bitcoin wallet which you can use to swap funds into and out of your Lighting channels. If you want to use regular BTC instead of L-BTC, you can use the on-chain bitcoin wallet that’s integrated with your Lightning node instead.

When you want to rebalance the channel, use the Peerswap daemon to initiate a peerswap. The peerswap daemon will coordinate the transactions with your channel peer. After initiating the swap, you just need to wait for 2 confirmations on the Liquid network for everything to complete. The whole process takes about 2 minutes (the time it takes for 2 blocks to confirm on the Liquid blockchain).

## Whitelist Peers
Peerswaps are direct swaps with direct channel partners. To use Peerswap your channel partner must also be running Peerswaps and must have whitelisted you in their peerswap config file (or set the `accept_all_peers` option). You must also whitelist them in yours. You can run `pcli listpeers` to check which of your connected channel peers support peerswaps and which chains they support (BTC and/or L-BTC).

Why the whitelist? Consider that a peerswap is an operation that has a cost (on-chain fees), a time opportunity cost (funds locked during the swap operation), and an effect on your liquidity profile (swapping capital between Lightning and BTC or L-BTC). It’s probably not something that you want to blindly allow anybody to do. However, it is something that you could reasonably enable between proven node operators within your own network of channel peers, or even your own nodes if you run multiple.

## Rebalancing Use Bitcoin (BTC) or Liquid Bitcoin (L-BTC)
Peerswaps supports swapping using both the Bitcoin base chain, and the [Liquid](https://liquid.net/) Bitcoin federated sidechain. Each has their pros and cons, but for the purposes of rebalancing channels, the Liquid Network has a distinct advantage in two important areas - speed, and cost.

### Speed
Blocks on the Liquid network are produced every minute and only 2 confirmations are required to complete a peerswap. So it takes ~2+ minutes to finalize a peerswap.

On the Bitcoin network blocks are produced on average every 10 minutes and it will take 3 confirmations to complete a peerswap. So it takes ~30+ minutes to finalize a peerswap.

### Cost
The average transaction fee on the Liquid network is currently 0.1 sat/vbyte to get into the next block (although this may change over time). Given an average transaction size of ~2000 vbytes it would cost you about 200 sats to perform a swap. That is about $0.025 by today's exchange rates.

On the Bitcoin base chain, fees are variable but generally much higher. At the time of writing, it will cost about 50 sat/vbyte to get into the next block. Given an average transaction size of ~300 vbytes it would cost you about 12,000 sats to perform a swap. That is about $5.62 by today's exchange rates. In other words, about 225 times more expensive than L-BTC, and a material consideration if you are a Lightning routing node operator or are running a business in which channels need to be regularly rebalanced.

### Other Considerations
Of course, cost and speed aren’t the only considerations. To use Peerswaps you will also have some additional overhead.

Running peerswaps itself is pretty straightforward. It’s only acting as a coordinator so it doesn’t directly hold funds, although it does need access to your nodes, and it does need to maintain state so you will need to ensure you have robust secrets management and backup solutions in place.

If you want to take advantage of Liquid you also need to run the Elements daemon where there is more to consider, as the Elements wallet will be holding an L-BTC balance. And there is also the different [trust model](https://blog.liquid.net/the-truth-about-liquid/) of the Liquid federation itself to consider.

### BTC vs L-BTC
All in all, if you're looking for a fast, very cost effective way to maintain balanced channels between semi-trusted direct channel peers, L-BTC is a good option. Although using BTC for peerswaps may also be useful and preferable in certain situations. This comparison from the Peerswaps team shows some of those considerations:

![](https://www.datocms-assets.com/99305/1702226228-peerswaps-btc-lbtc.png)

## Performing Swaps
Depending on the state of your channel, you’ll perform a swap-in or a swap-out to rebalance it:

### The Swap-Out
When most of the liquidity is at your end of the channel (you are short of inbound liquidity) you swap some of your Lightning Bitcoin with your peer’s L-BTC (or BTC); you perform a swap-out.

![](https://www.datocms-assets.com/99305/1702226245-peerswaps-swap-out.png)

In the swap-out, you will generate an L-BTC (or BTC) on-chain address, your peer will generate a Lightning invoice for the same amount, and you will then pay this invoice using the  unbalanced outbound heavy channel. This pushes Lighting Bitcoin along the channel, to your peer, rebalancing the channel. As part of the same process your peer will send the required BTC amount to your on-chain address.

### The Swap-In
Conversely, when most of the liquidity is at your peers end of the channel (you are short of outbound liquidity) you swap your L-BTC (or BTC) with your peers Lightning Bitcoin; you perform a swap-in.

![](https://www.datocms-assets.com/99305/1702226238-peerswaps-swap-in.png)

In the swap-in, you will generate a Lightning invoice, your peer will generate an L-BTC (or BTC) on-chain address, and they will then pay your invoice using the unbalanced inbound heavy channel, pushing their Lighting Bitcoin along the channel to your side of the channel making it yours, and in the process rebalancing the channel. As part of the same process you will pay the required amount of BTC to your peer’s on-chain address.

The end result - ~2 minutes later your channel will be back at your preferred liquidity profile for a cost of less than $0.03, if you used liquid. You could do this dozens of times in a single day and only pay $1 total at today’s rates.

## Automation to keep the channel balanced
With both yourself and your peer running peerswaps and elements, you now have the ability to keep channels between each other balanced for a very low cost.

One way to do this would be to maintain a pool of working capital in the form of L-BTC, which you peg into the Liquid sidechain from the Bitcoin chain when on-chain fee rates are relatively low. You could then automate things such that if all the liquidity in the channel moves towards 100% in either direction you can use peerswap to bring it back towards 50% by swapping into or out from the channel balance to and from your L-BTC working capital pool.

This can enable you to maintain fewer, smaller, well balanced channels with a very small on-chain footprint.

## Testing with Peerswap Playground
We put together this simple [PeerSwap Playground](https://github.com/LN-Zap/peerswap-playground) which you can use to try it out. It provides a Docker stack that comprises bitcoind (running on regtest), elementsd, 2x lnd nodes, 2x peerswap clients, and 2x L-BTC wallets. It connects everything together, initializes the wallets, and creates a channel between the two nodes.

You can use this to perform test swaps or just practice your skills with lnd, elementsd, and peerswapd! There are some simple instructions in the project’s readme which will walk you through the setup and the process of performing a swap.

## Rebalancing channels with Strike using Peerswaps
If you support Peerswaps and are one of our existing channel partners or run a reliable routing node and would like to maintain a balanced channel with the [Strike routing node](https://1ml.com/node/034d7f4bbbd6c1c1d8fbe0a42dd1f59e10b66540c6872dfcaa095d8d5cffebcf46), reach to our liquidity team at [liquidity@strike.me](mailto:liquidity@strike.me).

### Other Rebalancing Tools and Techniques
Peerswaps is a relatively new rebalancing technique. This comparison from the Peerswaps team conveys some of the key properties and tradeoffs of peerswaps as compared to other approaches to rebalancing channels.

![](https://www.datocms-assets.com/99305/1702226252-channel-balancing-options.png)

All in all, Peerswaps between Lightning and L-BTC can be a reliable, cost effective, and capital efficient way to keep channels between semi-trusted peers well balanced.

## More About Peerswaps
Peerswaps was created by the team at [Blockstream](https://blockstream.com/). It's in its early stages and under active development. Peerswaps currently supports LND and CLN. There is only a command line interface at the moment, although a GUI integration with [Ride the Lightning](https://www.ridethelightning.info/) is in the works. The Peerswaps team has an active [Discord](http://discord.gg/MSNt8eyZrT) where they engage with the community so if you need help or would like to help with the project you can head over to there.