Vulnerabilities happen. Open source is not immune to this, and no matter how many eyeballs are on the code SHTF sometimes. That is inevitable, and critical vulnerabilities in tools used by the entire world in the last 15years have proven that much. We had Log4j, Heartbleed and Struts exploits to name just a few that impacted huge parts of the internet. And bitcoin ecosystem is no exception, but it can make things a bit more complicated due to the nature of what we're dealing with - money.

Last year Burak's adventures showed us how bugs can effect everyone immediately. But with open source there is no list of customers. No software phoning home where you can quickly see which customers might still run vulnerable version, no emails or phone numbers to contact them that their funds are at risk. As luck will have it the lightning industry was (is?) still small at the time and most of us degenerates spend too much time on twitter, telegram groups and discords. So it was fairly easy to drum up together a large number of impacted companies and node operators and inform them of the issue. But this doesn't scale. And bigger blocks don't solve this scaling issue. Also not everyone reads developer mailing lists 24/7 in case something might happen.

We need better ways to communicate with users of open source projects.

While financial industry has always been a juicy target bitcoin made it that much more interesting. No more stealing credit cards and social security numbers, making it cumbersome and complex to monetize your hacking expeditions. With bitcoin, if you have an access to the server (hot wallet), you have access to the funds. And transactions are final. Which means that security and fast reaction times are that much more important.

Everything in lightning network is a hot wallet. That means that we need to not only write the best code (it will still have bugs), but we also need to have the processes to address the inevitable situations where things go wrong.

I've already mentioned lnd issues last year, but that is not the only example. Recent LNBank vulnerability that lead to at least one confirmed loss of funds is a good example. Luckily the vulnerability was in the plugin, not btcpayserver itself, but next time we might not be that lucky. It was announced on twitter, nostr and shared on various chat platforms. But how many of the 1000s btcpayserver installations were updated immediately because of that? Surely the usage of LNBank is probably significantly smaller than the number of btcpayserver deployments, but what happens next time when the vulnerability is in the btcpayserver itself.

Another example is lnbits which is a very popular tool that mostly has publicly exposed instances connected to lightning nodes. It also has a rich plugin system and rapid pace of development which makes it a great target for malicious actors. LNbits has a system for notifying their users about potential issues, but its based on the admin being logged in and visiting install page for plugins. I don't know about you guys, but I don't visit that frequently, neither I'm that frequently logged in to the lnbits itself. But I use the services of my amazing lnbits instance daily!

I could go on and on with more examples of popular software in this space, but lets focus on how we could address this.

Proposal

IT Security industry has a long established practices on how to deal with vulnerability information dissemination - they use good old RSS feeds. RSS has been around for ages, its very simple to integrate into everything. From chat clients to incident management tooling, any everything in between. And this is something every popular software and implementation should do. Maintain an RSS feed that is used exclusively for announcing critical vulnerabilities in your software. This can't be your blog's rss feed because people don't want to get woken up in the middle of the night by notifications about your new product release. But if there is a 0day vulnerability in part of my software stack that is touching a hot wallet I very much want to be woken up by my alerting system.

PSA: New release on github is not a sufficient way to announce urgent updates.

There are a lot of examples of this in the wild, Microsoft is publishing information about public vulnerabilities that haven't been patched yet on its rss feed. AWS is using RSS feeds to inform its customers about security issues impacting them, so are other big vendors.

To make this article more than just a rant - I've already mentioned this idea to btcpay crew both on mattermost and in a github issue. If you read the blog post by Dennis possibility of adding RSS to btcpayserver as future improvement.

Alternatively dedicated security mailing lists could be used to similar effect, but the overhead of collecting emails, running mailing list services (or paying for them) makes it suboptimal. Not to mention much bigger composability of RSS over email.

Opportunity

Having a public feed also enables nudging users to start implementing some operational awareness of what is going on with the their software stack. It is not the same as asking users to follow you on twitter for product updates. And I’m by no means saying that we should stop announcing things on popular venues like nostr, twitter and SN - far from it. The point is that it should be done as an addition to the dissimination over RSS, not as a replacement.

I’m not keen on starting another “spec” group but if there is enough interest there could be an opportunity to create a blueprint for open source projects in the space to remove the burden of implementing this on their own.

If any project or company wants to jump on implementing this for their own project and needs help feel free to get in touch (email or X) , I’ll be happy to assist.

Bitcoin did not arise from a vacuum. Rather, it was the culmination of numerous pioneering ideas that were germinated, nurtured, and disseminated in the open forums of the past. The foundational stones of Bitcoin were laid by concepts such as David Chaum's eCash, for instance, which brought the notion of anonymous electronic money transactions to the forefront. Adam Back's Hashcash introduced the concept of proof-of-work, a key ingredient in the prevention of email spam and denial-of-service attacks. Wei Dai's B-Money proposed a decentralized system for the creation and transfer of digital assets. And Nick Szabo's Bit Gold illustrated a mechanism for a decentralized digital store of value. Each of these ideas, openly shared and debated in various forums, contributed to the architecture of what would become Bitcoin. The idea was first shared on a humble mailing list, absorbing the wisdom of its predecessors and transforming it into a novel creation. This seed of an idea, nourished by the spirit of open collaboration and the genius of past innovations, sprouted into an open monetary system rooted in transparency and decentralization. 

Bitcoin’s gift was more than just transparency and decentralization - it also brought us self-custody. The concept of self-custody, both in terms of money and data, is a fundamental pillar on which we are building the future. With Bitcoin, individuals are granted the power to become their own bank, and to hold and control their financial assets without the need for intermediaries. This shift does not merely redistribute power; it redefines it, marking a departure from traditional banking systems and ubiquitous financial surveillance, towards financial autonomy and personal sovereignty. Self-custody extends beyond finance into the realm of data, a commodity growing in value in our increasingly surveilled world. With the rise of decentralized technologies, individuals are empowered to control their own information, decide who has access to it, and to shape their digital identities. This capacity for self-custody is a potent symbol of individual autonomy and security in the digital age. It reflects a world where individuals are not just passive consumers but active participants, equipped with the tools and knowledge to navigate, and indeed shape, the digital currents of our time.

Today, more than 14 years since the idea of Bitcoin was published, the importance of open systems and collaboration is more of a necessity than ever. Governments across the world have boundless ambitions to control the flow of information, money, and ideas. But we, the people of Bitcoin, need no convincing of that. It is in our nature to build (and argue) in the open. We have open proposal systems - BIP, BLIP; we collaborate on specifications - BOLT, WebBTC, LSP spec, and create new open protocols for open sharing of information - Nostr. The only thing we’re not open to is expanding the block size.

Open systems require open tools 

We don’t build in to open because it's easy, we do it because it's the only way. Ability to be in control of your data, to know what is running on your computers, and most importantly, what and who is operating your money is key to escaping the tyranny of big tech data siloes, surveillance capitalism, and failed monetary systems. 
Bitcoin is open-source money. And so should be the tools and projects built around and on top of it. Building a new monetary system is just too important not to be built in the open. And tons of companies and projects have already proved that it is not only possible but actually beneficial to do so. From amazing companies like Breez and Alby, trailblazing on Lightning network; hardware wizards like BitBox and Trezor, providing open source hardware wallets; projects like lnbits and btcpayserver, building open solutions for merchants and builders everywhere; Galoy, offering solutions for Bitcoin communities around the world; to communities like bolt.fun and bitcoin.design which provide space for collaboration, education and sharing of ideas. We can’t possibly list all of them, the ecosystem is way too vast by now. (but we still tried - check out lightning landscape)

