Seeking Uniform Valuation for Crypto (part I)

HASH CIB
HASH CIB
Published in
14 min readOct 29, 2019

--

By Sandro Gorduladze, Head of Research (s.gorduladze@hashcib.com), and Rustam Botashev, CFA, Lead Analyst (r.botashev@hashcib.com), at HASH CIB

Acknowledgement: We would like to express our thanks to Chris Burniske of Placeholder VC, Aleks Larsen of Blockchain Capital, Mable Jiang of Nirvana Capital, Max Mersch of Fabric Ventures, David Grider of Aenigma Capital, Felix Machart of Greenfield One, Phil Bonello, Dmitry Kalichkin of Cryptolab Capital, and many others for being part of the brain trust we put together for this effort and actively participating in discussions for this research, asking tough questions and providing great comments.

This article is the first iteration in a collaborative effort to produce a valuation approach that can be adopted by industry specialists, subject-matter researchers, and the investment community. The absence of a generally accepted methodology for crypto asset valuation is one of the main reasons traditional investors are not widely taking exposure to the asset class. And while much work has been done in this direction, valuation continues to be the key conundrum for industry professionals.

This paper proposes some significant upgrades to existing models, but we do not pretend to invent entirely new valuation metrics. Nor do we insist that any of the discussed approaches are ultimately correct. What we do here is describe a high-level approach to crypto asset valuation based on existing methodologies. We liken this approach to working with Lego blocks: we set out the general principles of what a house should look like, but it’s up to the builders to choose which blocks to use.

Researchers currently divide crypto assets into different classes to value them: Productive and Non-productive (Phil Bonello), Currencies/Commodities and Utility, as well as some other sub-categories (Fabric Ventures), Capital and Consumable (Chris Burniske). While the definitions of these classes vary, the consensus view is that each class can be valued by a methodology applicable solely to that particular class. For example, most analysts agree that productive tokens can be valued by a DCF; commodity/non-productive coins valued using the Equation of Exchange, and so on.

We hope to convince colleagues to adopt our approach, which differs in several ways from those currently used. First we’ll describe the proposals that make our approach different, and then we’ll walk through each, providing examples and a simple excel model that should help readers better understand our methodology.

Proposal 1. Classify distinct value-add features or properties of different crypto assets rather than group these assets based on those properties. Fabric Ventures suggested classifying the characteristics of crypto assets first back in 2018.

Proposal 2. Use a single uniform model for all types of crypto assets: bring DCF, Equation of Exchange, Store of Value, and other valuation methods under one roof.

Proposal 3. Determine the value flows into the asset generated by each feature or use case of a crypto asset separately, but then attribute a combination of those inflows to the whole network[1] the asset runs on, i.e. to all of the network’s tokens, regardless of how each is used.

Proposal 4. Value a crypto asset using the Net Present Value (NPV) of its Future Value Flow, or Discounted Value Flow[2]. The combined value inflows generated by all of the asset’s features make up the valuation of the network that it runs on.

Proposal 5. Account for the often-overlooked cost to run a blockchain network.

Proposal 6. Future issuance (inflation) is irrelevant for blockchain network valuation in a specified period; consider only tokens issued by that period.

While we are confident about Proposals 1–4, we admit that Proposals 5–6 are debatable. Unlike the former, the latter proposals do not work well across all networks: for example in PoW blockchains they require significant assumptions in order to hold. We need to conduct more research deeper into different types of blockchain protocols at all levels of the technological stack to arrive at a correct solution. Nevertheless, we believe all the proposals are worth presenting now, to show the direction of our thinking.

Proposal 1

