Indexing crypto

(a long overdue update)

March had passed, and, when it comes to crypto, I would say that nothing particular had happened. I was buying BTC at a rate of 1 USD per day. For other coins I was looking for opportunities to generate yield and rediscovered fixed term deposits at Binance. Many coins went into such deposit. On April 1st, when I wanted to get new CCi30 weights, I found that their website shows a database connection error and their index contains all kinds of minor coins. Unfortunately it was not a joke, because on early morning US time the website went on maintenance. And I have figured out that with the weighting scheme used by CCi30 I have to sell better performing coins, including those which are already deposited at Binance.

I already had thoughts about drawbacks of replicating CCi30 index, namely:

  • I cannot construct it myself and have to rely on a third party to provide the index composition.
  • The provided composition is only correct when a switch to it happens. The more time had passed since then, the stronger the current composition deviates from the nominal one.
  • I don’t want to be forced to sell coins for a regular rebalancing. During the accumulation, I want to only buy.
  • I felt that 30 coins is still not broad (or deep) enough. I want to buy every upcoming coin quite early by investing a very small part of my portfolio, well before its index weight reaches some percents.

This all had motivated me to create myself a market cap-weighted, or at least mostly cap-weighted, crypto index.

My starting point is coinmarketcap.com. There I take “Dominance” (in %) data for coins, which, at least for me, are easier to handle than “Market Cap” (in USD). To illustrate my approach, further I use dominance values as at the time of writing.

I exclude coins which value is “pegged” to other assets. Here is the list of such coins with the current dominance data as an example.

Now, if I look at current BTC dominance of 44.37%, it means that a plain market cap-weighted crypto index ex pegged coins should contain just a bit over 50% of BTC. Too much for my taste, so I started to look how I circumvent this problem.

First I thought about an index with capped (which means effectively a constant) weight of BTC and potentially ETH, and the rest should be market cap-weighted. But then there are open issues:

  • At which weight should I cap largest components? If for example the BTC weight is too low, the top coin(s) in the cap-weighted “tail” can have weights higher than BTC. I don’t want too much BTC, but I also don’t want to have an index that drastically deviates from the market cap.
  • Let’s say I choose now a BTC cap that produces a reasonable ratio between BTC and other coins. But how will it change in the future? Will I have to adjust this “fixed” weight? How? I would rather have a simple formula then sometimes have to adjust parameters based on I don’t know which criteria.
  • This is rather a practical issue, but still: as dominance is changing rather quickly, I would like to be able to just take momentary dominance data for two coins and calculate a momentary ratio between index weights of these coins. If I have a fixed BTC weight, I can calculate a ratio between index weights of BTC and any other coin only after I entered into the calculation table dominance data for all coins in the index. Which are changing while I enter them.

So I decided to look for another idea. Another option would be a constant ratio BTC to ETH. But the problem remains the same: what is a good ratio and how will it change in the future? It should be self-adjusting.

Finally I decided to use a solution used by the developers of CCi30 index: scale index weights according to the square root of the dominance, but only for the top coins. The rest is market-cap weighted.

index3-2

Here is an illustration how I proceed with the construction of the index. First column is coins sorted according to the dominance from coinmarketcap.com (second column), ex pegged. Second column is the change of dominance. For first three components, the dominance of the next component is less than a half of the previous one. This concerns BTC/ETH, ETH/BNB and BNB/XRP pairs. For these top components I employ an idea explored by the authors of CCi30 index: I adjust their dominance so that the proportion between their weights in the index is equal to the square root of the proportion of their dominance. For all further components the proportion between weights is equal to the proportion between the dominance. This adjusted dominance is shown in column 4.

Next question is how many components to take. For this I calculate the sum of dominances (original dominance, not adjusted) of the coins included in the index. The goal is that this sum is at least 95% of the total crypto market ex pegged coins. As I want to include in the index many smaller coins before they grow too big, I have introduced a second requirement: one third of components having lowest weights should contribute not more than 5% in the resulting renormalized index. And I can add few more coins to arrive to a larger drop of dominance. As capitalization change quickly in the crypto market, the order of coins is doing the same, so a dominance difference of only 1-2% is not that significant.

Then one should renormalize adjusted dominance to obtain the index composition (column 5). The index that was obtained this time includes 62 coins with BTC contributing only 25%; 45 components have a weight of less than 1%.