bolt.observer started as a monitoring tool where the SaaS approach makes a lot of sense. We spent a lot of time talking to our users, getting to know their problems and how they are tackling them, and gathering feedback from existing businesses on the most needed solutions and best practices out there. 

As time progressed we moved from simple reachability monitoring to providing liquidity alerts to our customers. That marked the beginning of our path towards building our automation engine driven by workflows, enabling users to streamline their liquidity management with LiquidOps. However for these tools to work users needed to share their private data with us. Despite having fine controls in our agent over how much and how precise data to share with us, the fact was they still had to share some of it to make the tools usable. And we decided we’re gonna do something about that.

In the coming months, we will be open-sourcing LiquidOps, enabling people to self-host our tooling and stay in charge of their own data. The decision was simultaneously hard and easy - it will take some of our very limited resources to make the transition from SaaS to open source, but it's a sacrifice we’re more than willing to make in order to enable people more sovereignty and privacy. It is the Bitcoin way and we’re excited to do it. We believe that the lightning network is the bedrock of a new financial infrastructure built on top of bitcoin, and as such a critical part of it. And we are committed to doing as much as possible to help make that a reality. 

With LiquidOps open-sourced and our agent-based architecture, companies will be able to deploy lightning node automation even in the most secure environments. The architecture empowers deeper isolation of nodes and credentials never leaving them, while keeping the user interface easily accessible to employees. We will keep improving our plugin system to enable you to expand and customize your lightning automation.   

While you are waiting for the open-source version of LiquidOps you are welcome to test existing functionality on our platform, check out Lightning Vault - secure lightning credential storage or build something cool with our go-runes library.

To stay up to date with new developments and news follow us on Twitter, Linkedin or Telegram.

We have developed a workflow-based lightning node automation solution to simplify the process and eliminate the need for manual intervention. The solution simplifies the connection of various applications and services by harnessing the power of conditional logic and custom triggers, enabling seamless interactions and task execution.

So, how does this make liquidity management easier? We have added a boltz plugin to our agent, allowing automatic swaps execution. We have been using their services for a long time and wanted to enable our clients to transform their business rules into streamlined workflows, while automating liquidity management with submarine swaps. The process is simple: configure automated rules to manage your liquidity with swaps.

Submarine swaps

Submarine swap is a particular type of atomic swap between on-chain and off-chain funds. This means it does not bear counterparty risk. Either the swap will go through entirely, or nothing will happen. It works in a similar trustless fashion as payments on the lightning network via HTLCs (hashed time-lock contracts). In practice, if the exchange is dishonest, your funds might get locked up for a while, but you will not lose money.

There are three common scenarios where submarine swaps can be used to address liquidity challenges in Lightning Network channels:

• Low inbound liquidity: Perform a reverse submarine swap (swap-out) to push funds to the other side of the channel and receive on-chain funds.

• Low outbound liquidity: Perform an on-chain transaction, and the swap service provider will pay your invoice to refill the channel, also known as a swap-in.

• Low channel inbound liquidity: Perform a reverse submarine swap (swap-out) to pay only through specific channels.

In practice, an operator initiates a submarine swap when the liquidity is too low. This is a manual process, and often, it implies a delay between the depletion of a channel and the detection of that state, making the channel unusable for some time. No one really wants to spend 24/7 behind a node to check when a swap is needed.

Here comes the idea of an automated swap, aka auto swaps.

What are auto swaps?

An auto swap is a proactive action configured by a node operator in anticipation of potential liquidity issues in the future, aiming to restore liquidity to a predefined level. It is executed automatically when the specified trigger conditions are met.

Unlike regular swaps that involve a fixed amount, auto swaps are designed to maintain a desired liquidity level as a reference. Auto swaps can trigger multiple swaps to restore liquidity to the desired level, ensuring that the channel or node remains adequately funded. Here is an illustration of 2 auto swaps-out executed as soon as the trigger is activated:

If you feel like automating some of the most time-consuming tasks, we provide an explanation of a workflow creation with swaps in this thread.

Create your first workflow

Context of high on-chain fees

You might be wondering if auto swaps can still be used in the context of skyrocketing on-chain fees since submarine swaps require at least one on-chain transaction. The answer is yes, and we can keep these fees under control even when the mempool is crowded.

The agent has been thought to allow granular configuration of actions with opt-in flags, and one option allows the swap cost control. To achieve this, configure the agent with the —maxfeepercentage flag to set an upper limit on the cost of a swap. For instance, setting —maxfeepercentage to 1% means that the total cost of an 8M sat swap, including Boltz fees, off-chain fees, and on-chain fees, will never exceed 80k sats.

For more details on swaps cost breakdown, we provide examples of fees estimation for optiondifferent use cases.

What’s next?

The journey doesn't end here! We're constantly striving to enhance our services with optionnew plugins, allowing you to streamline liquidity management and execute your strategies. The Lightning network industry is still in its early stages, and we need to foster many use cases to answer the needs of our growing community. Therefore, our agent is equipped with a plugin system that enables you to create custom workflows with triggers and actions.

We value your input and would love to hear which plugins you believe should be given priority. Your feedback is incredibly valuable because it enables us to tailor our offerings to meet your needs and provide the best possible solutions to the community.

Leave a comment

Feel free to connect with us on Telegram and Twitter, or schedule a meeting here to share your thoughts.

LiquidOps workflows are available to everyone - all you need to do is sign up on bolt.observer. Discover how to activate it for your node in our documentation.

Our emphasis on observability stems from its significance in decision-making. Being aware of events (i.e., observing them) and having access to historical data to identify trends empowers you to make more informed choices. As you consistently make similar decisions, they evolve into practices and eventually mature into standard operating procedures. This cycle is crucial in driving success and maintaining a competitive edge.

Whether it's businesses or individuals, everyone has a unique approach to handling various aspects of their lives, from morning rituals to critical business operations. Ultimately, these are all steps designed to achieve specific goals based on certain events or triggers. These could range from the simple ring of an alarm clock to more complex scenarios like your shop ceasing order processing due to a lack of inbound liquidity. The key is to identify and respond to these events in a manner that supports your goals and maintains efficiency.

As a user of our platform, you're likely familiar with the various alerts related to your node's liquidity and reachability that help you stay informed about its status. We're thrilled to announce the release of two new features on our platform, taking your node management to the next level. These additions will not only keep you aware of what's happening with your node but also enable you to automate actions for more efficient management. Get ready to experience a seamless and streamlined approach to node operation.

Workflows

We're excited to announce the launch of our cutting-edge workflow-based lightning node automation software, designed to revolutionize the way you manage your node operations. Inspired by user-friendly platforms like Zapier.com and IFTTT.com, our new software offers a host of benefits that will undoubtedly elevate your automation game.

