Today we’re excited to announce our alpha release of Lightning Pool a new non-custodial marketplace that connects people who want to buy inbound liquidity with those looking to earn a return on their bitcoin in Lightning channels, promoting more efficient capital allocation on the Lightning Network. In this post, we’ll be doing a deep-dive into the architecture and design of the marketplace.

This marketplace has two natural sides:

	Taker	Maker
Description	Nodes that need to receive funds over Lightning	Nodes that need help efficiently allocating capital over Lightning
Problem	Cannot signal to the network a need for inbound liquidity	Cannot determine where their Lightning capital is best allocated
Solution	Submit a bid on Pool to purchase new inbound liquidity from a maker	Submit an ask on Pool to lease their existing outbound liquidity to a taker
Examples	Merchants, exchanges, wallets, services, etc.	Well-capitalized routing nodes, exchanges, etc.
Alternate terms	Buyer, purchaser	Seller, lessee

Pool is a non-custodial marketplace consisting of auctions that allow participants to buy and sell Lightning Channel Leases (LCL). An LCL packages up inbound (or outbound!) channel liquidity (the availability to send and receive funds) and is a hybrid asset that has elements of a traditional fixed income asset (like a bond) and peering agreements as used on the Internet to help coordinate the allocation of bandwidth between ISPs.

Similar to traditional bonds, an LCL has a maturity date expressed in blocks. The maturity date of an LCL is enforced by Bitcoin contracts, ensuring that the buyer of a contract is able to utilize the leased capital for a set period of time, paying interest to the seller of the LCL over the duration of the contract. Lightning Labs serves as the auctioneer in this market place, with the auction itself being a non-custodial sealed-bid, uniform clearing-price, double-call auction (don’t worry, each term is explained in detail below) which runs every roughly 10 minutes. With each successful auction batch, participants are able to discover the current per-block lease rate (block percentage yield, or BPY) for capital in the Lightning Network. All cleared orders in a batch are executed using a single batch transaction, allowing participants to pay lower chain fees compared to non-batched channel opening.

Starting today, users can use the open-source alpha client of Pool (poold) to participate in the auction by either buying or selling channel lease contracts using the pool CLI tool or RPC API. An instance of poold is backed by an active lnd node similar to loopd. In the alpha, a single poold buys channels for the designated lnd node, and uses funds from the lnd node to sell channels. As a non-custodial system, when users use poold to participate in the auction, they remain in control of their funds at all times from the moment they open an account through the process of clearing and execution of their first contract. A combination of client-side verification and Bitcoin contracts are used to allow clients to verify and validate each component of the system.

Resource Allocation Problems in Lightning

In the Lightning Network today, participants aren’t able to effectively exchange pricing signals to determine exactly where in the network capital should be allocated. In the absence of a proper venue, those that need inbound capital to operate their Lightning service are forced to solicit capital on various chat groups, forums, or Twitter. On the other side, those seeking to deploy capital and earn routing fees must guess where their capital is most demanded. As such, node operators risk opening channels where they aren’t actually demanded, leading to poor capital efficiency. It’s as if node operators are speculatively building roads that no one will use (why isn’t my node forwarding?), and those seeking to receive aren’t able to flag their service as an attractive destination to be connected to internal network “highways”.

Pool solves this resource allocation problem by creating a new auction that matches up those seeking to deploy capital (by opening channels) to those that need these channels to operate their Lightning service or business. With each executed batch, the participants of the auction derive a per block interest rate which is effectively the current lease rate for capital on the Lightning Network.

A non-exhaustive list of resource allocation, bootstrapping, and incentive issues solved by Pool includes:

• Bootstrapping new users to Bitcoin directly on LN: A common question we’ve received in the past is: “how can a user Carol, who doesn’t have any Bitcoin at all, start using Bitcoin directly via the Lightning Network”? In the ideal scenario, Carol is also able to begin receiving and sending as soon as she finishes setting up her LN wallet. Pool solves this by instantiating an old concept called “side-car channels” wherein a third party is able to purchase a channel for Alice from Bob, which starts with both inbound and outbound liquidity, allowing users to be onboarded to Bitcoin directly via the LN. In the process, Bob also ends up earning a small amount, as he’s paid by Alice for his service.

