Cryptoasset Selection and Other Miscellaneous Sundry

“In matters of style, swim with the current; in matters of principle, stand like a rock.” — Thomas Jefferson

Days before I began writing this piece, I finished Ray Dalio’s book Principles. Besides being rather principled in my personal and investing life (the former informs the latter), I thought it would be fun to publish principles of my own, albeit those on investing in cryptoassets.

So that’s what I did. But before I published anything, I sent a draft of these cryptoasset investment principles to a few colleagues whose opinions carry significant weight. When I received their responses, however, it was clear that my principles were half-baked. Really, they were just notes and mental models that I’ve plucked from my head and converted into text.

So that’s what I’m sharing today. Nothing weighty like principles. Rather, I’m simply sharing half-done and very much unspectacular notes that inform my investment philosophy.

They say it takes a theory to beat a theory, and you can consider each of these notes to be miniature theories. On that note, I look forward to hearing your responses, especially if they are competing theories.

On Decentralization

As I see it, the inherent tradeoff found in most cryptoasset projects is one between decentralization and centralization. Put more concretely, projects can either be decentralized and unscalable or centralized and scalable. Rarely are things in life binary, of course, so it’s probably best to visualize this as a sliding scale between decentralization (least scalable) and centralization (most scalable).

Naturally, a project that is situated in the middle can be a hybrid (e.g., federated projects such as Stellar). To be fair, both centralized and decentralized projects come with their own advantages and disadvantages, which if you missed it, we spoke about here.

Very briefly, let us also touch on the definition of decentralization, since we’ve historically used it as a loaded term (the mistake is mine for not defining it in earlier pieces). Fortunately, to define decentralization in the context of cryptoassets, we don’t have to look very far. An excellent analysis conducted by Nic Carter gives us the definitions we need.

Carter defines decentralization on three dimensions: (i) decentralization of the nodes, (ii) the miners / stakers (i.e., the protocol level), and (iii) the governance level.

Thus, a perfectly decentralized project could be characterized by (x) cheap-to-run nodes, (y) equally dispersed miner hashpower / staked coins, and (z) an equally dispersed decision-making power (the section below on governance will cover this part in slightly more detail).

On Governance

In the case of governance, you can picture a scale going from democracy (decentralized) to autocracy (centralized). Naturally, both democracy and autocracy are idealized terms; you will find no perfect form of each in history (whether it’s governance of the sovereign, corporate, or holy state).

Now, biting into the philosophy behind governance is not a fruit I would like to taste; philosophers have been having this debate for centuries — who am I to contribute to it! Without arguing which form of governance is ideal, I do believe it is possible to list the merits of each, in addition to outlining where a specific governance type works or doesn’t work well. To the extent I could use lessons from history, I do (knowing history, I believe, is one of the greatest forms of leverage).

A recent paper out of Harvard’s Kennedy School explored the very topic we are discussing today. Titled Democracy Versus Dictatorship? The Political Determinants of Growth Episodes, the paper shows the effects of governance type on the medium-term growth of each country. The paper’s abstract begins like this (emphasis mine):

In contrast to previous literature, which looks at the effect of democracy on long-run growth or short-run volatility of growth, we examine the effect of political institutions on medium-term growth episodes. These are episodes of accelerations and decelerations that characterise the growth experience of most developing countries. We find that the effect of political institutions on growth is asymmetric across accelerations and decelerations, and that democracies do not necessarily outperform autocracies in a growth acceleration episode, though they are likely to prevent large growth collapses. When we disaggregate the type of autocracy, we find that party-based autocracies outperform democracies in growth acceleration episodes, though they do not limit the fall in the magnitude in growth deceleration episodes in comparison to democracies

Let’s take a look at another quote from later in the paper:

Democracies are unlikely to out-perform autocracies in growth acceleration episodes. However, they are likely to yield lower income losses as compared to autocracies in growth deceleration episodes.

And this is perfectly reasonable! Because of their centralized power, autocrats are able to make decisions quickly, giving them an edge (in times of rapid growth) over slow-moving democracies. Now you may be wondering, why at all does sovereign governance matter in the context of investing in cryptoassets?

If you think about it, the founders of a project are at first very similar to autocrats. For example, as he was developing Bitcoin, Satoshi could make any change to the protocol that he would like, whether it’s increasing the total supply of bitcoins to 42 million or renaming Bitcoin to Sukernikoin (we can all agree not calling it Sukernikoin was Satoshi’s biggest mistake. We can only assume it keeps him up at night to this very day).

So then, what are some governance notes? I’ve listed them below. Since governance is such a vast body of knowledge, I will attempt to list these notes as concisely as I can. Bullets do the trick well.

• For projects that need to move quickly at their initial stages, an autocratic (centralized) type of governance can work well. Just as the paper we referenced earlier mentioned, I believe a centrally managed project will advance more quickly than a decentralized one. Rapid advancements over a period of time will compound, allowing the project to be farther ahead than its decentralized competitor. When project team feels comfortable with how far ahead the project is, it can consider decentralizing the project in order to ensure its long term survival. Other than Bitcoin, we haven’t seen projects reach this stage yet. But watch closely, as decentralizing the project will prove critical to its long term success.
• Not all projects should pivot from centralized to decentralized in the same amount of time. Depending on the project, some will need to become decentralized faster than others to assure their survival. Bitcoin, for example, would not work if Satoshi kept development centralized with himself to this day. Ethereum, on the other hand, may be able to stay centralized much longer. I don’t think we have a perfect answer to how long the pivot from centralized to decentralized should take, nor do we know which type of projects should pivot slower or faster. If I had to guess, I would say projects that attempt to serve as a currency need to decentralize themselves as quickly as possible. On the flip side, projects that are platforms or applications can afford to stay centralized for much longer.
• It is far more difficult to change the direction of a large ship than a small one. This means that the larger the project becomes, the more difficult it will be to change it. For this reason, I would suggest thinking twice before investing in experimental projects that command a very high market capitalization, for they have much more to lose from experimentation than to gain (much like any large company). Here, projects such as Tezos come to mind. While we have no way of knowing, I think it’s safe to assume Ethereum would be much farther ahead had its price been suppressed to a maximum of $10 for the sole reason that it would be able to experiment at a quicker pace. (Nota bene: by saying so, I am implicitly making the argument that keeping the price of ether low provides greater benefits than the network effects of a high price. This point can be argued rightly by both sides; I merely take one of them).
• On topics where experimentation is needed, Mr. Edison put things most succinctly: “ hell, there are no rules here — we’re trying to accomplish something.”