This innovative approach simplifies the process of connecting various applications and services, enabling seamless interactions and task execution without the need for manual intervention. By harnessing the power of conditional logic and custom triggers, you can create tailored workflows that cater specifically to your needs, optimizing the way you manage your lightning node.

What sets our software apart is its accessibility. Even if you're not a technical guru, you'll find it easy to automate your processes, fostering a more productive and adaptable work environment. With our new lightning node automation software, we're confident that you'll experience improved efficiency and the freedom to focus on what truly matters.

Presently, all monitoring alerts available on our platform can serve as potential triggers for actions.

While we already support a variety of notification delivery integrations, we're in the process of adding a comprehensive set of actions that will encompass all your node operations. The first of these new actions is being released today, so continue reading to learn more about the exciting enhancements we're introducing.

In conjunction with the new workflows, our agent has also received significant upgrades, including the introduction of its own plugin system and the debut of its first plugin. The driving force behind the agent plugin system is to empower you, our users, to effortlessly extend its functionality while still reaping the benefits of our platform's features – the data we provide, monitoring, and workflows. This combination ensures a seamless and efficient experience in managing and expanding your node operations.

Automated liquidity management (and more)

Introducing the first action plugin for our agent, in collaboration with the esteemed folks at boltz.exchange. As long-time users of their services, we wanted to gift our clients the capability to transform their business rules into smooth workflows, all while witnessing the automation of liquidity management.

The concept is straightforward: configure automated rules to manage your liquidity, and then redirect your attention to developing your own projects. Rest assured, bolt.observer will take care of node management, so you can concentrate on what truly matters.

What makes our Auto Swaps particularly special is the ability to split swaps into multiple jobs, either in case where your swap size is too big for limits of boltz.exchange (0.1BTC at the time of writing) or liquidity to your node too small to send the full amount. With Auto Swaps you can rest assured that LiquidOps will do everything possible to execute the swaps for you.

This is just the beginning of what we have in store for you. We're continuously working on adding a wide range of new plugins to our agent, empowering you to automate liquidity management using any strategy you prefer, or even a combination of multiple approaches.

In the near future, we'll be expanding our support to include additional swapping providers, such as Loop, Deezy, and more. Moreover, we'll be introducing features like automated channel opening and closing, as well as fee management. Stay tuned as we roll out these exciting new capabilities to enhance your experience.

We understand that the vast array of unique use cases employed by you, our incredible node operators, is too expansive to cover entirely. That's why we've designed our agent's capabilities to incorporate a plugin system, enabling you to create custom actions while still benefiting from our workflow capabilities and data sources.

We're eager to hear your thoughts on which plugins you'd like to see rolled out first, and what innovative actions you're considering implementing. Your feedback is invaluable in helping us tailor our offerings to better suit your needs and ensure we're providing the best possible solutions. You can reach out on Telegram and Twitter or book a meeting here.

LiquidOps workflows are available to everyone while in open beta - all you need to do is sign up on bolt.observer. Discover how to activate it for your node in our documentation.

To stay up to date with new developments and news follow us on Twitter, Linkedin or Telegram.

Financial reporting is a critical tool to provide valuable insights into the financial health of a business. The primary aim of financial reporting is to offer useful information to external stakeholders, including investors and creditors, to enable them to make informed decisions that align with their financial goals. Moreover, leaders and management teams heavily rely on four main financial statements to steer their businesses toward success:

• Balance sheet

• Income Statement

• Cash flow statement

• Statement of retained earnings

With the continued growth of Lightning Network adoption, businesses are constantly seeking ways to enhance their services to meet the ever-evolving demands of their clients. Among the various needs of lightning node businesses, measuring the financial viability of their activities is of utmost importance in ensuring the sustainability of their operations. In this regard, we sought to envision the integration of Lightning Network operations into existing financial statements, starting with the balance sheet.

The balance sheet

