Lightning Network (Part 3) – Where Is The Justice?

Abstract: In our third look at the lightning network, we examine lightning channel closure scenarios and the incentives to punish dishonest parties and prevent them from stealing funds. This punishment mechanism is called a “Justice Transaction”. We explain how to arbitrarily construct a “Justice” scenario and present data on the prevalence of this type of transaction on the Bitcoin network. We have potentially identified 241 Justice transactions, representing 2.22 Bitcoin in value, since the lightning network launched at the end of 2017.

(Lightning strikes the city of Singapore)

Overview

Following on from our January 2018 discussion of the motivation behind the lightning network and our March 2019 analysis of lightning network routing fee economics, this third piece on the lightning network looks at channel closures and the incentives designed to prevent dishonest lightning nodes from stealing funds, by broadcasting an earlier channel state.

It should be noted that, by design, when a thief attempts to steal funds on the lightning network, if caught, they do not only lose the money they tried to steal, they lose all the funds in the relevant channel. This “punishment” is expected to act as a deterrent and is sometimes called “justice”.

The four lightning channel closure scenarios

Opening lightning channels is, generally speaking, more simple than closing them, there is only one way to open a lightning channel, cooperatively with interactive communication between the parties. On the other hand, when evaluating channel closures, one needs to consider four different scenarios, as outlined in the decision tree below (See figure 1).

Figure 1 – Lightning network channel closure types – decision tree

(Source: BitMEX Research)

Figure 2 – The four lightning channel closure scenarios explained

Closure type Description Onchain technical details and example transactions
This is the most common scenario.

A cooperative closure occurs when an honest node initiates the channel closure, while the node on the other side of the channel is online and communicating.

Funds are distributed to each party’s onchain wallet based on the latest channel state.

A cooperative closure requires only one onchain transaction.

Inputs are redeemed using a “normal” 2 of 2 multi-signature script and sent to two outputs, each belonging to the parties involved, with the balance based on the latest channel state. 

This transaction is hard to identify as lightning and therefore it is the most private of the three channel closure types.

Example closure:

A non-cooperative non-breach closure occurs when an honest node initiates the closure, without directly communicating with the node on the other side of the channel.

Funds are distributed to each party’s onchain wallet based on the latest channel state.

These two different economic scenarios, are represented by one technical onchain scenario.

This scenario requires two onchain transactions. 

Firstly the funds are redeemed using a 2 of 2 multi-signature witness and sent to two outputs. The node which did not initiate the closure is allocated funds based on what the channel closing party says is attributable to them, while another pot of funds is sent to an output which can be redeemed by using either an OP_IF or an OP_ELSE script. 

In a second transaction, the funds sent to the OP_IF script, are claimed by the party that initiated the channel closure, using the OP_ELSE branch of Bitcoin script.

Example closure:

A non-cooperative breach non-justice closure occurs when a dishonest node initiates the channel closure, by broadcasting an earlier channel state, attempting to steal funds from the node on the other side of the channel.

The non closing node does not check the network within the locktime period, normally 24 hours and does not broadcast a justice transaction. Therefore the theft is successful.

Funds are distributed to each party’s wallet based on an earlier channel state, such that the non closing party losses funds and the dishonest channel closing party successfully steals funds.

A non-cooperative breach justice closure occurs when a dishonest node initiates the channel closure, without directly communicating with the node on the other side of the channel.

The non closing node does check the network within the locktime period, and creates a justice transaction, such that the attempted theft fails.

The would-be thief is punished and all the funds go to the honest non closing party.

In the justice scenario, two onchain transactions are also required. 

In the first transaction, the funds are redeemed using a 2 of 2 multi-signature witness and sent to two outputs. The node which did not initiate the closure is allocated funds based on what the channel closing party says is attributable to them, while another pot of funds is sent to an output which can be redeemed by using either an OP_IF or an OP_ELSE script.

In a second transaction, the honest node, that did not initiate the closure claims all the funds sent to the OP_IF script, using the OP_IF branch.

This is the most revealing of the three channel closure types and provides the lowest level of privacy.

Example closure:

How to construct a Justice transaction?

In the below arbitrary scenario, we manually created a justice transaction, using the following steps:

1. Spin up a new lightning network node (LND), with the alias “BitMEXThief” and open a channel, worth US$50 (400,000 Satoshis) with the BitMEXResearch lightning node
2. Switch off the BitMEXThief node and back up the .lnd directory
3. Restart the BitMEXThief node and make a lightning payment of US$25 (200,000 satoshis) to BitMEXResearch. The channel is now balanced, US$25 in both directions
4. Switch off the BitMEXThief node again
5. Switch off the BitMEXResearch lightning node (to prevent it broadcasting the latest channel state to the thief node)
6. Restore the BitMEXThief node back to its state prior to the channel re-balancing, the state in step 2
7. On the restored BitMEXThief node, attempt to close the channel from its earlier state and claim the full US$50 (400,000 satoshis) to the BitMEXThief node’s onchain wallet
8. Restart the BitMEXResearch node. The node then automatically detects the attempted theft and broadcasts the “justice transaction”, sending the full US$50 (less fees) to its onchain wallet. The would be thief was punished, by losing all the funds inside the channel. Note that the thief attempted to steal US$25, but ended up losing the full US$50.

The above experiment occurred successfully, providing some assurance that Lightning does actually work and if you try to steal, you will be punished.

Network Justice transaction data

After conducting our own justice transaction, we looked at the characteristics of this transaction (Inputs redeemed using the OP_IF branch) and searched for other justice transactions on the Bitcoin blockchain. We identified 241 transactions, which appear to be justice channel closures, dating back as far as December 2017. Mr. Alex Bosworth, from Lightning Labs, has created a tool to identify justice transactions, which may be more robust than our more basic search methodology.

Figure 3 – Number of justice transactions – monthly

(Source: BitMEX Research)

(Note: There is a possibility the data includes false positives)

Figure 4 – Value redeemed in justice transactions – monthly (BTC)

(Source: BitMEX Research)

(Note: There is a possibility the data includes false positives)

The justice transactions we identified had transaction inputs totaling 2.22 BTC, with the monthly total peaking at around 0.67BTC in February 2019, as figure 4 above illustrates. This does not necessarily mean thieves tried and failed to steal 2.22 BTC, as the dis-honest nodes may have punished thieves by a amount larger than the value they tried to steal (we do not know the latest channel state). The 2.22 BTC represents the total funds claimed by honest non channel closing nodes, part of this value is funds originally owned by the dis-honest nodes and part of the value will be the value they tried to steal.

It is also possible that many of the 241 justice transactions do not indicate genuine dishonestly, for instance it could be users testing the system, where the same user owns both lightning nodes in question. For example BitMEX Research is responsible for 5 of the 241 justice transactions, when there was no victim, as BitMEX owned all the nodes and funds.

241 justice transactions, with a value of just over 2 BTC is reasonably small relative to the size of the lightning network. The lightning network statistics website 1ml.com, indicates that there are currently 940 BTC locked up in 32,951 channels. The total number of justice transactions in the last 18 months is therefore only 0.7% of the current number of lightning channels.

Conclusion

In order for the lightning network to succeed as a robust, reliable and scalable payment system, the justice mechanism needs to be effective in deterring and preventing theft. As for the optimal justice rate, this is hard to determine, if it is too high and it shows that successful thefts may be too prevalent and the threat of justice may not be sufficient. If it is too low, it may mean nobody is attempting theft, thereby increasing the risk that users do not monitor their channels. This may lead to increases in the risk of large systemic channel thefts in the future.

For now, at least according to the data we have analysed, there appears to be a reasonable degree of justice on the burgeoning lightning network.

Facebook Takes on ETF Giant Blackrock, with a Fixed Income ETF called Libra

Abstract: In a bold move, social networking giant Facebook, has challenged the traditional finance and ETF industry, with its “Libra coin”, or as we call it the “Libra ETF”. We note that there are many unanswered questions about Libra, which may lack transparency, when compared to traditional ETFs. Another key disadvantage of Libra is that unlike with legacy ETFs, investment income is not distributed to unit holders. We conclude that although Libra has significant disadvantages when compared to traditional ETF products, Facebook’s wide consumer reach with platforms such as Whatsapp and Instagram could give Libra a key commercial advantage.

(Facebook vs Blackrock – The battle for the ETFs)

Overview

The structure of Libra is analogous to the popular Exchange Traded Fund (ETF) model, where unit holders are entitled to the financial returns of a basket of financial assets. The units are tradable on exchanges and a select group of authorised participants are able to create and redeem units using the underlying assets.

As we pointed out in our February 2019 piece, the ETF industry has enjoyed considerable growth in the last decade or so, in particular in the area of fixed income (See figure 1 below). In June 2019, in a bombshell moment for the ETF industry and challenge for the established players such as Blackrock and Vanguard, social media and internet conglomerate Facebook, entered the game. In a direct challenge to Blackrocks’s “iShares Core U.S. Aggregate Bond ETF” (AGG), Facebook announced plans to launch a new ETF, the “Libra ETF”, also focused on fixed income and government bonds.

Figure 1 – Size of the Top Bond ETFs Targeting US Investors – US$ Billion

(Source: BitMEX Research, Bloomberg)

(Note: The chart represents the sum of the market capitalisations of the following bond ETFs: iShares Core U.S. Aggregate Bond ETF, Vanguard Total Bond Market ETF, iShares iBoxx $ Investment Grade Corporate Bond ETF, Vanguard Short-Term Corporate Bond ETF, Vanguard Short-Term Bond ETF, Vanguard Intermediate-Term Corporate Bond ETF, iShares J.P. Morgan USD Emerging Markets Bond ETF, Vanguard Total International Bond ETF, iShares MBS Bond ETF, iShares iBoxx $ High Yield Corporate Bond ETF, PIMCO Enhanced Short Maturity Strategy Fund, Vanguard Intermediate-Term Bond ETF, iShares Short-Term Corporate Bond ETF, SPDR Barclays High Yield Bond ETF, iShares Short Maturity Bond ETF)

