Federal Reserve Bank of Cleveland Working Paper Series

The Lightning Network: Turning Bitcoin into Money

Anantha Divakaruni and Peter Zimmerman

Working Paper No. 22-19

June 2022

Suggested citation: Divakaruni, Anantha, and Peter Zimmerman. 2022. "The Lightning Network:
Turning Bitcoin into Money." Working Paper No. 22-19. Federal Reserve Bank of
Cleveland. https://doi.org/10.26509/frbc-wp-202219.

Federal Reserve Bank of Cleveland Working Paper Series

ISSN: 2573-7953

Working papers of the Federal Reserve Bank of Cleveland are preliminary materials circulated to
stimulate discussion and critical comment on research in progress. They may not have been subject to
the formal editorial review accorded official Federal Reserve Bank of Cleveland publications.

See more working papers at: www.clevelandfed.org/research. Subscribe to email alerts to be notified
when a new working paper is posted at: www.clevelandfed.org/subscribe.
 The Lightning Network: Turning Bitcoin into Money

Anantha Divakaruni∗ Peter Zimmerman†

Abstract

The Lightning Network (LN) is a means of netting Bitcoin payments outside the blockchain.
We find a significant association between LN adoption and reduced blockchain congestion, sug-
gesting that the LN has helped improve the efficiency of Bitcoin as a means of payment. This
improvement cannot be explained by other factors, such as changes in demand or the adoption of
SegWit. We find mixed evidence on whether increased centralization in the Lightning Network
has improved its efficiency. Our findings have implications for the future of cryptocurrencies as
a means of payment and their environmental footprint.

JEL classification: E42, G10.

Keywords: Bitcoin, blockchain, cryptocurrency, Lightning Network, payments.

∗
University of Bergen. E-mail: anantha.divakaruni@uib.no.
†
Federal Reserve Bank of Cleveland. E-mail: peter.zimmerman@clev.frb.org.
The views stated herein are those of the authors and not necessarily those of the Federal Reserve Bank of Cleveland
or of the Board of Governors of the Federal Reserve System. This paper was previously circulated under the title
“Ride the Lightning: Turning Bitcoin into Money.” The authors wish to thank Huzaizhi Chen, Rodney Garratt,
Engin Iyidogan, Carlos León, and Ahmed Sewaid, along with seminar audiences at the Bank of England, Boca Cor-
porate Finance and Governance Conference, CEBRA, CEMLA, Paris Fintech & Crypto Seminar, Southern Finance
Association, Southwestern Finance Association, and UCL P2PFISY 2020. Any errors are the responsibility of the
authors.
1 Introduction

Bitcoin was originally designed to serve as a “peer-to-peer electronic cash system” — that is, a reli-
able means of payment outside the control of centralized monetary authorities (Nakamoto (2008)).
Since its introduction in 2009, Bitcoin has grown immensely in value, but still sees relatively little
use as a means of payment (Bolt and van Oordt (2020)). One important reason is that Bitcoin’s
blockchain technology imposes capacity constraints on processing transactions. These constraints
allow Bitcoin to handle, on average, merely seven transactions per second, which compares unfa-
vorably with centralized payment systems such as Visa or Mastercard.1 When transaction demand
is high, the processing limits mean that Bitcoin transactions can take a long time to settle. In
recent years, many solutions have been proposed to resolve this so-called scalability problem, to
help Bitcoin achieve its potential as a large-scale payments system.

One such solution is the Lightning Network (LN), which allows Bitcoin users to make payments
outside the blockchain. Rather than inscribe every individual payment onto the blockchain, two
individuals can open an LN channel and make bilateral payments. Once they have completed their
payments, they can close the channel and settle the net amount. In principle, doing this requires
only two transactions on the blockchain — one to open the channel, and another to close it —
regardless of the amount settled or the number of underlying payments. In this way, adoption of
the LN can reduce demand for blockchain space and ease congestion.

We find that adoption of the Lightning Network has led to a reduction in Bitcoin blockchain
congestion and lower mining fees. The results are significant, both statistically and economically,
and cannot be explained by changes in demand for blockchain space, nor by other technological
developments. We find limited evidence that greater centralization of the network is associated
with lower fees. Our results suggest that the Lightning Network can help Bitcoin achieve greater
scalability, allowing it to operate better as a payments system. According to our results, if the LN
had existed in 2017, congestion could have been 93 percent lower.

Our analysis covers the period January 1, 2017, to September 5, 2019. Data limitations prevent
us from extending our data set. The Lightning Network continues to grow, doubling in size over
2021.2 There has been institutional adoption, too. For example, Twitter allows tipping using the