Don’t classify the crypto asset itself; classify its value-added qualities or features. Some crypto assets may have multiple use cases that meet the definition of two or more classes: ETH 2.0, for example, will be used for staking, and therefore it would be a revenue-generating asset. But it is also expected to be used for computation and storage payments on the network and maybe even function as a currency on the Ethereum network. Instead of worrying which bucket to put it to, we only need to know its distinct use cases (features). To classify the features, we can use same categories other crypto researchers have already proposed: Productive (like the “work” token feature), which also include Capital (passive staking) or Consumable (“utility” token) features as well and Currency/Commodity features. One may classify the features as they see fit, but it’s most useful to think about classifications in the context of methods applied to value these features (as you will see in the next proposal).

The properties of a single crypto asset may evolve. The economics of a blockchain network can change and its native asset may obtain more than one use case or feature, but putting a digital asset into a particular bucket restricts our mental modelling. Looking at its evolution as the gradual acquisition of different use cases allows us to adjust our valuation on the go rather than search for a new paradigm. We believe this more fluid approach is crucial for a still-nascent industry that is developing rapidly.

Proposal 2

Bring all the valuation methods that we have so far — DCF, MV=PQ, SoV — under one roof, leave room for those we might have in the future, and work from that place to value all kinds of crypto assets. Because we have not divided crypto assets into different classes but rather classified the assets’ features, we can have one valuation approach that is applicable to all crypto assets and draw on different methods to value the various features of each asset. Those methods would be the building blocks — the Lego pieces — and the overall valuation model would be our house.

A combined valuation approach can accommodate different views on individual features, new methodologies for each feature, and even changes in the functionality of specific assets. If someone disagrees with a particular method of valuing a feature, or a new, more appropriate methodology is developed, they can substitute this new method in the combined model. For example, if someone comes up with a better solution for valuing commodity/currency property than the Equation of Exchange, we can easily substitute MV=PQ with a new method while maintaining the same model. We swap an old building block for a new one, leaving the house intact. Similarly, if an asset evolves, we do not have to reclassify it, we only need to see how its features (use cases) may have changed. Each new feature adds value that can be evaluated using an appropriate methodology.

Proposal 3

Determine the value inflows (e.g. a user exchanging USD for that crypto) generated from each use case of a crypto asset separately but then attribute those inflows to the whole network the asset runs on, i.e. to all of the network’s native tokens, regardless of how those tokens are used. For instance, a token is used as a means of payment, this feature adds value to all of the network’s fungible tokens, not only those participating in transactions. We believe this is the correct approach, as otherwise we would get different valuations for one token that is used differently, while being effectively fungible — which makes no sense.

Fungible assets have the same value regardless of how they are used. A dollar in our pocket has the same value as a dollar deposited in the bank, even though the former is a means of payment and the latter is an interest-generating capital asset. In the same way, a staked fungible coin should have the same value as a similar coin used for payments, e.g. staked ETH 2.0 should have the same value as a non-staked ETH 2.0.

To value the productive feature of a protocol, we can use DCF. Even in the absence of actual cash going to holders, there is a value inflow into the asset by users of such features, who exchange cash for that crypto asset. In other words, DCF works for productive features of a crypto network regardless of whether the payment for its digital service goes to its service suppliers in the form of tokens (tangible value flow, as in ZRX) or to the protocol itself, which then burns the network’s tokens held by suppliers (intangible value flow, as in MKR). There are and will be many other forms this takes place, but what is crucial is theres is always the value that flows into the network that is then equally distributed to all holders of its tokens — as each is eligible to perform this network’s productive service at any time by holding the token.

To obtain value flows from the non-productive means-of-payment feature, we can use the MV=PQ approach, as we did in our earlier in-house model. We are well aware of the existing criticism around the Equation of Exchange[3]. However, currently this approach seems to be the best we have to value crypto assets possessing commodity features, and as such, we will stick to it for now.

