Today, we're excited to unveil a new set of features in the latest litd release including automated fee management, custodial accounts, finer grained LNC permissions, and the Pool Order Board, all designed based on feedback from the developer and node operator community. Litd bundles the base version of our lnd Lightning implementation with liquidity services such as Loop and Pool, a web-based node management UI with Terminal, the ability to remotely connect nodes with Lightning Node Connect, and a set of accounting features with Faraday into a single software package.

With this latest release, we're introducing a handful of new features like automatic channel fee management in Terminal, custodial off-chain accounts, more control over connection permissions for LNC, and an Order Board for a simpler way to interact with Pool. In this post, we dive into the details of those features and outline new use cases for the Lightning developer community to explore.

Automagically Manage Channel Fees

Today's release includes a new version of Lightning Terminal, the web-based UI for node and liquidity management, which now supports automated channel fee management. To turn on Autofees, for all channels or on a channel-by-channel basis, users should navigate to the Autopilot section of the new Lightning Terminal home page. After Autofees is turned on, the Autopilot section of the Terminal homepage will populate fee changes made by the Autofee algorithm.

To make fee decisions, Terminal uses the forwarded traffic of the top five earning channels over 60 days as a reference for the entire node (in order to determine a target throughput). It will then look at the forwarded traffic from the past seven days for each channel and decide whether to adjust fees upwards or downwards. Each fee adjustment is made in small increments once every three days.

At its core, Autofees does not change the privacy and security model of your Terminal session. By enabling automatic fee management, you create a new additional session with the Autopilot server. This session is limited in its permissions through a dedicated macaroon. The session is visible in the locally hosted UI for litd and can be revoked at any time.

The server is able to access historic routing data over the past seven days as well as channel balances to assess whether to increase or decrease fees. In the interest of privacy, channel ids, channel points, and node pubkeys are all obfuscated by litd. Further, amounts and timestamps in the forwarding data are randomly obfuscated to break any amount and time correlation.

Further, with this launch, the dashboard experience has also been re-designed to give node operators more actionable information about top routes, forwards, and channel actions. In particular, the Terminal Home UX now calculates return on investment at both a node and channel level based on earnings and costs including channel opens, channel closes, forwarding fees, rebalances, Pool revenue, Loop costs, and more. Additionally, within the Forwards tab, node operators can now see a graph which tracks their fee earnings on forwards over time.

This alpha feature is another step towards automating node and liquidity management in addition to the existing Autoloop feature, an automated option for using Loop to manage liquidity. We plan to continue to introduce new automation features into the Terminal experience like auto-channel opens, auto-channel closes, and more. These features will help reduce the maintenance overhead of running a node while increasing fee revenue and general balance of funds on a node. We will continue to release more automation features to help reduce the Lightning node maintenance overhead and, thus, make the Lightning Network more accessible for all.

One Node for Many Users

In discussions with the Lightning developer community and companies building on LN, we learned that a key use case for onboarding more users into Bitcoin and Lightning is using a single LND node for many users. This model would allow for a single node operator to onboard thousands of Lightning users in a scalable, easy to maintain way. To help builders accomplish this goal, we're launching custodial off-chain accounts in litd.

Within litd, the user account is a virtual construct that provides restricted access to an existing lnd node. An account has a virtual (off-chain only) balance in satoshis and an optional expiration. This feature allows node operators to give any individual (or application) restricted access to their node with the ability to spend up to a certain amount of the node's channel balance. This accounts system is secured thanks to the power of macaroon cryptography and the RPC middleware interceptor within lnd.

With this system, a node admin can give a user or client application access to their node through the default gRPC interface of lnd. This access mode is fully compatible with any remote (or local) user interfaces or app/browser plugins, as well as Lightning Node Connect. The user requesting restricted access to a node will receive a macaroon that is bound to an account that is defined in litd. Because of the cryptographic security of macaroons, that restriction cannot be removed from the macaroon, by the user, without invalidating the macaroon itself.

This account system is designed, with the help of community feedback, to deliver features that meet the use cases necessary to increase end user adoption of Lightning. First, any payment made by a custodial user account is deducted from an account's virtual (accounted for internally) balance (including off-chain routing fees). In this way, developers have an easy-to-manage system for giving users a specific amount of Lightning funds. Further, if any payment exceeds the virtual balance, it is denied. This functionality ensures that developers can give access to their node without worrying about a user overspending. And, developers don't have to fret about oversharing their node information as the off-chain balance visible to the account is only the virtual balance, not the overall node balance. Finally, invoices created by an account are mapped to that account. If such a mapped invoice is paid, the amount is credited to the corresponding account's virtual balance. As a result, node operators don't have to add additional functionality for multiple invoice flows as it's included out of the box. One caveat to note is that, at this point, these accounts cannot yet pay or receive funds from each other. We intend to add this functionality in a later release.