1
Visa claims to able to handle over 24,000 transactions per second. See https://usa.visa.com/
run-your-business/small-business-tools/retail.html.
2
See https://bitcoinvisuals.com/lightning.

1
LN, among other payment methods.3 El Salvador enables Bitcoin payments among its citizens
using the Chivo Wallet, which features LN functionality (Alvarez, Argente, and Patten (2022)).
And several cryptocurrency exchanges have introduced support for the LN.4 But recent episodes
of high congestion, especially in early 2021, suggest that the LN is not a panacea.

The development of the Lightning Network may have consequences for welfare. First, as Bitcoin be-
comes a more efficient payments system, users are better off. Their transactions settle more quickly
and more cheaply (Zimmerman (2020)). Second, since fewer transactions need to be recorded on
the blockchain, less memory and energy are needed to run a Bitcoin node. This saving lowers the
cost of maintaining the blockchain, allowing more nodes to participate and making the system more
secure against a double-spending attack (Budish (2018)). Third, by reducing fees, the LN reduces
the incentive for Bitcoin miners to use large amounts of computing power, meaning less energy
use and positive consequences for the environment.5 Fourth, less blockchain congestion may mean
lower barriers to arbitrage across cryptocurrency exchanges, thereby improving market liquidity
(see Hautsch, Scheuch, and Voigt (2018)).

While this paper focuses on Bitcoin, the same technology can allow other cryptocurrencies to
be widely used, secure, and decentralized. For example, the Raiden Network is a similar netting
solution for Ethereum. Other solutions to the scalability problem have been proposed, including
sharding, and batching at exchange level.6 If the scalability problem can be successfully addressed,
it may be possible for a currency based on a permissionless blockchain to obtain wide acceptance.

The rest of the paper is organized as follows. Section 2 briefly describes the Lightning Network
and outlines findings from the existing literature. Section 3 describes our data, and Section 4 our
results. Section 5 concludes.
3
See https://blog.twitter.com/en_us/topics/product/2021/bringing-tips-to-everyone.
4
See https://github.com/theDavidCoen/LightningExchanges.
5
The total energy consumption of Bitcoin miners is substantive, so the benefits could potentially be large. See
https://ccaf.io/cbeci/index. However, these benefits may not be realized immediately, because fees currently
comprise a small part of miners’ revenue and are expected to grow in importance over time (Easley, O’Hara, and
Basu (2019)).
6
See https://blog.coinbase.com/reflections-on-bitcoin-transaction-batching-b13dad12a12 and https:
//ethereum.org/en/upgrades/shard-chains/.

2
2 The Lightning Network

The Lightning Network was first introduced by Poon and Dryja (2016), and began to attract
widespread usage in January 2018. The LN is a secondary transaction layer that operates outside
the blockchain. Two users open an LN channel by contributing Bitcoin to a smart contract. They
can then transfer these coins between them without creating traffic on the blockchain (Auer (2019)).
Once the channel is closed, only the net amount needs to be settled on-chain as a single payment.
This netting reduces the required number of on-chain transactions to just two: one to introduce
the smart contract that opens an LN channel, and a second to close it. In this way, the system
can handle a much larger number of payments. Arcane Research (2022) provides an up-to-date
description of the Lightning Network.

In payments system terms, the Lightning Network can be thought of as a net settlement system
appended to Bitcoin’s gross settlement system (Kahn, McAndrews, and Roberds (2003)). This
economizes on liquidity, but introduces counterparty credit risk. The LN introduces various safe-
guards to minimize the risk of counterparty default. In particular, if one party tries to close the
channel without the approval of the other, she may forfeit her claim on any Bitcoin that are locked
in.

The Lightning Network protocol itself relies on Segregated Witness (SegWit), which is a change
to the Bitcoin transaction format activated on August 23, 2017. SegWit improves the efficiency of
blockchain storage, so that a single Bitcoin block can potentially store up to four times as many
transactions as before. Brown, Chiu, and Koeppl (2021) show that the introduction of SegWit has
reduced Bitcoin mining fees.

Only a couple of papers in the economics and finance literature focus on the Lightning Network.
Guasoni, Huberman, and Shikhelman (2021) build a strategic model in which Bitcoin users choose
whether to open LN channels, and examine the characteristics of the network that emerges. Bertucci
(2020) studies a strategic model of network formation and shows that competition between nodes
prevents the network from becoming highly centralized. More broadly, our paper relates to a
literature examining the fee-based market for blockchain space; see, for example, Easley, O’Hara,
and Basu (2019), Hautsch, Scheuch, and Voigt (2018), Huberman, Leshno, and Moallemi (2021),
Lehar and Parlour (2020), Makarov and Schoar (2020), and Zimmerman (2020).

