Enabling Lightning network
for traders and exchanges

Eclair integration manual
Lightning risks and mitigations
Arbitrage API

back to wallet

Lightning network risks

Naively running a Lightning node poses a number of well known complexities, the most notorious of which are the following two:

  1. Managing direct customer payment channels is hard because liquidity present in them often can’t be utilized until a channel gets closed: exchange can’t use those funds for off-chain routing if customer is offline or has a non-public channel.

    Here’s a detailed report from an exchange which has expirienced this already: Admittedly, what they were using had no routing and with Lightning network situation should not be that bad, but it still may happen such that a lot of liquidity gets locked inside of thousands of customer channels with many of them being offline or rejecting cooperative closes. The only option left for an exchange in this case would be to force-close these channels and get refunding transactions locked for up to thousands of blocks.

  2. Sending an off-chain payment to a distant place across many hops may get that payment stuck for hundreds of blocks and can even result in eventual channel closing.

    Typically this happens due to bugs in routing software but this can also be a deliberate attack vector: exchange users may order a lot of off-chain withdrawals to payee nodes they control and then delay these payments for as many blocks as possible before failing them. Since stuck funds are unusable until a payment is in-flight this will result in a frozen liquidity.

Joint node as mitigation

Issues described above can be eliminated if exchange chooses to interact with global Lightning network not directly but only through channels opened with an intermediary Joint node. What this precisely means is:

  1. Exchange does not open direct payment channels with anyone but Joint node and other exchanges to avoid liquidity lockups.
  2. Exchange only sends withdrawals to its direct peers and to Joint node peers, such that off-chain payment is never more than one hop away.

This approach has a number of advantages: amount of funds kept in channel wallet is kept at minimum and there is no need to deal with locked liquidity or expired payments while off-chain arbitrage, which is arguably the main reason to have LN, is still perfectly possible.

The only disadvantage here is that exchanges would have to rely on Joint node being online. That said there is no possibility of losing money since this setup is still trustless and channel funds can always be refunded irregardless of Joint node actions. The absolute worst thing which can happen is exchange won’t be able to process off-chain payments for some time if Joint node becomes uncooperative.