Blockchain tech and cryptocurrency are the underpinnings of a new financial infrastructure, just as the internet was the underpinning of a new information infrastructure. Neither was, nor will be, built overnight.
When one looks at the history of advances in free speech and increased access to information, you notice, almost universally, that society advances by every imaginable metric: literacy rates, educational advancement, dissemination of ideas and new technologies, GDP per capita, and poverty rates — just to name a few.
The first information revolution was the printing press, followed by the telegram, telephone, radio, television, and of course, the internet. The internet is interesting in that it encompasses all the other revolutions into one: you can listen to sound over the internet, you can read a text, and you can watch videos. You can even do it all in the same place! The internet, unlike historical information revolutions, not only revolutionized access to content, it democratized the creation of that content.
Finance hasn’t gone through this series of revolutions, indeed nothing close to the level of free speech wrought onto society by the internet. At best, one can argue that most trades today take place electronically; financial infrastructure uses the internet to communicate; and execution speed has improved considerably since the 1970’s — all true statements. Finance, however, has not been transformed at its most critical point: the creation of new instruments, contracts, and agreements. If today you wish to create a new financial contract — a derivative, loan, or money market instrument, for example — good luck! In short, I would argue that finance has not even begun it’s equivalent to the printing press phase of the information revolution!
This sounds radical, just as it would have seemed quite radical to suggest that people beyond monks and scribes would want to author their own books, or that people would want to have their own websites or spin-up new websites about entirely random subjects.
People exclaimed, “But shouldn’t the publishers control what gets published, they’re a check on sensibility!”
Others rejoined, “What if people were able to publish whatever they want and choose for themselves what to read?”
I’d argue that the same fundamentals apply to the financial system, and by opening access to democratize the creation of new financial markets, society will benefit on the scale brought by the information revolutions in the past, but this time, it’ll transform value, money, and finance.
There’s another weird thing, specifically about cryptocurrency: given the sorry state of finance, we’re not just trying to create the printing press, or the telegram, or even television. No, here we’re aiming to jump straight to the level of disintermediation and free speech of the internet today but applied to finance.
It’s only natural to consider money an extension of speech, and, even if you disagree, Citizens United effectively deems it so. But one doesn’t need a Supreme Court case to recognize that bits of information on a computer are speech, and, therefore, if you can represent money as bits, it too is speech.
Just as the internet effectively created a parallel information infrastructure, crypto (sorry cryptographers, the term has officially been co-opted!) will build a parallel financial infrastructure. And, no, it’s not going to happen with private blockchains any more than the internet revolution occurred with intranets.
Remember after the internet how companies were either “internet native” or offline behemoths (publishers, music, and streaming/videos/television)? The same thing’s going to happen here. Old school financial behemoths will either have to adapt, support, and ultimately join this parallel system or fade away.
This infrastructure will be borderless, cheap, quick, and, most importantly, will let people trade on things they’ve never been able to exchange before, and if markets for those don’t exist yet, it’ll let them create it.
Imagine being able to develop new financial markets that previously needed a multimillion-dollar bespoke contract designed by Goldman, but with a few points and clicks?
Not only will that happen, but it’s also already here. It happens to be slow, expensive, and hard to use, just like the internet was in 1992. Fast forward a few years, and it’ll be fast, cheap, and easy to use. One benefit of the internet is that we have the internet to help us build crypto faster, a luxury that didn’t exist in the early days of the web. The reason all of this will be possible is due to blockchains’ lower coordination and enforceability costs, it’ll all happen programmatically instead of having to trust an institution to do things in a fair, open, and honest way.
For any financial system, you essentially need two core components: the underlying and derivatives.
The underlying is what exists in the real world: stocks, bonds, commodities, etc… A derivative is a contract that derives its value from the performance of an underlying. For example, a derivative on Tesla stock might give you the right to buy Tesla at a future date at a given price, or it might be a cash-settled agreement that pays the price difference between the price Tesla today and the price at which it trades in one month. Most of the activity and value in the financial system is in derivatives: Why, the thinking goes, buy something imprecise (the underlying) when instead you can make a bet tailored to your unique and desired terms (a derivative)?
In any functioning financial system, these primitives require a set of tools like:
- Leverage — being able to essentially bet wherein something goes up a dollar, you gain or lose a multiple of that
- Margin — being able to borrow money against things you already own to buy more stuff (you can see how this can quickly go wrong)
- A Unit of Account — such as something stable to trade in (like the dollar)
- Exchange Infrastructure to actually trade the assets on
- Lending and Issuance Infrastructure — to issue both debt and equity instruments (underlying). Projects that work with these core primitives can be divided into three categories: Those that solve issuance of the underlying on blockchains, those that solve trading of derivatives on the underlying, and those that solve the trading of the derivatives on…everything else.
In each case, the crypto infrastructure will be able to accommodate.
Leverage, for example, is easy to insert and code into the structure of a contract. Margin (and Lending) requires systems like Dharma which enables people to borrow cryptocurrencies using other cryptocurrencies as collateral.
For a unit of account, getting a stable cryptocurrency is a challenge. It is not as simple as just tokenizing US Dollars — a depository bank could unexpectedly freeze the account. A better approach is to create something like Maker, which is developing Dai — an asset-backed, hard currency and the first decentralized stablecoin on the Ethereum blockchain. Effectively, the stablecoin is backed by over-collateralizing the system with other crypto-assets. Despite blathering by bloggers, Dai remains valued at one US dollar, thereby retaining its peg.
As for exchange infrastructure, 0x‡, is an open protocol for decentralized exchange message formats on the Ethereum blockchain. 0x is building a lot of the exchange infrastructure and developing protocols for exchanges to use.
The Blockchain community today is building out the foundation and infrastructure required to host the necessary tool set of a functioning financial system. This tech is good for multi-sided marketplaces.
I don’t believe that all traditional assets will migrate to blockchains, and ones that do will have restrictions on them since they frequently touch the real world.
Security tokens, for example, are a great “9-to-10” innovation, but they are not a “0-to-1” type of innovation like the projects described above. The greater the interaction between the real world and blockchains, the more challenging the overall project becomes — and security benefits of using the technology begin to fade.
For example, if a tokenized stock owner loses their private key, they will likely have the right to recover the stock. However, as more and more governance layers are added, the protocol eventually converges to a Wall Street 2.0 database with a smoother backoffice and less — if any — public blockchain interaction.
There are some exceptions to this, e.g. Harbor*,which is trying to tokenize real world assets and have them tradable on Ethereum. The benefits of this are cheaper costs to securitize assets and more global liquidity pools — with the latter possibly being the biggest benefit. I think it’s harder to capitalize on this space though, but there’ll be a handful of players like Harbor that dominate, and most of the value will go to the companies and assets that get tokenized.
For issuance of debt underlying, the Dharma protocol is well suited and is more crypto native. For derivatives on the underlying, you have projects like dYdX — an open source protocol for decentralized margin trading and derivatives on tokens on Ethereum. For trading on everything else, even assets where there is no on chain underlying, there’s Augurǁ, a decentralized oracle and prediction market protocol. While tokenizing most real-world assets will take decades at best, once blockchains scale and there are good fiat on-ramps, these new financial protocols will be able to take off faster than a Model 3 in Track Mode.
Blockchain tech is good for multi-sided marketplaces — particularly for finance. Other use cases, which really just converge with financial markets, include: file storage markets like Filecoin‡§; computational markets; markets for items in video games; namespaces like Handshake‡§; regular betting/gambling like FunFair‡; and sharing economy protocols like Origin‡§. These projects will fuel a classic disintermediation play: cut out the existing profit-seeking corporations and replace them with software. As software eats the world, software is eating software.
You’ll notice I haven’t touched much on money here. In general, I think cash and payments are one of the last areas blockchain will affect. But I think, that too, will eventually will be transformed by crypto. While Bitcoin may win digital gold, I don’t think it’ll succeed as money: it’s too volatile, isn’t designed to be money, and has no dynamic monetary policy (which is part of why gold was abandoned as a form of payment in society). I think Beam‡§ has a chance of tackling this goal: it’s the only cryptocurrency I’ve seen thus far which has a dynamic monetary policy designed to minimize volatility, without keeping a 1–1 peg to a traditional currency (which won’t hold up against attacks in my opinion, except for large collateral backed reserves like Maker). Anything that doesn’t work in the regular world currency wise, I doubt will work in crypto. Anything that does work in the ordinary world, might work in crypto — and this is what Beam is trying.
A new financial system sounds exciting and promising, but its useless without underlying liquidity. What is liquidity? Think of it as a running stream of water. A dried-up stream isn’t useful: fish can’t swim in it. On the other hand, a stream full of water sustains a small ecosystem. Imagine you want to buy Tesla stock: if you try to buy $5,000 worth and your order gets immediately filled, from your perspective, the market is liquid. However, if you decide to buy $5,000 worth and it takes one day for your order to get filled, it would be quite right to say that the market is illiquid. To encourage liquidity, it needs to be fair, easy, cheap, and fast to trade in each market. Right now, blockchain-based financial markets do not have most of those characteristics. Consequently, I do not expect to see much liquidity or usage until they do.
Anyone screaming that the lack of users means blockchain tech is useless, probably doesn’t understand liquidity or what attracts it. For something to be adopted and widely accepted, it needs to be 10x better than the existing experience. In blockchain tech we just aren’t there yet. I will address this later in this paper.
The lack of liquidity is a binding constraint. If people are unable to trade quickly and make markets because execution is too slow or expensive, it’s practically impossible to bootstrap a marketplace. Once these problems that I will discuss later are solved, I believe we will witness one of the sharpest S curve shifts ever seen in adoption.
Bootstrapping a marketplace in crypto is not like building a web 2.0 application and waiting for a bunch of traffic by simply spinning up more servers. Here, you cannot get any meaningful traffic without the “server” capacity being high out of the gate (read: network throughput) because liquidity begets liquidity. If traders cannot market make on financial dApps, they are unable to add liquidity.
So, what about companies building on top of all this open source stuff? Fiat on-ramps seem like a clear opportunity that could capture value, what else?
We could easily see a flourishing of a bunch of mini Red Hat style businesses on top of these protocols. There are almost limitless opportunities for companies to offer value-added services that capture value in a non-rent seeking fashion. Some examples include making it easier to construct smart contracts, providing tools for writing smart contracts more securely, Stripe style KYC/AML compliance and onboarding, better exchanges, custody solutions, dispute resolution and arbitration tools, remittance companies, asset management tools, etc.
In the traditional company space, I believe we will see the most significant value capture in the medium to long-term on easy-to-use interfaces developed on top of protocols. We are only just beginning to see the first of these with projects like Veil which aims to create a derivatives and sports betting site on top of Augur.
Why would someone build on top of a protocol instead of a traditional centralized company (side note: dApp is the new horseless carriage, a few years from now they’ll just be called apps) as opposed to just making a centralized company? There’re two answers: lower fees, and regulatory advantages/unbundling.
Provided a protocol is designed correctly, you will not be able to fork it and lower fees, because proper protocols are not rent-seeking: they charge the smallest fee level to execute transactions without compromising the security of the network. Augur, for example, has adopted an almost sacred approach to what could be described as a decentralized version of Amazon Jeff Bezos’ creed, “Your margin is my [protocol’s] opportunity.”
So, from a fee level perspective, there is no reason not to build on top of something else. If you lower fees by forking a non-rent-seeking protocol, you will sacrifice security. For instance, if it costs $1,000 to secure a given network and miners or stakers are only being paid $500, it could create an incentive to do malicious things. Whereas if they’re paid $1,000, the network is incentive compatible, secure, and everyone’s happy. Or if you raise fees, you will become the rent seeker and get disintermediated yourself.
It begs the question, “Okay, how will these companies make money?”
The answer is by supplying services that are valuable and worth the price they cost. Taking the Augur user interface (UI), hosting it on AWS and slapping a 50-bps fee on top will not last and is not a sustainable business model.
However — supplying liquidity and market-making, or taking a risk on as a trader — will always be rewarded by someone willing to pay a price for the liquidity. There may be competition, but people are still willing to pay for instant liquidity.
I think these companies may look more like Two Sigmas (software + finance experience combined) than Googles or Facebooks.
The second advantage is from a regulatory standpoint. We are beginning to witness a segmentation of regulatory compliance. Using Coinbase as an example, if they had created and operated Bitcoin (as a centralized network), they would have been burdened by significantly more compliance obligations than had they chose to merely function on top of the Bitcoin Blockchain and used Bitcoin.
Under the former scenario, they would be characterized as an operator of Bitcoin, resulting in a colossal compliance obligation. Imagine having to deal with money transmission of several pseudonymous users across the globe!
Instead, they use Bitcoin and consequently are only required to fulfill KYC/AML requirements on their clients — the users exiting and entering Coinbase itself. In other words, these systems divide regulatory compliance obligations in a highly segmented fashion. A lot of the benefits of smart contracts are also that they can enable fairer, programmatic, transparent, and open markets where things happen programmatically and the rules are codified and fair for everyone.
It would be impossible to run an exchange that is compliant in 150+ jurisdictions, but it is entirely possible for multiple exchanges to spring up that are able to comply with their own respective local jurisdiction.
Similarly, with other solutions that are being created such as Veil, you could do KYC/AML on your counterparties for taking trades/bets in the countries where they operate, but possibly not have to register as an exchange itself (because Ethereum nodes do that, Veil would merely be another trader on the p2p exchange). Although, if Veil got into the business of creating markets or matching orders, it could be a different story and registration may be required. Either way, “Veils” in their own respective geographies could spin up and provide their own compliant interfaces into decentralized protocols like Augur or 0x.
Back To ‘Companies On Top Of Open Source Protocols’…
I believe these sorts of businesses will capture a good amount of value because they will reside in the areas where consumers interact the most. Worst case scenario, if you are a user of an application built on top of a decentralized protocol and that application goes down, you can always revert to fully decentralized UIs as a backup.
Projects on top will differentiate themselves by skinning things differently, removing certain functionalities, adding features, making things easier, or just making things simpler. For example, in my opinion, one could create a multibillion-dollar company with this strategy by creating an easy-to-use betting style UI on top of Augur where they took the other side of the trades profiting off the spread and competing with Bet365 — something I would fund if done right with the appropriate licenses. As Jeff Bezos would say: their margin is your opportunity.
Companies building on top of protocols sometimes forget one critical component: while a protocol executes a lot of backend/backoffice related tasks, it does not market for you. Building on top of a protocol shifts a lot of your company’s focus to user acquisition and marketing. And don’t forget that it’s not the protocol’s job (or ability) to market your product on top anymore than it is Google search’s job to market your website.
In my opinion, there are three main barriers to both feasibility and adoption of all this tech:
- Nascent Infrastructure
- Fiat (to Crypto) On-Ramps
On the infrastructure side, building something in the cryptocurrency/blockchain space is more akin to building a rocket or, to biotech, than it is to building something like Snapchat. The developer environments, languages, and tooling are just so new in crypto — it makes it a difficult experience to create something. It’s like the early days of the internet when creating a simple website was difficult. Building on Ethereum, you can use Solidity to write smart contracts. Solidity is a step up above Bitcoin’s scripting language which doesn’t allow you to do much at all. Building all this sort of stuff has only really even been possible since 2015. It’s time-consuming to test Solidity as well because there aren’t any good test frameworks for testing Solidity smart contracts. And Truffle, one of the few solutions out there, is not too great or easy to use.
The most significant challenge, however, is to ensure that written code is correct. There are two aspects here: your spec and your implementation. When specifying a protocol design, it is time consuming to ensure the technical specification makes sense. Notwithstanding that it is also imperative for the code to make sense economically.
Crypto is rare in that it combines computer science and economics quite intimately, and if you don’t get both right (i.e., incentive compatible), then your system will not work, or, worse yet, could catastrophically fail due to an attack. This requires many long nights of game-theoretical debates over different attack vectors and the ways something could go wrong. Once you have a spec, the next step is to implement it and, when you do so, it must essentially be a 100% perfect match to the specification. Otherwise, your system will not do what you planned for it to do.
Once you have your code written, you then have to do security audits by multiple independent third parties, bug bounty programs, manual code reviews, write copious amounts of tests, run static analysis tools that detect common vulnerabilities, and make sure these things have also been done for any critical code you rely on. Oh, by the way, most of these tools don’t work well for projects that use multiple smart contracts that interact together.
What’d You Say About Rockets?
If you’re NASA building a rocket and subsequently launching it, you have only one chance to get it right. Any bugs in the rocket’s code could inadvertently cause it to blow up. Of course, a replacement rocket could be launched, but loss of a rocket is quite expensive and has tragic consequences if anyone is on board.
In crypto, the launch of a rocket is equivalent to the launch of a smart contract. The smart contract’s cargo, however, is money. There is one fundamental and critical difference between a NASA rocket and a smart contract: a rocket’s code is closed source, while a smart contract is open source. The analogy would be a rocket in midflight, while anyone who wants to can issue commands to blow it up. Oh, and because of open source code, anyone can read all the blueprints to try to find attacks. This is the challenge of writing secure smart contracts.
Approaches To Decentralization — Using ‘Autopilot’ As A Metaphor
There are two approaches to create decentralized applications. One is to go fully decentralized from day one, and the other is to start relatively centralized and become progressively more decentralized over time. This is similar to different approaches in self-driving. With Tesla, you start closer to Level 2 (partial automation) autonomous driving and progressively go towards Level 5 (full automation) over time.
With Waymo, Alphabet Inc.’s multibillion-dollar self-driving vehicle project, you’re starting at Level 4–5 and waiting to scale until it can be achieved in a secure fashion. Cryptokitties or 0x relayers have taken a Tesla style approach, with centralized websites hosting the UIs and progressively opening things. Augur, on the other hand, takes a more Waymo style approach where it started fully decentralized from day one, and is now working on improving the experience and scalability to be possible in production at scale.
In self-driving, I think the Tesla style approach makes more sense as you get end users in the real-world testing things out. In my opinion, security and trust issues make the Waymo approach more sensible for crypto. Additionally, everything is gated by scalability issues anyway, so you have more time to iterate while that’s the limiting factor.
What’d You Say About Biotech?
If you look at a biotech company, typically they have what’s called a pipeline, which is a series of drugs that are currently undergoing research and development. Moreover, the company hopes they can solve a bunch of unsolved research problems and, in doing so, they will finally be able to release a drug to the public that’ll provide a benefit. These drugs usually go through three to four phases. First, you have the discovery of a drug candidate and, if it looks promising, the start of trials. Sometimes animal trials happen first, or sometimes companies jump straight to human trials. Then, within human trials, you have essentially three stages.
What’s interesting about biotech is that these companies, many of which are publicly traded, fundamentally must solve research problems on demand. And, like crypto, you have all of these unsolved research problems: like figuring out scalability, proof of stake, the data availability problem, etc…that you kind of have to do on a timeline. People are interested in seeing Ethereum release Casper (a Proof-of-Stake protocol); and sharding, etc…And they’re asking people to solve all of these unsolved computer science problems on a timescale of two to three years. I think that’s part of why these markets are so volatile: when you look at some of the world’s greatest biotech companies, their stock prices sometimes floundered for a long time until they executed on certain vital milestones or had successful trials in various phases of the drug. Of course, for crypto, these are early days, and I think we’ll see this sort of dynamic for the next 5–6 years (I may even be underestimating this). After that point, I think crypto will look much more like traditional software development.
As an investor, you should necessarily buy things that you think will do well if some critical milestones in the space surrounding scalability and cheap on-ramps are hit. The cool part about crypto, which we’ll get to in more detail shortly, is that the catalysts for most projects are tied together. As an investor, you can figure out who is good at execution and building things you think will have a longterm value for the ecosystem; and with a solid team, tech, and economic fundamentals behind them. Then your bet is essentially that, if these problems are solved, that team will succeed from the utility of what they’ve built being enabled by scale. In other words, pick investments that stand to benefit the most from those problems being solved and that are either creating this future, or allowing it. Like biotech, you’re going to get killed if you try to time the market, instead buy a basket of companies with good teams and products, and hold them until they either get adopted or fail.
When we think about what will catalyze this market, the remaining two (scalability and fiat on-ramps), are also the most important.
The reason scalability is so important is because, without it, these applications are neither fast, cheap, nor easy-to-use. Now, it’s easy to look at Bitcoin and say, “Things have only scaled a small amount in a decade — this will never scale!” I think this is shortsighted for a few reasons. One being that Bitcoin is primarily used for transferring value, and there are better solutions for scaling that (like Lightning). In addition, scaling smart contract platforms with utilities beyond payments has only been in development for three years.
Ethereum, for example, has only been around three years, and while the first few were spent making lots of developer user experience (UX) improvements, bug fixes, etc., the next three will be spent scaling the technology. Also, until recently there were no substantial applications or projects on top of Ethereum that were live. From a practical standpoint, now that there are real world applications, people working on scalability can look at those use cases to see how they should solve scaling problems.
There are two places to scale blockchains: Layer 1 and Layer 2. We examine both below.
Layer 1 simply means the underlying blockchain such as Ethereum and Bitcoin. The main scalability challenges come down to networking, storage, and computational power. Networking is the biggest bottleneck. If you want to propagate a block full of data around the world, you might send it to a few computers, then those computers send it to a few computers, and so on until the whole network is aware of it. This takes a good amount of time, which is why Ethereum and Bitcoin have a relatively high amount of time between blocks. If you can figure out how to decrease propagation times and reduce the time it takes to send a block around the network, you can increase throughput and speed. If you had a computer 10x more powerful than the one you have today, without fixing the network propagation issue, you would not see a meaningful increase in throughput due to bandwidth still being the limiting factor.
Some ideas for fixing networking issues are to compress the data so that nodes just send around smaller amounts of data. Another is to attempt to reduce the number of hops required to get the whole network to be aware of a piece of data by doing something like what Bloxroute is doing by building the equivalent of content delivery networks (CDN’s) for blockchains. This should result in a meaningful 100x throughput increase out of the box.
Another attempt is to not require every computer on the network to be aware of every transaction, or to effectively “shard” things. I will discuss sharding and STARKS (another technology solution) separately as they essentially may solve all three roadblocks to scalability upon execution. There are also Direct Acyclic Graphs (DAGs) that allow people to process and broadcast transactions in parallel, which could help with networking issues. The challenge is that no one has figured out how to achieve a global ordering of transactions in a DAG (well, maybe, stay tuned here). The lack of an ordering-of-transactions capability makes trading and financial applications extremely difficult.
You can also do things like decouple processing transactions from achieving consensus upon them or having fast and slow paths where the network is relatively centralized by default but falls back to being fully decentralized if something goes wrong. That’s another great one-off,100x or more increase in throughput.
Storage and Computational Power
The other two big challenges here are storage and computational power. Computational power is much easier, it’s almost always increasing, and even my MacBook Pro can do thousands of transactions per second. If we want to improve it further, there’s tons of work that could be done by switching to using Web Assembly which is far more optimized than the EVM and doing things as native code as opposed to the EVM which is quite slow. There’s also work that could be done to process non-interacting transactions in parallel across multiple processor cores/threads.
On storage, there are two problems, one is that blockchains today require a great deal of reading from, and writing to: the disk. This could also be parallelized — work is already underway to do this on Ethereum.
The other problem is the sheer amount of storage capacity required to store the blockchain and the data associated with the blockchain. Bitcoin and Ethereum require many hundreds of gigabytes of storage space, and someday this will be in the tens of terabytes. One solution to this is to have finality gadgets that finalize blocks after a certain point, allowing nodes to chop off history and only store the more recent blocks. Still, storage of all the state data associated with the blockchain will still be required, and further research looking at ways to store data more efficiently, compressed, using less data, etc is going to be important.
There are two pieces of technology that could essentially solve all layer one scalability problems: sharding and STARKS. Both sharding and STARKs are promising. In my view, both are roughly three years away from wide scale production and use.
Sharding is the idea of making it so that individual nodes in the network are not required to store all the data, to process all the transactions, or even broadcast all the blocks. A simple way to think about it is if you were to slice the blockchain into n slices. Users would then just pay attention to slices they use.
Concerns arise, of course, with security: how do you ensure someone is unable to attack a shard and get an invalid transaction processed or something censored? And there are challenges with enabling communication across shards. For instance, imagine if an Augur market lived on shard “A” while Dai lived on shard “B”: there would need to communicate securely with each other for Augur to use Maker. Assuming all the challenges listed above are resolved, including the problem of ensuring that the data does not disappear across shards (data availability), you end up with a scalability solution that addresses the networking problems, computational issues, and the storage challenges.
For STARKS, the idea is you can bundle a bunch of transactions together and prove that the transactions were processed in an honest fashion, then nodes just verify these proofs. So, you (someday) process 10000 transactions by verifying a single proof. Of course, there are problems like proof size and creation time, but companies like Starkware*† are solving these issues. Less computational power and networking bandwidth is required because this technology enables people to verify batches of transactions as opposed to running every transaction.
Layer 2 involves protocols and technology stacks above, or on top of, layer one. These technologies include the following systems:
- State/Payment Channels
- Plasma (examples: Gluon Plasma and Arbitrum)
All of these systems support smart contracts without certain limitations of scalability, and each has different tradeoffs.
For state channels, the idea is you collateralize contracts with capital and then sign messages of transactions to pass money around. The tradeoff this makes is liquidity/capital lockup. At a minimum, 2x the collateral required to do a transaction is needed, so this tech will work well for use cases like payments. But I believe it’s unlikely to work well for cases like trading — where users will balk at the collateral requirements.
Sidechains are systems like POA Network, Cosmos, and Polkadot‡§. All are various ways of connecting parallel systems to chains like Ethereum and using those new networks as scalability avenues. For instance, Augur, Maker, and 0x might all run on their own parallel chains in these systems. It’s difficult to get security right, as well as seamless bridging of these chains together, but Polkadot and Cosmos are making strong progress here. Plasma could also be considered to be sidechains, in a way.
Plasma, which doesn’t require excess capital, still has a lot of unsolved problems: it takes a long time to settle/withdraw back to the main chain, it requires logging around relatively sizable amounts of data, it’s difficult to do with account-based models / full on smart contracts like Ethereum, etc. These problems will eventually be solved I think, but for now it’s quite early. The most promising thing I have seen here is something called Gluon Plasma.
Finally, we have Arbitrum. I think this is the most interesting tradeoff because it doesn’t involve liquidity or time, but rather a very minor trust tradeoff. The tradeoff with Arbitrum is that there must be one honest person/node in the validator set, that’s it. If there’s one honest node, the system will operate securely. As a user, you effectively deposit your funds in a separate VM, and then all the transactions are processed quickly there. If anyone disagrees it can be disputed on chain and the point of disagreement can be pinpointed and verified on chain, whoever is wrong loses a bond of capital they’ve put up, so there’s financial incentive to be honest.
Fiat on-ramps are an essential piece to the puzzle as well. A large part of the benefits of crypto is that it makes things substantially cheaper in the long run. A simple illustration of this is the concept of a payout ratio in betting: all else equal, if you bet $100 on a bunch of random dice rolls and get back $92, your payout ratio is 92%, or your fees are 8%. Right now, if you want to use a decentralized exchange, or something like Augur, your fees are going to be around 10% or more: ~5% daily price volatility of Ether; a few percent fiat onboarding costs; and a few percent due to gas fees to trade. Scalability will help the last one; projects like Maker and Dai will help the first one; but the fiat onboarding cost still needs to be solved. For this, there are two angles to consider:
- The Exchange and Institutional On-Ramp Problem
- The Broker and Consumer On-Ramp Problem
I believe that Bakkt†, the newly-created subsidiary of Intercontinental Exchange, will solve the institutional on-ramp problem by providing low cost exchange transaction infrastructure. No one in the world runs a better global network of exchanges that than ICE — it’s their bread and butter.
In crypto, the consumer side will be critically important to the future development of any decentralized application — consumers will need the ability to cheaply and easily convert into crypto.
If they are forced to leave the app and go to an exchange at a cost of 2–4% in fees, mainstream adoption may never take place. Instead, the winner here will look much more like Stripe — but for onboarding into dApps. Wyre is the leading and, in my view, the sole contender in this space today. They aggregate liquidity across exchanges, OTC providers, and others — which results in low-cost trading with ACH support and debit card onboarding. In short, the ability to get into and out of Dai for less than 50 basis points would permanently knock this problem out of the park. My money is on Wyre.
To fully maximize the investment upside in this nascent market, I would take a medium to long-term focus. The market is often irrational in the short term, and it will take a while to separate the wheat from the chaff. In short, the market today does not recognize the idiosyncratic attributes of many projects that are actually useful, have strong development teams, and can attract users. Only when the technology begins to scale and cheaper on-ramps become more available, will the market begin to recognize which projects have merit and which do not. To paraphrase Warren Buffet, when the tide rolls out, we’ll see who is wearing bathingsuits and who isn’t.
So, it makes sense to buy and hold assets in this space on a medium to long-time horizon, while everything unfolds. In addition, the nascent nature of the market often requires a longer reaction lead time to positive developments in the underlying fundamentals. A case in point was the launches of Ethereum, Maker, and Augur, in which the native asset in each case dropped in price immediately after achieving an important milestone.
As an investor, you primarily want to do three things:
- Buy the assets and companies that will most effectively enable your investment thesis;
- Hold them, buy more when they decline in price or become cheap vs. fundamentals;
- Constantly reevaluate #1 and #2, and your thesis
ThIs sounds easier said then done. For each project, I look at the Tech; Economics; Team; Market; Product and Traction; and, after making an investment, Constantly Reevalute.
When I’m looking at projects in the space, the first thing I look at is the tech. This may seem silly since it’s contrary to pretty much all conventional wisdom. But given how young crypto is, a project is more like building a biotech company or manufacturing a rocket than a traditional software startup.
There are some exceptions to this rule, namely businesses that aid or support the actual underlying vision. When you evaluate the technology, you are looking to see whether it makes sense. Now this sounds stupidly abstract, but it is quite a bit more concrete than it appears on the surface. Say, for example, that you invest in companies in the energy industry and someone shows you an idea that violates the laws of physics — like a perpetual motion machine…You should avoid that company/project.
Similarly, people are doing projects that essentially promise the computer science equivalent in the blockchain space. I would argue that most projects in the area promise the equivalent of perpetual motion machines, particularly in scalability research. Lots of investors don’t understand things: like that the networking layer is a much more significant bottleneck than a computational one, or that a scalability proposal can sometimes converge to just a handful of AWS servers — not very decentralized.
After assessing the tech, it is critical to evaluate the economics of a project or company. Crypto is one of the few fields where computer science and economics are closely intertwined.
A common mistake is creating a cryptocurrency that is used only for payments within a specific app. This is akin to forcing all Walmart shoppers to buy things with Walmart gift cards only. One, this severely restricts your market. Secondly, the crypto in this example would not be considered a valuable asset. People would exchange into it only when they need to use it, and trade out of it when they are done. As a result, the cryptocurrency will not need to accrue much value as a prerequisite to sustain economic activity.
So, having a token that’s useful, say — as a staking mechanism, for example…or that’s a yielding asset — this is essential. It’s also crucial that incentives in the system add up: it shouldn’t be possible for a handful of people to cause the system to collapse or fail.
Any system that is incentive compatible should not rely on altruism or goodwill to function. Instead, a rational profit maximizing response should be the most profitable decision and behavior for all network participants — and the one that happens to be honest.
The reason for this structure in cryptocurrency is because all the actors are pseudonymous. To trust people, you must align economic incentives. In my view, projects need to perform significantly more in-depth game theory analysis. This is as opposed to simply slapping something on paper with little rigor and even less consideration for economic incentive structures.
Once you’ve established that the tech and economics are good, the next step is to look at the team. While good tech and economics are essentially table stakes, a good team is what you need to push things over the line. The qualities necessary in a group building a normal company have been analyzed to death, so I won’t bore you with it here (relevant domain experience, insane drive and work ethic, credibly describable as an animal, brilliant, visionary, honest, well rounded, etc…). However, when building a protocol, there are a few additional things you want to look for. For instance, it’s vital that a team have experience building communities in the past and have experience with open source projects. The mentality between closed source and open source is just so different, and if you don’t understand the latter, it will be like you’re speaking something that’s tone deaf to your audience. It’s also important to be able to build developer communities: you almost need someone like Apple’s original evangelist, Guy Kawasaki, to get developers to build on your protocol.
When looking at the market, you want to invest in something that either may have a large market if/when specific technical and user acquisition problems can be solved, or, something that looks like a toy — but that people are interested in. That second category might be a hint that there is a much longer tail of applications of that toy than first meets the eye. Another way to think about this tech is as the long tail of finance: just like Amazon became the long tail of Internet retail and eventually cornered most the market, crypto will start as the long tail of finance.
Product And Traction
Beyond those things, you also have product and traction, which, despite all the other stuff, are two of the most important things. Lot’s of crypto projects don’t yet have these because the space is so early and the infrastructure is so nascent, it takes quite a lot of time to build a product. Over time the speed to bring a product to market will go down, and these two things will be quite relevant even at the seed stage in crypto. For now, they’re mostly relevant for later stage rounds or on new protocols that are gaining traction, but the market is ignoring them. A straightforward, easy to use product that people love is king, and driving users to that product and getting traction is even better. Remember that while ideas are a dime a dozen, execution is $20 a share!
Once you’ve bought assets, the next step is to constantly reevaluate whether you should be buying new assets, selling existing ones, or buying more of existing ones. We just went over buying new ones, but how about the other two? Buying more is straightforward if the asset is cheap compared to underlying fundamentals (i.e., a yield), or it has achieved some milestones, and the market has just not reacted at all. I think those are the best times to buy more. Most crypto assets don’t have yields yet, so you’re mostly looking at the second category when determining to add to a position: if your thesis hasn’t changed, the fundamentals are intact, and the price is down, that’s a good time to buy.
When it comes to selling existing assets, you mostly want to sell when you either think it’s maximized its value and no longer in the growth stage, or, when something has changed and you no longer fundamentally believe in that asset. But the most crucial part of this evaluation is continuing to update your thesis as things change. If an entrepreneur creates some new thing that drastically changes the market; or the market ends up telling you you’re wrong: you need to update your viewpoints. I plan to post updates with redlined differences to this over time as well.
Some people ask whether they should invest in tokens or equity. I think you should buy both. You are buying at different stages and different liquidity profiles, but the underlying assets in which you invest all support the same handful of things. Some projects are already liquid and publicly traded. Some are brand-new and are doing ICOs, and some are just regular companies with equity structures. Of course, you evaluate them a bit differently too, as explained above. A traditional company is very different from an open source project. But I believe that you can make money from both in this ecosystem.
Right now, pricing of these assets is effectively a beauty contest based primarily on branding. But predicting the whims of the crowd is notoriously difficult. Consequently, it makes more sense to buy things with strong fundamentals such that, as the scalability and on-ramp barriers are lifted, they become so good that the market can no longer ignore them.
And if you want to benefit from this financial system disruption, I think the best thing to do is to buy projects that will benefit most from those two barriers being lifted. It means having a longer time horizon (think on the scale of three years), and it means keeping your finger off the trigger, as these things take time to play out. As long as blockchains only execute ten transactions per second and on-ramp costs range from 2% to 4%, there is no reason to worry that the projects in which you are invested today are not building a massive user base.
Your project could be vulnerable to short-term whims of the market. But only because, right now, the market is a beauty contest that is pricing based off brand as opposed to utility. As an informed and disciplined investor, you must ride this period out.
Conversely, it would be a warning sign if a smart contract platform executes 10,000 transactions per second with dApps on it and 50 basis points of on-ramping into crypto, and your positions still have no users. That’s when you should be worried.
Now, during the trough of disillusionment, is the time to be invested if you believe the technology will scale. The killer apps from the decentralized/parallel financial system use cases are already live. They work, they’re just slow and expensive. They just need to scale and have lower on-ramp costs. When technologies are range bound and widely viewed as slow and expensive, and the “It will never get fast or cheap” mentalities are pervasive, is usually the best time to invest.
I think to make money in this market you have to be contrarian and right about which projects and companies to invest in. It’s easy to just buy bitcoin and hope that digital gold will be the end-all, be-all. But I think we’re standing on the precipice of something much, much bigger than that: the early beginnings of a revolution of the entire financial system.