Lightning Network Audit Considerations

Are you a Bitcoin or Lightning Network investor whose portfolio companies have deployed capital to the Lightning network?

Are you an audit firm with Bitcoin exchanges (and Lightning integration) as clients?

Are you a Lightning Service Provider or Node operator?

How are you accounting for and auditing your (client’s) capital deployed on the Lightning Network?

In the wake of the $3 Billion+ FTX fraud, the value of audit services, financial controls, and reporting has never been greater.  And as regulation continues to be introduced, it is never too early to be thinking about how to account for, report on, and audit capital deployed to the Bitcoin Lightning Network.

Professional skepticism and the Bitcoin mantra of ‘Don’t Trust, Verify’ should be applied to capital deployed on the Lightning Network.  And in this context, Layers (formerly Exponential Layers) has introduced new functionality to provide third party, deterministic audit reporting on any node on the Lightning Network.

Sign up for free to build your first two node audit reports here, and please get in touch for additional reports, a custom demo, or to talk about your specific audit challenges.

The Lightning Network is NOT a Blockchain

As its name implies, the Lightning Network is a network graph.  Just as LinkedIn and Facebook have people and “friends” and “connections”, the Lightning Network graph has nodes and channels (channels being the “connection” points and nodes representing other “people”).

Because the network is an evolving graph with data that can change every second, there is no such thing as a single view of the network at a given point in time.  Nodes gossip with one another, transactions propagate across the network, channels open and close, and new entrants (nodes) can enter or leave the network at any time.

This idea of the Lightning Network as a graph and not a blockchain is a feature.  It is what gives unlimited throughput to transactions and allows the properties of Bitcoin as money to scale and have immediacy in its medium of exchange - all fully custodial, native to Bitcoin, and without any other tokens required.

Because the network is constantly in flux, however, this poses a challenge.  How can we provide deterministic network data?  And just as importantly, how can we use this data to audit capital deployed on the network?

Total Transparency vs Total Privacy

Analytics, privacy, and auditability is a spectrum.  On one end of the spectrum, total knowledge and control of every transaction gives rise to surveillance and censorship.  On the other hand, full privacy with no ability to see or understand and track capital allocation leaves uncertainty - and no entity will put meaningful capital onto a network without some level of visibility and assurance on how to account for its flow.

The Lightning Network offers a perfect hybrid approach to these competing ideologies.  On a top down basis, the network can be analyzed to provide upper bounds on capital deployment and third party assurances as to specific Lightning transactions (channel open and closes) occurring on the Bitcoin blockchain.

The Layers explorer shows all of these details of the Lightning Network:

• What are the top nodes on the network?
• Where is capital deployed?
• How are nodes, channels, and capacity trending over time?
• When (and with what transaction) was a Lightning channel opened or closed?

From a bottom up perspective, all of the data about a node is private.  Specific transactions, forwards, sends, receives, and balances within a channel are known only to a node operator.  Again, this is by design and offers important aspects for privacy.

Audit Considerations for the Lightning Network

So how can we account for capital deployment on the network?

Any audit engagement requires reporting on data from the node itself.  Because a node’s data is private, there is no getting around this.  As such, specific information on all activity from a node is required in an audit including:

• On chain transactions
• Channel Balances
• Payments Received
• Payments Sent
• Forwards

Thunderhub, Ride the Lightning, Lightning Terminal, and other platforms provide this information in various ways.

How this information is accounted for, aggregated, and flows through to an income statement and balance sheet can vary depending on the company, the tools used, and the presentation.  The technical approaches and regulation for answering such questions as to what qualifies as income vs an asset (and other considerations) are an ongoing development in many regards.

Taking a balance sheet approach to an audit, however, there are principles we can apply to the Lightning Network:

I) Ownership: does an entity have an ownership claim to an asset?

II) Existence: does the asset exist?  What is its value?

Ownership of Bitcoin deployed to the Lightning Network can be proved cryptographically.  Signing and verifying a message using a node’s private key proves ownership of a node.  Layers has a directory of verified nodes, and other explorers offer similar functionality.  If you would like this functionality built into you or your client’s audit workflow, please reach out.

Proving existence of Bitcoin on a Lightning node can be audited in a number of ways.  Some of the specific methodology may be proprietary to a firm, and certain tools or automated strategies can be employed to help automate the process.  Please reach out to discuss specific strategies.

One particular audit strategy:

1. Audit or begin with an established balance per channel on a node.
2. Get a list of all node transactions, forwards, and fees throughout a period per channel.
3. Perform any number of audit procedures to gain comfort over the transactions occurring on the network for a node.
4. Sum all of the data and compare with the ending balance in each channel.

Each of these steps requires a data dump from a node, presented according to their specific knowledge of their business.

But how can we help determine the accuracy and completeness of client provided data?

How can we deterministically prove that a channel was open during a certain audit period and not fabricated?

How do we know that a reported channel open or close was seen by the network?

Introducing the Layers Audit Platform

To provide this data, Layers continually monitors the Lightning Network graph, and transforms network gossip and information into time series data.  This helps form the basis of all historical trends and reporting seen in the Explorer.

And by combining Lightning Network data, channel opening data from the Lightning graph, and custom logic to continually poll the Bitcoin blockchain for transaction inputs and outputs to establish channel closes, Layers is able to provide deterministic data on existence and overall channel capacity and act as a third party to independently verify and corroborate network level data from a node.

With the audit platform, you can now select your node to audit, enter your beginning and ending audit period dates, and get a list of all public channels that exist for a node through the period, along with all deterministic Bitcoin blockchain data.  And all of this data is exportable to CSV for your records with a single click!

Of course, the data provided by Layers is just one piece of the puzzle - any balances within a channel must be confirmed directly with a node.  It is very possible that a channel's capacity could be local to the party opening a channel and serve as a 'zero' asset for the audited node.  However, these audit reports offer an upper bound for any node and offer a one click starting report for conducting an audit.  No more need to manually compile lists and scrape explorers for all data required.

Get In Touch to Setup Your Audit(s)

The Layers Audit Platform is free to use for your first two reports.  Simply sign up and browse here to get started.

Certain limitations apply, so please get in touch to discuss the full functionality, limitations, and your needs.

Is this information helpful?  Please consider subscribing to this newsletter or following Layers on Twitter.