• Routing node inbound bandwidth allocation: Many new participants to the routing network typically ask: “to which nodes should I open channels, such that they’ll actually be used for routing?” Before Pool, routing node operators could only guess where their channels would be most effective. Pool provides a new signal for routing node operators and autopilot agents: actual market demand. WIth Pool, a node can offer up its capital to allocate into channels, and have it automatically be allocated where it’s most demanded. By buying and selling channels on the network, routing nodes are also able to effectively emulate “dual funding” of channels.

• Bootstrapping new services to LN: Any new service launched on the Lightning Network will likely need to figure out how to obtain inbound channels so that they can accept payments. For this, Pool provides an elegant solution in that a merchant can set up a series of "introduction points" negotiated via the marketplace. The merchant can pay a small percentage of the total amount of liquidity allocated towards it, and also ensure that the funds will be committed for a set period of time.

• Allowing users to instantly receive with a wallet: Lightning wallet developers commonly face the UX challenge of ensuring that a user can receive funds as soon as they set up their wallets. Some wallet providers have chosen to open new inbound channels to users themselves. This gives users the inbound bandwidth they need to receive, but can come at a high capital cost to the wallet provider as they need to commit funds at a 1:1 ratio. Pool allows them to lower their customer acquisition costs, as they can pay only a percentage of the funds to be allocated to a new user. Just like the merchant purchasing inbound liquidity as described above, a wallet could pay 1k satoshis to have 1M satoshis be allocated to a user, instead of fronting the whole 1M satoshis themselves

• Compensating routing node operators for the cost of their capital: Today, routing node operators aim to join the network in order to facilitate the transfer of payments as well as earn fees over time with successfully completed payments. However, if a node isn’t regularly routing payments (thereby earning a forwarding fee), then they aren’t compensated for the various (though minor) risks they expose their capital to. With Pool, routing node operators are able to ensure that they’re consistently compensated for their cost of capital.

As operators of Lightning Loop, a non-custodial off/on-chain bridge, we’ve faced many of these issues ourselves as the Loop service has scaled up. As we surveyed the space, we determined that no existing tool or service fully met our needs, nor the challenges that our customers were running into as they scaled up their own Lightning services and businesses. Today with the launch of Pool, Lightning Loop is an active buyer of inbound liquidity toward the Loop gateway node. In the past, this process (soliciting new inbound channels) was carried out via a primarily manual, slow process. With the wonders of electronic markets such as Pool, we’re now able to automate away much of the resource allocation issues that Loop has faced as we’ve scaled up the service.

Lightning Network Market Design

The field of market design is a sub-discipline of economics which is concerned primarily with the efficient allocation of scarce resources. In particular, we’ve drawn on the branch of market design concerned with instances wherein money is used to govern the exchange of goods and services: auction design. Common established examples of auction design widely used today include: emission of carbon credits, electricity markets, auctions for airport slot usage, and also wireless spectrum auctions. In each of these examples, market design is used to allow more effective communication of pricing information, resource allocation, and preference expression. In the context of LN, the scarce resource we aim to more efficiently allocate is: inbound channel bandwidth, commonly referred to as inbound liquidity.

Resource Allocation via Lightning Channel Leases

As the Lightning Network is a fully collateralized system, in order to be able to receive up to N BTC over a channel, another peer on the network needs to first allocate at least N BTC into a channel toward you. In a similar vein, a node that opens only outbound channels isn’t able to immediately begin routing payments, as it requires other nodes to allocate an ideally equivalent amount of capital to its node. New users that join Lightning also grapple with these issues, as a wallet user isn’t able to receive funds until they either spend some of their money in channels, or somehow gain an inbound channel from elsewhere in the network.

