PeerSwap enables Lightning Network nodes to balance their channels by facilitating atomic swaps with direct peers. PeerSwap enhances decentralization of the Lightning Network by enabling all nodes to be their own swap provider. No centralized coordinator, no 3rd party rent collector, and lowest cost channel balancing means small nodes can better compete with large nodes.

PeerSwap currently has a working implementation for both CLN and LND nodes.
An interoperable implementation for Eclair is in progress along with protocol improvement discussions.

At the moment PeerSwap is suitable for developers and expert node operators with Linux command line skills. Implementations of control panel GUI interfaces are currently underway which will make PeerSwap easier to use for ordinary end users.

Join our Discord chat for discussion and support:

Full Spec and Github Repo

The proposed protocol specification and Github repository can be found at

Why PeerSwap?

Most Difficult Problem: LN Channel Balancing

  • Most capital tied up in LN channels is stuck forever in unbalanced channels.

  • Unbalanced channels are significantly less productive. Routing algorithms remember failures and try them less often.

  • Most people want channels to be balanced at 50%.

  • Most existing guides encourage opening more channels as the “solution”.

  • Most existing solutions utilize multi-hop routes.

Visualization: Mostly unbalanced channels

Multi-Hop Balancing can be considered Harmful

  • Most existing solutions utilize multi-hop routes to balance your immediate channels.

  • Multi-hop is very unreliable because …

    • By design you don’t know what the capacity is of other nodes.

    • Often balancing your own channel causes other node’s channels to become unbalanced.

    • Cooperative circular balancing can be zero cost and beneficial - but this is rare and labor intensive requiring real-time communication between 2+ node operators.

    • Unsolicited (normal) circular balancing is parasitic.

      • Nodes who charge a higher proportional feerate prey upon any available liquidity of lesser priced competitors - a.k.a. victims.

  • Ultimately can’t escape the zero sum game.

    • Need some other method that does not add to the overall problem.

Unsolicited circular multi-hop balancing rarely works or is most often parasitic

Multi-hop balancing is most often unreliable

What does PeerSwap do?

  • On-chain atomic swap negotiated over custom-message with direct peers.

  • Opposite approach to most existing balancing methods.

    • If you balance channel only with direct peers it is very reliable.

    • Rather than opening more and bigger channels, you can cheaply refill channels you already have to the desired balance.

    • Fixes balance without harming other nodes.

  • Opening new channels is recommended not for the purpose of balancing, but if you want a more direct connection with a frequent source/destination node.

  • Multiple optional swap types.

    • Currently BTC & L-BTC onchain swaps.

    • Additional wallet options can be implemented.

Balance channel to 50%

Most channels want 50%. That one channel wants to be 100% because their mining pool makes mostly outgoing payments.

Benefits of PeerSwap

Benefits of PeerSwap

  • Simple - works with existing LN nodes of today.

  • Lowest cost balancing and rebalancing.

  • Reliable because of single hop.

  • Fully P2P and decentralized. No coordinator. No 3rd party data collection.

  • Don’t need to open yet more channels for balancing

    • Reduces Hot Wallet Risk.

    • Reduces Cost of Capital.

      • More channels == More unproductive

    • Reduces need to pay for incoming capacity.

  • End-users don’t need to open new channels if they don’t want to!

Balancing Solutions Comparision

PeerSwap Swaps

Types of Swaps


  • Why should use PeerSwap instead of centralized markets for submarine swaps?

    • More Reliable - PeerSwap is significantly more reliable because you are not reliant on unknown channel balances, random network degredation, and slow routing attempts as often occur with multi-hop routes.

    • Lower Cost - PeerSwap is the lowest cost because there is no 3rd party coordinator or intermediary nodes to collect rent.

    • More Private - Swaps are entirely between two consenting nodes. Nobody else is able to record details like who swapped.

  • What is the difference between splicing and PeerSwap?

    • Splicing will take a long time to become code ready and widely available. Meanwhile PeerSwap is very simple and already works today without changes to existing LN nodes.

  • What is the difference between liquidity-ads and PeerSwap?

    • Liquidity Ads is a great way to lease new channels to be opened toward you for the purpose of gaining incoming capacity. New channels add new capacity in a desired direction but only once.

    • PeerSwap lets you repeatedly refill your existing channels at a cost lower than opening, closing, and maintaining additional channels.

  • Why PeerSwap instead of opening more channels?

    • PeerSwap can be more tolerant of onchain confirmation delay than LN channel open/close so BTC onchain fee rates could be lower. Large service providers like stores often close channels when they are depleted because it is capital inefficient to leave them open while unbalanced. Channel closing is often unexpectedly expensive so it is beneficial to reduce the frequency of channel closures.

    • It is more capital efficient to refill channels that already exist rather than open yet more channels with the same peer in order to improve your routing capacity.

    • PeerSwap nodes have the option of alternate swap assets. For example Liquid L-BTC can be faster and with greater transaction privacy (with some trade offs). Additional optional swap methods can be added to PeerSwap for users who want them without affecting users who don't.

  • Why test with Signet instead of Testnet?

    • PeerSwap supports Bitcoin testnet3 but we strongly recommend instead testing with Bitcoin Signet. Testnet has significant reliability problems like often no blocks, or too many blocks, or sometimes 10,000 block reorgs. If your goal is to test software integrations dealing with chaotic situations like reorgs or for race conditions you should be using regtest where you have control of that chaos.