Comparing the new ETF structure with the traditional space

In figure 2 below, we have analysed and compared the new innovative Libra ETF to a traditional ETF, Blackrock’s iShares Core US Aggregate Bond ETF (AGG). Our analysis shows that, although the Libra product is new, much of the relevant information, such as transparency of the holdings and frequency of the  publication of the NAV, has not yet been disclosed.

The analysis also highlights that Libra may suffer from unnecessary complexity with respect to portfolio management. The fund appears to be managed by the Libra Association, which consists of many entities in multiple industries across the globe. These same entities are responsible for issuing the ETF and the list of companies is set to expand further. At the same time, the investment mandate is unclear. In contrast Blackrock’s fixed income ETF product has a clear investment mandate, to track the Bloomberg Barclays U.S. Aggregate Bond Index, which is managed independently of the ETF issuer.

Perhaps the most significant disadvantage of the Libra product, is that unit holders do not appear to be entitled to receive the investment income. This contrasts unfavourably with Blackrock’s product, which focuses on an almost identical asset class and has an investment yield of around 2.6%. Defenders of Libra could point out that the expenses need to be covered from somewhere and that the Libra’s expense fee is not yet disclosed. However, the ETF industry is already highly competitive, with Blackrock charging an expense fee of just 0.05%. This expense fee is far lower than the expected investment yield of the product, at around 2.6% and therefore the Libra ETF may not be price competitive, a key potential disadvantage for potential investors.

Figure 2 – Libra ETF vs iShares Core U.S. Aggregate Bond ETF (AGG) – Detailed Comparison

  Libra ETF

iShares Core U.S. Aggregate Bond ETF (AGG)

Launch date June 2019 September 2003
IssuerThe Libra Association/Facebook Blackrock
AuM Unknown

US$63.5 billion

Asset class

Fixed Income

Bank deposits and government securities in currencies from stable and reputable central banks

Fixed income – Investment grade government and corporate bonds
Underlying Index Unknown/Not applicable Bloomberg Barclays U.S. Aggregate Bond Index

Portfolio managers

The Libra Association, based in Switzerland will manage the reserve. The investment mandate is not currently disclosed. The current members are as follows:
  • Mastercard
  • PayPal
  • PayU (Naspers’ fintech arm)
  • Stripe
  • Visa
  • Booking Holdings
  • eBay
  • Facebook/Calibra
  • Farfetch
  • Lyft
  • MercadoPago
  • Spotify
  • Uber
  • Iliad
  • Vodafone Group
  • Anchorage
  • Bison Trails
  • Coinbase
  • Xapo
  • Andreessen Horowitz
  • Breakthrough Initiatives
  • Ribbit Capital
  • Thrive Capital
  • Union Square Ventures
  • Creative Destruction Lab,
  • Kiva
  • Mercy Corps
  • Women’s World Banking

James Mauro and Scott Radell, with a clear constrained mandate to track the index

Fees

Unknown

0.05%

Investment yield

Unknown

2.6%

Use of investment income

Unit holders are not entitled to investment income Investment income will:

first go to support the operating expenses of the association — to fund investments in the growth and development of the ecosystem, grants to nonprofit and multilateral organizations, engineering research, etc. Once that is covered, part of the remaining returns will go to pay dividends to early investors in the Libra Investment Token for their initial contribution

Attributable to ETF unit holders

Available exchanges

Currently None

The Libra Association

will encourage the listing of Libra on multiple regulated electronic exchanges throughout the world

NYSE

Creation/redemption basket size

Unknown

100,000 units

Authorized Participants (entities able to create and redeem units)

Authorized resellers, not currently disclosed

Investment Banks

Fund auditor

Unknown

PwC

Information about holdings and Net Asset value (NAV)

Unknown

Full disclosure (Published daily)

(Sources: iShares, Libra)

We have also analysed the two alternatives from a technical perspective. As figure 3 below indicates, the key difference is that control of Libra tokens may in part be managed by digital signatures. As long as no whitelist of addresses is implemented, this may provide some advantages:

  • Pseudonymity
  • A limited amount of censorship resistance
  • Relatively easy integration with cryptocurrency exchanges

However, as we mentioned in our Tether report in February 2018, history has shown that these characteristics can cause platforms to ultimately face a choice between implementing KYC or face being shut down by the authorities. Facebook has already censored politically controversial figures on its main platform, therefore it may appear likely the extent to which Libra ETF units are managed by public private key cryptography is significantly constrained or eventually becomes phased out.

Figure 3 – Technical and cryptographic considerations

 

Libra ETF

iShares Core U.S. Aggregate Bond ETF (AGG)

Consensus system

Not applicable (An ETF does not require a consensus system)

Blockchain

Not relevant (Grouping records of ETF transactions into a chain of blocks linked together by hashing, is inconsequential for ETFs)

Control of units based on digital signature

Possibly:

The Libra Blockchain is pseudonymous and allows users to hold one or more addresses that are not linked to their real-world identity

No

(Sources: iShares, Libra)

Conclusion

Despite the key disadvantage, namely that Libra unit holders are not entitled to the investment income, many industry analysts are carefully examining the impact Libra could have on the traditional ETF industry and existing electronic payment systems.

While our comparison to ETFs is a bit tongue and cheek, it does highlight that the structure of the product has similar attributes to existing financial products. We therefore think it is an appropriate comparison, and if Libra wants to be competitive, it should emulate some of the governance and fee characteristics of traditional ETFs.

However, Libra could attract clients due to integration with platforms such as Facebook, Whatsapp and Instagram. If Libra does retain the property of allowing coins to be controlled by private keys, this is an interesting development and the coin is likely to gain share from tokens such as Tether. However, in our view, in the long run, it is likely Libra either disables this feature or makes it technically difficult, such that only a tiny minority of users have these “non-custodial” wallets. If that happens, Libra is nothing more than a high fee ETF.

HDR Global Trading Limited Donates to the Massachusetts Institute of Technology’s Digital Currency Initiative (MIT DCI) In Support of Cryptocurrency Research

We are delighted to announce HDR Global Trading Limited’s support of the MIT Digital Currency Initiative, which conducts research into the development and betterment of the global cryptocurrency ecosystem.

Sam Reed, CTO of HDR Global Trading and co-founder of the BitMEX trading platform, announced the sponsorship:

Our company has always been energized by the potential of cryptocurrency. Our donation into research and development is about ensuring that the network is more robust. A stronger Bitcoin network will be beneficial to all, and we are very excited to be able to aid in its progress.

HDR Global Trading owns and operates BitMEX, the world’s largest cryptocurrency trading platform by volume. HDR Global Trading is proud to support Bitcoin research and engineering that will make Bitcoin stronger, improving Bitcoin’s robustness, scalability and privacy.

In particular, HDR is keen to help support the work of Bitcoin Core developers Wladimir van der Laan and Cory Fields. Their roles have important implications on different parts of the Bitcoin protocol.

The donation is provided unconditionally and without restrictions.

The Bitcoin Cash Hardfork – Three Interrelated Incidents

Abstract: The 15 May 2019 Bitcoin Cash hardfork appears to have suffered from three significant interrelated problems. A weakness exploited by an “attack transaction”, which caused miners to produce empty blocks. The uncertainty surrounding the empty blocks may have caused concern among some miners, who may have tried to mine on the original non-hardfork chain, causing a consensus chainsplit. There appears to have been a plan by developers and miners to recover funds accidentally sent to SegWit addresses and the above weakness may have scuppered this plan. This failure may have resulted in a deliberate and coordinated 2 block chain re-organisation. Based on our calculations, around 3,392 BCH may have been successfully double spent in an orchestrated transaction reversal. However, the only victim with respect to these double spent coins could have been the original “thief”.

Illustration of the Bitcoin Cash network splits on 15 May 2019

(Source: BitMEX Research)
(Notes: Graphical illustration of the split)

The three Bitcoin Cash issues

Bitcoin Cash’s May 2019 hard fork upgrade was plagued by three significant issues, two of which may have been indirectly caused by a bug which resulted in empty blocks. The below image shows the potential relationships between these three incidents.

The relationships between the three issues faced by Bitcoin Cash during the hardfork upgrade

(Source: BitMEX Research)

The empty block problem

Bitcoin ABC, an important software implementation for Bitcoin Cash, appears to have had a bug, where the validity conditions for transactions to enter the memory pool may have been less onerous than the consensus validity conditions. This is the opposite to how Bitcoin (and presumably Bitcoin Cash) are expected to operate, consensus validity rules are supposed to be looser than memory pool ones. This is actually quite an important characteristic, since it prevents a malicious spender from creating a transaction which satisfies the conditions to be relayed across the network and get into a merchants memory pools, but fails the conditions necessary to get into valid blocks. This would make 0-confirmation double spend attacks relatively easy to pull off, without one needing to hope their original payment doesn’t make it into the blockchain. In these circumstances, an attacker can be reasonably certain that the maliciously constructed transaction never makes it into the blockchain.

An attacker appears to have spotted this bug in Bitcoin Cash ABC and then exploited it, just after the hardfork, perhaps in an attempt to cause chaos and confusion. This attack could have been executed at any time. The attacker merely had to broadcast transactions which met the mempool validity conditions but failed the consensus checks. When miners then attempted to produce blocks with these transactions, they failed. Rather than not making any blocks at all, as a fail safe, miners appear to have made empty blocks, at least in most of the cases.

Bitcoin Cash – Number of transactions per block – orange line is the hardfork

(Source: BitMEX Research)

The asymmetric chainspilt

At the height of the uncertainty surrounding the empty blocks, our pre-hardfork Bitcoin ABC 0.18.2 node received a new block, 582,680. At the time, many were concerned about the empty blocks and it is possible that some miners may have reverted back to a pre-hardfork client, thinking that the longer chain was in trouble and may revert back to before the hardfork. However, this is merely speculation on our part and the empty block bug may have had nothing to do with the chainsplit, which could have just been caused by a miner who was too slow to upgrade.