The goal of a balance sheet is to report the position (assets, liabilities, and shareholders' equity) of an accounting entity at a given time. As shown in Table 1, transactions are classified  in a standardized format called accounts :

As a general rule of accounting, Assets = Liabilities + Shareholders's equity.

Nodes can drive revenues from at least three activities; routing, financial, and business.

• Routing activity refers to forwarding a payment from a sender to a recipient. Nodes will charge a fee for forwarding other users' payments.  

• Financing activities are the functions of a business related to lending and borrowing money. For LN, buying and selling liquidity is currently the closest activity to be considered as a financing activity.

• Operating activities are the functions of a business directly related to providing its goods and/or services to the market. The company's core business activities include manufacturing, distributing, marketing, and selling a product or service (Bitrefill, Opennode, ThunderHub, Zebedee, etc… ).

A business can perfectly combine all these activities or focus on only one. In this article, the accounting entity would be limited to a node whose primary function is to route transactions. Any other business or financing activity has been excluded.

Let's now dive into this article's core and evaluate how lightning network operations can be accounted for.

Assets

An asset is a resource with economic value that an individual, corporation, or country owns or controls with the expectation that it will provide a future benefit. 

Accounts receivable

Definition: Accounts receivable are the balance of money due to a firm for goods or services delivered or used but still needs to be paid for by customers.

Currently, accounts receivables don't exist on Lightning Network. Overdue bills, bad debts, or terms of payments are concepts that don't apply to a routing node simply because the protocol ensures instant settlements of transactions. However, the situation might evolve if nodes facilitate lending between each other.

In the following figure, we compare two channel leasing methods and their impact on buyer and seller cash flow.

Use Case 1 is an example of a liquidity leasing agreement for a volume of 10 million sats over 30 days. Currently, the seller opens the channel only after receiving the full payment upfront. However, nodes may offer liquidity in the future with alternative payment models, such as recurring payments or subscriptions.

Use Case 2 illustrates a fictitious form of leasing with monthly payments in which the buyer could buy a channel for an extended period. If the buyer defaulted on one of the payments while the channel remained open, it may result in an account payable for the buyer and an account receivable for the seller.

In the liability section, we explore other scenarios that could lead to the emergence of some form of account receivables.

Cash and inventory

Definition: Cash and cash equivalents refers to the line item on the balance sheet that reports the value of a company's assets that are cash or can be converted immediately.

Pretty much everything in Lightning Network should be considered cash. In a lightning channel, Bitcoins represent the most liquid form of money ever created, flowing at the speed of light. In comparison, on-chain funds, yet very liquid, move slower. The block time on the bitcoin blockchain is 10 minutes on average, or rather; the network tries to reach a confirmation within that time frame.

Node operators have several options to manage the right balance between on-chain and off-chain funds by opening or closing channels or doing submarine swaps. Sometimes, part of the on-chain funds will also be kept in cold storage. 

Accounting tends to rank assets by order of liquidity, from the most liquid to the least liquid. If we apply the same rule to a node, the balance sheet will assets section should be organized as follows:

Cash

• Off-chain - immediately available

• On-chain - available after ~10mn

• On-chain - cold storage, available after several hours

Note:  Inventory represents a company's physical goods, raw materials, and work-in-progress. Just like banks, routing nodes don't have inventory. 

Equipment

The largest lightning network nodes can hold up to several hundreds of bitcoins and be connected to thousands of their peers. We could expect a very high infrastructure cost to operate such a wonder, but it's not even required. There is a form of asymmetry between the relatively low infrastructure costs, which approximate just around a thousand dollars a year for a business, and the value a lightning node can operate. Adding equipment value to a balance sheet for self-hosted nodes sounds reasonable, but that amount would be negligible.

Intangibles

Definition: An intangible asset is an asset that is not physical in nature. Goodwill, brand recognition, and intellectual property, such as patents, trademarks, and copyrights, are all intangible assets.

Even though the lightning network doesn't need trusted third parties to work, the number of transactions a node can route will highly depend on the quality of its neighborhood. Over time, several rankings have emerged to highlight a node's age, uptime, and connectivity, but they have yet to turn into monetary value. 

Is the value of a node routing several bitcoins a month more valuable than a node merely routing 100k sats? The obvious answer is yes because it generates more cash flow, but in the future, we could see accountants value the brand of a node with other metrics and reputational scores. 

revenues

Liabilities

Accounting practices involve managing financial transactions and preparing financial statements that accurately reflect a company's position. One key aspect of accounting is the treatment of liabilities, which are amounts owed by a person or company to another person or company. Historically, debt emerged as a means to finance activity and growth, allowing businesses to expand beyond their immediate resources. However, with technologies like the Lightning Network, which allows for instantaneous settlements of transactions, the concept of liabilities for routing nodes has yet to emerge. 

But as the future unfolds, the professionalization of node operators may lead to more acute capital needs to fuel their growth. The emergence of bitcoin lending services, provided by other nodes or dedicated companies, as a form of short-term or long-term debt may become a reality. If this future unfolds, several new accounts will appear on the balance sheet of a node operator borrowing and/or lending capital.

Shareholders´ equity

Shareholders´ equity, also referred to as stockholders' equity or owners' equity, refers to the assets remaining in a business once all liabilities have been settled. This figure is calculated by subtracting total liabilities from total assets.

The owners' investment of cash and other assets in the business is called contributed capital. The amount of profits reinvested in the node operations, which will not be distributed to node owner(s), is called retained earnings. Both of these accounts can be translated to the world of lightning nodes.

Perspectives

Based on the observations developed in this article, we extrapolated the balance sheet of a fictional routing node. As shown in the following figure, we compared the current nodes' balance sheets and possible evolution that could involve some level of liability.

As shown in the 2030 scenario, the balance sheet could include many more accounts as the complexity and variety of operations grow.

Currency

Financial reports for businesses are typically denominated in the currency of the country in which they are incorporated. However, all financial statements should be denominated in bitcoins for routing nodes. Nevertheless, lightning businesses will likely keep using fiat currencies as their accounting currency for various activities, including selling products and services, financing, and routing.

Time span

Financial statements are provided on a monthly, quarterly, or yearly basis. However, seeing the nature and the speed of transactions on a lightning node, it would make sense to report activity on a daily or even hourly basis for balance sheets. For traditional businesses, a week represents the short term, but if we compare it to lightning speed of operations, a week could be seen as long-term.

Conclusion

As Lightning Network grows, there is a pressing need to adopt some form of standardization of financial reporting techniques that can provide insights into nodes' financial viability. As the industry crosses the chasm, current accounting norms must help lightning operations become more understandable to a broader audience.

This article explored the balance sheet, one of the four financial statements, which provides a snapshot of a company's assets, liabilities, and equity at a given time, and how it can be adapted to a Lightning Network node. Interestingly, we observed that the balance sheet of current nodes doesn't hold any liability, and a node operation is 100% equity based. That situation may change in the future, leading to capital borrowing/lending between nodes.

This field of financial accounting for lightning operations remains uncharted territory, and it will probably require several years before reaching a form of standardization between nodes, businesses, and accounting bodies. Eventually, efforts of standardization should allow the on-boarding of the early majority of accountants and financiers to Lightning Network.

In the next episode, we will talk about the income statement.

Just like biodiversity is critical to the health and longevity of the natural world, a diverse ecosystem of technology implementations ensures that the system can withstand the loss of any one implementation and continue to function. This diversity also drives competition and innovation, leading to better products and services for users.

In the context of the Lightning Network, having multiple implementations is essential for its success. If all Lightning nodes were running the same implementation, the network would be highly vulnerable to bugs, security flaws, and other problems that could potentially bring it down. With multiple implementations, this risk is reduced and the network can continue to function even if one implementation experiences issues.

The availability of multiple implementations has spurred innovation and competition in the Lightning Network ecosystem. Developers are constantly working to improve the performance, reliability, and security of their implementations, and this competition benefits users by providing them with access to a better and more dependable Lightning network.

The Lightning Network has the potential to make Bitcoin accessible to the masses by making it cheap and fast to use for everyday transactions. However, to realize this potential, it must be reliable, secure, and user-friendly. The presence of multiple, high-quality implementations is critical to achieving these goals.

That's why we're thrilled to announce our support for another implementation in our recently released LiquidOps product. We've added Core Lightning to our stack, now we’re supporting both major implementations, allowing more clients to take advantage of our full suite of features. This gives them insight into their node operations, liquidity, and reachability. Register on bolt.observer beta (still free till end of the month) to check out our offerings.

To make all this work we of course had to extend support of core across all our tooling, namely adding it to Lightning Vault and developing additional tools that helped us dive into core ecosystem, more on that will be explained in our next blog post.

To stay up to date with new developments and news follow us on twitter, linkedin or telegram. For more info about our open source projects check out our github.

This article is part of a more extended series wherein we explore the Lightning Network's evolution and propose an in-depth analysis of liquidity services. The research follows a top-down approach by providing an overview of the Lightning Network industry and focusing on specific lightning liquidity projects, products, or companies that have recently emerged.

The Lightning Network Industry

The Lightning Network has evolved from reckless to professional within a few years. From an ecosystem to industry, from a group of enthusiasts to communities and entire countries.

The Cambrian explosion of projects and companies crafted over the first years of its life is one of the most distinctive signs of nascent ecosystems. But what is an ecosystem?  

Even if this definition is hard to give from an economic perspective, an ecosystem generally refers to a network of interdependent elements or organisms that work together to sustain a balanced system. In the context of the Lightning Network, an ecosystem would refer to a community of developers, users, and businesses that use the network to facilitate fast, low-cost, and private transactions on the Bitcoin network. This community is self-sustaining, with users and developers contributing to the network through node operation and code contributions.

On the other hand, an industry refers to groups of companies or organizations that produce goods or services within a specific market. In the case of the Lightning Network, as the technology matures and adoption increases, businesses and organizations have started to offer specialized products and services to provide even better experiences to their customers.  

This specialization is one of the main driving forces to the emergence of the Lightning Network industry, where businesses' goal switches to service monetization and profit making. 

As shown in the following table, ecosystems and industries differ at several levels of the value chain, from actors' profiles to value creation and funding:

Where should the Lightning Network go? 

One of the first points we should address as a community is whether the evolution to an industry is even desirable. After all, everyone could keep using open-source tools and be happy. Not exactly.

The scenario of services and tools built by independent developers could be viable if Lightning Network limited itself to the community of bitcoiners and an anonymity/tech-savvy audience. In the past, we witnessed similar open-source tools whose adoption never managed to reach a broad audience: 

• PGP was also a brilliant invention with great potential for digital identity and online privacy applications. However, the user experience has never been improved sufficiently to allow an adoption beyond code signature and epic key signing parties.

• Linux kernel was created to provide a free, open-source alternative to proprietary operating systems and has become a preferred solution for professional developers and servers. However, it occupies less than 3% of the desktop/laptop OS market share as of 2022 (15% for Mac OS and 70% for Windows). 

We will all agree that the potential of the layer 2 technology is much larger than a few percents. The companies operating in the payment industry are here to remind us that competition and alternatives already exist. Payment service providers such as Visa, Mastercard, and American express already provide very reliable payments to their customers in most parts of the world. Reversing the network effects and breaching the barriers built over the last 60 years will be challenging if Lightning Network folks don´t channel their efforts.

We all want the Lightning Network to succeed and become one of the main - if not the main -  payment networks. To make that vision come true, the industry should enter a virtuous circle in which builders design better products, leading to more users, VC investments, and more builders again, in that order. As the wheel spins, every actor focuses on providing specialized services that will increase the sophistication of the whole industry.    

So going back to the first question, do we need Lightning Network to evolve from ecosystem to industry? Yes. It is not only desirable, it is essential. And we are getting there!

Key factors: How?

A combination of factors, including technical features, user experience, and overall market conditions, will likely drive mass adoption of the Lighthing Network. 

• Technical features, such as fast transaction times, low fees, security and reliability, will be key differentiators as users seek solutions that meet their needs for fast and affordable payments. As previously discussed in our article on observalibility, many efforts are still required at the network level to reach high throughput and reliability. Additionally, the ability of the Lightning Network to offer private transactions will attract new users. 

• User experience will also play a significant role in driving the adoption of the Lightning Network. If the network is easy to use and provides a seamless user experience, this will undoubtedly lead to increased adoption. The availability of user-friendly wallets and applications that make it easy for users to access and utilize the network will be primordial. 

• As we have seen many times, market conditions significantly increase awareness. NgU - Number goes Up - refers to the fact that Bitcoin, unlike the internet, is a tradable technology whose price depends on demand and supply. In a context of limited supply and growing adoption, the price is meant to go up, a.k.a. NgU. More people will hear about Bitcoin during the next bull market and seek solutions to meet their needs. By then, Lightning Network will have solidified even more.

• Last, but not least, capital. Investment is a critical component of any digital industry's growth as it helps fund the ongoing development and improvement of the network, support its growth and reach, and ensure its competitiveness in the market. Lightning Network needs to attract more private money from angel investors and VCs and unleash its disruption power.

Perspectives

Within a bit more than 7 years, Lightning Network progressively transitioned from a concept to an ecosystem and a nascent industry. As shown on Lighthing Landscape, builders and enthusiasts have already delivered hundreds of projects and companies during the first years.

However, the risk of seeing technologies not crossing the chasm is real. It has already happened, and it will happen again.

The evolution of Lightning Network from an ecosystem to an even more structured industry is essential to reach mass adoption. Improving technical features and user experience will be helpful, especially if it coincides with a bull market. Also, the industry's future relies on more investment, which will fund its development and support its growth and competitiveness in the market.

While we would all prefer to host our lightning nodes in our fortified citadels the reality is that this is not always possible or feasible. From the stats, more than half of network capacity is hosted on either AWS or GCP, and we at bolt.observer are among those.

While having your keys on a 3rd party cloud is far from ideal there are a lot of other risk factors one needs to consider while developing applications around lightning network. You can keep your keys safe but if your macaroons get exposed you can still lose your funds. With the rising tide of new projects in the space this is more important than ever.

Secure management of secrets is a big field in IT, and many solutions have become an industry standard in the broader IT ecosystem. One of the principles for tackling this problem is using rotating secrets which solves at least two problems. First, everyone sharing the same password, it is written down and possibly even committed in source control repositories. The second one is that in the case of your application being hacked or your credentials being leaked somehow is that they are short-lived.

With this in mind, we developed a tool for our internal use at bolt.observer. We are releasing it into the wild today to help other companies and individuals in the space build better and more secure applications - introducing Lightning Vault.

Lightning Vault is a cloud secrets manager for lightning node authentication tokens on AWS. Currently, it supports macaroons (lnd) but we're expanding it to runes (cln) in the near future.

How it works

Lightning vault utilizes AWS Secrets Manager to store your macaroons. You can read more about the security model of it here. Vault is essentially an API layer that sits on top of Secrets Manager to provide macaroon issuance and rotation. It is written in Go and currently supports 3 different time horizons for secrets - 10 minutes, 1 hour, and 1 day.

An example of how you'd design your infrastructure to incorporate Lightning Vault:

Privileged cluster consists of several vault instances for redundancy and it’s the only service that has access to Secrets Manager. It is only accessible on the internal network with only API exposed to the application cluster, thus separating access to secrets and minimizing threat surface.

Usage

The API for Lightning Vault is simple and we included examples in python and Go, with internal Go library for interacting with Lightning Vault.

Vault supports multiple authentication methods that might fit into different scenarios and use-cases. You can use the standard HTTP Basic Auth or make use of Amazon’s Signed Requests to leverage IAM.

Example of interacting with Lightning Vault, how to run and configure it can be found here.

Future

We created this tool for our internal needs but it could easily be expanded to support different cloud providers like GGP Secret manager or hardware HSM solutions to serve different needs. If anyone would like to integrate it with a different storage please reach out, we’re happy to assit. All pull requests and comments are of course welcome.

What we would like to do today is tell you a bit more about a new product we released in beta at Adopting Bitcoin last year - LiquidOps. 

What LiquidOps enables you to do right now is to monitor liquidity in your channels and configure advance alerting options for various scenarios as your needs vary depending on what your business is, for example:

• If you’re a merchant you generally mostly care about inbound liquidity so people can pay you for goods and services

• If you’re an LSP or a routing node you need to have good overall liquidity on both sides so you can route payments

By bringing more visibility to your liquidity and its historical movements, you can see the trends and with that improve your operations, predict future problems and optimize your capital deployment.

There are many reasons for payments to fail - from hardware node failure your node, lack of liquidity, problems with your peers, or failures somewhere along the route. Observing what is happening with your payments carefully and reacting to it before it becomes visible to your users can significantly improve user experience and reliability. For example, if you see that your successful payments now take more attempted routes than they historically did that could indicate that your neighbors have problems with liquidity and your future success rates may drop, thus impacting your service and its users. By being aware of that early you can mitigate this by opening new channels.

What we are building with LiquidOps is a smart platform where you can define how your node should be behaving based on your business rules and with it ensure that you can focus on building your business and not just operating your nodes.

Currently, LiquidOps offers you several ways to improve your node operations, mainly (for now) by adding extra visibility and automating your monitoring.

You can for example:

• monitoring the balance of your channels and getting configurable alerts on what you want do to, for example:

  • at 15% outbound left, message the team on slack so they are aware of it

    

  • at 10% inbound left, trigger a webhook that tries to rebalance the channel

  • if it falls below 10% trigger do a swap on boltz to ensure business continuity

• monitor the status of your important channels and be notified if they become disabled or closed

• see historical charts of liquidity movements in your channels

  

• get alerted on the overall liquidity state of your node, how much inbound or outbound you have, for example, you're a merchant with several inbound channels and you primarily care that you have enough inbound so your clients can pay you, and when that is drained you either try to swap/rebalance, or just purchase a new inbound channel

  

With the current feature set of LiquidOps, we are expanding the monitoring capabilities of our platform, from reachability of nodes and data exploration to your node's liquidity. However, this is only the beginning. At the moment we offer lots of integrations in terms of chat platforms, incident and monitoring solutions, and simple things like email. To see what are all the integrations we are currently supporting see our integrations documentation.

What is coming next is integrations with existing platforms for swaps, purchasing liquidity from marketplaces, automatic rebalancing, and much more. All are based on your desired rules and tailored to your specific use case or concerns. Our goal is to automate away the complexity of node management and enable you to forget that lightning network liquidity was once something you had to pay attention to.

LiquidOps is currently in beta and free to test for everyone - just visit our site and register. For more information about our platform check documentation.

We are looking for feedback from our beta users - reach out to us over twitter, telegram or email.

By introducing payment channels in 2009, Satoshi Nakamoto already foresaw the limits of Bitcoin in its initial version as an efficient payment system at large scale.

source: github.com

However, it took a few years and several evolutions of the concept of payment channels to finally get to the current version of Lightning Network, as introduced in Poon and Dryja's whitepaper in 2016. Since then, Lightning Network adoption has grown steadily to reach a network of over 17k public nodes and a total capacity of 5000 BTC.

Bitcoin layers

The fact that Bitcoin is organized in layers can be confusing to many. However, Bitcoin is a protocol, and like TCP/IP before it, it is organized in layers. TCP/IP specifies how data is exchanged over the internet. In contrast, Bitcoin specifies how value is exchanged over the internet of money, with the power to rebuild the entire monetary and financial systems on more a robust foundation.

• Bitcoin layer 1 is characterized by an unequaled level of reliability and security of its transactions. To date, Bitcoin has performed more than 750 million transactions with almost no downtime events. Yet, the number of transactions per second, or throughput, remains limited compared to centralized payment solutions.

• The second layer, a.k.a Lightning Network, significantly improves the scalability of Bitcoin layer 1. It has been created primarily to provide faster and cheaper transactions, while benefiting from layer 1’s powerful decentralized security. But do we experience the same level of reliability for off-chain payment and on-chain transactions?

We have to face reality; Lightning Network doesn't yet allow the same level of reliability as current payment systems or Bitcoin on-chain payments. It is still pretty common to experience failed, or unusually long, payments. Nevertheless, Lightning Network presents many other advantages compared to existing payment service providers that make it particularly attractive:

The private nature of Lightning Network prevents any actor from obtaining precise information on the number of transactions or the reliability rate of the entire network, but every node operator can do it at his level. And this is where things get actionable; we need to run more reliable nodes to build a better network.

Areas of improvement

To match or even exceed the performance of existing payment solutions, we identified several areas of improvements:

Reachability

If we want to check the performance of a node, the first step is to make sure it is reachable. How? Our monitoring solutions offer a set of checks to monitor the status of your node:

• TCP connectivity: basic tcp check to see if your node is reachable over internet (ipv4 and ipv6).

• TOR connectivity: basic tcp check to see if your node is reachable over Tor network.

• Lightning connectivity: checks run on multiple nodes positioned in different parts of the network to ensure connectivity and prevent false positive alerts.

The idea is to receive an alert when bad things happen and to help you maintain the continuity of your operations.

Latency

The success of a transaction depends on several factors, but latency is a parameter of primary importance.

In a previous tweet, we provided an analysis on a sample of +17k public nodes and showed the impact of connectivity (TCP or TOR) on the latency. The average latency of TOR nodes is significantly higher than that of clearnet nodes, which also highlights the trade-offs between privacy and reliability.

Explorer provides free access to latency for several thousand public nodes to allow any operator to test the latency of its neighborhood before connecting or to monitor existing peers.

Connectivity

On a sample of +18k nodes, we analyzed the minimum distance, or shortest path, required for each node to reach another node by obtaining the full graph of the network.

In that sample, we see that most nodes can connect to their peers within 3 or 4 hops. Since every node can potentially become a source of problems, the longer the distance between the sender and recipient, the lower the transaction's reliability. We designed our tools to offer a better understanding of a node’s neighborhood and help node operators to be better connected.

With Explorer, node operators get a chance to look at the graph from the perspective of their nodes. Their node becomes the “reference node”,i.e the center, and all other peers are organized from the reference in number of hops.

Liquidity

Liquidity is an essential parameter for most nodes but does not manifest similarly for all the nodes. On the one hand, low-capacity nodes generally have a higher outbound than inbound liquidity. On the other hand, high-capacity nodes tend to attract inbound liquidity. All nodes aim to keep their channels balanced to maximize the likelihood of successful payments.

Maintaining liquidity in channels can quickly become complex, especially for nodes with many channels. Liquidity has become so vast that it requires a more in-depth analysis of the problems and solutions in place and will result in a dedicated article.

Conclusion

The steady growth of nodes and capacity remains a very positive sign for the network's health and the adoption of Bitcoin in general. However, to reach mass adoption, the community needs to prove the superiority of the lightning network compared to existing payment systems. How? By building even better apps and services to provide private, faster, cheaper transactions and also by matching the level of reliability and UX that consumers already experience on existing payment rails.

The low cost of lightning transactions is already a decisive advantage, but we must improve reliability. Without better reliability, lightning probably can't cross the chasm and will impede the development and adoption of other layers.

bolt.observer wants to accelerate lightning network adoption by removing node management complexity and making it simple and accessible to every business. Using the right tools helps you be a more efficient node operator and gives you more time to focus on serving your clients.

Make sure you check out bolt.observer and feel free to reach by email , Twitter or Telegram for any question.

Share

We at bolt.observer like data. What we like even more is using data to help us make better decisions, improve our processes and teach us something new or interesting. 

Deploying new bitcoin into the lightning network can mean a daunting decision - depending on your goals your optimal channel peers can be significantly different. The steady growth of the lightning network means that we have more and more choices, and picking the right node for your precious bitcoin is no easy feat with close to 20k nodes in the network. With Explorer you are able to filter nodes in the network by many different parameters - from basic ones like the number of channels and total capacity to slightly more advanced ones like median and average channel sizes, fee structures, or connectivity types. 

But we didn’t want to stop here. We wanted to put our users (well, their nodes) in the center of attention. Using our reference node filter you can explore the network from your (nodes) point of view, enabling node operators to observe how nodes close to them look and behave.

We developed Explorer partially to solve our internal needs for deployment of our monitoring infrastructure, but mostly because we love exploring lightning data (as you might have guessed from our #lightningfact twitter series).

Explorer

Explorer gives you the ability to explore lightning network data with various filters and thus enabling you to think about it more analytically. Besides standard parameters provided through gossip (channels, capacity, fees, etc) you can also use many of our aggregates (average/median/maximum) or data that we obtain by crawling the network ourselves - for example, channel size limits. More of those will be announced in the following weeks.

When visiting https://bolt.observer/explorer you are presented with this advanced search form:

A list of all available parameters that can be used in filters can be found in our documentation. For each of the parameters you have three available conditions with which you can narrow down your searches precisely:

• Less than

• Equals

• Greater than  

The only exception to this is supported communication options - ipv4, ipv6, and tor.

Let’s explore some ideas on how we can use various filters and what information can be learned from their results.

Hops

With our reference node search, you can easily see what kind of nodes you have in your neighborhood, their inbound and outbound fees and capacities. This can give you better insight into what is happening around you, and how similar or different you are from your neighbors. It also enables you to see how much of the network you can reach within a certain number of hops - showing you how well connected you are. A lower number of hops to reach the majority of the network means that generally, your payments could/will be faster and more reliable (more hops = more potential problems).

In our previous article, we talked about the concept of the neighborhood. To quickly remind you what we meant by that - neighborhood consists of nodes you have channels with (first hop), and nodes that they are connected to (second hop). If you feel very adventurous you can also include nodes that are 3 hops away from you but by then, if you have more than a couple of channels, you will already cover the majority of current nodes. 

Connectivity

As I’ve already mentioned in our previous article - how a node communicates with the rest of the network, mainly tor or clearnet makes a difference. While privacy gains by using tor are significant downsides are higher latency and lower reliability of the network. This tradeoff means that depending on your use case and threat model you might want to prioritize opening channels to nodes that are using clearnet connections (either ipv4 or ipv6) over nodes that are using tor. Without Explorer, you can easily filter out nodes by their advertised address types.

Capacity

Sending large(er) payments requires channels with sufficient capacity over the entire path (not accounting for MPPs) which means that opening channels to nodes that have sufficiently large channels will make your life easier. In Explorer we offer filters for three channel parameters:

• Average channel size

• Median channel size

• Maximum channel size

Let's take a look at River Financial node as an example:

By comparing all three numbers you can gain insight into how their channel size distribution looks and make more informed decisions about where to deploy your precious bitcoin. 

An additional useful data point is the minimum channel size requirement by a specific node. In River’s example, this is set to 1 million sats which means that generally, you can expect all channels to be at least of this size (depending on when the limit was configured smaller channels can exist). 

Fees

Last but not least is fees. We all want to earn them, but we prefer not to pay (too much) of them. With Explorer, you can find potential channel peers that fit your needs, for example finding nodes that support zero base fee movement. Same as with channel capacity you also have the ability to filter outgoing or incoming fees by three parameters:

• Average fee rate/base fee

• Median fee rate/base fee

• Maximum fee rate/base fee (outgoing only)

We’ve seen several examples of how we can use network data and filtering to find nodes that match our desired criteria, but there is another side to Explorer that I’ve mentioned in the beginning.  If you are anything like me, you are a curious individual with a deep interest in the lightning network, then you might also enjoy Explorer just for the sheer ability to explore this great invention we call lightning network from a data perspective. For example - did you know that about a third of the network is just single channel nodes? I invite you to find something interesting yourself and share it with us over Twitter!

Lightning network is open for everyone who wants to participate as long as they have an internet connection. Having an open distributed payment network doesn't come without its own complexities, and while the reasons for them, privacy and openness,  make the lightning network good, we must be aware of them.

What defines a good payment network?

The first one is obvious - the ability to transfer value. But being able to transfer value does not mean you want to spend 3 minutes staring apologetically at your barista while you figure out that your private node is down, switch to a secondary wallet and hope that they do a better job than you of keeping the channels balanced, wait for your wallet to find a path to this coffee shops node that actually works and then finally pay for what is by now only lukewarm coffee. This brings us to two other vital properties - predictability and reliability.

We want to be reassured that our every payment will go through. Nobody wants a lightning network equivalent of “sir, your card was declined,” which is reliability, but we also want to have a predictable speed with which it works so we are not forced into unnecessarily long social situations that we're all avoiding after the last two years. Let's define both of those properties a bit clearly.

Reliability is an ability of a system to perform a function without failure. It is also one of the key properties of any payment system we'd like to use. Standards of reliability in value transfer were set with cash. It works every time and everywhere. Everything invented later is just trying to get close to it. We all agree that the lightning network as a whole is an excellent piece of technology, but for it to replace a significant portion of the world's payment volumes, reliability will have to be on top of our minds.

Predictability is a system property that enables the user or machine to rely on the expected outcomes of a system, given its current state. But more importantly, we think it's crucial for adoption and user experience. Users generally expect a better experience if they are going to switch to new technology or platform. And while lightning payments really can be lightning fast, that is not always the case - your or your peer's liquidity might be lacking, your wallet might need a bit longer than usual to find a route etc. With improved visibility and better, more informed pathfinding, this can be a thing of the past.

Above sets the stage for the premise of this article - observability of the lightning network. For the purpose of this article, we'll focus on the above-mentioned properties and leave others for another time. 

What is this observability you are talking about?

The origins of the word observability started decades ago with control theory, but in more recent times, it is increasingly applied to distributed IT systems and their performance improvements. In IT systems, we use different types of telemetry data - metrics, logs, and traces, to provide visibility into our systems and enable teams to uncover complex bugs and eliminate performance bottlenecks. Part of that translates to the lightning network itself - if our node is not working, then no matter how balanced our channels are, how well connected our peers are and how cheap are the fees to our destination, our payment will not go through. But our node(s) working is where this story only begins.

At the start of this article, we defined the ability to transfer value as the primary utility of a payment network. This means that besides our side, the counterparty receiving the value we want to transfer must be working too, and in the case of the lightning network, all hops on our path to the destination as well.

In transmitting payments or routing them, two things matter the most. First, how much capacity do you have available to either accept (inbound capacity) or send payments (outbound capacity), and who are you connected to (open channels). Those two factors primarily define your ability to transact on the network and in the case of routing nodes, earn. But as with many things in life, the devil lies in the details. Therefore, if you want to have the best experience transacting on the lightning network, you should pay a lot more attention to many factors:

• Your node’s positioning in the graph (which depends significantly on your use case)

  • are you a merchant who will mostly transact with users in a small region and maybe pay some local vendors in bitcoin

  • are you an LSP trying to provide global services to clients

  • are you a routing node trying to generate yield on bitcoin

  • etc…

• Your peer’s position and connectivity (and peers of your peers) 

  • your 2-3 hop neighborhood is something that will significantly factor into your payment success rates and pathfinding attempts, thus impacting predictability and reliability

  • if all your channel peers run on residential connections, their availability and reliability can become a problem as people rarely have redundant power lines and internet connectivity at home, not to mention that hardware dies

  • if all your channel peers are geographically close together or all of them run at the same cloud provider etc, you might find yourself without a lot of liquidity when providers experience issues (AWS reported incidents bringing down entire regions or availability zones in the last 12 months), or natural disasters hit, and there are wide power outages

• Higher latency in routing and pathfinding

  • while tor network provides a lot of benefits in terms of privacy and avoiding censorship, it does bring some downsides as well - speed and latency are not exactly great, which can cause a lot of friction if you're doing high volumes of transactions (high latency on routing/pathfinding, timeouts causing locked capital and user dissatisfaction)

  • even with the best connectivity and hardware, roundtrip New York and Singapore or Sydney can be in the order of a couple of 100 milliseconds which adds up. If you end up routing your payment on the around the world trip several times, even the speed of light won't make it unnoticeable

• Peers and neighborhood liquidity (you might be able to push large payments to your peers, but they can only have two channels large enough to handle them)

  • you might have great wumbo channels that are perfectly rebalanced, but what about your peers? Your 10BTC channel won't be of much use if two hops out all the nodes on your path have channels smaller than 2m sats. Sure, you can use MPP but wouldn't you rather plan ahead and make sure you deploy your capital in the best possible way and avoid additional complexity if not necessary?

Above is just an introductory list of important factors to consider, data points to monitor and changes to possibly implement. What we aim to do at bolt.observer is provide you insights into the observable universe that is the lightning network, enable you to remove part of the complexity of running your nodes, improve your flows and give you back some of your precious time to spend it on building new amazing things in this great ecosystem. 

As is with all things, one has to start somewhere. Where we started is a product that everyone running a node can use - monitoring the reachability of their lightning node and, with that ability to transact on the network and route payments. We all consider ourselves great node operators with exceptional skills, but no matter how blessed our lives are, bad things still do occasionally happen. From hardware failure or misconfigured firewall to power and internet outages, no matter what happens, knowing that it happened as soon as possible is always a good thing. 

Reachability of your lightning node is the first service we, at bolt.observer, are releasing into the wild, but far from the last. We're gonna be releasing tools making the lives of everyone using lightning, from LSPs, merchants, plebs to sophisticated node operators, easier, providing access to data to give you better insight into the lightning network, help you deploy your bitcoins more efficiently, providing you with real-time monitoring and enabling you to build your solutions on top of our data platform, either by integrating with our APIs or just using our data to make more informed decisions.

Using the right tools helps you be a more efficient node operator and gives you more time to focus on serving your clients. Make sure you check out bolt.observer and feel free to reach by email, Twitter or Telegram for any question. 

If you’d like to read more about our views on financial metrics in lightning network check out our previous article - Lightning network financial metrics

LN unit economics

To illustrate our approach, we took an example of a semi-fictitious channel with the following characteristics:  

• Channel size: 1M sats

• Channel opening

  • The on-chain fee for the funding transaction was calculated based on a size of 1500vB and a fee of 5sat/vB. 

• Channel open and live

  • In our example, we estimate a net total of 80000 sats earned over the channel´s lifetime and include possible rebalancing fees.

• Channel Closing 

  • We make the assumption that the channel balance is the same at the opening and the closing. 

  • The HTLCs will release the local and remote reserves to their owners for a cooperative close. Therefore, reserves shouldn’t be accounted for in the PNL statement or cash flow. Similarly, commit fees are kept as a buffer to close the channel and permit the final closing transaction. 

  • We assume that on-chain fees have decreased to 2sat/vB at the moment of closing, and the channel doesn’t have pending htlcs. Details are shown in Figure  1. 

In this example, the channel has routed enough payments during its lifetime to generate profits. As shown in Figure 2, the amount available at closing is higher than the capital initially locked in the channel. 

Return on Investment

The return of investment, or ROI,  can perfectly help a node operator to evaluate the profitability of a channel by dividing the gross profit by the initial investment, i.e. capital locked, but it doesn't take into account the time value of money. In our example, the ROI would yield a generous return of 7.2% (72050 / 1000000). Even if this rate gives a first level of information, a more sensible approach would be to take into account the channel lifetime and the time when transactions were actually routed. 

Discounted Cash Flow method: the CARR

For decades, investors have been using well-known indicators such as the "Net Present Value" or the "Internal Rate of Return" to measure and compare the effective return of investments. These indicators are particularly well suited for projects when initial investments or project duration are different. 

We adapted these indicators to a channel's unit economics to offer node operators the tools to identify the best-performing channels and allocate their capital efficiently. 

We introduce the Channel Annualized Rate of Return, or CARR, to estimate the performance of an investment in a channel as per the following formula:  

Where:

• NPV: Net Present Value (sats)

• Ct = Net cash flow during the channel´s lifetime (sats)

• t = time of the transaction (seconds)

• T= total lifetime of a channel (seconds)

• CARR (%) = Channel Annualized Rate of Return

By definition, the CARR, or IRR in traditional finance, represents the rate that makes the net present value (NPV) of all cash flows equal to zero in a discounted cash flow analysis, expressed as an annualized rate. The higher the CARR, the more profitable the channel. This formula applies to closed channels to evaluate their actual return or to open channels to estimate the “committed” return. 

A LN channel presents key differences from traditional finance such as a shorter lifetime, a higher speed of transactions, and also more unpredictable flows. For example, while investment analysis usually projects cash flows over months or years, LN theoretically allows a channel to be open for an hour, and payments flow every second. Therefore, as shown in figure 3, our model calculates all cash flow with a unit of time of a second. Also, while a discounted cash flow analysis is usually built on top of semi-realistic models, it is very difficult to predict future cash flows on an LN channel.

To gain a more accurate estimate of the return, we constructed a discounted cash flow whose time unit, in seconds, is shown in UNIX Time and a human-readable format. We considered a channel with a lifetime of 14 months that has seen irregular cash flows as shown in Figure 3. Transactions start flowing a few days after the channel opening and the volume keeps on growing until the closing. Data shared in this model don´t reflect the reality of a channel because no single transaction would be large enough to generate 45000 sats of routing fees at once but we had to simplify the model. 

In our example, the discounted cash flow exhibited a CARR of 6.302%, while the ROI was 7.2%. The differences we observe in these returns can be explained by the fact that CARR method captures the time value of money. Also, we observed that ROI was higher than CARR, but this is not always the case; if a channel's total lifetime is lower than a year, which is frequent in LN, the absolute value of the CARR will be higher than the ROI. Last, if a channel doesn’t route sufficient payments and on-chain fees still need to be paid at opening and closing, then the CARR will go into negative territory.

Conclusion

The purpose of this article was to introduce better financial metrics to evaluate the profitability of the smallest element on the lightning network; the channel. First, we introduced the unit economics of an LN channel, and we provided an estimation of the return on investment of this channel. Then we proposed the Channel Annualized Rate of Return formula to consider cash flows and the time value of money. Finally, the differences between a discounted cash flow calculation such as CARR and the return on investment have been discussed. Specifically, we demonstrated that returns calculated with a discounted cash flow such as the CARR will be more accurate than ROI because the time value of money is accounted for.  

Our intention was to offer node operators better tools to determine whether their nodes are operated efficiently and whether investments in channels are worthwhile. While we focused our efforts on analyzing the unit economics of a channel in this first article, our broader goal is to foster discussions in the LN community to come up with open metrics.