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”.

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.

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.

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.

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.

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.

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 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.

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 or loops to expedite rebalancing.

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

• Use a blended fee estimator 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.