Bitcoin Cash consensus chainsplit

(Source: BitMEX Research)

The chainsplit did highlight an issue to us with respect to the structure of the hardfork. We tested whether our post hardfork client, ABC 0.19.0, would consider the non-hardfork side of the split as valid. In order for the break to be “clean”, each side of the split should consider the other as invalid.

In order to test the validity of the shorter pre-hardfork chain, from the perspective of the Bitcoin ABC 0.19.0 node, we had to invalidate the first hardfork block since the split. We then observed to see whether the node would follow the chainsplit or remain stuck at the hardfork point. To our surprise, as the below screenshot indicates, the node followed the other side of the split. Therefore the split was not clean, it was asymmetric, potentially providing further opportunities for attackers.

Screenshot of the command line from our Bitcoin ABC 0.19.0 node

(Source: BitMEX Research)

The coordinated two block re-organisation

A few blocks after the hardfork, on the hardfork side of the split, there was a block chain re-organisation of length 2. At the time, we thought this was caused by normal block propagation issues and did not think much of it. For example, Bitcoin SV experienced a re-organisation a few weeks prior to this, of 6 blocks in the length. When Bitcoin SV re-organised, all transactions in the orphaned chain eventually made it into the main winning chain (except the Coinbase transactions), based on our analysis. However, in this Bitcoin Cash re-organisation, we discovered that this what not the case.

The orphaned block, 582,698, contained 137 transactions (including the Coinbase), only 111 of which made it into the winning chain. Therefore a successful 2 block double spend appears to have occurred with respect to 25 transactions. The output value of these 25 transactions summed up to over 3,300 BCH, as the below table indicates.

List of transactions in the orphaned block (582,698) which did not make it into the main chain

Transaction ID

Output total (BCH)

1e7ed3efb7975c06ca46598808e17c6f42c66a085fcb65356dc090e3c434d874

Coinbase (not counted)

0cdd5afff40831199d78ac55116a94aaf4ea7d53e599ac44962c29861ef9f05e

79.9

1907e59313a5c2607f706e8439feb613ed3ff89530d17bd9deced7113928df79

358.9

27553ff15a9d58b10b33da69bef3ccd570c007fc0d695cf8b88817cfc4d49065

65.2

2ff74d9b244469dcd87f9c853b70f9bc72d4116c662ee12783a1c32a6825d45e

196.3

357e31bcf17b4d557954b2d69b7169559a64605a628c4bb9eb11adbd416967d1

117.4

3801dc4ee11ccaeda243ac287ee5e40afb0f07dc0ba26f534ea52f4bfde0d3da

161.2

83e6065dd31ef706f6a90669e460000741820c4dcb753290bd2b003a9f853211

71.2

8950cae069562893aa3583b75fd14f2aaef4f0db72292bd05e11f915ca38cd86

107.8

8e10f1f85d9707ca974ddabd9cb8188d0b890586781ef4161a9133dadefbe0e6

72.0

8fc0b3665f4734b56686ffec83f6b23000720af90102e20f39d9dddb5f1f5c25

183.0

99bd320fb7e3fc487b393c3b9afbc6a7bc765d7f9df5902201a70d3cb8fc5a63

57.8

a38b43f85cc592c4bd69b2b1f0f865df6d36f3b89dfa6119780197369e48192a

177.8

b091bf34d72444ff1669dd13b6c912d8801b94aad8a92d162a9680d46d4b727f

89.2

bd8ee13735dcbdad983fe9624c5b3fd3d257b15a62b269ddb40bb4be9d4a15cb

100.5

beae5bc9137beebddea6f5fbc6fe79b77f6d59f2aa2a5da675ccc39b2b2f8cb6

166.3

c47d1c18c39d28df21ce0e3c34021295658b56c7e669af3aebe685cea32462dc

210.3

c8031b2fd429d9e2838dccc7fa0631788139443a7609958c5d2ce195aec97f8a

85.7

cf3af954a7c3b327107aa42498ec31924075bd926a61428352695a696af8d6c4

114.8

cf8f47928c37bc24c88ff8ff8ea3c84419d4cedc907e74d113e681b055c566dc

162.0

dff4537328f2568db5b7f0fa81a57024fdeb9da23a432a893fb48eca1ab63079

115.9

e1398e628da1258db08f969efdade13e6daac6a53e5b43121dab3604c605af29

69.9

e926ce8ca0192b3ea7f971d93eec3f651e8a35839a76101512cb8c37f98caa89

126.8

e9e0482d61300d3b3d6a9340f9ee66bd6d098328cd7ced50416bb28eb8dc796e

307.4

ebc4392b27056b84a0337638f1257031172d842c148f9ffa10e80afc4080d8a1

           82.7

f81267d65855040bf08bb5291a87733555067041ab611cd4e874368c8c1a2c2a

111.9

Total

3,391.7

(Source: BitMEX Research)

As the above table shows, the total output value of these 25 double spent transactions is 3,391.7 BCH, an economically significant sum. Therefore, one may conclude that the re-organisation was an orchestrated event, rather than it having occurred by accident. If it occurred by accident, it is possible there would be no mismatch between the transactions on each side of the split. However, assuming coordination and a deliberate re-org is speculation on our part.

We have provided two examples of outputs which were double spent below:

Example of one of the double spent UTXOs – “0014”

(Source: BitMEX Research)

The above table illustrates what happened to a 5 BCH output during the re-organisation. The 5 BCH was first sent to address qzyj4lzdjjq0unuka59776tv4e6up23uhyk4tr2anm in block 582,698. This chain was orphaned and the same output was eventually sent to a different address, qq4whmrz4xm6ey6sgsj4umvptrpfkmd2rvk36dw97y, 7 block later.

Second example of one of the double spent UTXOs – “0020”

(Source: BitMEX Research)

What happened to the above outputs shares characteristics with almost all the funds in the 25 double spent transactions. Most of the outputs appear to have been double spent around block 582,705 on the main chain, around 7 blocks after the orphaned block.

The SigScript, used to redeem the transaction inputs, starts with “0020” or “0014”, highlighted in the above examples. These may relate to Segregated Witness. According to the specification in Segregated Witness, “0014” is pushed in P2WPKH (Pay to witness public key hash) and “0020” is pushed in P2WSH (Pay to witness script hash). Therefore the redemption of these inputs may have something to do with Segregated Witness, a Bitcoin upgrade, only part of which was adopted on Bitcoin Cash.

Indeed, based on our analysis, every single input in the 25 transactions in the orphaned block 582,698 was redeemed with a Sigscript starting “0014” or “0020”. Therefore it is possible that nobody lost funds related to this chain re-organisation, other than the “attacker” or “thief” who redeemed these SegWit outputs, which may have accidentally been sent to these outputs in the first place.

As part of the Bitcoin Cash May 2019 hardfork, there was a change to allow coins which were accidentally sent to a SegWit address, to be recovered. Therefore, this may have occurred in the incident.

Allow Segwit recovery

In the last upgrade, coins accidentally sent to Segwit P2SH addresses were made unspendable by the CLEANSTACK rule. This upgrade will make an exemption for these coins and return them to the previous situation, where they are spendable. This means that once the P2SH redeem script pre-image is revealed (for example by spending coins from the corresponding BTC address), any miner can take the coins.

(Source: https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/2019-05-15-upgrade.md)

It is possible that this 2 block re-organisation is unrelated to the empty block bug. However, the split appears to have occurred just one block after the resolution of the bug, therefore it may be related. Perhaps the “honest” miners were attempting to coordinate the spend of these outputs directly after the split, perhaps to return them to the original owners and the empty block bug messed up their timing, allowing the attacker to benefit and sweep the funds.

On the other hand, the attack is quite complex, therefore the attacker is likely to have a high degree of sophistication and needed to engage in extensive planning. Therefore, it is also possible this attack may have been effective even without the empty block bug.

Conclusion

There are many lessons to learn from the events surrounding the Bitcoin Cash hardfork upgrade. A hardfork appears to provide an opportunity for malicious actors to attack and create uncertainty and therefore careful planning and coordination of a hardfork is important. On the other hand, this empty block bug, which may be the root cause of the other 2 incidents, could have occurred at any time and trying to prevent bugs like this is critical whether one is attempting to harfork or not.

Another key lesson from these events is the need for transparency. During the incidents it was difficult to know what developers were planning, the nature of the bugs, or which chain the miners were supporting. Open communication in public channels about these issues could have been more helpful. In particular, many were unaware of an apparent plan developers and miners had to coordinate and recover lost funds sent to SegWit addresses. It may have been helpful if this plan was debated and discussed in the community more beforehand, as well as during the apparent deliberate and coordinated re-organisation. Assuming of course if there was time to disclose the latter. It may also be helpful if those involved disclose the details about these events after the fact.

The largest concern from all of this, in our view, is the deliberate and coordinated re-organisation. From one side of the argument, the funds were stolen, therefore the actions were justified in returning the funds to their “rightful owners”, even if it caused some short term disruption. However, the cash like transaction finality is seen by many, or perhaps by some, as the only unique characteristic of these blockchain systems. The ability to reverse transactions, and in this case economically significant transactions, undermines the whole premise of the system. Such behavior can remove incentives to appropriately secure funds and set a precedent or change expectations, making further reversals more likely.

For all those in the Bitcoin community who dislike Bitcoin Cash, this could be seen as an opportunity to laugh at the coin. However, although Bitcoin Cash has a much lower hashrate than Bitcoin, making this reversal easier, the success of this economically significant orchestrated transaction reversal on Bitcoin Cash is not positive news for Bitcoin in our view. In some ways, these incidents contribute to setting a dangerous precedent. It shows that it may be possible in Bitcoin. Alternatively, this could just illustrate the risks Bitcoin Cash faces while being the minority chain.