This problem domain is similar to establishing initial connectivity on the internet as a fledgling Internet Service Provider (ISP). A new ISP needs to peer with other ISPs (typically via peering agreements, either directly or at an Internet Exchange Point (IXP)to be able to service prospective new customers and connect out to the greater internet. If the Internet is a series of tubes, then Lightning is a series of money tubes wherein allocated capital serves as transportation infrastructure for payments on the Internet. However as our resource in question (BTC in channels) is “virtual”, new entrants have a much lower barrier to entry as they don’t need to lay expensive fibre cables, or enter into long-term contracts with existing ecosystem participants. Over time, we expect this lower barrier to entry to create a much more competitive, and therefore much more decentralized, market for Lightning Service Providers (LSPs) than today’s market for traditional ISPs.

New companies or entities seeking to launch a new venture also have a similar need: they require capital in order to operate their businesses or invest in new promising areas. In the world of traditional finance, bonds are used to allow a company to raise capital for an endeavour from various investors. Bonds typically have a maturity date (the period after which the capital is returned in full back to the lender), and pay out interest over the lifetime of the bond in order to compensate the lender for their cost of capital.

Lightning Channel Leases effectively borrow from these distinct contexts to create a new type of contract which is a cross between a traditional internet peering agreement and a bond. LCLs are low-risk in that the seller or lessor of one remains in full control of the allocated capital at all times. They also incur no additional risk compared to the existing hot wallet risk of running a Lightning node. LCLs allow capital providers to earn yield, or interest, by allocating their capital to the network. Those seeking to have capital allocated towards them (to be able to receive funds) are able to pay a small percent of the total capital, ensuring that the capital will be available for use for a minimum period of time. As this is a brand new type of market, it’s hard to gauge exactly what the yields might be once the market is mature. However, as LCLs are a relatively low-risk asset, we imagine the yields will be priced accordingly.

Node Ratings for LCLs

In the alpha version of Pool, purchasers of LCLs will by default specify that they’d like to be matched only with “preferred” nodes that are able to maintain an “adequate” score based on our rating system. Those seeking to purchase channels that care less about the quality of nodes they’re connected to can opt-out of this filter. However, we want to ensure that users purchasing LCLs are confident that they’re purchasing a high quality of service from the backing routing node by offering the option to only purchase from rated nodes. Prospective users of the system can monitor the current rating of their routing node here via this publicly available end point. Users of Pool are also able to opt-out of this rating system all together if they choose to do so.

High Level Auction Design

Pool is a new discrete-interval, non-custodial, sealed-bid, uniform clearing-price batched auction, that allows participants to buy and sell LCLs on an open marketplace. For those not familiar with auction design, this description may be quite a mouthful, lets breakdown each of these system attributes in turn:

• Discrete-interval: Rather than the market clearing continually like typical continuous central limit order books, this market is cleared periodically. This shift to a discrete market eliminates several classes of problematic situations such as order sniping and front running. Also as all orders are themselves executed using the Bitcoin blockchain, the block interval itself provides a natural lower bound on the execution latency of the system. With each cleared batch, the market participants continually discover the current lease rate of capital in the Lightning Network.

• Non-custodial: Participants of the auction need to maintain an on-chain account that’s used to pay for any execution fees, premiums, and fund any sold channels. As the system is non-custodial, the funds allocated into these special accounts remain fully in the control of the user throughout all stages of the auction. This self-custody also allows the clients to audit all actions of the auctioneer in order to ensure that the market is being operated properly.

  * As all funds are stored in 2-of-2 multi-sig outputs, with the client needing to sign off on all transfers. With the current architecture, it isn’t possible for the server to initiate withdrawal from a client’s account, only the client is able to do so.

• Sealed-bid: All orders (bids and asks), are only sent to the auctioneer. As a result, an agent can’t rely on the price of any other orders (other than the prior clearing rate), or attempt to cut off existing orders in the system. Instead, agents are incentivized to bid based purely on public information and perceived value of inbound liquidity on the network. Naturally, all orders are submitted off-chain directly to the auctioneer, resulting in no chain activity during the bidding and clearing process.

• Uniform clearing price: The orders cleared in an auction batch all pay the same price. This is similar to the way the U.S Treasury clears auctions for various instruments including treasury bills. As all traders pay the same price, it can be perceived as being “more fair”, as all agents are incentivized to bid only what they think the true price is. A rule of thumb is that participants will either get their posted price or better when their orders clear.

• Batched execution: All orders cleared during an auction epoch are bundled into a single on-chain transaction. This bundling allows users to batch several channel openings in a single transaction, which ends up reducing the chain fee burden of all participants in a batch. As the marketplace grows, as each user contributes part of the batch fees, it may grow to be cheaper to open a channel using the auction rather than in isolation.

If you want to dive into the specifics of how each of these components are constructed in the live system, we invite you to read the technical white paper which you can find here.

Don’t Trust Verify: Client-Side Security Attributes

Similar to Loop, the Pool backend server is closed source, but clients are able to fully verify and audit each phase of the auction. At a high level, Pool can be seen as a “Shadowchain” anchored in the base Bitcoin blockchain. The Shadowchain validates modifications to a subset of the UTXO set (the Pool accounts) with the auctioneer acting as a block proposer to extend the chain. State transitions are validated and accepted by those that are involved in a new block (the auction batch). Newer clients are even able to audit the prior history of the system in order to ensure proper operation. Pool uses the Bitcoin blockchain for what it’s best for: global censorship-resistant batch execution.

Leveraging this Shadowchain structure, users remain in control of their funds at all times, and will only enter into agreements that they’re able to fully verify, ensuring that channels are properly constructed and that the market is operating as expected. Compared to existing centralized exchanges with off-chain order execution, Pool has a number of attractive security properties:

• As a non-custodial system, users are in control of their funds at all times.
• A purchased LCL will result in the creation of a channel with parameters that capture the preferences expressed in the initial order.
• If the auctioneer server is hacked, the breach doesn’t unilaterally compromise user funds.
• Orders by one trader cannot be used to spoof orders by another trader.
• Clients are able to verify and audit all operations carried out by the server during batch construction including proper order matching.

Beyond this initial alpha version, we aim to continue to iterate on the system in order to improve the verifiability and transparency properties. Stay tuned for more information on these additional security enhancing features.

Alpha Release Limitations

As this is an early alpha release, a number of features have been left out of this initial version, which will be in place by the time the system enters beta. In addition to these initial limitations, we’ve started to design future iterations of the system which add additional functionality, improve security, and explore new use cases. For more detailed information concerning these future directions, please check out the technical white paper.

Service-Level Based Lifetime Enforcement

In the alpha release, LCLs won’t yet be enforced by Bitcoin’s Script. Instead, the purchaser of a Pool LCL won’t allow the maker (the node that sold the channel) to execute a cooperative close of the channel. As a result, the malicious maker must force-close instead, which will incur additional capital lock up by the seller of a LCL. As a stop-gap until the necessary new channel type and scripting changes are implemented in lnd, the system will continually monitor the lifetime of all LCLs and penalize makers that force close the channel early, uniquely identifying the party at fault. Those detected reneging on their agreements will be temporarily banned from participation in the marketplace. Repeat offenders will have their ban duration extended in a compounding manner.

Lump Sum Yield Payments

All interest payments in the alpha release are paid upfront from the taker to the maker once a batch has been executed. In other words, the interest payment is collected in a single lump sum by the taker. This simplifies the initial system, but means that if the leased channel breaks down for some reason, the lessor is able to collect full payment without providing a service over the agreed upon duration.

In the future, we aim to resolve this issue by allowing interest to be “streamed” in real-time (with each block) from taker to maker. With this change, the taker will be able to send interest payments off-chain in a verifiable way using Bitcoin contracts to the maker. We’ll have more details on this exciting concept in the future as it allows a number of interesting concepts to be built upon it.

Limits on Account and Channel Sizes

Account sizes are limited to 10 BTC in the alpha. As we gain more confidence in the system these limits will be increased, and eventually lifted similar to the Wumbo channel limit for lnd.

Unified Duration Interval

In the alpha version of Pool, only a single duration bucket of 2016 blocks (~2 weeks) is live. In the near future, we aim to add other duration buckets (4 weeks, 8 weeks, etc.) as well, in order to allow participants to properly express their pricing preferences regarding short vs. long term lease durations.

Conclusion

With this alpha release of Pool, we’ve put forth a new way to solve the inbound liquidity problem by framing it as an economic problem in the context of market design. Pool helps those that need to receive funds over Lightning (merchants, exchanges, services, etc) obtain the inbound liquidity they need, and also helps routing nodes figure out where to open channels. As this is an early version of the system, there’s still a long road ahead of us to properly bootstrap the marketplace, as well as to improve the capabilities and security of the system over time. Those that want more technical details should check out our technical white paper.

We invite those that are comfortable with low-level node operation to download the alpha client and start acquiring and leasing inbound channel liquidity today! Between now and the eventual beta of the system, we’ll be fine tuning the API, collecting user feedback, fixing bugs, and executing on our vision to ensure the system reaches its full potential. Node operators and developers interested in joining the marketplace first-hand or integrating Pool into their Lightning Service should join our slack where we’ll be happy to answer any questions and help with initial onboarding.