Note that on blockchain networks that represent the underlying infrastructure (like Ethereum, which also has other networks/protocols running on top of it) transaction fees and similar payments for securing the network should be separated from value inflows from using actual digital good/services. By doing so we avoid double counting. For example, the transfer of 1 ETH from a buyer to a seller for a digital good or service on the Ethereum network would add to the means-of-payment value inflow into Ethereum and accounted for using MV=PQ method, while the fee paid to the miners for conducting this transaction would add to the transaction fee (security) value flow and accounted for using DCF. Additionally, the value paid in the form of ETH for a digital good or service (potentially, exchanged for a token) in the example above would create an inflow into the application/protocol that provides it.

To derive the value flows from the use of the store-of-value feature, we propose an upgrade to the current approach. We introduce the concept of Additional Store of Value (ASoV), which is very similar to the Additional Current Utility Value (ACUV) construct presented in our year-old upgrade to the original MV=PQ model. For each period i we can estimate a blockchain’s SoVi by assuming that its tokens replace a certain percentage of gold/fiat (or other SoV assets) as a store of value. SoVi will equal the product of the dollar amount of gold/fiat (one may add other assets in their assumption) used to store value and the store-of-value market share the tokens will take in that period. The annual value inflow derived from the token’s store-of-value feature will be SoV0 for period zero, and Additional SoVi for the periods i > 0, where ASoVi = SoVi — SoVi-1. The terminal value of ASoV is calculated using the standard formula.

Proposal 4

The value of any crypto asset is the NPV of its Future Value Flow — DVF (discounted value flow) — much like a value of a company is its DCF. Summing the value inflows into the network’s asset from all of its the features (use cases) gives us a valuation for the whole network. Note that here we are valuing the network rather than its tokens. We therefore simply add up the value flows, without regard for the network’s token structure. (Deriving the values of the tokens that make up the network is the next step, discussed below.) This is exactly the way an enterprise is valued, first by summing up all cash flows to the firm, and then deriving the values of each class of securities, such as common and preferred equity or different classes of debt, depending on the firm’s capital structure.

Value Flows from Features Make Up the Overall Value of the Network

Deriving the value flows coming from each feature separately gives us more degrees of freedom and more precision. For example, we can use different discount rates for value inflows from different features, depending on their level of readiness or assumed acceptance by the market. Then, we can sum up the values of each of the network’s distinct features to arrive at its total value.

However, simply adding up value flows from each feature assumes that those properties are independent. In other words, that changes in the value inflow coming from e.g. some productive feature do not affect the value flows from, say, means-of-payment utility (or any other value flows). In reality this is unlikely, since resources (which are usually limited) will be allocated to the more valuable (“profitable”) feature. For example, rising sales of a certain product makes a company reallocate its resources to that particular product, causing a decline in the production and sales of its other products. Similarly, an increase in the value flow from any productive feature should lead to reallocation of tokens to network’s suppliers offering the service, which may negatively impact a means-of-payment feature (e.g. token becoming less wide spread and thus used less for value transfers).

A simple example will illustrate the concept of adding up the value flows coming from an asset’s different use cases. We have prepared an excel spreadsheet so that readers can get comfortable with this valuation approach. The native tokens of an imaginary blockchain are used to stake and receive transaction fees for providing core service of the network (a productive feature), to pay for third-party goods and services (a currency feature), and to store value (an SoV feature). Assuming all transaction fees go to suppliers (miners in a PoW network, validators in PoS, and other types of keepers in different apps/protocols), we see an annual value inflow in year i from this feature as TXi. Because in valuation only future cash flows matter, we account for TX starting from the first year: i > 0. An annual value inflow from the means-of-payment feature will be CUV0 (Current Utility Value) — today’s value + ACUVi (Additional Current Utility Value) for the year i > 0. An annual value inflow from store-of-value will be SoV0 today and ASoVi for the years i > 0. Thus, total annual value flows to the network will be the sum of those three value inflows: CUV0 + SoV0 today (year i = 0) and TXi + ACUVi + ASoVi (years afterwards, i>0).

Proposal 5