In the computer science literature, papers have focused on the financial viability of the LN (e.g.,
Béres, Seres, and Benczúr (2019) and Brânzei, Segal-Halevi, and Zohar (2017)); its network struc-

3
ture (e.g., Lin et al. (2020) and Martinazzi and Flori (2020)); and its ability to guarantee security
and privacy (e.g., Harris and Zohar (2020), Kappos et al. (2021), and Pérez-Solà et al. (2020)).

3 Data

We aim to test whether adoption of the Lightning Network is associated with reduced congestion on
the Bitcoin blockchain. We construct measures of congestion using data on the Bitcoin mempool ;
that is, the set of payments waiting to be added to the blockchain. Our data come from Jochen
Hoenicke.7 We collect data on: (i) the number of pending transactions (mempool txn count); (ii) the
fees attached to pending transactions (mempool txn fees); and (iii) the proportion of transactions
with fees under 10 satoshis per virtual byte (low fee txns).8

Data on the Lightning Network come from the website hashXP.9 This repository contains detailed
historical information on all public Lightning nodes (both active and inactive), channels between
these nodes (both open and closed), and channel capacity (in bitcoin and USD). In addition,
hashXP provides complete details of Bitcoin transactions executed in order to open and close LN
channels.10

The shape of the Lightning Network may affect its efficiency. For example, if Lightning channels
tend to be intermediated via a few central nodes, then collateral (i.e., the Bitcoin that users have
locked into the LN) can be used more efficiently. In other words, when the network is more

7
See https://jochen-hoenicke.de/queue. Hoenicke operates a Bitcoin node with its own mempool. There is no
definitive mempool: each Bitcoin node may detect different pending payments. We assume that Hoenicke’s data are
an unbiased sample of the union of mempools maintained by all nodes in the Bitcoin network.
8
A virtual byte is equivalent to a physical byte for non-SegWit transactions and to four physical bytes for SegWit
transactions. Since SegWit allows data to be stored up to four times as efficiently, a virtual byte is a measure
of the amount of data encoded to the blockchain. Hoenicke only provides fees per virtual byte, not per physical
byte. In addition, the data do not include transactions with zero fees. This omission is because it is costless for a
vexatious attacker to submit zero-fee transactions to the mempool, so miners tend to ignore them. Including zero-fee
transactions could therefore overstate the actual level of mempool congestion. Easley, O’Hara, and Basu (2019) study
the determinants of zero-fee transactions in Bitcoin.
9
See https://hashxp.org/lightning. To our knowledge, these data are available for public access and there is
no restriction on their use.
10
Our data set contains only public LN channels. Users can also open private channels, which are known only to
the connecting nodes and not announced to the broader network. By their nature, no data are available on these
private channels.

4
centralized, each channel, and each Bitcoin locked into the protocol, is likely to support a higher
volume of payments (see Martinazzi and Flori (2020)). To account for this effect, we include
the LN clustering coefficient as an independent variable. This network statistic is defined by
Watts and Strogatz (1998) as the average probability that two neighbors of any given node are
themselves connected. When the network is more centralized, the clustering coefficient is lower.
Thus, we predict that when the clustering coefficient is high, mempool congestion is worse. As
Figure 1 shows, the network has tended to become more clustered — and thus less centralized
— as it develops, though the last few months of the sample period show a trend toward greater
centralization.

Figure 1: Mean clustering coefficient among Lightning Network nodes.

Source: hashXP.

We introduce proxies for Bitcoin demand over this period. Higher demand for transactions on
the Bitcoin blockchain can increase congestion for reasons unrelated to LN adoption, so we need
to take it into account. While demand cannot be observed directly, Liu and Tsyvinski (2020)
suggest that it is positively related to historical price changes; in other words, there is a momentum
factor. Motivated by this observation, we introduce 1-day price change as the log-lagged change
in the Bitcoin price at midnight UTC (Coordinated Universal Time) each day. We also use price