Initial Exchange Offerings

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.

Overview

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.

ICO market

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

ICO Name
Funds raised – US$m
Return based on average ICO price
EOS
4,234
(4%)
Telegram
1,700
Coin not listed
Dfinity
195
Coin not listed
Bankera
150
(87%)
t0
134
Coin not listed
Basis
125
Returned capital to investors
Orbs
118
(64%)
PumaPay
117
(93%)
Jet8
33
(99%)
Unikoin Gold
32
(88%)

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

CoinIEO DateIEO issue amount vs total coin supplyReturn vs first exchange trade priceReturn vs IEO price
US$m raised in IEO
Binance
Gifto21/12/20173.0%(90.5%)142.2%
0.4
Bread26/12/20177.9%(84.2%)164.6%
0.8
Fetch.AI02/03/20196.0%(55.0%)203.6%
4.1
BitTorrent03/02/20196.0%54.8%433.9%
7.5
Celer24/03/20196.0%(29.4%)82.0%
4.5
Matic24/04/201919.0%Ongoing
Binance Total
17.3
Huobi
TOP26/03/20197.5%10.2%357.0%
3.3
Newton16/04/20192.0%(23.0%)197.0%
4.8
Huobi Total
8.1
Bittrex
VeriBlock02/04/20193.3%(30.9%)(33.0%)
7.0
RAIDCanceled
OKEX
Blockcloud10/04/20195.0%(43.1%)599.7%
2.5
BitMax
Dos Network11/04/201914.2%(55.1%)74.2%
1.7
Kucoin
MultiVAC03/04/20196.0%(30.5%)20.0%
3.6

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

Coin IEO Date Platform
Coin Analyst07/07/2018Exmarkets
SID Token15/11/2018Exmarkets
Rebglo01/12/2018Coineal
Aerum01/01/2019Exmarkets
TerraGreen21/01/2019Exmarkets
Verasity01/03/2019Probit
Percival05/03/2019Coineal
Decimated06/03/2019Exmarkets
Menapay15/03/2019Exmarkets
Linix16/03/2019Probit
Levolution18/03/2019Coineal
WeGen18/03/2019Probit
Spin Protocol19/03/2019Probit
CharS20/03/2019Probit
Windhan Energy21/03/2019Exmarkets
HUNT23/03/2019Probit
KIZUNA GLOBAL TOKEN25/03/2019Coineal
PUBLISH26/03/2019Probit
ZeroBank31/03/2019Coineal
REDi03/04/2019Probit
VenusEnergy04/04/2019Exmarkets
Bit Agro05/04/2019Exmarkets
XCon06/04/2019Coineal
YellowBetter08/04/2019Bitker
Link by BlockMason09/04/2019BW
GTEX Gaming Platform12/04/2019Coineal
AlienCloud16/04/2019IDAX
Evedo16/04/2019Bitforex
PantheonX18/04/2019BW
NUVO19/04/2019Probit
Grabity19/04/2019BW
Farm2Kitchen22/04/2019Exmarkets
Cryptobuyer23/04/2019Coineal
Airsave Travel01/05/2019Exmarkets

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

Conclusion

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.

Disclaimer

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.

The Schnorr Signature & Taproot Softfork Proposal

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.

(Source: Pexels)

Overview

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.

Schnorr Signatures

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
5.9%
Effective network capacity increase assuming 100% Schnorr adoption
13.1%

(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

(Source: p2sh.info)

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.

Taproot

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
Yes
Joint signature for multiple inputs in a transaction
No
Joint signature for multiple inputs in multiple transactions (Grin coin has some capabilities in this area, using Mimblewimble)
No

(Source: BitMEX Research)

Conclusion

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.

Bitcoin Cash SV – 6 block chainsplit

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)
754,008
Fork chain
1,050,743
Overlap (within 6 blocks)
753,945
Eventual double spends
0

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

Local ClockBlock TimestampHeightHashSize (MB)Log2 Work
11:39:4711:39:19578,638 000000000000000001ccdb82b9fa923323a8d605e615047ac6c7040584eb24193.187.803278
12:04:5112:04:37578,639 0000000000000000090a43754c9c3ffb3627a929a97f3a7c37f3dee94e1fc98f8.687.803280
12:28:0112:20:36578,640 00000000000000000211d3b3414c5cb3e795e3784da599bcbb17e6929f58cc0952.287.803282
12:43:4212:29:39578,641 0000000000000000050c01ee216586175d15b683f26adcfdd9dd0be4b1742e9e42.187.803285
12:59:2712:51:40578,642 00000000000000000a7a25cea40cb57f5fce3b492030273b6f8a52f99f4bf2a876.287.803287
13:05:1812:32:39578,640 000000000000000007ad01e93696a2f93a31c35ab014d6c43597fd4fd6ba959035.587.803282
13:05:1812:33:16578,641 0000000000000000033ed7d3b1a818d82483ade2ee8c31304888932b7729f6920.187.803285
13:05:1812:41:38578,642 00000000000000000ae4a0d81d4c219139c22ba1a8a42d72b960d63a9e1579141.087.803287
13:05:1912:56:37578,643 00000000000000000590821ac2eb1d3c0e4e7edab586c16d5072ec0c77a980dc0.887.803289
13:19:3613:14:22578,644 0000000000000000001ae8668e9ab473f8862dc081f7ac65e6df9ded635d338e128.087.803291
13:21:5613:18:07578,645 0000000000000000049efe9a6e674370461c78845b98c4d045fe9cd5cb9ea634107.287.803293
14:12:5413:15:36578,643 0000000000000000016b62ec5523a1afe25672abd91fe67602ea69ee2a2b871f23.887.803289
14:12:5513:43:35578,644 000000000000000003e9d9be8a7b9fc64ef1d3494d1b0f4c11845882643a64391.387.803291
14:12:5514:01:34578,645 0000000000000000052be8613e79b33a9959535551217d7fdacc2d0c1db1e6720.087.803293
14:12:5514:06:35578,646 00000000000000000475ab103a92eb6cb1c3c666cd9af7b070e09b3a35a15d660.087.803296
14:27:0914:24:37578,647 0000000000000000062bade37849ade3e3c4dfa9289d7f5f6d203ae188e94e4f77.087.803298

Source: BitMEX Research

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.

The Lightning Network (Part 2) – Routing Fee Economics

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.

(Lightning strikes the city of Singapore) (Pexels)

Please click here to download a PDF version of this report

Overview

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

Fee type Description Convention
Base fee A fixed fee charged each time a payment is routed through the channelThis is expressed in thousandths of a Satoshi.

For example a base fee of 1,000 is 1 satoshi per transaction.
Fee rateA 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.

Investment capital

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

Description Creation
Inbound capacityInbound 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 capacityOutbound 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:

  1. The federal reserve base rate is 1.0%
  2. Lightning node operators are typically earning an annualised investment yield of 1.5% on their outbound balance
  3. Due to robust economic conditions and inflationary pressure, the federal reserve open market committee increase interest rates from 1% to 3%.
  4. Due to the more attractive investment returns, Lightning network node operators withdraw capital from the Lightning network and purchase government bonds
  5. 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

Conclusion

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.

BitMEX Research Launches Ethereum Node Metrics Website – Nodestats.org


Abstract: BitMEX Research is delighted to announce the launch of a new website to monitor the Ethereum network, Nodestats.org. The website connects to five different Ethereum nodes and collects data every five seconds. The main focus of the website is providing metrics related to the computational resources each Ethereum node requires. While analysing some of the metrics, we may have identified issues with respect to the integrity of the data reported by the nodes, which may be of concern to some Ethereum users. Nodestats.org was produced in collaboration with TokenAnalyst, who are BitMEX Research’s Ethereum network data and analysis partner.

(Screenshot of website as at 12 March 2019)

Overview

Nodestats.org compares the statistics of the two largest Ethereum node client implementations by overall adoption – Geth and Parity. Within these client implementations, Nodestats.org compares the performance of different node configurations – fast, full, and archive nodes.

The main purpose of Nodestats.org is as follows:

  1. To provide metrics comparing the computational efficiency of the different Ethereum implementations. For instance by comparing requirements related to:
    • CPU usage
    • Memory (RAM)
    • Bandwidth
    • Storage space
  2. To compare the resource requirements between running Ethereum node software and that of other coins, such as Bitcoin
  3. To evaluate the strength of the Ethereum P2P network and transaction processing speed, by looking at metrics related to whether the nodes have processed blocks fast enough to be at the chain tip or whether poor block propagation results in nodes being out of sync for a significant proportion of the time

Nodestats.org began collecting data at the start of March 2019 and it is too early to draw any firm conclusions. However, we are saving the data and hope to analyse the long term trends at a later point. The Nodestats.org data is produced by querying our five Ethereum nodes or machines running the nodes, every five seconds (720 times per hour) and then storing the results in a database. Various rolling averages and other metrics produced from this data, are displayed on the Nodestats.org website.

Description of the Nodestats metrics

Name Description Initial findings
% of time in sync This represents the percentage of time the node has verified and downloaded all the block data, up what the P2P network is informing the node is the chain tip.

The hourly metric is calculated by determining if the node is at the tip every 5 seconds, which should be 720 queries per hour. The proportion of these queries where the node says it is at the tip is the reported metric.

This field is based on the web3 “isSyncing” field, which we believe uses the highest block the node has seen, the “highestBlock” field, to determine if the node is behind what its peers regard as the highest block ever seen.
Nodes typically report they are at the tip around 99.8% of the time, which means that in only around 1 of the 720 hourly queries are the nodes not at the chain tip.

The only exception here is the Ethereum Parity full node, which we talk about later in this report.

We believe the data integrity of this metric is poor, for instance in the case of the Parity full node the integrity of the information provided is weak, as we explain later in this report. Going forwards we aim to establish a more effective way of calculating this metric.
% of time on conflicting chainThis represents the percentage of time the node is following a different or conflicting chain to the node opposite it on the website.

