A commentary on Burniske's "cryptocommodities vs cryptoassets"

Chris Burniske recently published a blog post titled "Value Capture & Quantification: Cryptocapital vs Cryptocommodities" as an attempt to extending and amending his popularized framework of valuing cryptoassets (MV=PQ) - which you can access directly here. In today's edition I'll provide a summary of the key propositions.

The extension of the thesis, introduces an important distinction of all cryptoassets in two main buckets; cryptocommodities - non-productive digital assets (e.g. Bitcoin) and cryptocapital - productive (stake based) digital assets (e.g. Cosmos ATOMs). The following table provides a conceptual backdrop for the two clusters, borrowed and adapted from Robert Greer's (1997) framework of defining different types of assets.

 
Screenshot%2B2019-09-16%2Bat%2B16.25.36.jpg
 

Burniske  asserts that one's best bet in valuing cryptocapital, by merit of its potential for productively generating returns, is a customized DCF, while for non-productive cryptocommodities, the best approach is probably still some rendition of the MV=PQ equation (e.g. NVT, MVRV).

Getting more specific into what constitutes cryptocapital, Burniske offers a loose definition as "any asset that is staked, bonded, or otherwise committed in orderto get a claim on value flows. "Given that within the proposed framework no cryptoasset is of a purely singular nature (CA+CT/A), it is implied that some part of its value might be calculated via a DCF and some other via NVT - though it is further implied that the consumable part might often be negligible, given the supply side insulation that many of these assets are subjected to. What this means is that these assets are used by the supply side to secure the network, and might never be used as demand side instruments.

When considering cryptocommodities, things are presented in a more straightforward fashion - as this strand of thinking has been around for a little longer, and iterations exist since Burniske first proposed the model in 2016. Here's an example of an attempt at valuing cryptocapital from HASH CIB btw, where CUV - current  utility value = PQ/V

 
Screenshot+2019-09-16+at+16.24.08.jpg
 

SoV type assets are presented as an add-on property to cryptocommodities, that according to Burniske make the asset display the unique property of perfect hardness. According to the author, few commodities make the leap into being considered reliable SoVs and for the cryptocommodities that don’t achieve the financial premium associated with SoV assets, their value capture prospects are grim. Here's how this "superclass" is characterised in the whitepaper;

 
Screenshot+2019-09-16+at+16.27.26.jpg
 

A couple more interesting assertions being made in the paper are that:

  • commodities are typically thought of as having a floor at their marginal cost of production - and Bitcoin seems to so far exhibit similar behaviour (miner's PnL).

  • in a digital world, there is no natural consumption/destruction of the commodity - which is where the artificial constriction of supply through forced burning and extreme scarcity becomes vital (bye bye GRIN).

  • most physical commodities have ​marginal costs of production that fall​ as the systems cales in its ability to extract it - in crypto it's the opposite.

  • assets that have to be somehow put to work to earn residual income, are distinctly different than assets on which passive income is earned, and therefore are more difficult to define as securities.


But perhaps the most valuable takeaway of all is the following:

Screenshot 2019-05-30 at 14.51.46.png

It is becoming increasingly clear that for a token economy to attract value, there has to be some form of stake and/or work involved - the clearer the implication, in fact, the better - as the closer we get to repeatable business/network models, the closer we get to the promised land.

Statefulness and value capture

One of the themes that has really stuck with me from the past couple of weeks on the road, is the idea that "tokens that govern state will accrue value, while tokens that govern schema won't". Here, I am looking to unpack this argument, touching on topics of statefulness vs statelessness, governance and value sinks. We'll start by understanding what statefulness is in a software context.

Stateless vs Stateful

State is the bulk of information referring to preceding events or user interactions, stored in a protocol (or programme) from t=0 up to t=n. A computer program stores data in variables, which represent storage locations in the computer's memory. The content of these memory locations, at any given point in the program's execution, is called the program's state.

By extension then, a stateless protocol does not require the server to retain session information or status about each communicating partner for the duration of multiple requests. Examples include the Internet Protocol (IP), which is the foundation for the Internet, and the Hypertext Transfer Protocol (HTTP). Conversely, a program is described as stateful if it is designed to remember preceding events or user interactions. In stateful protocols, information about previous data characters or packets received is stored in variables and used to affect the processing of the current character or packet.

Statelessness imbues software with fast performance, reliability, and the ability to grow, by re-using components that can be managed and updated without affecting the system as a whole, even while it is running. In contrast stateful protocols, provide continuity and are more intuitive (since state related data are embedded).

Statefulness and value over time

Blockchains and smart contracts platforms, are in their majority, stateful. By definition, a blockchain is a database of past states - such that the further away we move from t=0, the more stateful it becomes. This is equally true for Web 2.0 systems, but especially true for blockchains.

Consider the following example: a user may interact with the service to address a personal need, for example, to find a certain website with the aid of a keyword query. The service satisfies that need by returning a list of results, but a byproduct of the user’s action is the service improving its global state - e.g. with every new search queried, Google's algorithm is more informed than before, and therefore better able to deliver optimal results for all future users.

So it appears that while code is of paramount importance to kickstart a software system, as time goes by, the value migrates from the code to the state captured by the programme/protocol. A service’s reliance on state makes it fundamentally different than a tool. A service’s software, when instantiated, creates a vessel for persistent state. It starts off empty and becomes useful only when filled with data, users or both. State compounds and becomes more valuable exponentially. Code, while crucial for the stable operation and evolution of a service, becomes less important and necessary to defend.

As Denis Nazarov of a16z has noted in the recent past, "blockchains are too slow to do any computing that is really interesting aside from their one redeeming feature: they maintain “state” incredibly well", while concluding that they are probably the best “state machine” invented to date — properly aligning the incentives to coordinate a network of machines distributed globally that maintain this state of truth without an intermediary.


Statefulness and value capture

So, from the above, it follows that (i) stateful protocols have memory; the more memory they accumulate, the more valuable they become and (ii) value migrates from code to state over time. At the same time, (iii) the more memory stateful protocols and apps accumulate, the slower they become and (iv) blockchains are the best state machines invented to date.

Granted all of the above then, is there truth to the statement - "tokens that govern state will be valuable, tokens that govern schema won't"?

Since blockchains are in effect databases, we can define schema as the overall design of the database -  the skeleton structure that represents the logical view of the entire database. It tells how the data is organized and how the relations among them are associated. Conversely, as mentioned previously, state refers to the content of a database at a moment in time.

It then follows that as governance of an open source system comes into place, the value accrues increasingly more to the ability to influence future state. In other words, having influence over the terms that influence state (e.g. Maker DAO liquidation margins) is more valuable relatively to having influence over how those terms come into effect.