Lightning Network: The Financial Operations Challenge

At RADAR we believe that the Lightning Network will accelerate blockchain adoption, which is why we created ION to be the home of the Lightning Network. The Lightning Network, a nascent and powerful solution that enables near instant bitcoin payments, needs the community’s help in building tools to make it better.

As a CPA working in the blockchain and cryptocurrency sector, I’m often asked about the Lightning Network and its implications for accounting for enterprise users. How can the network stand to benefit financial operations teams, and what are the main drawbacks that still require improvement?

Our team at RADAR has identified some ways that the community can improve the Lightning Network’s viability for the accounting domain, particularly in the form of enterprise tooling. This post outlines various opportunities for tooling to enable financial operations best practices on the network.

What Is the Lightning Network?

Excerpts from the Bitcoin and Lightning Network whitepaper abstracts combine to provide us with the following summary:

An instant and scalable peer-to-peer version of electronic cash would allow online payments of any amount to be sent directly from one party to another without going through a financial institution.

With apps like Venmo or Square Cash, users first connect to a banking network to access their banking assets. Banks attempted to solve for privacy by limiting information access to only the parties involved and trusted third parties. Conversely, Bitcoin solves the privacy issue by publishing all of the transactions to ensure the validity of transactions across the system while allowing users to maintain private keys.

The Lightning Network inherits security attributes of the Bitcoin blockchain and makes it faster, more affordable, and more scalable by enabling instant payments, micropayments, and new transaction types between peers. Lightning adds additional privacy by allowing peers to transact within off-chain “payment channels”, and thus isolates the visibility of transfers to peers themselves. For paying those with whom a user doesn’t have a direct connection, Lightning routing nodes exist.

One notable difference between “traditional” payment networks and the Lightning Network is the custody and nature of digital assets. With existing payment networks the currency being moved is typically the same (USD), with no state changes, and third parties provide custody. In a Lightning Network transaction, the currency remains the same (BTC), the nature varies between on-chain and off-chain states depending on the status of the channel, and users have the ability to retain custody depending on wallet selection.

Financial Operations Opportunities and Challenges on Lightning

Combining the Bitcoin and Lightning Networks allows peers to transmit payments, companies to accept digital currency payments, and developers to build infrastructure and tools. It also opens up a vast array of opportunities and challenges for enterprises wishing to engage in this frontier space. To enable enterprise participation in the Lightning Network, new tools are needed.

Enterprises can both contribute to the Lightning Network and use the network, but they have unique operational and reporting needs in order to fully operate on the network. One of the greater opportunities for enterprise adoption of the Lightning Network is the questions that arise around financial operations and accounting ambiguity.

Treasury Management

Treasury management within an enterprise comprises functions such as cash and risk management and optimizing for the availability and deployment of funds.

Each participant in the Lightning Network is responsible for their own asset security or must individually designate a third-party security provider. Actions like multi-signature fund access, verification solutions for digital assets, and limiting amounts accessible by different employees are solutions to securing assets.

Financial Planning & Analysis (FP&A)

Forecasting for different business activities is complicated by relatively volatile assets. Coupling the current volatility of the price of BTC with Lightning Network growth can compound the problem of determining asset allocation. Limiting funds converted to BTC allows the enterprise to have more stability but may be an opportunity cost on the BTC price and network opportunities.

We use a conservative approach, ensuring that our funds are accessible for our multiple product roadmaps while closely monitoring and predicting use of our nodes to ensure capital is available. Custom forecasting and treasury management tools will be necessary in order to simplify forecasting, allow for different digital asset usage, and enable full operation within the network.

Accounting

Transactions on the Lightning Network include opening and closing payment channels, sending and receiving funds off-chain, and routing a payment and collecting an associated fee.

The Lightning Network presents a trade-off between additional security, speed, and cost savings for public validation and transparency. New types of transactions emerge which create ambiguity around whether any particular transaction will require an accounting transaction to be recorded. With no guidance, there are instances on the Lightning Network that force a decision maker to arbitrarily decide whether or not an accounting transaction even occurred.

A Challenge in Practice

Putting all of that together, a real-life example where a Lightning Network transaction might result in ambiguity could be the act of opening a payment channel. In this scenario, let’s imagine that BTC is deposited from a BTC wallet into an LN-BTC-enabled wallet.

Opening a Channel

• Treasury management. Is the resulting LN-BTC automatically in the same custody situation as the BTC was previously? Who now has access to the LN-BTC and what are the risks of the counterparty in the channel being able to maliciously claim funds?
• FP&A. How much LN-BTC is needed as opposed to BTC? What is the enterprise trying to accomplish with the asset transition and what is the optimal amount?
• Accounting. Is this deposit a change to the nature of the asset requiring a recorded transaction? If yes, then the basis of the underlying BTC determines a gain/loss on the transition transaction. If no, then the basis of the BTC carries over to the LN-BTC. Further, whoever opened the payment channel must identify and record an associated transaction fee to the network.

After opening a channel, what does it mean to lock up funds in a multisignature contract with another party? Are these funds in escrow? Are they still assets of the company? When does this change?

Assets deposited into a channel are now available to transfer to the other channel party. This does not mean any requirements have been met in order for the other party to claim the funds as their own, although the other party can attempt to claim the funds. However, since no business requirements or agreements of transfer have occurred the funds remain on the balance sheet as assets of the depositor.

Closing a Channel

• Cooperative close. When removing funds from a channel, the respective balance given to each party should equal the amount of the interactions over the lifetime of the channel. However, the accounting transactions have already occurred within the channel. As obligations occurred and balances were updated, both parties should have already accounted for these in the previous time periods. The only accounting updates needed are for amounts paid for the on-chain transaction required to close a channel, if applicable.
• Losing a breach. A counterparty can attempt to close a channel and report inaccurate balances. The company would effectively lose money due to counterparty fraud, mistake, or negligence. This transaction would be classified as a loss of the corresponding inaccurate amount. However, this would have to be identified as such, which may be difficult if it wasn’t noticed during the occurrence.
• Successfully performing a breach remedy. If the breach is noticed and flagged as such upon close by the company, all of the funds in the channel will be awarded to the company. This net difference awarded is an extremely unique situation. A new account will be created for Channel Management Revenue on the income statement to account for the rewarded assets.

The View from Here

Currently, the best solutions for financial operations ambiguity have been implemented on the Lightning network protocol layer itself. The LND Lightning Network client, for example, provides an API for monitoring activity within a Lightning node. LND uses a permissions system called macaroons to securely grant read-only access to specific subsets of the node’s data and functionality and enable a simple accounting function: the ability to answer questions relating to a variety of transactions.

Isolating the transactions of a single node allows a company to focus on the transactions within the channels operated by the node and ignore the remainder of activity on the network.

The growth of peer-to-peer transactions has highlighted a need for better financial operations tools, and we expect to see more needs surfaced as growth continues. Transaction data can assist in surfacing information to provide insight without providing custody, allowing various enterprise functions to operate as long as access to information is provided. As the Lightning Network grows, it will be imperative to develop tools that allow peers and enterprises alike to function in their interactions with the network.