This is determined by storing all the block hashes in our database, if the nodes have a different block hash at the same height, they are considered to be on different chains.
Typically Nodestats.org is not able to identify times when the clients are following different chains. As such this metric is normally 0%. (i.e. 0 times out of 720 in a one hour period)
CPU UsageThis represents the average percentage utilization of the machine’s CPU resources.

All the machines Nodestats.org are using have the “Xeon(R) CPU E5-2686 @ 2.30GHz” processing unit with two cores. The exception to this is the archive node, which has 16 cores.

All the nodes are using the AWS “i3.large” machines, with the exception of the archive node, which is running “i3.4xlarge”.
Generally speaking, CPU usage tends to be between 0.01% and 1.0%. Parity tends to be towards the 1% level, while Geth appears to use less CPU power.

Geth’s CPU usage appears less stable than Parity’s, with Geth’s CPU demand occasionally spiking to around the 1% level.
Memory UsageNodestats.org takes a reading from the machines every 5 seconds, related to how much memory is being utilized by the Ethereum client.

All the machines Nodestats.org are using have 14GB of Ram, with the exception of the archive node, which is a 120GB of Ram machine.
Generally speaking, however much RAM is available, the nodes use up the overwhelming majority of it (e.g. over 95%).

The memory demands of the clients appear to be reasonably stable.
Peer countThe node provides Nodestats.org with the number of network peers, every 5 seconds.Parity tends to have around 450 peers, while Geth only has around 8.

Geth’s peer count is more volatile than Parity, as it appears to occasionally fall to around 6.
Upstream bandwidth Nodestats.org takes a reading from the machine every 5 seconds, related to the total network upstream bandwidth of the server. Parity, which has more peers, tends to use over 100KB/s of bandwidth (in each direction). In contrast Geth tends to only use around 4KB/s of bandwidth.

Geth’s bandwidth demand tends to be more volatile than Parity, with occasional spikes to around 60KB/s.
Downstream bandwidth Nodestats.org takes a reading from the machine every 5 seconds, related to the total network downstream bandwidth of the server.
Chain data sizeThis metric represents the total data utilized by all the directories dedicated to the client.

Unlike the other metrics, the disclosed figure is the absolute value, not a rolling 1 hour average.
Currently, Parity requires around 180GB, Geth uses just under 200GB, and the full archive node uses up 2.36TB of data.

The Parity full node is still syncing

The Parity full node was started on 1 March 2019, at the time of writing (12 March 2019) it has still not fully synced with the Ethereum chain. The client is around 450,000 blocks behind, and based on its current trajectory, it should catch up with the main chain tip in a few days. Due to the slow initial sync, the “% of time in sync” metric is shown as near 0%, as the client is never in sync.

The Ethereum Parity Full node machine has the following specifications:

  • Dual Core 2.3GHz
  • 14GB of RAM
  • SSD storage
  • 10 Gb/s internet connection

The fact that a machine with the above specification takes over 12 days to sync may indicate that it is the initial sync issues could be a greater concern for the Ethereum network than post sync issues, such as block propagation. While the slow initial sync is a potential problem, at least for this system setup, Ethereum has not yet reached a point where the node cannot catch up, as the sync is faster than the rate of blockchain growth.

Data integrity issues

The Parity full node also sometimes reports that it is in sync, despite being several hundred thousand blocks behind the chain tip. For instance in the screenshot at the start of this piece, the website reports that the node is fully synced 0.02% of the time, indicating the node falsely thought it was at the tip for some periods of time.

As the chart generated from the Parity full node logs below illustrates, the highest block seen on the network figure, in blue, appears potentially incorrect. The highest block number seen on the network figure, sometimes falls in value as time progresses and has remained consistently well behind the actual chain tip (shown in green). On occasion this potentially buggy figure fell towards the height of the verified chain (orange) and our website incorrectly reports the node as in sync. This may be of concern to some Ethereum users, since the Parity full node has many connections to the network, therefore this may be a bug.

Ethereum Parity Full Node Block Height Data – 11 and 12 March 2019 (UTC)

(Source: Ethereum Parity full node logs)

This potential bug could undermine this whole metric for our website, even for the other nodes, as the highest tip seen field may not function appropriately and our figures may be inaccurate. However, we continue to include this metric, since the Nodestats.org website displays the data reported by the nodes, regardless of our view on the integrity of the data. We may look to implement our own improved metric in the future.

One could argue the impact of this potential bug could be severe in some limited circumstances, if exploited by an attacker in the right way. For example a user could accept an incoming payment or smart contract execution as verified, while their node claims to be at the network chain tip. However, the client may not really be at the chain tip and an attacker could exploit this to trick the recipient into delivering a good or service. The attacker would need to double spend at a height the vulnerable node wrongly thought was the chain tip, which could have a lower proof of work requirement than the main chain tip. Although successful execution of this attack is highly unlikely and users are not likely to be using the highest seen block feature anyway.

Conclusion

Like its sister website, Forkmonitor.info, Nodestats.org is very much a work in progress. Along with TokenAnalyst, over the coming months and years, we plan to add more features, such as:

  • Improving the integrity of the data, by being less reliant on what the nodes report and developing our own calculation methodologies
  • Charts & tools for analysing longer term trends
  • Improved granularity of the data
  • Fork detection systems
  • Data related to other peers

For now, Nodestats.org provides a useful tool to assess the approximate system requirements for running Ethereum nodes. At at a very basic level, it also provides mechanisms to assess the reliability of the Ethereum network and its various software implementations. However, we accept that the “% of time in sync” metric may not be reliable, but it does highlight a potential issue.

Anatomy Of The Next Global Financial Crisis

Abstract: We examine a question which many in the crypto-currency community frequently ask: “When is the next global financial crisis going to happen?” We attempt to answer this by first explaining how that since 2008, the epicentre of financial risk seems to have shifted from the banks to the asset management industry. We therefore argue that a repeat of 2008, where retail banking deposits and payment systems are under threat, is unlikely. In particular, we assert that corporate debt investment funds and unconventional debt investment vehicles, encouraged by the deceptively low volatility and low return environment, could be the area where the fragility in the financial system is most significant.

(Ten years since the global financial crisis, as the newspapers from the time exposed to the sunlight turn yellow and pink, at some point credit conditions could tighten significantly again, but will the asset management industry, rather than the banking sector, be the epicentre of risk?)

Please click here to download a PDF version of this report

Overview

Due in part to the timing of its launch, Bitcoin is said to have been born out of the financial chaos and scepticism resulting from the 2008 global financial crisis. Therefore, many Bitcoin investors and members of the crypto-currency community often seem to ask:

When is the next global financial crisis going to happen?

Due to the demand, we will attempt to address the issue.

First, we will look into the question itself. In our view, there appears to be three main assumptions behind the question:

  1. The next global financial crisis will arrive in the next few years and it’s inevitable one will occur every decade or so;
  2. Such a crisis will have a positive impact on the price of Bitcoin;
  3. The next global financial crisis will look similar to the last one, resulting in many questioning the integrity of the banking system and electronic payment systems.

Of these three assumptions, we only really agree with the first one. Although we think the latter two assumptions could possibly hold true, there is significant uncertainty about them.

As for the second assumption, we touched on this issue in March 2018, when we noted that Bitcoin was trading more like a risk-on asset than a safe-haven asset. Of course the Bitcoin price has fallen a lot since then and this could change going forwards. If Bitcoin does respond well in the next crisis (when liquidity is constrained), that will be a huge positive for Bitcoin and the store of value investment thesis. Although, there is no significant evidence for this yet. A decoupling of the Bitcoin price from many of the alternative coins, which more clearly have a risk-on type investment thesis (e.g. world computer or high capacity payment network), is necessary for this to occur, in our view.

As for the third assumption, the mechanics of the next global financial crisis, that is the focus of this report.

Bank Balance Sheets In Developed Markets Are Relatively Healthy

As the famous saying goes, “History doesn’t repeat itself but it often rhymes.” Over the last decade, bank management teams and banking regulators have operated in the shadows of 2008. As a result, bank balance sheets and capital ratios have significantly strengthened. Bank Tier 1 capital ratios in developed markets have improved from around 5% pre-crisis to around 12% today (Figure 1). The more basic ratio of equity to total assets, which is more difficult to manipulate, also illustrates a similar story: improving from c5% to c9% in the period (Figure 2).

Figure 1 – US & UK Bank’s Aggregate CET1 Capital Ratios

(Source: UK aggregate data from the Bank of England, US data from the Federal Reserve)

Figure 2 – US Bank’s Aggregate Tangible Equity to Total Assets Ratio (Banks with over $50 billion in assets)

(Source: Federal Reserve)

Perhaps even more revealing and compelling than the above ratios, is the following more simple chart (Figure 3). It illustrates that the main western banks have not expanded their balance sheets at all since the global financial crisis. Actually, the sample of the nine major banks we have reviewed experienced a significant decline in total assets in aggregate, from US$19.3 trillion in 2008 to US$15.6 trillion in 2018. One could argue that M&A activity is a driver of the below chart, but our point still stands.

Figure 3 – Total Assets Of Selected Banks In Developed Markets – US$ Trillion

(Source: BitMEX Research, Bank Earnings, Bloomberg)

(Note: The chart represents the total reported assets for JP Morgan, Bank of America, Citigroup, Wells Fargo, HSBC, RBS, Deutsche Bank, Credit Suisse and UBS.)

In our view, financial leverage is one of the the primary drivers of financial risk. The epicentre of risk in the financial system appears to have shifted since 2008. In 2008, the risk was caused by leverage in the banking system and the interrelationships between this and the securitisation of the mortgage market. Today, the equivalent risk is leverage in the asset management industry and in particular the corporate debt sector, driven by the deceptively low volatility environment.

Growth In Leverage In The Asset Management Industry

