By Lisa Neigut

Liquidity ads, a spec proposal that recently shipped in v0.10.1 of c-lightning, are an important addition to the Lightning Network. They are a lightweight way of providing the ability to coordinate liquidity deployment across the network in a decentralized and accessible fashion.

Liquidity ads address a common problem of accepting payments over Lightning: how and where to source inbound liquidity from.

In fact, sourcing inbound liquidity on Lightning is a problem that every node solves at some point.

Why Inbound Liquidity Matters

Inbound liquidity is incredibly important for both accepting and routing on lightning.

Your total inbound liquidity is the upper limit on the funds you’ll be able to receive over Lightning; this matters most for the vendoring/service providing use case of Lightning, but it also impacts the total amount of routing fees you’ll be able to earn.

In other words, inbound liquidity allows you to:

• accept payments over Lightning
• earn routing fees

Inbound Liquidity and Routing Fees

Earnings on Lightning are made by collecting fees for routing payments. The earnings from routing accumulate as local balance in your node’s channels.

In other words, your balance on Lightning increases when you convert inbound liquidity into outbound liquidity, across all channels.

Here, let’s consider a fairly contrived example where a routing node earns fees by routing payments. Let’s see how the amount of routing fees they earn is capped by the amount of inbound capacity the channel starts out with.

In this example, our node starts with two channels. The channel’s balances are set such that payments can be ‘yo-yo’d through the two channels, routed through the node. Our <Node> sits at the middle of these two channels.

It starts out with 1000sats of inbound capacity and 1000sat of outbound capacity.

<Node> has set a base_fee of 100sats on both channels. This means that every time a payment moves through the channel, our node collects 100sats.

As we’ll see, with enough passes, the Node’s channel fee take will slowly erode its ability to route — as a result of it netting fees for transferring capital.

Let’s briefly illustrate this. Here we’ll send the sats back and forth through both channels, paying <Node> 100sats at each pass.

Starting:

Let’s push payments back and forth over these two channels. We’ll use the entire available balance for each push, so our first push is for 1000sats. Minus the 100sat fee, the other end gets a payment of 900sats.

At this point, we can’t afford to route. The Node has routed 9 payments through these channels.

Originally, the node had 1000sats of outbound capacity, or balance it can spend, and 1000sats of inbound capacity.

After these 9 payments have been routed, the Node now has 1900sats of outbound capacity and 100sats of inbound capacity.

By routing payments, you’ve successfully earned 900sats from this pair of channels. The Node is going to need to source more inbound capacity now, if they want to continue earning fees by routing payments.

Making Liquidity Accessible, Cheaply

At some point, every node will need inbound liquidity.

This is because it’s a fundamental part of operating a Lightning node — the network only works insofar as nodes are able to source inbound liquidity for themselves.

There’s a lot of options for sourcing inbound liquidity today:

• Buying something over Lightning will create inbound capacity
• Using a loop out service such as Lightning Labs’ Loop or Boltz to push money from your lightning node back into your onchain wallet
• Talking to friends and orchestrating a balanced channel open
• Using a third party bulletin board such as LightningNetwork.plus
• Buying it from a known vendor such as LNBig’s liquidity service
• Finding someone who’s willing to lease it to you via a centralized auction

Liquidity ads are another method for sourcing liquidity: leased directly from nodes that you’ve found via the Lightning gossip network.

Ads are decentralized; any node with a single public channel can create one and have it sent to every node on the network. Leasing advertised liqudity is as simple as opening a channel with the node that’s advertising it. You know exactly who you’ll be opening the channel with — you’ll be able to see what their other existing channels are, before initiating the lease.

Liquidity Is Not Fungible

Liquidity on Lightning is not fungible, it is embedded into a network. This network is made up of nodes and their channel balances.

No two edges between nodes in the liquidity network are the same — channels uniquely connect different parts of the graph. New channels impact the Lightning channel graph differently. A node’s centrality and shortest path heuristic will look different, depending on which new node they create a channel to.

Said a different way: Each channel created has a unique impact on a node’s placement in the network graph. A new channel to one node may greatly increase the centrality whereas a channel to a different node may have no impact on a node’s centrality.

Valuing new inbound liquidity is difficult to do without knowing where in the graph the new channel will be placed. Despite good third party metrics which attempt to “grade” the value of different peers, it’s difficult to accurately value inbound funds from an unknown peer. In fact, figuring out what attributes of a node make allocating liquidity to a channel with them worthwhile is still an open research question.

This difficulty in assessing value makes it hard to figure out the what the inbound liquidity is worth.

For example, if my node is advertising liquidity, how would you figure out how much you are willing to pay for it?

The answer to this question will be different for every node that asks, as it depends on your node’s current liquidity situation and where your node is located relative to mine in the channel graph.

I’d love to see some services that offer realtime evaluations of various nodes liquidity advertisements, tailored to the node that’s looking to lease inbound funds.

Trade Offs

Liquidity ads are a great, lightweight, way to coordinate inbound liquidity from any node on the Lightning Network. There’s a few things to highlight about the bulletin board approach, however.

Pros:

• Only one onchain transaction is required to lease inbound liquidity. There’s no need to pre-commit capital to an auction account, as Pool requires.
• Any node with a single public channel can create an advertisement
• You know exactly who your new channel peer will be, before the lease is committed to
• Leases last for a month (4032 blocks)
• Some* on-channel enforcement of the lease terms
• Peer commits to a cap on routing fees they’ll charge to route payments with the leased funds

Cons:

• No guarantee that liquidity is available. The node may be out of capital or unable to provide the amount that you’re requesting
• Nodes looking to lease funds will have to determine the rate for their capital ahead of time (no auction mechanic for valuing it out of the box). This could be layered on top by a third party service, however, that helps you auction off available liquidity that’s then executed via a dual-funded/liquidity ad open.
• Market for liquidity may be thinner, as anyone can request liquidity from you at any time.
• Have to do your own research about the peer offering the liquidity.

* Funds that are leased are encumbered by a CSV lock for the to_remote output.

For a more in-depth comparison between the centralized Pool liquidity auctions and the liquidity ads spec proposal, the July 28th Bitcoin Optech Newsletter has more details.

Using Liquidity Ads Today

c-lightning, as of the v0.10.1 release, now includes an implementation of the draft ‘liquidity ads’ spec proposal.

Find out more on how to see, advertise, and lease funds here.

Note: This blog was originally posted at https://medium.com/blockstream/lightnings-missing-piece-a-decentralized-liquidity-market-a0bb47534a4f