This account system is a powerful tool for developers and we're incredibly excited to see what the community builds with it. Potential use cases include the "Community Custody" model whereby a tech savvy member of a community runs a Lightning node and gives access to Lightning by creating accounts for other members of their community. Although trust would be required in this case, it still can have a major impact on onboarding more early adopter users to Lightning. Additionally, this feature can be used for apps to give their users the ability to spend up to a certain amount of bitcoin, automatically. For instance, a browser extension could easily give users the ability to pay invoices for paywalls automatically up to a certain amount per month.

This developer tool is yet another example of providing easy-to-use infrastructure to the Lightning community, which we believe will result in a wide variety of use cases that help bring Bitcoin to billions of users. To learn more about how to set up, configure, and use this off-chain account functionality, check out the LND Accounts documentation in our Builder's Guide. We are excited to see what the community builds!

Moar LNC Permission Controls

We've also heard from Lightning builders the desire for more granular control over Lightning Node Connect, a protocol for creating an end-to-end encrypted connection between a Lightning Node and a web browser or mobile application. Previously, with LNC, users could only generate connection sessions for admin (where a user is able to see and do anything on the node) or read-only (where a user is only able to see information, not able to interact). From community feedback, we learned that developers wanted the ability to offer finer-grained controls on LNC permissions for use cases like giving a user permission to access the node in a limited sense and giving businesses more secure control over node access.

With today's release, users can create LNC pairing phrases with limited permissions beyond just the existing admin and read only types. There are two new types of permissions with Liquidity Manager (gives access to only Loop and Pool) and Payments Manager (gives access to only send and receive payments). Additionally, within the litd binary UI, users can also set up custodial accounts, the new feature discussed above.

But, beyond new types, we also are introducing fully customizable LNC session creation. This allows for node operators and builders to create sessions with custom permissions like "this user can only send payments, but do nothing else". Check it out to see what's possible today!

These new finer-grained permissions will be especially useful for apps looking to integrate LNC into their experience because they can instruct users to only give the app certain key permissions. We can't wait to see all of the apps and businesses integrating LNC to build better non-custodial Lightning experiences for users.

Hop in the Pool Beta

With litd, developers also get access to the latest and greatest releases from our products including Lightning Pool, a marketplace to connect Lightning node operators to liquidity providers. The latest Pool release moves the product out of alpha to beta with useful features to help builders and Lightning companies create smoother Lightning UX for near-instant, non-custodial Lightning usage. These new user flows are unlocked by beta features like zero confirmation channels and sends, plus unannounced channels, Lightning channels not visible on the public channel graph.

With zero confirmation functionality, Pool users can now purchase or sell Lightning Network channels without the need for on-chain confirmations. A Lightning business, or Lightning service provider (LSP), can purchase inbound and outbound zero-conf channels for a user to give them the ability to send payments over the Lightning Network in a fully non-custodial manner, without requiring the end user to understand Lightning liquidity.

Further, Pool also now supports MuSig2 accounts, a 2-of-2 funding transaction based on the latest multisignature technology to allow for users to add and manage funds within Pool securely, and unannounced channels. Both features increase user privacy and unlock offering liquidity for other assets in the future within the Pool marketplace.

Finally, with this release, by default, orders will be marked as public so that other users can see what orders exist in the market. Users can easily mark orders as private if they want to retain privacy. With that addition and feedback from the community, we also are excited to unveil the Pool Order Board within the Pool Lite experience on Terminal. The Order Board allows for node operators to browse open orders to buy or sell Lightning liquidity and choose to directly match to a particular order. So, if you're a node operator who needs inbound liquidity, you can navigate to the Pool Order Board and choose an offer directly, which will then be matched in the next batch automatically. Users don't need to take any further action to open a channel once it's matched.  Additionally, if you're a node operator who wants to sell liquidity, you can easily post your orders to the board for potential buyers to see. We're incredibly excited to make Pool a simpler, more straightforward experience for node operators to be able to easily buy and sell Lightning liquidity.

To learn more about these new features and Pool, check out the Pool Overview documentation in our Builder's Guide.

Get LIT Today

To get started exploring litd, download the latest release and read the getting started guide. These new features expand the functionality of litd to help the Lightning builder community create compelling use cases for their end users to help bring bitcoin to billions. To use the Terminal features outlined above, once you're on the latest version of litd just navigate to terminal.lightning.engineering and connect your node! We'd love to hear feedback from the community about the features launched today along with any ideas for future features within litd. If you haven't already, please join the lnd Slack, reach out to us on Twitter, contribute a PR, or subscribe to our newsletter!