The asset management industry is far more opaque than banking and determining the degree of leverage is far more challenging. Therefore, it is difficult to conclude on either the extent of leverage in the asset management industry or the timing of any financial crisis related to this leverage.

A 2015 Bank of International Settlement (BIS) report entitled “Leverage on the buy side,”  focused on the shift in risk from the banking system to the asset management industry. The report notes that while investment fund leverage has been reasonably stable in equities, in the fixed income area, it has grown considerably since 2008, especially in emerging markets. The BIS report concludes with the following:

Leverage in the banking system was an important ingredient in the 2008 global financial crisis. Since then, asset managers (the “buy side”) have quickly increased their footprint in global financing, helped by the sharp retrenchment of banks nursing their balance sheets back to health. Balance sheet information for investment funds is much less readily available than for highly regulated banks. Using information provided by a market data vendor, we found that leverage on the buy side is not negligible, although it seems to vary considerably depending on the type of fund. Equity fund portfolios seem to be minimally leveraged, while fixed income funds tend to resort abundantly to borrowed money.

(Source: BIS)

The BIS report used data from investment fund flow specialist EPFR, and although we agree with the report’s conclusions, it is difficult to formulate a strong view of the data’s reliability. Although we have not found good sources of global data ourselves, US-domiciled investment funds over a certain size are required to submit data to the SEC about the extent of leverage used. The SEC has complied this data since Q2 2013 and we have summarised the main trends in the below charts (Figures 4, 5, and 6).

The data shows that, unlike the banking sector, the asset management industry has expanded considerably since 2008 (Figure 4). At the same time, leverage also appears to have increased, although producing a clear chart since 2008 illustrating this is difficult.

Figure 4 – US Fund Industry Gross Asset Value (US$ billion)

(Source: BitMEX Research, SEC)

Although there are competing methodologies, the most basic method for establishing the degree of leverage for an investment fund is calculating the gross asset value over the net asset value, sometimes referred to as the gearing ratio. Unfortunately the time span in the below chart (Figure 5) is limited, but it appears to indicate a moderate expansion of leverage, at least in the hedge fund sector.

Figure 5 – US Private Fund Industry Gearing Ratio – Gross Asset Value/Net Asset Value

(Source: BitMEX Research, SEC)

The gearing ratio underestimates true leverage, by ignoring the impact of derivatives. Disclosure of the notional value of derivative exposure is also required by the SEC. The below chart illustrates the growth in usage of derivatives by US-based hedge funds.

Figure 6 – US Private Fund Industry – Hedge Funds – Notional Value Of Derivatives/Net Asset Value

(Source: BitMEX Research, SEC)
(Note: Adjustments were made to reflect changes in how the SEC reports the data.)

New Corporate Debt Market Vehicles

In addition to the increased use of leverage in the fixed income market by investment funds, the mechanics of the debt markets are becoming increasingly complicated and opaque. The replacement of the role of the banks in the corporate debt markets, has resulted in the rapid growth of a whole range of interrelated, non-mutually exclusive investment structures. Some of these structures are summarized in the table below.

Type of Debt Description/Comments Reference
Collateralized Loan Obligations (CLOs) CLOs are when a group of loans from multiple companies, are pooled together to form a security. The product is typically split into different tranches, lower risk tranches with lower returns and higher risk tranches with higher returns. Investors in the highest risk tranche are the last to be paid in the event of any insolvencies.

Typical buyers of these products are pension funds, insurance companies and hedge funds. They are particularly popular with yield hungry Asian investors.

Market growth – Figure 7
Leveraged Loans These are typically variable rate loans provided to companies who are already highly indebted. In the majority of cases the loan is fully unsecured. The typical holders of such instruments are pension funds and other private investors.

The Bank of England recently estimated the size of the leveraged loan market globally at US$2.2 trillion and compared it to the size of the US subprime mortgage market in 2006 (US$1.3 trillion).

Market growth – Figure 8

Credit quality – Figure 15

Private debt deals This is similar to the leveraged loan market, except the debt does not normally trade on a secondary market. Market growth – Figure 9
Bond fund ETFs and mutual funds ETFs have expanded in popularity in all asset classes in the period, corporate bond funds are no exception. Market growth – Figure 10
Private Equity Credit quality – Figure 16

(Note: The fields in the above table are not meant to be mutually exclusive)

As the following charts from various sources indicate, all these non-bank mechanisms for providing corporates with financing have grown considerably since the last global financial crisis.

Figure 7 – Size of Collateralized Loan Obligation (CLO) Market – US$ billion

(Source: Citi, FT)

Figure 8 – Size of US Leveraged Loan Market – US$ billion

(Source: S&P, FT)

Figure 9 – Size of Private Debt Market – US$ billion

(Source: Bank of America, FT)

Figure 10 – Size of the Top Bond ETFs Targeting US Investors – US$ Billion

(Source: BitMEX Research Bloomberg)

(Note: The chart represents the sum of the market capitalisations of the following bond ETFs: iShares Core U.S. Aggregate Bond ETF, Vanguard Total Bond Market ETF, iShares iBoxx $ Investment Grade Corporate Bond ETF, Vanguard Short-Term Corporate Bond ETF, Vanguard Short-Term Bond ETF, Vanguard Intermediate-Term Corporate Bond ETF, iShares J.P. Morgan USD Emerging Markets Bond ETF, Vanguard Total International Bond ETF, iShares MBS Bond ETF, iShares iBoxx $ High Yield Corporate Bond ETF, PIMCO Enhanced Short Maturity Strategy Fund, Vanguard Intermediate-Term Bond ETF, iShares Short-Term Corporate Bond ETF, SPDR Barclays High Yield Bond ETF, iShares Short Maturity Bond ETF)

Corporate Debt Markets Conditions

As Figure 11 below illustrates, corporate debt levels have increased considerably since 2008, with gross debt of Russell 3000 companies now totalling US$11 trillion, compared to being just over US$8 trillion at the time of the last crisis. Corporations have taken advantage of low interest rates and the new investment products mentioned above, to borrow money at record levels.

However, as the red line on Figure 11 illustrates, Russell 3000 corporate balance sheet conditions still appear reasonably healthy, with an aggregate net debt to EBITDA of just under 2.5x.   Although this ratio has been increasing in the last few years, it is nowhere near as large as the c3.7x level which was present before the 2008 financial crisis. This perceived strength is caused by a few large tech giants hoarding cash and the strong economy boosting earnings. If the economy turns, corporate balance sheets could start to look unhealthy again, as earnings fall.

Figure 11 – Corporate Debt levels

(Source: BitMEX Research, Corporate Data, Bloomberg)
(Note: The figures consist of aggregate data for all the Russell 3000 companies.)

There is a considerable volume of corporate bonds set to mature in the coming years. This could exacerbate the impact of any liquidity crisis or stress in the fixed income sector. As our analysis shows (Figure 12), US$ 880 billion of corporate debt in the US will mature in 2019.

Figure 12 – Corporate Bond Maturity Wall – US$ billion

(Source: BitMEX Research, Bloomberg)
(Note: Figures are based on a database of around 6,400 US corporate bonds with an aggregate amount outstanding of US$5.7 trillion.)

Perhaps the most alarming indicator is the quality of the corporate debt. Figure 13 shows the credit rating distribution of the outstanding investment grade corporate debt over time.  At the end of 2018, almost 50% of the bonds had been rated at the lowest possible rating for investment grade securities, a far higher proportion than any time in the past 30 years. Figure 14 indicates that the situation from 2021 will get even worse, when the overwhelming majority of corporate debt maturing will be at the lowest investment grade rating.

Figure 13 – S&P Credit Rating Distribution of US Corporate Bonds Over History

(Source: Bloomberg, HSBC USD IG index constituents, including financial and non financial companies)

Figure 14 – S&P Credit Rating Distribution of US Corporate Bonds Outstanding By Maturity

(Source: BitMEX Research, Bloomberg)
(Note: Figures are based on a database of around 6,400 US corporate bonds with an aggregate amount outstanding of US$5.7 trillion.)

Evaluating the credit quality of some of the less conventional debt vehicles mentioned above, is more challenging. However, a recent report from Moody’s indicated that there has been a significant deterioration in the level of protection for investors in the leveraged loans market, as Figure 15 below illustrates.

Figure 15 – Moody’s Assessment Of The Covenant Quality For Leveraged Loans (US & Canada)

(Source: Moody’s, Bloomberg)
(Note: 5.0 is the weakest score, 1.0 is the strongest.)

Figure 16 – Average Total Debt To EBITDA Multiple Of Private Equity Deals

(Source: S&P, FT)

Low Volatility Environment

In our view, the unconventional monetary policies in advanced economies have squeezed investment returns and volatility, all while reducing borrowing costs; this has created an incentive for asset managers to use more leverage and take on more risk. At the same time the same policies have encouraged corporates to take on more debt. It is the fixed income sector, more than any other, which has been impacted by this low volatility. “Risk Parity” type investment strategies have become increasingly popular, where funds manage risk by constructing portfolios according to the risk (volatility) of each asset class and then using leverage to increase returns. The leverage mitigates the impact of lower returns from the higher weighting to the lower risk assets. This typically involves a larger weighting to fixed income, rather than equities, while incorporating more leverage to offset the low returns of these supposedly lower risk assets.

In February 2018, there was a sharp increase in volatility as the VIX skyrocketed and investment strategies focused on shorting the VIX, such as the Velocity Shares Daily Inverse VIX ETN, plummeted in value to almost zero. This was discussed in the March 2018 edition of the BitMEX Crypto Trader Digest. The victims of this were a small number of opportunistic investors looking for easy returns and the impact of the “volocaust” was limited on the rest of the financial system. However, in a way, the February 2018 event was a microcosm for what is happening more generally in fixed income markets. This time the more mainstream investors, are taking advantage of artificially low volatility and cheap borrowing costs. At some point the market will correct, and the impact of this will be far greater than in February 2018, when a multi-trillion dollar asset class unwinds, rather than one only worth several hundred million dollars.