5
volatility as a proxy for speculative demand for Bitcoin. We define 30-day volatility as the rolling
standard deviation of Bitcoin returns from each of the past 30 trading days. These two measures
are computed using price data from Coin Metrics (https://coinmetrics.io/).

We also include a measure for the supply of blockchain space. Unlike demand, supply is directly
observable ex post, since we can see how many blocks were created each day. We proxy supply
by dividing miners’ total hash rate divided by average mining difficulty, using Coin Metrics data.
We call this measure mining intensity. While the Bitcoin protocol aims for a long-run mean of one
block every 10 minutes, the realized rate of block creation can vary due to chance, or due to changes
in miners’ hash rate since the previous difficulty adjustment (Nakamoto (2008)). In addition, since
SegWit adoption may affect mempool congestion, we control for it in our regressions. We obtain
data from Bitcoin Visuals on the estimated proportion of Bitcoin transactions that use SegWit
(https://bitcoinvisuals.com/chain-tx-block).

A description of each variable can be found in the Appendix. Our sample period contains daily
data from January 1, 2017, to September 5, 2019, so it includes a period of about a year before
the LN was widely adopted. We cannot extend our data set any later because, beyond these dates,
hashXP was no longer actively monitoring the Lightning Network and providing accurate data. As
a result, we are unable to study any more recent developments in the LN.

Hoenicke’s mempool data set is missing six days: Feb 1, 2017; Apr 17–19, 2017; Jun 1, 2019; and
Jun 26, 2019. We drop these days from our data set. We use first-differenced data (see later in
this section), so we also drop the following days (i.e., Feb 2, 2017; Apr 20, 2017; Jun 2, 2019; Jun
27, 2019). As a result, we have a total of 968 daily observations of the dependent variables. In
addition, the Coin Metrics data on prices are missing one day (Jan 1, 2019).

Table 1 shows summary statistics for our data. Many of the variables are highly volatile with
substantive right-skew. Because of this skewness, we use the logarithms of mempool txn count,
mempool txn fees, LN channels, and LN capacity in our regressions.

Figure 2a plots the number of transactions waiting to be confirmed in Bitcoin’s mempool (denoting
congestion) over our sample period, along with active LN channels over time and the percentage of
transactions that use SegWit. Congestion in Bitcoin has fallen markedly since early 2018, coinciding
with the introduction and rapid adoption of the LN. Congestion has remained relatively low since

6
Table 1: Summary statistics.

count mean std dev min median max

Mempool txn count 968 23,042 40,619 92 5,731 252,750
Mempool txn fees (USD) 968 106,180 440,206 39 3,008 4,750,619
Low fee txns (%) 968 53.45 28.30 0 52.04 95.99
Lightning Network channels 968 12,671 15,374 0 7,575 44,087
Lightning Network capacity (USD) 968 2,766,535 4,080,066 0 205,388 11,794,337
Lightning Network mean clustering 968 0.06 0.07 0 0.06 0.19
SegWit txns (%) 968 20.72 15.48 0 27.61 46.80
30-day volatility 968 4.16 1.54 1.10 4.03 8.07
1-day price change 967 0.00 0.04 -0.21 0.00 0.23
Mining intensity 968 7.49 0.82 3.98 7.51 9.79

Notes: Daily data from January 1, 2017, to September 5, 2019. See the Appendix for variable definitions
and data sources.

then, although it picked up slightly in mid-2019.11 Figure 2b plots similar measures weighted by
monetary value: we measure congestion using mempool fees, LN adoption using the USD value of
locked Bitcoin, and SegWit usage by the monetary value of transactions. Total fees attached to
payments waiting in the mempool have fallen since 2017, suggesting either lower demand or greater
supply of settlement capacity. Over this period, the total value of Bitcoin used to collateralize LN
channels has risen.

Figure 3 shows that the distribution of fees has changed over our sample period. Generally, fees
have fallen in nominal bitcoin terms. The proportion of transactions with fees below 10 satoshis
per virtual byte rose from 32.6 percent on January 1, 2018, to 74.2 percent on September 5, 2019.12

We are interested in whether LN adoption is associated with lower mempool congestion. We test
for relationships using autoregressive integrated moving average (ARIMA) specifications, which

11
By September 2019, the average daily mempool count was 75 percent lower than at the start of 2017. This
decline in congestion does not appear to be driven by lower demand for Bitcoin. Although demand initially declined
following the collapse of the cryptocurrency market in early 2018, the number of confirmed transactions subsequently
grew to over 300,000 transactions per day by September 5, 2019, nearly back to its 2017 peak. See https://www.
blockchain.com/charts/n-transactions.
12
There are 100 million satoshis to a bitcoin.

7
Figure 2: Bitcoin mempool and the adoption of the Lightning Network and SegWit.

(a) Mempool size

100
Active Lightning Network channels (1000s)
250

50
Bitcoin Mempool
Mempool pending transactions (1000s)

Lightning Network
SegWit
200

40

80
SegWit transactions (%)
150

30

60
100

20

40
10

20
50

0
0

Ja Ap J Oc J A J Oc Ja Ap J
n r− ul− t− an−2 pr−2 ul−2 t n r− ul−
−2
01 2017 2017 201 01 01 01 −201 −201 201 201
7 7 8 8 8 8 9 9 9

(b) Mempool fees

Total Lightning Network channel capacity (mil USD)

Mempool pending transaction fees (mil USD)

100
2.5

12
Bitcoin Mempool
Lightning Network
SegWit

Fees by SegWit transactions (%)

10
2.0

80
8
1.5

60
6
1.0

40
4
0.5

20
2
0.0

Ja Ap J Oc J A J Oc Ja Ap J
n r− ul− t− an−2 pr−2 ul−2 t n r− ul−
−2
01 2017 2017 201 01 01 01 −201 −201 201 201
7 7 8 8 8 8 9 9 9

Notes: Daily data from January 1, 2017, to September 5, 2019.

Sources: Jochen Hoenicke, blockchain.com, and hashXP.

estimate the following regression equation:

p
X q
X
ytd = c + d
φi yt−i + θj εt−j + Xtd β + εt , (1)
i=1 j=1

8
Figure 3: Distribution of fees in the Bitcoin mempool.
100

80

% Mempool Transactions
60

40

20

0
Ja Ju Ja Ju Ja Ju
n− l−17 n− l−1 n− l−1
17 18 8 19 9

100+ sat/B 11−100 sat/B 4−10 sat/B 0−3 sat/B

Notes: Daily data from January 1, 2017, to September 5, 2019. The chart plots fees in satoshis per virtual
byte. There are 100 million satoshis to a bitcoin. Source: Jochen Hoenicke.

where c is a constant term, y d is the variable of interest expressed after taking d differences, Xtd
is a vector of the d-differenced independent variables, and εt is a residual term. The parameter p
is the number of lags of the variable of interest, d is the number of differences taken, and q is the
length of the moving average window of historical residual terms. For each specification, we esti-
mate the parameters (p, d, q) using the Hyndman-Khandakar algorithm (Hyndman and Khandakar
(2008)). The time variable t is daily. We employ robust standard errors, since we cannot be sure
of homoskedasticity.

Figures 2a and 2b suggest that the data are non-stationary. We take first-differences of all our
variables. Augmented Dickey-Fuller (ADF) and Kwiatkowski–Phillips–Schmidt–Shin (KPSS) tests
confirm that these first-differenced variables are stationary (i.e., d = 1).

4 Results

We run three sets of regressions. First, we test the effect of LN adoption on mempool count,
using the number of LN channels. We run four versions of this model. Model (1) contains no
controls; model (2) includes the demand and supply controls; model (3) includes the proportion
of transactions that use SegWit; and model (4) has all the controls. Table 2 reports the results.
In each of the four specifications, an increase in the number of LN channels reduces the mempool

9
count. The results are significant at the 1 percent level. None of the supply and demand controls
have a significant impact on mempool size.13

Table 2: Impact of Lightning Network adoption by number of channels on mempool

count.

(1) (2) (3) (4)

ΔLN channels (log) -0.247∗∗∗ -0.244∗∗∗ -0.251∗∗∗ -0.249∗∗∗
(0.075) (0.077) (0.077) (0.078)
ΔLN mean clustering -3.857 -3.803 -4.004 -4.007
(5.959) (6.073) (5.800) (5.918)
ΔSegWit txns (%) 0.016 0.018
(0.012) (0.012)
Δ30-day volatility -0.024 -0.020
(0.082) (0.082)
Δ1-day price change -0.738 -0.744
(0.622) (0.620)
ΔMining intensity 0.033 0.042
(0.048) (0.049)
Constant -0.001 -0.001 -0.001 -0.002
(0.009) (0.009) (0.009) (0.009)
Observations 967 966 967 966
AIC 2589 2590 2589 2589

Notes: Regressions of LN channels (log) on mempool transaction count (log). In all four models, the param-
eters selected by the Hyndman-Khandakar algorithm are: p = 6 lagged terms included for the dependent
variable, d = 1 difference taken, and q = 2 length of window for the moving average of historical residual
terms. Data are from January 1, 2017, to September 5, 2019. See the Appendix for variable definitions and
data.

Our second set of results tests a similar relationship using US dollar values. We regress the USD
value of Bitcoin locked into the LN against the USD value of fees attached to mempool transactions.
Table 3 shows the results. As before, greater LN capacity is associated with reduced congestion.
This time, however, the results are not significant at the 5 percent level once we include supply and
demand controls.

Finally, we investigate how the LN affects the proportion of low fee transactions in the mempool.

13
For each model, Portmanteau and Durbin-Watson tests suggest no evidence of autocorrelation in the residuals.

10
Table 3: Impact of Lightning Network adoption by capacity value on mempool fees.

(1) (2) (3) (4)

ΔLN capacity (USD log) -0.198∗∗ -0.199∗ -0.197∗∗ -0.198∗
(0.099) (0.102) (0.100) (0.102)
ΔLN mean clustering -6.889 -7.233 -7.150 -7.572
(7.940) (7.977) (7.652) (7.674)
ΔSegWit txns (%) 0.025∗ 0.027∗
(0.014) (0.014)
Δ30-day volatility 0.115 0.122
(0.105) (0.105)
Δ1-day price change -0.549 -0.548
(0.837) (0.835)
ΔMining intensity 0.030 0.041
(0.058) (0.058)
Constant 0.003 0.003 0.002 0.002
(0.010) (0.010) (0.010) (0.010)
Observations 967 966 967 966
AIC 3042 3043 3040 3041

Notes: Regressions of LN capacity (USD log) on mempool fees (USD log). In all four models, the parameters
selected by the Hyndman-Khandakar algorithm are the same: p = 6 lagged terms included for the dependent
variable, d = 1 difference taken, and q = 1 length of window for the moving average of historical residual
terms. Data are from January 1, 2017, to September 5, 2019. See the Appendix for variable definitions and
data.

Table 4 shows that greater LN usage is associated with a significant increase in low fee transactions.
Unlike the first two sets of regressions, clustering has a significant and negative impact on low fees.
In other words, a more centralized network means that transactions are likelier to have low fees, in
line with our priors.

Overall, these results suggest that increased LN usage is associated with a significant reduction in
mempool congestion. Since there is no theoretical upper limit on LN usage, there is the potential
for further reductions in congestion in the future. However, network centralization does not have a
clear effect on the efficiency of the network.14

14
We also run a set of regressions that include interaction terms between the LN adoption variable and the mean
clustering coefficient. In each case, the interaction terms are not statistically significant and their inclusion does not
affect the other results. More details are available upon request.

11
Table 4: Impact of Lightning Network adoption by number of channels on low fee
mempool transactions.

(1) (2) (3) (4)

ΔLN channels (log) 0.192∗∗∗ 0.186∗∗∗ 0.195∗∗∗ 0.187∗∗∗
(0.034) (0.035) (0.034) (0.035)
ΔLN mean clustering -2.244∗∗∗ -2.295∗∗∗ -2.169∗∗ -2.144∗∗
(0.858) (0.863) (0.864) (0.871)
ΔSegWit txns (%) -0.016∗∗∗ -0.016∗∗∗
(0.004) (0.004)
Δ30-day volatility -0.018 -0.024
(0.024) (0.024)
Δ1-day price change 0.059 0.065
(0.224) (0.223)
ΔMining intensity 0.042∗∗∗ 0.036∗∗
(0.015) (0.015)
Constant -0.002 -0.002 -0.002 -0.001
(0.002) (0.002) (0.002) (0.002)
Observations 967 966 967 966
AIC 692 674 676 658

Notes: Regressions of LN channels (log) on proportion of mempool transactions with fees below 10 satoshis
per virtual byte. In all models, the parameters selected by the Hyndman-Khandakar algorithm are the same:
p = 6 lagged terms included for the dependent variable, d = 1 difference taken, and q = 2 length of window
for the moving average of historical residual terms. Data are from January 1, 2017, to September 5, 2019.
See the Appendix for variable definitions and data.

In each regression, SegWit has the opposite effect of Lightning Network adoption on mempool
congestion, although the results are only significant in Table 4. At first glance, the signs of the
coefficients are surprising: greater use of SegWit appears to increase, rather than reduce, congestion.
There are a number of possible explanations. First, LN transactions require SegWit, so there is
some positive correlation between these variables. However, the exact relationship is not clear,
since we do not have data on the number of LN transactions, only on the number of channels and
the value of Bitcoin locked in. Second, the causality is not clear. It may be that periods of high
congestion encourage greater SegWit usage. Third, since SegWit transactions use fewer virtual
bytes than non-SegWit transactions (all else equal), users may be willing to pay a higher fee per

12
virtual byte.15

We can assess the economic significance of reducing Bitcoin congestion by posing the following
counterfactual question: if, during 2017, the LN had existed and been the size it was at the end of
our sample, by how much would Bitcoin congestion have been lowered? Our results suggest that
the mempool count would have been 93 percent lower, mempool fees 96 percent lower, and the
proportion of low fee transactions 197 percent higher. These numbers demonstrate that the LN
can potentially have a substantial impact on blockchain congestion.

5 Conclusions

We show that usage of the Lightning Network is associated with reduced mempool congestion in
Bitcoin and with lower fees. Our findings suggest that the off-chain netting benefits of the Lightning
Network can help Bitcoin to scale and function better as a means of payment. Centralization of
the Lightning Network does not appear to make it much more efficient, though it may increase the
proportion of low fee transactions.

Data are not available on how Bitcoin is used, so we cannot say for sure whether Bitcoin is being
increasingly used as a means of payment. Makarov and Schoar (2021) study blockchain data and
conclude that the majority of usage is for trading and speculative purposes, but their analysis does
not extend to transactions that take place on the Lightning Network. We can only say that the
Lightning Network loosens a key technological constraint by allowing payments to be settled more
quickly.

References

Alvarez, F. E., D. Argente, and D. V. Patten (2022). “Are cryptocurrencies currencies? Bitcoin as
legal tender in El Salvador.” National Bureau of Economic Research working paper no. 29968.
doi: 10.3386/w29968.
Arcane Research (2022). “The state of Lightning, volume 2.” Report. url: https://arcane.no/
research/reports/the-state-of-lightning-volume-2.

15
Suppose, for example, that Bitcoin users have the power to set fees, while miners are price takers. Then fees are
not likely to be very sensitive to the amount of blockchain space a transaction uses. In that case, a SegWit transaction
may attract a similar fee to its non-SegWit counterpart, and so will appear to be more expensive per virtual byte.

13
Auer, R. (2019). “Beyond the doomsday economics of proof-of-work in cryptocurrencies.” BIS
working paper no. 765. url: https://www.bis.org/publ/work765.htm.
Béres, F., I. A. Seres, and A. A. Benczúr (2019). “A cryptoeconomic traffic analysis of Bitcoin’s
Lightning Network.” arXiv. doi: 10.48550/arXiv.1911.09432.
Bertucci, L. (2020). “Incentives on the Lightning Network: a blockchain-based payment network.”
Proceedings of December 2020 Finance Meeting EUROFIDAI–ESSEC. doi: 10 . 2139 / ssrn .
3540581.
Bolt, W. and M. R. C. van Oordt (2020). “On the value of virtual currencies.” Journal of Money,
Credit and Banking 52.4, pp. 835–862. doi: 10.1111/jmcb.12619.
Brânzei, S., E. Segal-Halevi, and A. Zohar (2017). “How to charge Lightning.” arXiv. doi: 10.
48550/arXiv.1712.10222.
Brown, C., J. Chiu, and T. V. Koeppl (2021). “What drives Bitcoin fees? Using SegWit to assess
Bitcoin’s long-run sustainability.” Journal of Financial Market Infrastructures 9.4, pp. 1–25. doi:
10.21314/jfmi.2021.014.
Budish, E. (2018). “The economic limits of Bitcoin and the blockchain.” National Bureau of Eco-
nomic Research working paper no. 24717. doi: 10.3386/w24717.
Easley, D., M. O’Hara, and S. Basu (2019). “From mining to markets: the evolution of Bitcoin
transaction fees.” Journal of Financial Economics 134.1, pp. 91–109. doi: 10.1016/j.jfineco.
2019.03.004.
Guasoni, P., G. Huberman, and C. Shikhelman (2021). “Lightning Network economics: channels.”
Michael J. Brennan Irish Finance working paper no. 21–7. doi: 10.2139/ssrn.3840374.
Harris, J. and A. Zohar (2020). “Flood & loot: a systemic attack on the Lightning Network.” arXiv.
doi: 10.48550/arXiv.2006.08513.
Hautsch, N., C. Scheuch, and S. Voigt (2018). “Building trust takes time: limits to arbitrage in
blockchain-based markets.” arXiv. doi: 10.48550/arXiv.1812.00595.
Huberman, G., J. Leshno, and C. Moallemi (2021). “Monopoly without a monopolist: an economic
analysis of the Bitcoin payment system.” Review of Economic Studies 88.6, 3011–3040. doi:
10.1093/restud/rdab014.
Hyndman, R. J. and Y. Khandakar (2008). “Automatic time series forecasting: the forecast package
for R.” Journal of Statistical Software 27.3, pp. 1–22. doi: 10.18637/jss.v027.i03.
Kahn, C. M., J. McAndrews, and W. Roberds (2003). “Settlement risk under gross and net set-
tlement.” Journal of Money, Credit and Banking 35.4, pp. 591–608. url: https://www.jstor.
org/stable/3649902.

14
Kappos, G., H. Yousaf, A. Piotrowska, S. Kanjalkar, S. Delgado-Segura, A. Miller, and S. Meiklejohn
(2021). “An empirical analysis of privacy in the Lightning Network.” FC 2021. Lecture Notes in
Computer Science, vol 12674, pp. 167–186. doi: 10.1007/978-3-662-64322-8_8.
Lehar, A. and C. A. Parlour (2020). “Miner collusion and the Bitcoin protocol.” SSRN working
paper no. 3559894. doi: 10.2139/ssrn.3559894.
Lin, J.-H., K. Primicerio, T. Squartini, C. Decker, and C. J. Tessone (2020). “Lightning network: a
second path towards centralisation of the Bitcoin economy.” New Journal of Physics 22.083022.
doi: 10.1088/1367-2630/aba062.
Liu, Y. and A. Tsyvinski (2020). “Risks and returns of cryptocurrency.” The Review of Financial
Studies 34.6, pp. 2689–2727. doi: 10.1093/rfs/hhaa113.
Makarov, I. and A. Schoar (2020). “Trading and arbitrage in cryptocurrency markets.” Journal of
Financial Economics 135.2, pp. 293–319. doi: 10.1016/j.jfineco.2019.07.001.
– (2021). “Blockchain analysis of the Bitcoin market.” National Bureau of Economic Research
working paper no. 29396. doi: 10.3386/w29396.
Martinazzi, S. and A. Flori (2020). “The evolving topology of the Lightning Network: centralization,
efficiency, robustness, synchronization, and anonymity.” PLoS One 15.1. doi: 10.1371/journal.
pone.0225966.
Nakamoto, S. (2008). “Bitcoin: a peer-to-peer electronic cash system.” Mimeo. url: https : / /
nakamotoinstitute.org/bitcoin/.
Pérez-Solà, C., A. Ranchal-Pedrosa, J. Herrera-Joancomartı́, G. Navarro-Arribas, and J. Garcia-
Alfaro (2020). “LockDown: balance availability attack against Lightning Network channels.” FC
2020. Lecture Notes in Computer Science, vol 12059, pp. 245–263. doi: 10.1007/978-3-030-
51280-4_14.
Poon, J. and T. Dryja (2016). “The Bitcoin Lightning Network: scalable off-chain instant pay-
ments.” url: https://lightning.network/lightning-network-paper.pdf.
Watts, D. J. and S. H. Strogatz (1998). “Collective dynamics of ‘small-world’ networks.” Nature
393, 440––442. doi: 10.1038/30918.
Zimmerman, P. (2020). “Blockchain structure and cryptocurrency prices.” Bank of England staff
working paper no. 855. url: https : / / www . bankofengland . co . uk / working - paper / 2020 /
blockchain-structure-and-cryptocurrency-prices.

15
Appendix: Definitions of variables

Variable Definition

Mempool txn count Total number of unconfirmed transactions in the Bitcoin (BTC) mempool.
Source: Jochen Hoenicke.

Mempool txn fees (USD) Total fees in USD of pending unconfirmed transactions in the Bitcoin
mempool. Source: Jochen Hoenicke.

Low fee txns (%) Percentage of transactions in the Bitcoin mempool offering a fee lower
than 10 satoshis per virtual byte. 100 million satoshis = 1 bitcoin. Source:
Jochen Hoenicke.

Lightning Network channels Number of active channels on the Lightning Network. Data from Jan 1,
2018. Source: hashXP.

Lightning Network capacity (USD) Total value of active channels on the Lightning Network (in USD). Data
from Jan 1, 2018. Source: hashXP.

Lightning Network mean clustering Mean clustering coefficient across Lightning nodes, as defined by Watts
and Strogatz (1998). Source: hashXP.

SegWit txns (%) Average daily percentage of Bitcoin transactions per block that use Seg-
regated Witness (SegWit). Data from Aug 23, 2017. Source: Bitcoin
Visuals.

30-day volatility Rolling standard deviation of Bitcoin returns from past 30 trading days.
Source: Coin Metrics.

1-day price change Rolling difference in log Bitcoin price between days t−1 and t−2. Source:
Coin Metrics.

Mining intensity Expected rate of block creation, measured as total hash rate supplied by
miners divided by average difficulty. Source: Coin Metrics.

Note: Data are from January 1, 2017, to September 5, 2019 unless otherwise indicated.

16