On Evaluating the Target Market

It has become somewhat of an inside joke among savvy investors when projects say they have a total addressable market in the trillions. Why, if you believe them, you’d probably be tricked by ole’ Miss Daisy!

To put things bluntly: nobody — not even the founders — know what the target market of an early stage cryptoasset project will be. If they do know, they’re probably selling snake oil in their free time. Early stage projects constantly pivot, and the target market will naturally pivot with the technology.

A few years ago, folks were trying to model the future price of bitcoin by tallying the market for international remittances and applying penetration percentages in order to determine what amount of the remittances market bitcoin could address.

Today, few think of bitcoin as ideal for remittances, given the rapid increase in transaction fees (for most remittances, censorship resistance presents itself as a classic case of performance oversupply). More recently, folks were making the same calculation, but with the market for gold. We will come back to their calculations in a few years to see just how wrong they were. In short, total addressable market (TAM) calculations are valuable, but not when you’re unsure what the product being sold is.

If there is one thing we know about bitcoin, it’s that nobody knows where it’s headed, especially once network improvements such as Lightning Network and Merkelized Abstract Syntax Trees (MAST) develop.

On Marketing

Among venture capitalists, Chris Douvos is a well known figure. He’s well known because he is the rare LP with a public persona. But to me, he’s great for putting me on to this formula: Opportunity = Value-Perception. In my interpretation of the formula, assuming the value of a company stays constant, the greater the perception surrounding the company, the lower the opportunity to make above average returns. Or to paraphrase Howard Marks, above average returns don’t come from being consensus and right.

I avoid projects that market themselves heavily for two reasons. First, they increase their perception among the population of investors, making it unlikely that every investor will generate above average returns. Second, they’re often setting themselves up to overpromise and underdeliver in the long term.

The second point requires a bit more elaboration. The technology underpinning nearly all cryptoasset projects is still a relatively new, and it won’t be ready for mainstream usage for years. Look no further than the scaling roadmaps of Bitcoin and Ethereum to tell you as much. Great developers don’t keep this a secret either. It’s the boosters that sell you the dream of blockchains with the throughput of centralized systems and the benefits of decentralized ones.

Projects that engage in this type of better than life marketing are shooting themselves in the foot by promising things to the user which will not be available for years. User’s don’t have that kind of patience. More often than not, projects that engage in this type of overzealous marketing are smoke and mirror machines; once the smoke clears up, the bare emperor will become exposed.

On People and Teams

Something I’ve always been unsure about is why anyone in their right mind would call themselves a serial entrepreneur. To my ears, that sounds only a little better than serial killer (at least the latter doesn’t switch careers every year!).

While I jest, I take diligencing the project team very seriously. Similar to what we did under the governance section, we will use bullets in this section for brevity.

• You want to pay close attention to the past experience of the founders. I have noticed many founders in this space have started 2–3 projects in the past few years, jumping from one to the other as if they’re on a road of trampolines. Raising money from investors for one ICO project, leaving that project, and doing the same thing for another ICO does not inspire confidence. There is nothing wrong with failing in one project and starting another one in a few years after some self-reflection. There is something wrong, however, if this is done in an obviously opportunistic way.
• While not mandatory, it’s generally great when project founders said no to high paying salaries in order to work on the project. That usually means they had plenty of lucrative options to chose from, but chose the project because of their conviction for it.
• Generally speaking, the fewer conferences founders attend, the better the project (unless they are fundraising, doing demos, or hiring). The reasoning is rather simple. Conferences take time. This time could be spent on things such as developing the project, building better developer tools, and if it’s centralized, growing the company.
• Projects solving problems that the founding team does not empathize with should generally be avoided. Here, projects that immediately come to mind are those that are built by first world elites for third world developing nations. Folks from New York City dressed in suits probably don’t viscerally feel what it’s like to be unbanked living in Africa. But supposedly, they have the solution!

On Competition

Craig McCaw was one of the folks who pioneered broadband internet in the United States. As he was building out the pipes for the internet with his company NextLink, he was known to say brilliantly witty things. For example, here’s a quote of his that I reference often: “you are always at the mercy of your stupidest competitors.”

What McCaw said of broadband competitors is similar to the type of things we see happen in cryptoassets. In August, for example, Bitcoin Cash (BCH) forked from Bitcoin, giving users 8MB blocks. To the uninformed user and sensational journalist, this seemed like a panacea for the high transaction fees and the large pending mempool of Bitcoin. But in reality, this was a band-aid solution to a problem that only surgery could fix.

With competitors that seek short term solutions, it becomes difficult for projects to think long term. Despite this, good projects will ignore short term narratives and build for the long term user. Competitors can always copy (fork) what your project is building, but they cannot copy the incentives and the team behind the project. And that’s just as good, if not better, than IP.

Arjun Balaji, Josh Nussbaum, Crypto de’ Medici, and Dan Zuller had the unpleasant misfortune of reading this post before it was published. Because of their sacrifices, it stands in a readable format today.