The sequence of events can be described as follows, with various different factors contributing to exacerbate risk:

  1. Some catalyst occurs, causing a sharp increase in volatility.
  2. Investors will need to de-risk their portfolios, concentrating first in the most liquid markets, fixed income.
  3. In the most liquid markets, machines dominate trading and machines are likely to all withdraw liquidity at the same time.
  4. Fixed income markets become volatile, illiquid and dysfunctional, as investors rush for the exit.
  5. Securitised bond-based assets, such as CLOs and Bond ETFs, trade at a significant discount to their net asset values.
  6. The contagion spreads across other liquid asset classes, such as equities.
  7. Over the coming years the newly-established components of the debt machine begin to dry up; corporates struggle to refinance and the economy suffers.

Of course we do not know what will be the main catalyst leading to increased volatility. It could be a geopolitical event, excessive levels of emerging market US Dollar-based debt, high levels of leverage in the Chinese asset management industry, passive ETFs, high frequency traders, the contraction of central bank balance sheets too quickly, a large unexpected corporate bankruptcy, the Eurozone debt crisis, even a catastrophic consensus bug in Bitcoin causing volatility ect ect…  

The point is, that whatever the particular event is, it doesn’t really matter. What does matter is the inherent instability and fragility of the financial system, driven by artificially low volatility and excessive leverage. Many may point their fingers at the particular catalyst after the event and blame it for the crisis, but that could be somewhat intellectually dishonest.

Conclusion

Banks are more crucial to the financial system and society than asset managers. If asset managers come under pressure, whilst some high net worth individuals may experience a write down in their assets; retail and corporate deposits should be safe; and therefore the coming crisis could be less intense than 2008. However, critically, the potential for government intervention to mitigate the impacts of the crisis may be more limited than in 2008.

Firstly and most obviously, the toolkit available to central bankers has been greatly diminished, with interest rates already low and their balance sheets already large. Secondly, and perhaps more importantly, is the political side of things. One cannot know for sure, but the typical people behind the Trump, Brexit, or the Yellow Vest movement may not be supportive of certain kinds of government intervention in financial markets.

In today’s more “populist” political climate, it may be more challenging to justify programs such as quantitative easing or other programs designed to increase asset prices at the relative expense of those earning median type salaries, who don’t own a large pool of financial assets. Therefore, in the next crisis, managing the perceived risk of a “political uprising” could significantly reduce the scope of action central bankers may be willing to take.

Keep in mind, there was also political opposition to central bank policy in the aftermath of 2008, with the rebellion peaking in around 2011. Another key difference this time is that available tools to those leading the rebellion then, such as social media, are now more developed. Political uncertainty in the West seems to have increased since 2008. If this uncertainty begins to interact with financial volatility, risks could be exacerbated.

As for when such a crisis will occur, we obviously do not know. In our view, the charts in this report identify a problem, but they do not seem to suggest that we are necessarily right on the precipice of a major crisis; it could be several years away. As for how to profit from such events, this is perhaps even more challenging than predicting their timing. Maybe one could construct a portfolio of VIX calls, long dated corporate bond ETF puts, index-linked government bonds, hedge funds specializing in volatility, gold and maybe to a lesser extent, even Bitcoin. Again, although one cannot know when these events will occur, perhaps now is a time to adjust one’s investment portfolio.

The Mystery Of The Bitcoin Nonce Pattern

Abstract: We note that the distribution of nonce values in the Bitcoin block header does not appear to be random, with unexplained gaps emerging, where nonces occur less often. We then speculate on why this may be the case and provide charts illustrating the phenomenon. Although in our view the explanation for this is likely to be benign, it remains a mystery.

Overview and Recent Tweets

The Bitcoin nonce forms part of the block header, which is used by miners to provide entropy as part of the Proof of Work process, to try and find a hash meeting the difficulty requirement. Although it may depend on how mining software and hardware is configured, in theory the distribution of the nonce values should be random. In 2009, when Satoshi is presumed to have been a significant miner, the nonce value followed a particular pattern, as we discussed in an earlier piece.

On 4th January 2019, @100trillionUSD tweeted a graphic illustrating the nonce value distribution for Bitcoin. It seemed to show that the nonce value was random from mid 2010 to the start of 2016, after which point four mysterious regions appeared, where nonces occurred less often.

A few days later, on 7th January 2019, @khannib noted that Monero also appeared to have an unusual nonce value distribution. The Monero hardfork, which may have prevented the usage of ASICs, appears to have made the distribution random again, perhaps indicating ASICs cause the pattern.

On 23rd January 2019, TokenAnalyst dug further into the Bitcoin nonce value distribution pattern, by colouring the nonce values for the relevant mining pools.

A further tweet from TokenAnalyst implies that Antpool is a major cause of the unexpected nonce value distribution, while Bitfury and Slushpool have nonce values which perhaps do not significantly contribute to the “white spaces”.

New Nonce Value Distribution Scatter Charts

We have replicated the above analysis, producing similar scatter charts (starting in 2018); in an attempt to shed more light onto the issue.

We have also produced an individual scatter chart for Antpool, BTC.com, F2Pool, Slushpool and Bitfury. The charts appear to agree with TokenAnalyst’s data, in that the “white spaces” are more clearly visible for Antpool, than for Slushpool and Bitfury. Although, with respect to Slushpool the white spaces are still visible, but they are more faint. Bitfury may not have found enough blocks for one to see a clear pattern. A statistical analysis may also be possible, although the human brain interpreting these scatter charts may be just as useful compared to some forms of statistical analysis.

 

Bitcoin nonce value distribution – All nonces (Since 2018)

(Source: BitMEX Research)

 

Bitcoin nonce value distribution – Antpool (Since 2018)

(Source: BitMEX Research)

 

Bitcoin nonce value distribution – BTC.com (Since 2018)

(Source: BitMEX Research)

 

Bitcoin nonce value distribution – F2Pool (Since 2018)

(Source: BitMEX Research)

 

Bitcoin nonce value distribution – Slush (Since 2018)

(Source: BitMEX Research)

 

Bitcoin nonce value distribution – Bitfury (Since 2018)

(Source: BitMEX Research)

Bitcoin Cash ABC

Bitcoin Cash ABC also shares the same nonce value distribution pattern as Bitcoin.

Bitcoin Cash ABC nonce value distribution – (Since 2018)

(Source: BitMEX Research)

 

AsicBoost

It is possible that covert AsicBoost may be either a contributing factor or cause of the pattern. The pattern began to emerge around the time many speculate covert AsicBoost started; and this pattern could be a quirk in the implementation of covert AsicBoost, which requires the manipulation of the nonce. However, the usage of covert AsicBoost is believed to have stopped in Bitcoin in 2018, when this pattern continued. Although it’s possible that despite covert AsicBoost itself being stopped, the quirk in the firmware remains.

In the below chart we have looked at the nonce value distribution for blocks mined using overt AsicBoost. Again, the pattern remains visible, albeit faintly. This may suggest the pattern has nothing to do with covert AsicBoost, but it’s far from conclusive.

Bitcoin nonce value distribution – Overt AsicBoost blocks (Since 2018)

(Source: BitMEX Research)

Conclusion

For now, the unusual nonce value distribution on Bitcoin remains a mystery. The community may wish to dig into this issue further and conduct more analysis, such as reviewing mining pool software and ASICs in more detail. We would guess this is nothing more than a meaningless anomaly with a benign cause; however a mystery in Bitcoin like this could be intriguing to some analysts.

Tracking US$24 billion Of Tokens ICO Makers Allocated To Themselves

Abstract: This is our third major piece on ICOs. In our first piece in September 2017 we focused on the interrelationships between ICO team members. In our second piece, in October 2018, we tracked the Ethereum balances in the ICO treasury accounts. In collaboration with TokenAnalyst, this piece focuses on the treasury balances of the ICO tokens themselves, on the Ethereum network. This report is based on tokens where the team controlled holding’s were worth an astonishing US$24.2 billion on issuance (in reality liquidity was too low for this value to be realized). Today this figure has fallen to around US$5 billion, with the difference primarily being caused by a fall in the market value of the tokens, alongside US$1.5 billion of transfers away from team address clusters (possibly disposals).

(Source: BitMEX Research)

(Note: A reminder of the various interconnections between ICO team members, from our September 2017 interactive graphic)

Team controlled token holdings (Own tokens) – summary data

US$ billion
Value of ICO coins allocated to token teams 21.5
Issuance to team post ICO 2.7
Total issuance to team controlled wallets
24.2
Coins leaving the team address cluster (Perhaps sales) (1.5)
Profits/(losses) due to token price changes (12.0)
Net impact of Noah (token burn) (4.4)
Net Impact of EOS (1.2)
Current team holdings 5.0

(Source: BitMEX Research, TokenAnalyst, the Ethereum blockchain, Coinmarketcap (for token prices))
(Notes: Price data up to Jan 2019, token data up to Dec 2018, based on data for 108 tokens)

Of the US$24 billion worth of tokens ICO project teams issued to themselves, 54% of the value has been lost due to coin price reductions. The peak valuation of the team holdings of their own tokens, using the individual price peak for each coin, is over US$80 billion. This larger figure implies US$70 billion of “losses” from the peak. Although peak valuation highly is dubious due to a lack of liquidity and most of the tokens were granted to the teams essentially for nothing, therefore classifying these price movements as losses may not be appropriate. Unlike ICO investors, the teams did not have an offering price or initial investment. However, some trading activity occurred at these ridiculously high valuations, therefore we believe it’s still interesting to consider these figures, while bearing these caveats in mind.

Based on current illiquid spot prices, the ICO teams still appear to own around US$5 billion of their own tokens, money they essentially got from nothing, depending on ones view. At the same time the teams may have realized gains of US$1.5 billion by selling tokens, based on coins leaving team address clusters. Although this figure may also be an overestimate, as coins could have left the team address cluster for a variety of reasons.