The cost to run a network should be included in its valuation, since we must account for both value inflows and value outflows. In simple terms, these costs are electricity and hardware for miners, the cost of capital and overhead for validators, and the build-out and maintenance of a digital infrastructure for other types of network supply siders. As the technology matures we expect complications and interdependencies of networks/protocols to create multiple new forms of such costs .

However, whether such costs should be considered as the network’s value outflows depends on the type of a blockchain protocol. Subject to further research, we currently think that physical and related costs are an inalienable part of valuation for both Middleware/dApp and PoS-like protocols since they are borne by the network participants (i.e. token holders who are also effectively supply siders). At the same time, for PoW blockchains, physical costs are not necessarily intrinsic to the valuation, since miners, in the strict sense, are placed outside of the circle of token holders — as you don’t need to hold the token in order to mine it. Additionally, accounting for the PoW costs may require significant assumptions.

Another caveat is that forecasting the costs of running a PoW blockchain is easier said than done. In most networks, these costs are in constant flux and depend on supply-side competition. When token prices rise, competition intensifies and costs also rise, and vice versa. Costs are therefore a function of the token market price (not intrinsic value that we’re talking about here), and forecasting the token market price would require a crystal ball.

Cost to Run a Network is a Value Outflow — Decreasing the Overall Value of the Network

Proposal 6

Future issuance is irrelevant for a network’s valuation at a specified period, except for PoW blockchains. We should not discount the impact of future inflation into the current valuation of PoS-like networks because once investors buy in, they are eligible for the block rewards and therefore, won’t be diluted. Although the rewards go directly to supply siders (e.g. validators), investors can get a pro-rata share of those rewards if they opt to back validators, as the mechanics of some PoS networks suggest (and we expect, middleware protocols and even dApps in the future). The fact that investors, who opt out of accruing such passive returns, see their holding lose value over time does not affect the valuation of the network. By the same token, a company’s valuation would not be affected if some shareholders decided not to receive stock dividends or exercise their preemptive rights to purchase new shares. Thus, for a protocol where investors (holders) get a share of block rewards, future issuance should not affect the current value of the network’s outstanding tokens.

The PoW is very different. Investors in PoW networks have no opportunity to receive a share of block rewards simply by owning tokens, unlike investors in PoS-like blockchains. As such, the value of their holdings is diluted by inflation, and this should be factored into valuation.

For networks where future issuance is irrelevant for each period, arriving at the value of a single token in this period is simple. If the network consists of fungible coins only, then we just need to divide the value of the network by the number of tokens outstanding at each period we include in the valuation. If the network consists of several types of tokens, the process becomes more complicated. As a very simple example, let’s consider a network that has two types of coins: with voting rights (N%) and without voting rights (1-N%). If we assume a D% discount for coins without voting rights, we can derive the values for each type of coins from the following equation:

NV (network value) = N*P1 + (1-N)*P2 = N*P1 +(1-N)*(1-D)*P1

where P1 and P2 are the sought-for fair values for the first and second types of coins respectively. After deriving those values we can divide them by the number of tokens outstanding of type 1 and type 2 respectively.

Together, these six proposals represent a strong starting point for a uniform approach to crypto asset valuation. While we are confident that the first four apply across all types of blockchain protocols, the last two need more study, as they do not work equally well across the blockchain universe.

[1] We use the word “network” here broadly, meaning any blockchain-based network/protocol/app, irrelevant of its place in the blockchain stack: whether it is an underlying protocol, a DApp built on top of it, or what is often considered a middle-ware protocol. So, in this context, the term covers any cryptocurrency/digital token network.

[2] We adopted the concept of DVF from Chris Burniske.

[3] Essentially: MV=PQ is not an equation, it is an identity which should be re-written V=PQ/M. Changes in PQ lead to the corresponding changes in V and do not necessarily affect M. Therefore, it is impossible to derive the value of M if PQ is known or the value of PQ if M is known.

--

--

HASH CIB
HASH CIB

HASH CIB is offering financial solutions in the cryptoasset markets https://hashcib.com