One of BitMEX’s claims to fame is the ability for clients to use 100x leverage while trading the Bitcoin / USD price. We often get asked to what extent traders use the maximum leverage offered. I asked our data science team to pull up historical data on leverage usage for the XBTUSD perpetual swap from May 2018 to April 2019.
The first chart and table combo shows the weighted effective leverage at month end for XBTUSD longs and shorts.
It appears traders are quite “responsible” in that they do not on average use the maximum amount of leverage.
Definitions aggregation grouped by month, side, and symbol
Methodology for Calculating Percentiles
Pick the last available timestamp for each of the prior 12 months (i.e. ‘month-end snapshot’), and calculate the effective leverage for every position across all accounts rounded to the nearest integer
Create a sorted list from the resulting values, flattened by expanding each position’s resulting effective leverage by the number of contracts held (e.g. if an effective leverage of 3 was used by an account with a position quantity of 4, it’s a contribution to the list is '3 3 3 3')
Any given percentile of this list can be found by taking the value at the index given by: (Count of the list) * (Desired percentile)
Using the mean is crude because traders who hold large positions must use less leverage than smaller traders. This is due to the risk limit feature of BitMEX. Traders may use 100x leverage up to a position size of 200 XBT. After that, the initial and maintenance margin requirements step up 0.5% per 50 XBT.
To understand the distribution of leverage respective to the number of contracts, we looked at a histogram of XBTUSD long and shorts averaged over the 12 month-end snapshots from May 2018 to April 2019. The above two charts display this data. As we expected, the largest traders use the least amount of leverage.
While the maximum leverage allowable for opening a position in XBTUSD is 100x, the effective leverage can then increase to 200x (i.e. the reciprocal of the 0.50% maintenance margin requirement), at which point liquidation occurs.
Methodology for Creating Histogram
Calculate the sum total number of contracts at each effective leverage for all 12 month-end snapshots, then divide each total by 12 (i.e. average month-end snapshot)
I hope this data allows traders to better understand the BitMEX market microstructure. I will continue to periodically post backward looking statistics in the near future.
We are pleased to introduce updates to the BitMEX visual identity. Starting today, you will see the replacement marks applied to all BitMEX properties. For some background on the history of our logo, as well as the construction of the update, please read on.
The BitMEX logo was created in early 2014 before the launch of the initial trading platform and is a representation of the ‘put-call parity’. The put-call parity defines that a futures contract (or more simply, a forward) can be replicated by a portfolio consisting of a long call option and a short put option.
The original logo design was a literal interpretation of the put-call parity formula, which, while effective, proved unwieldy when applied to a myriad of real-world scenarios. Over time, we have made the icon and logo less representational, and more flexible, to allow for easier use in social media, contracts, and everything in between that comes with running a modern trading platform.
As we continue to improve the BitMEX trading experience, we will also be improving the look and feel of the platform so as to give you all the information you need to make intelligent, decisive trades on a clean, easy-to-read, and professional platform.
We value all the support and feedback we have received over the past few years, please continue to let us know how we can continue to improve, on Twitter, and through our support page.
Abstract: In this piece we present data on a relatively new phenomenon, Initial Exchange Offerings (IEOs). The ICO market is down around 97% in Q1 2019 (YoY), based on the amount of capital raised. In this relatively challenging climate to raise funds, some projects have changed the “C” in ICO to an “E”, perhaps in an attempt to assist with raising capital. At least for now, to some extent, this appears to be working, with almost $40m having been raised so far this year. However, we remain sceptical about the prospects for long term investors.
We consider an Initial Exchange Offering (IEO) as the issuance and sale of a token based on public-private key cryptography, where participation in the issuance occurs exclusively through one trading platform or exchange. This piece provides a basic overview of the largest IEOs and tracks various IEO token metrics, including investment performance.
First we briefly look at the ICO market. As the following chart indicates, the market has dried up following a massive boom in 2017 & 2018.
Funds raised by ICOs – US$M
Source: BitMEX Research, icodata.io Notes: Data as at 25 April 2019
As the below chart illustrates, the investment returns of the 2018 ICOs has been poor, many of the projects are down around 80% from the ICO price, if the coin even trades at all. Peak to trough, project token prices typically declined much further than this.
Top ten ICOs by funds raised in 2018 – Investment performance data
Funds raised – US$m
Return based on average ICO price
Coin not listed
Coin not listed
Coin not listed
Returned capital to investors
Source: BitMEX Research, tokendata.io Notes: Data as at 25 April 2019
Changing a “C” into an “E” – The IEO market
Perhaps in an attempt to address some of the concerns about the poor investment returns and the lower levels of enthusiasm for ICOs, IEOs appear to have gained in popularity. Below is a list of the major IEOs and the main exchange platforms involved.
List of IEO token sales
IEO issue amount vs total coin supply
Return vs first exchange trade price
Return vs IEO price
US$m raised in IEO
Source: BitMEX Research, IEO Launchpad websites, Coinmarketcap Notes: Data as at 25 April 2019
The number of IEOs taking place has intensified in recent months, as the model is proving somewhat successful. Smaller exchange platforms are attempting to replicate the model, as the long list of IEOs below illustrates.
Other IEOs with limited data available
KIZUNA GLOBAL TOKEN
Link by BlockMason
GTEX Gaming Platform
Source: BitMEX Research, IEO Launchpad websites
With respect to all but one of the tokens, investors have earned strong positive returns based on the IEO price. However, after the tokens begin trading, the investment returns have typically been poor. This is illustrated by the below chart, which rebases the token price to the IEO issuance price.
IEO Investment performance since launch (IEOs in 2019)
Source: BitMEX Research, IEO Launchpad websites, Coinmarketcap Notes: Data as at 25 April 2019
US$38.9m has been raised so far by IEOs in 2019 (up to 25th April). Binance has been the most prolific IEO platform by a considerable margin.
Top exchange platforms by IEO funds raised – US$m
Source: BitMEX Research, IEO Launchpad websites, Coinmarketcap Notes: Data as at 25 April 2019
The proceeds from IEOs can be relatively small, however on average only 4.4% of the total token supply is made available in the sale. Therefore, there are opportunities for project teams to make considerable profits from selling coins they granted to themselves. The 2019 IEOs were priced at a level which implies a total market capitalisation of US$907.7m, based on the disclosed total token supply.
Top exchange platforms by IEO token market capitalisation at IEO price – US$m
Source: BitMEX Research, IEO Launchpad websites, Coinmarketcap Notes: Data as at 25 April 2019
While exchanges, traders & subscribers may have done very well from IEOs thus far, we are less confident on the outlook for long term investors. However, this is simply a high level analysis – we have not looked into any of the individual projects in detail.
Any views expressed on BitMEX Research reports are the personal views of the authors. BitMEX (or any affiliated entity) has not been involved in producing this report and the views contained in the report may differ from the views or opinions of BitMEX.
The information and data herein have been obtained from sources we believe to be reliable. Such information has not been verified and we make no representation or warranty as to its accuracy, completeness or correctness. Any opinions or estimates herein reflect the judgment of the authors of the report at the date of this communication and are subject to change at any time without notice. BitMEX will not be liable whatsoever for any direct or consequential loss arising from the use of this publication/communication or its contents.
If we have made any errors in relation to particular projects, we apologise and are happy to correct the data as soon as possible.
Abstract: We summarise and provide context for a recent Bitcoin softfork upgrade proposal, which includes a new digital signature scheme (Schnorr), as well as a complementary upgrade called Taproot, which adds new capabilities that extend Bitcoin’s smart contracting capability. The upgrades are structured to ensure that they simultaneously improve both scalability and privacy. Other than increased complexity, there are no significant downsides to the proposal, and the most controversial aspect of it is likely to be the lack of other anticipated features. We conclude that although many will be enthusiastic about the upgrade and keen to see it rolled out, patience will be important.
On 6th May 2019, Bitcoin protocol developer Pieter Wuille posted a softfork upgrade proposal to the Bitcoin developer mailing list, called “Taproot”. If this proposal is accepted, it is likely to complement the Schnorr signature softfork upgrade, which Pieter posted in July 2018. The benefits of these proposals are related to both scalability (efficiency) and privacy. Scalability and privacy enhancements now appear somewhat interrelated and inseparable. Removing details about transactions, ensures both that transactions are smaller (improving scalability) and that they reveal less information and are therefore potentially indistinguishable from transactions of different types, thereby improving privacy.
The Schnorr signature scheme was patented in 1991 by Claus Schnorr and the patent expired in 2008. Although the Schnorr scheme is said to be stronger, a variant of it, the Digital Signature Algorithm (DSA) scheme was more widely adopted, as the patent for this scheme was made available worldwide royalty free. However, Dr Schnorr himself always maintained that DSA should be covered under his patent.
When Bitcoin was launched, in 2009, it therefore used a variant of DSA, Elliptic Curve Digital Signature Algorithm (ECDSA) for its digital signature scheme, due to its widespread adoption. However, the original Schnorr signature scheme was always more simple and efficient than DSA, with less burdensome security assumptions. After 10 years of experience of Bitcoin usage, it is becoming more apparent that these efficiency advantages could be important. Therefore it seems sensible that Bitcoin should migrate over to the Schnorr signature scheme.
The main benefit with Schnorr signatures, is that multi-signature transactions appear onchain as a normal single signature transaction. Using Schnorr signatures, multiple signers can produce a joint public key and then jointly sign with one signature, rather than publishing each public key and each signature separately on the blockchain. This is a significant scalability and privacy enhancement. This implies that Schnorr signatures result in significant space savings and savings to verification times, with the comparative benefits getting larger as the number of signatories on a traditional multi-signature transaction increase.
Schnorr signature space saving estimates
We have tried to calculate the potential Bitcoin network capacity increase this aggregation feature of Schnorr multisig can provide. However, due to the large number of assumptions involved, our 13.1% capacity increase figure below should be considered as a very approximate estimate.
Savings estimates based on UTXO count
Estimated current multi-signature usage by UTXO count
(Source: BitMEX Research calculations and estimates, p2sh.info)
(Notes: The estimates ignore the impact of Schnorr’s smaller signature size and only include the benefits of joining the public keys and signatures. The capacity increase was estimated by using p2sh.info related to multi-signature usage and applying a savings multiple to each multi-signature type (ranging from 50% to 85%). A network wide capacity increase was estimated by assuming the UTXO usage proportion was typical of blockchain usage and applying a higher weight to larger multi-signature transactions. Unspent P2SH outputs were allocated to multi-signature types in proportion to the spent outputs. This figure should only be considered as a very approximate estimate. Data as at 07 May 2019 )
The above estimated capacity increase can be considered as small, however one should consider the following:
Economic usage of multi-signature technology is far more prevalent than by merely looking at the UTXO count. Around 21.5% of all Bitcoin is stored in multi-signature wallets, a far higher figure than the 5.9% adoption by UTXO count
Multi-signature adoption is growing rapidly, as the below chart indicates. While at the same time new systems like the lightning network require multi-signature adoption and with Schnorr signature making multi-signature systems more powerful, adoption is likely to increase
Bitcoin stored by P2SH address type – chart shows strong growth of multi-signature technology
Therefore, although based on the current usage of the network, according to our basic calculation, even 100% Schnorr adoption only results in a 13.1% network capacity increase, in the long term the potential space savings and network capacity gains are likely to be far higher than this.
Merkelized Abstract Syntax Tree (MAST)
MAST was an idea worked on by Bitcoin protocol developer Dr Johnson Lau in 2016. Dr Lau has written for BitMEX Research in the past, in his February 2018 piece entitled The art of making softforks: Protection by policy rule. The MAST idea is that transactions can contain multiple spending conditions, for example a 2 of 2 multi-signature condition, in addition to a time lock condition. In order to avoid putting all these conditions and scripts into the blockchain, the spending scripts can be structured inside a Merkle tree, such that they only need to be revealed if they are used, along with the necessary Merkle branch hashes.
Graphical illustration of MAST spending conditions
(Source: BitMEX Research) (Notes: The diagram is trying to illustrate a transaction structure assuming MAST was used in conjunction with Schnorr. In the above construction funds can be redeemed the cooperative way if both Bob and Alice sign, or in an uncooperative way after a timelock. The above is supposed to illustrate the type of structure which could be required when opening and closing lightning network channels)
Based on the above design, it can be assumed that only one spending condition will need to be revealed. For example, to spend the output, all the signers need to do is provide one Schnorr multi-signature and the hash at the top of the right hand side of the Merkle tree (Hash (1 & 2)). Therefore despite the existence of a Merkle tree, in the majority of cases, where everything goes as planned, only a single signature and 32-byte hash is required. More concisely, in order to verify a script, you need to prove that it is part of the Merkle tree by revealing other branch hashes.
However, the disadvantage of this structure is that even in normal optimal circumstances, when the single key and script on the top left of the Merkle tree is provided, one still needs to publish another hash to the blockchain (Hash (1 & 2) in the above diagram), using up 32 bytes of data. This weakness also reduces privacy, since third parties can always determine if more complex spending conditions exist, as the top branch of the Merkle tree is always visible.
As far as we can tell, the origins of the Taproot idea are from an email from Bitcoin developer Gregory Maxwell in January 2018. Taproot is similar in construction to MAST, except at the top of the Merkle tree. In the case of Taproot, in the cooperative or normal scenario, there is an option for only a single public key and single signature to be published, without the need to publish evidence of the existence of a Merkle tree. An illustration of the Taproot transaction structure is provided below.
Graphical illustration of Taproot spending conditions
(Source: BitMEX Research)
(Notes: The diagram attempts to illustrate the same spending criteria as the MAST diagram above)
The tweaked public key on the left (or address) can be calculated from the original public key and the Merkel root hash. In the event of a normal or cooperative payment, on redemption, the original public key is not required to be onchain and the existence of the Merkle tree is not revealed, all that needs to be published is a single signature. In the event of a lack of cooperation or abnormal redemption, the original public key is revealed along with information about the Merkle tree.
The benefits of Taproot compared to the original MAST structure are clear, in the cooperative case, one is no longer required to include an extra 32-byte hash in the blockchain or the script itself, improving efficiency. In addition to this, the transactions looks “normal”, just a payment with a public key and signature, the existence of the other spending conditions do not need to be revealed. This is a large privacy benefit, for example when opening a lightning channel or even doing a cooperative lightning channel closure, to an external third party observer, the transaction would look exactly like a regular spend of Bitcoin. The transaction could be structured such that only in an uncooperative lightning channel closure would the existence of the Merkle tree need to be revealed. The more different types of transactions look the same, the better it is for privacy, as third parties may be less able to determine which types of transactions are occurring and establish the flow of funds. A long term objective from some of the Bitcoin developers may be to ensure that, no matter what type of transaction is occurring, at least in the so-called cooperative cases, all transactions look the same.
The confusion over Signature aggregation
The potential scalability benefits of reducing the number of signatures needed on the blockchain are large and therefore the concept tends to generate a lot of excitement. Schnorr signatures do provide the capability to aggregate signatures in multi-signature transactions, which should be a significant benefit to Bitcoin. However, the inclusion of this and the existence of other signature aggregation related ideas, has lead to some unrealistic expectations about the potential benefits, at least with respect to this upgrade proposal. As far as we can tell, for this particular upgrade proposal, the only aggregation benefits are in the form of joining signatures in multi-signature schemes, not for multiple inputs or multiple transactions.
Summary table of signature aggregation ideas
Included in softfork proposal
Combined public key and signatures in multi-signature transactions – Included as part of Schnorr
Joint signature for multiple inputs in a transaction
Joint signature for multiple inputs in multiple transactions (Grin coin has some capabilities in this area, using Mimblewimble)
(Source: BitMEX Research)
In our view, the benefits associated with this softfork are not likely to be controversial. This softfork appears to be a win-win-win for capability, scalability and privacy. The largest area of contention is likely to be the absence of the inclusion of other ideas or arguments over why to do it this particular way.
That being said, many are likely to be excited about the potential benefits of these upgrades and keen to see these activated on the network as fast as possible. However, when it comes to Bitcoin, and in particular changes to consensus rules, the need for patience cannot be overstated.
To better serve customer support requests, we have created a new support page to manage customer inquiries at https://bitmex.com/app/support/contact. We will continue to improve this page with future updates, such as multi-language forms.
Please note that while firstname.lastname@example.org will continue to function until further notice, we recommend customers use this new form to contact the Support team.
Abstract: On 18th April 2019, the BitMEX Research Bitcoin Cash SV node experienced 2 block re-organisations. First a 3 block re-organisation, followed by a 6 block re-organisation. In this brief piece, we provide data and graphics related to the temporary chainsplit. The chainsplit appears to be caused by large blocks which took too long to propagate, rather than consensus related issues. Our analysis shows there were no double spends related to the split.
Chainsplit diagram – 18 April 2019
Source: BitMEX Research Notes: The above image indicates there were two valid competing chains and a non-consensus split occurred at block 578,639. Our node followed the chain on the left until block 578,642, then it jumped over to the right. About an hour later, it jumped back over to the left hand side. The chain on the left continued, while the chain on the right was eventually abandoned.
Chainsplit transaction data
Number of transactions
Main chain (within 6 blocks)
Overlap (within 6 blocks)
Eventual double spends
Source: BitMEX Research
Based on our analysis of the transactions, all the TXIDs from the forked chain (on the right), eventually made it back into the main chain, with the obvious exception of the coinbase transactions. Therefore, it is our belief that no double spends occurred in relation to this incident.
Timestamps of the blocks related to the split – 18 April 2019
If one is interested, we have provided the above table which discloses all the relevant details of the blocks related to the chainsplit, including:
The block timestamps
The local clock timestamps
The block hashes
The block sizes
The total accumulated PoW up to each block
With the above details one can follow what occurred in relation to the chainsplit and create a timeline.
Conclusion Our primary motivation for providing this information and analysis is not driven by an interest in Bitcoin Cash SV, but instead a desire to develop systems to analyse and detect these type of events on the Bitcoin network. Systems are being developed on our website, https://forkmonitor.info, to help detect chainsplits, caused either by poor block propagation or consensus related issues. This event on Bitcoin Cash SV is good practice for us.
As for Bitcoin Cash SV, the block sizes were particularly large during the period of the re-organisations. On the forked chain, the last two blocks were 128MB and 107MB respectively. On the main chain many of the blocks were over 50MB. Therefore, in our view, it is likely the large sizes of the blocks were the root cause of the re-organisations, as miners couldn’t propagate and verify these large blocks fast enough, before other blocks on different chains were found.
As for the implications this has on Bitcoin Cash SV, we have no comment. We will leave that to others.
HDR Global Trading, the owner of BitMEX, has partnered with Trading Technologies International, Inc. (TT), a global provider of high-performance professional trading software. Through the partnership, traders eligible to trade at BitMEX now have access to market-leading trading tools via TT on all BitMEX products, including the flagship XBTUSD Perpetual Swap.
Arthur Hayes, CEO of BitMEX, said: “Like Trading Technologies, BitMEX is committed to providing innovative financial products and a seamless experience for sophisticated traders. By combining our robust technologies, this partnership will not only extend BitMEX’s unique services to Trading Technologies’ discerning clients, but advance our mutual vision to unlock access to cutting-edge cryptocurrency products.”
“This collaboration with BitMEX brings our award-winning trading software to a much broader cryptocurrency market. We expect this partnership will grow trading volume on BitMEX, not only through our existing clients, who want access to cryptocurrencies, but also through new users keen to leverage professional trading software and enjoy better trading experiences,” said Rick Lane, CEO of Trading Technologies.
The TT platform provides professional traders with direct global market access and trade execution through TT’s privately managed infrastructure spanning five continents. Designed specifically for professional traders, brokers, and market-access providers, TT incorporates a broad array of customizable tools to accommodate trading styles that range from manual point-and-click trading to automated order entry.
About Trading Technologies
Trading Technologies (www.tradingtechnologies.com, @Trading_Tech) creates professional trading software, infrastructure and data solutions for a wide variety of users, including proprietary traders, brokers, money managers, CTAs, hedge funds, commercial hedgers and risk managers. In addition to providing access to the world’s major international exchanges and liquidity venues, TT offers domain-specific technology for cryptocurrency trading and machine-learning tools for real-time trade surveillance.
On 2 April 2019 between 04:44:34 UTC and 05:22:08 UTC, less than 200 positions were auto-deleveraged due to the sharp price movements of the underlying mark price on XBTU19 and ETHM19.
At the time of these auto-deleveraging events, the Insurance Fund allocated to these contracts was minimal. The Insurance Fund is allocated individually to each contract according to how many liquidations contribute to that specific contract (System Gains and Losses). In the case of expired contracts, BitMEX has a process in place to roll over the Insurance Fund allocated to these contracts into the next front month contract. With the recent expiry on the 29th March 2019, this process failed and front month contracts did not receive their reallocation, and the funds remained unallocated. As a result, a handful of users were auto-deleveraged upon large liquidations within these affected contracts.
BitMEX receives auto-deleveraging reports and was made aware of the unusually high rate of auto-deleveraging events, at which point we investigated the matter. We identified the root cause, corrected the allocation and put further controls in place to ensure that reallocation failures are automatically flagged internally.
For users that were affected, BitMEX will be reaching out to you personally to explain the situation and document your compensation. We compensated users based on the maximum potential profit that they would have made over the timeframe of these auto-deleveraging events. We exited these users at the best price of each contract: longs at 5,079.5 on XBTU19 and shorts at 0.03103 on ETHM19. BitMEX did not profit from these auto-deleveraged positions.
We apologise for any inconvenience this caused. Should you have any questions, please contact customer support.
On 29 March at 12:00 UTC, BitMEX experienced a minor outage for approximately 15 seconds whereby all requests would have been load shed as the engine was blocked during settlement operations. The platform was back to normal after the 15 second outage.
At 20:13 UTC, the BitMEX website experienced a limited interruption in service to a small group of users. The issue was immediately identified and fixed. The API was not affected.
We apologise for the inconvenience. Should you have any questions, please contact customer support.
Abstract: BitMEX Research examines the market dynamics of Lightning network routing fees and the financial incentives for Lightning node operators to provide liquidity. We identify the interrelationship and balance between Lightning routing fees and investment returns for channel liquidity providers, as a major challenge for the network, rather than the computer science aspects of the routing problem. We conclude that if the Lightning network scales, at least in theory, conditions in wider financial markets, such as changing interest rates and investor sentiment may impact the market for Lightning network fees. However, regardless of the prevailing economic conditions, we are of the view that in the long term, competition will be the key driver of prices. Low barriers to entry into the market could mean the balance favours users and low fees, rather than investment returns for liquidity providers.
We first wrote about the Lightning network back in January 2018, when it was mostly theoretical. Today, as the Lightning network transitions from abstract to experimental, we felt it was time to take another look. The primary focus of this report is to analyse the Lightning network from a financial and investment perspective, notably with respect to fees and the incentives for Lightning network providers. We will not examine other aspects of the technology.
The routing problem
Critics of the Lightning network often point to routing as a major problem, typically making claims like its “an unsolved problem in computer science”. In general, we do not really agree with this characterization of the routing problem and do not see the computer science of routing to be a major challenge, finding paths between channels to make payments may be relatively straightforward and similar to other P2P networks, such as Bitcoin.
However, what we do think its a major challenge is the interaction or balance between the financial and economic aspects of liquidity provision and payment routing. Lightning network node operators need to be incentivised by routing fees to provide sufficient liquidity, such that payments can be made smoothly. Liquidity needs to be allocated specifically to the channels where there is demand and identifying these channels may be challenging, especially when new merchants enter the network. This balance between ensuring the network has low fees for users, while also ensuring fees are high enough to incentivise liquidity providers, is likely to be a significant issue. As we explain further in this article, the magnitude of this problem and the fee rates at which the market clears, may depend on economic conditions.
Lightning fee market dynamics
For onchain Bitcoin transactions, users (or their wallets) specify the fee for each transaction when making a payment and then miners attempt to produce blocks by selecting higher fee transactions per unit block weight, in order to maximise fee revenue. In contrast, Lightning currently appears to work the other way around, routing node operators set the fee and then users select a path for their payment, selecting channels in order to minimise fees. With Lightning, suppliers initially set fees rather than users. Lightning may therefore offer a superior fee architecture, as suppliers are providing a specialised service and it is more suitable that suppliers compete with each other over fee rates, rather than ordinary users, where the priority should be on simplicity.
In Lightning there are two types of routing fees node operators must specify, a base fee and a fee rate.
Two types of Lightning network fees
A fixed fee charged each time a payment is routed through the channel
This is expressed in thousandths of a Satoshi.
For example a base fee of 1,000 is 1 satoshi per transaction.
A percentage fee charged on the value of the payment
This is expressed in millionths of a Satoshi transferred.
For example a fee rate of 1,000 is, 1,000/1,000,000, which is 0.1% of the value transferred through the channel. Equivalent to 10bps.
In order to provide liquidity for routing payments and to earn fee income, Lightning node operators need to lock up capital (Bitcoin) inside payment channels.
Two types of channel capacity
Inbound liquidity, are funds inside the node’s payment channels which can be used to receive incoming payments.
These funds are owned by other participants in the Lightning network.
If the payment channels are closed, these funds will not return to the node operator.
An inbound balance is created in one of two ways:
* When another network participant opens a payment channel with the node
* When the node operator makes a payment via an existing channel
Outbound liquidity, are funds inside the node’s payment channels which can be used to make outbound payments.
These funds are owned by the node operator and part of their investment capital. The node operator may consider the opportunity costs of other investments, while considering the total outbound balance.
If the payment channels are closed, these funds will return to the node operator.
An outbound balance is created in one of three ways:
* When the node operator opens a payment channel with another network node
* When the node operator receives a payment via an existing channel
* When payments are routed through the node and fees are received
Graphical illustration of a channel’s inbound and outbound capacity
(Source: Bitcoin Lightning Wallet) (Note: The orange balance is the inbound capacity, while the blue balance is the outbound capacity)
The operation of the Lightning fee market
Becoming a successful routing node is harder than one may think. At the time of writing, according to 1ml.com, there are 7,615 public Lightning nodes. However, it is likely that only a few hundred of these nodes are doing a good job providing liquidity, by managing the node, rebalancing channels and setting fees in an appropriate manner.
Node operators may need to:
Adjust both fee rates and the base fee, monitor the impact of the adjustments and calibrate for the optimal income maximising settings
Analyse the network and look for poorly connected Lightning nodes with high payment demand, such as a new merchant
Analyse the fee market, not just for the network as a whole, but the high demand low capacity routes you are targeting
Constantly monitor and rebalance ones’ channels, to ensure there is sufficient two way liquidity
Implement a custom backup solution for the latest channel states, to protect funds in the event that the node machine crashes
Currently, there are no automated systems capable of doing the above functions. If this does not change, specialist businesses may need to be setup to provide liquidity for the Lightning network. However, just as with liquidity, the challenges in overcoming these technical issues do not necessarily mean payments will become difficult or expensive. These technical challenges may simply adjust the equilibrium market fee rate. The more difficult these problems are to overcome, the higher the potential investment returns will be to channel operators and the greater the incentive will be to fix the problems. It will be demand that drives Lightning’s success, not the challenges for node operators.
In order for Lightning fee markets to work, node operators may need to adjust fees based on the competitive landscape, this could be based on algorithms or be a manual process, aimed at maximising fee income. In an attempt to emulate what may eventually become standard practise, BitMEX Research experimented with modifying the fee rate on one of our nodes over a three month period, as the below section reveals.
Fee rate experimentation
BitMEX Research decided to conduct a basic experiment to try and evaluate the state of the fee market, even in the Lightning network’s current nascent state. We set up a Lightning node and regularly changed the fee rate to attempt to determine which rates would maximise fee revenue, just as node operators may eventually be expected to do as the network scales.
Our basic non-scientific analysis from one node is illustrated in the scatter chart below. It appears to indicate that fee rates do currently have an impact on a lighting node’s fee income. The daily fee income appears to quickly accelerate as one increases the fee rate from 0 till around 0.1 bps. Once the fee is increased above this rate, average daily fee income appears to gradually decline. Therefore, based on this experiment, it appears as if the revenue maximising fee rate is around 0.1 bps, which is certainly very low when compared to other payment systems. However, of course, this is only the fee for one hop, a payment may have multiple hops. At the same time, the current Lightning fee market is barely exists, indeed BitMEX Research may be one in only a handful of Lightning nodes that has significantly experimented with economic revenue maximising behaviour by changing fees. Once the network scales and other parties try to maximise revenue, fee market conditions are likely to be very different. This exercise should therefore only be considered as an illustrative experiment, rather than anything particularly revealing about lighting fee markets.
Lightning node daily fee income versus the feerate
(Source: BitMEX Research) (Lightning fee income data charts – notes and caveats: * Daily data from 31st December 2018 to 24th March 2019 * Data from one Lightning node * The base fee was 0 across the period * The investment return data excludes onchain Bitcoin transaction fees, when including the impact of fees all but the most optimal fee rate buckets would show a negative investment return * The data includes both weekdays and weekends, in general Lightning network traffic is significantly lower at weekends * The fee rate was changed every day at around 21:00 UTC. The fee rate was reduced each day and then jumped up to the top of the fee rate range after several days of declines, to begin the next fee rate downwards cycle. The reason for this was that some wallets (e.g. mobile wallets) did not always query the fee rate each time it attempted to route a payment through the node, therefore when increasing the fee rate, many payments would fail. For example, when opening a channel from a mobile wallet to the Lightning node, then increasing the fee rate and immediately attempting to make a payment, the payment often failed as the wallet attempted to pay with a fee which was too low. In our view, in order to Lightning network fee markets to work, node operators may need to regularly change fees and therefore wallets may need to query fee rates more often * Channel rebalancing occurred manually, once every two weeks. Approximately 30 minutes was spent on each occasion * The Lightning node was running LND and the software was updated to the master every two weeks * Approximately 30% of the channels (by value) were opened using the autopilot, the other 70% were opened manually * The investment return was calculated by taking the outbound channel capacity of the network each day, annualising the investment return based on the daily fee income and then calculating a simple average based on all the days with a fee rate inside the particular range * The data is based on one node only and its particular set of channels, the experience for other node operators may be very different * We tried to use our public node for this experiment, however the fee income was too sporadic, with some network participants regularly paying well above the advertised fee rates by considerable amounts, making the data unreliable * Unfortunately we needed to use a log scale for both axis. With respect to the fee rate we were unsure of which rates to charge, even which order of magnitude to set, therefore we tried a wide range of fees, from 0.0001% to 0.5% and a log scale was appropriate. At the same time, the daily fee income was highly volatile, ranging from 0 satoshis to over 3,000 satoshis. Therefore a log scale was deemed most appropriate. As the network develops and fee market intelligence improves, a linear scale may be more appropriate)
Fee incomes and investment returns
In addition to daily fee income, one can also consider the annualized investment return associated with running a lighting node and the various fee rates. This is calculated by annualising the daily fee income and dividing this number by the daily outbound liquidity.
The highest annualised investment investment return achieved in the experiment was 2.75%, whilst the highest fee bucket investment return was almost 1%. This seems like a reasonably attractive return for what should in theory be a relatively low risk investment, at least once the ability to backup lighting channels in real time becomes implemented. Existing Bitcoin investors could be tempted by these returns and provide liquidity to the Lightning network, or alternatively US dollar based investors could buy Bitcoin, hedge the Bitcoin price exposure using leverage and then attempt to earn Lightning network fee income.
Lightning node annualised investment return by fee bucket
(Source: BitMEX Research)
Of course, liquidity providers in the current Lightning network are not likely to be motivated by investment returns. Current node operators are likely hobbyists, with the overwhelming majority of node operators making losses when considering the onchain fees required to open and rebalance Lightning channels. Although this hobbyist based liquidity probably can sustain the network for a while, in order to meet the ambitious scale many have for the Lightning network, investors will need to be attracted by the potential investment returns.
Lightning network fees and economic conditions
A 1% investment yield may seem attractive in the current low yield environment, however the Lightning network may initially have difficulty attracting the right commercial liquidity providers. Investors in this space are typically looking for a high risk high return investment, which appears to be the opposite end of the spectrum for the relatively low risk low return investment on offer for Lightning liquidity providers. Therefore a new type of investor, one that fits this profile, may be needed.
If the Lightning network reaches a large scale, it is possible that the highly liquid investment product, with stable low risk returns, is sensitive to economic conditions.
Consider the following scenario:
The federal reserve base rate is 1.0%
Lightning node operators are typically earning an annualised investment yield of 1.5% on their outbound balance
Due to robust economic conditions and inflationary pressure, the federal reserve open market committee increase interest rates from 1% to 3%.
Due to the more attractive investment returns, Lightning network node operators withdraw capital from the Lightning network and purchase government bonds
Due to the lower levels of liquidity in the Lightning network, users are required to pay higher fees to route payments and the Lightning network becomes more expensive
However, if Lightning network liquidity is large enough for the above logic to apply, Lightning would have already been a tremendous success anyway.
The risk free rate of return
In some ways, if the Lightning network matures, one can even think of the investment returns from running a Lightning node as Bitcoin’s risk free rate of return, or at least a rate of return free from credit risk. In traditional finance this is often the rate investors earn by holding government bonds, where the government has a legal obligation to pay the principal and coupon and a means to create new money to pay the holders of the bonds, such that the risks are near zero. In theory, all other investment projects or loans in the economy should have a higher return than this risk free rate. The same could apply to Bitcoin, with Lightning node liquidity providers return rates being considered as the base rate within the Bitcoin ecosystem.
In the future, if most of the technical challenges involved in running nodes have been overcome and there are competitive fee setting algorithms, this Lightning network risk free rate could ultimately be determined by:
Conditions in wider financial markets – higher interest rates could mean a higher Lightning network risk free rate
The demand for Lighting network transactions – more demand or a higher velocity of money, should increase the Lightning network risk free rate
Whether specialist hedge funds and venture capital investors will have the same enthusiasm about becoming Lightning network liquidity providers, as they did for the “staking as a service” business model for proof of stake based systems in mid 2018 remains to be seen. While the investment returns for Lightning network liquidity providers do not yet look compelling, with the network in its formative stages, we do see potential merit in this business model.
In our view, the Lightning network can easily scale to many multiples of Bitcoin’s current onchain transaction volume without encountering any economic fee market cycles or issues, all based purely on hobbyist liquidity providers. However, if the network is to reach the scale many Lightning advocates hope, it will need to attract liquidity from yield hungry investors seeking to maximise risk adjusted investment returns. Should that occur, unfortunately the network may experience significant changes in fee market conditions as the investment climate changes over time.
However, it is relatively easy to set up a node, provide liquidity and try to earn fee income by undercutting your peers. Where the balance is ultimately struck between the operational channels of running nodes, the extent of liquidity provision and the investment returns, we obviously do not know. However, if we are forced to guess, based on the architecture and design of the Lightning network, we would say the system is somewhat rigged towards users and low fees, rather than liquidity providers.