Data Caveats & weaknesses in calculation methodology

  • The liquidity of many of these tokens is low and therefore the US Dollar values may be gross overestimates, this applies to both the initial allocation, current value and the value of any losses. In some cases, the value of tokens given to the team, for instance with projects such as Veritaseum or Noah, were almost comically large relative to the real trading volume in the coins. Therefore it can be considered unrealistic to value the team holdings based on the exchange price of the tokens.
  • The challenge and uncertainty involved in producing this dataset surrounds the allocation of the tokens to the team address cluster. TokenAnalyst conducted this allocation. The methodology used was imperfect and we have not dug into individual projects. The data was obtained by analysing the token smart contracts and transaction patterns on the Ethereum blockchain and applying machine learning type techniques to establish a team controlled address cluster for the team of each project. The data is therefore a probabilistic estimate and is likely to be inaccurate at the individual project level. However, the primary motivation for this report was to produce macro data about the team holdings of ICO tokens on Ethereum. Although this analysis has produced results which are far from perfect, we believe one can draw reasonable macro conclusions from the analysis.
  • As mentioned above, our analysis is based on reviewing smart contract data and transaction patterns, not documents and policies of individual projects. Therefore, it’s possible we included tokens as part of a team balance, although in reality they are held as part of another form of reserves, escrow or some other category, where it’s inaccurate to attribute the coins to the team’s own funds.
  • The data assumes the issuance date is the same date as when the first price data appeared on Coinmarketcap, this may not be a reliable assumption.

Summary data

Value of coins issued to team controlled address clusters (own tokens) – US$ million – Top 10

(Source: BitMEX Research, TokenAnalyst, the Ethereum blockchain, Coinmarketcap (for token prices))
(Notes: Token data up to Dec 2018, data based on prices at the time(s) of issuance)

Loss in value of team controlled holding (own tokens) – US$ million – Top 10

(Source: BitMEX Research, TokenAnalyst, the Ethereum blockchain, Coinmarketcap (for token prices))
(Notes: Price data up to Jan 2019, token data up to Dec 2018)

Proportional loss in value of coins in team controlled address clusters (own tokens) – Top 10

(Source: BitMEX Research, TokenAnalyst, the Ethereum blockchain, Coinmarketcap (for token prices))
(Notes: Price data up to Jan 2019, token data up to Dec 2018)

Value of coins transferred out of team controlled address clusters (Own tokens) – US$ million – Top 10

(Source: BitMEX Research, TokenAnalyst, the Ethereum blockchain, Coinmarketcap (for token prices))
(Notes: Price data up to Jan 2019, token data up to Dec 2018. Huobi and Qash are exchanges and the tokens appear to have been sent to their respective platforms. It is possible the above figures represents sales/”cashing out”, although there could be other reasons for the transfers)

Current value of coins in team controlled address clusters (Own tokens) – US$ million – Top 10

(Source: BitMEX Research, TokenAnalyst, the Ethereum blockchain, Coinmarketcap (for token prices))
(Notes: Price data up to Jan 2019, token data up to Dec 2018)

The raw data – Team holdings of own tokens – US$ million

Token Value at ICO Post ICO issuance Transfers away from team cluster Loss in value Current value
VERI 4,762 0 (15) (3,196) 1,552
NOAH 4,478 0 (4,423) 55
KIN 980 0 (0) (703) 277
AGI 863 0 (27) (814) 22
POLY 842 0 (17) (727) 99
HT 643 0 (366) (29) 248
GNO 636 0 0 (533) 103
QASH 617 0 (177) (300) 140
MKR 596 0 (46) (445) 105
TEL 452 0 (8) (408) 36
ITC 334 0 (7) (323) 4
ZRX 333 0 (9) (155) 169
ZIP 266 0 0 (226) 41
BLZ 256 0 (32) (207) 17
GTO 241 0 (67) (157) 17
BNB 219 110 0 118 447
BTO 198 0 (28) (165) 5
ICX 160 0 (79) (67) 14
ETHOS 153 0 (15) (123) 16
TNT 152 0 (10) (133) 9
CENNZ 143 0 (6) (121) 15
AST 141 0 (24) (104) 13
KEY 132 0 (2) (124) 6
BIX 118 2 0 (85) 35
CVC 117 0 (1) (75) 41
FSN 100 0 (6) (75) 19
OCN 100 0 (31) (64) 5
DEW 95 0 (1) (87) 7
SRN 89 0 (15) (69) 4
MDS 88 0 (8) (75) 5
EDO 83 0 (11) (58) 15
ABT 76 0 0 (71) 5
WTC 69 0 (50) 17 37
INS 68 0 0 (66) 2
PPT 65 0 (55) (5) 5
IHT 65 0 (2) (58) 5
CPT 65 0 (0) (43) 21
SPHTX 64 0 0 (60) 4
DRGN 58 0 (47) (2) 8
MCO 54 0 (89) 72 37
XYO 54 0 (6) (23) 25
RCN 54 0 0 (48) 6
DPY 47 0 (23) (22) 2
THETA 45 0 0 (30) 16
MANA 41 0 (95) 127 73
R 40 0 0 35 75
APPC 35 0 (24) (9) 2
CMT 33 0 (1) (25) 8
FUEL 32 2 0 (29) 5
CREDO 31 0 (0) (6) 25
DMT 31 0 (17) (12) 2
POWR 30 166 0 (154) 42
LRC 30 8 0 (21) 17
WPR 26 0 0 (24) 2
AMB 24 0 0 (17) 7
RNT 22 0 (1) (15) 7
ENG 22 0 0 (12) 10
COB 22 0 (10) (5) 7
GTC 20 126 0 (141) 6
REN 19 0 (3) (13) 3
DENT 19 635 0 (564) 90
UTT 19 0 (0) (11) 8
AE 13 0 (19) 6 0
DATA 11 0 (3) (6) 3
BRD 10 17 0 (21) 7
SNGLS 8 0 0 (3) 6
LEND 6 0 (7) 3 2
RLC 6 0 (5) 2 3
PLR 6 3 0 (4) 5
HVN 5 0 (5) 0 1
CVT 5 11 0 (8) 9
LYM 5 0 (4) 0 2
SAN 5 0 (7) 5 4
GNT 4 0 (12) 31 23
KICK 3 2 0 (4) 1
DGD 2 0 (5) 5 3
EDG 2 0 (29) 28 1
ENJ 2 0 (0) 1 2
RHOC 1 14 0 (13) 1
ARN 0 6 0 (6) 1
ELF 0 45 0 (40) 6
PAY 0 142 0 (132) 11
DAI 0 1 0 0 1
HPB 0 134 0 (119) 15
CRPT 0 3 0 (2) 1
HOT 0 7 0 0 7
SALT 0 95 0 (92) 3
NAS 0 71 0 (50) 21
NGC 0 12 0 (11) 1
CPC 0 12 0 (9) 3
GVT 0 3 0 (2) 2
SNM 0 14 0 (11) 2
BTM 0 9 0 (1) 8
QRL 0 7 0 (6) 2
NULS 0 71 0 (52) 19
POE 0 58 0 (54) 4
TEN 0 29 0 (15) 13
MTL 0 188 0 (177) 11
WINGS 0 18 0 (15) 3
SPANK 0 106 0 (93) 13
OMG 0 195 0 (154) 41
STORJ 0 133 0 (85) 48
BAT 0 38 0 14 52
VIBE 0 10 0 (8) 2
IOST 0 218 0 (185) 34
Total 21,513 2,723 (14,805) (4,396) 5,035

(Source: BitMEX Research, TokenAnalyst, the Ethereum blockchain, Coinmarketcap (for token prices))
(Notes: Price data up to Jan 2019, token data up to Dec 2018)

Conclusion & summary data

This analysis highlights the lack of standards and transparency in the ICO market, especially when it comes to the allocation of tokens to the founding team’s wallet. Teams were often able to mint, burn, buy, and sell (their own) tokens at will, without analysts being able to easily track what is occurring. We would often see tokens in exchange clusters, and it was hard to tell whether the token project “paid” the exchange to list tokens or the token project just transferred their treasury to the exchange to cash out.

To be fair, perhaps we could improve the analysis by spending more time reading the specific documentation of the individual projects and by speaking to the teams involved. This would have resulted in a more robust dataset.

But one thing about ICOs that many people often overlook, is that ICO teams often make profits in two ways from the issuance:

  1. Selling the newly issued tokens (often for Ethereum), and,
  2. Issuing themselves their own tokens.

Our October 2018 report focused on the former, while this report focuses on the latter. The summary table below combines the figures from both of our reports.

ICO team profits US$ billion
ICO process
Ethereum Raised 5.4
Own tokens issued to founding teams 24.2
Total raised 29.6
Changes in coin price
Ethereum profits/(losses) – Mostly realised 0.8
Own token profits/(losses) – Mostly unrealised (17.6)
Total profits/(losses) post issuance (16.8)
Total ICO team profits 12.8

(Source: BitMEX Research, TokenAnalyst, the Ethereum blockchain, Coinmarketcap (for token prices))
(Notes: Ethereum price data to October 2018, Own token price data to January 2019)

Although, as we have repeatedly explained, there are many inaccuracies and assumptions involved in producing the data. Based on our methodology, it appears as if ICO teams have profited by almost US$13 billion from this ICO process. In our view, this money was made incredibly easily, with very little work, accountability or transparency. Therefore, ICOs have proven to be an extremely attractive way for project founders to raise funds. The results for investors of course, have not been as attractive.

The ICO cycle now appears to be dying down to some extent and it’s much harder to raise funds than it was in late 2017. But with so much money made and lost, the events of 2017 and early 2018 are not likely to be quickly forgotten. Entrepreneurs will remember the success (and keep trying to raise money) while investors will remember the pain. A repeat of this cycle within a few years is therefore less likely than many may think.