The Web3 Stack, 2019 Edition
Disclosure: Multicoin has established, maintains and enforces written policies and procedures reasonably designed to identify and effectively manage conflicts of interest related to its investment activities. Multicoin Capital abides by a “No Trade Policy” for the assets listed in this report for 72 hours (“No Trade Period”) following its public release. No officer, director or employee shall purchase or sell any of the aforementioned assets during the No Trade Period. At the time of publication of this report, Multicoin Capital is long Kadena, Near, Solana, Dfinity, Keep, dfuse, The Graph, Livepeer, Arweave, and Coda.
A year ago, I illustrated the Web3 stack as I understood it at the time.
I have learned more, and the ecosystem has evolved since then, so I decided to update the Web3 stack.
Whereas the 2018 Edition was just a flat visualization of a single instance of the Web3 stack, the 2019 Edition aims to show the Web3 stack as a set of interoperable networks. In order to do this, I organized the 2019 Edition into 4 images (plus a bonus), starting from a narrow view, and zooming out from there. You can download all 5 images in English, Chinese, and Korean.
The images are large, and can be difficult to be read on the Multicoin website or in your email inbox. While they are included below, you may need to download them and open them in a dedicated image viewer to understand them. The images are labeled v2.1, v2.2, v2.3, v2.4, and v2.1bonus for referenceability.
The remainder of this post will be organized as follows: I’ll present some observations and commentary on themes that are observable across the ecosystem. Then I’ll explain how these observations are reflected in our portfolio construction. And I’ll conclude by summarizing each of the 4+1 images.
Observation #1: Heterogeneity, Fragmentation, and Uncertainty
The most salient difference between the 2018 Edition and 2019 Edition is that the 2018 Edition didn’t do a good job of showcasing the heterogeneity of the Web3 stack. When I published the 2018 Edition in July 2018, there weren’t any smart contract chains running other than Ethereum. Today there are ecosystems growing around Ethereum, EOS, Tezos, and Cosmos, and there are smaller communities forming around soon-to-launch chains like Kadena, Polkadot, Near, Solana, Dfinity, Tari, and Coda. It’s clear that the Web3 ecosystem is becoming much more heterogeneous, as I wrote about earlier this year in The Unbundling of Ethereum.
A year ago, developers didn’t have to think about which chain to build on because there was only one option. Today, the sheer number of options is creating a lot of complexity, both for teams who’ve built protocols and services on an existing chain and for new teams entering crypto. Let’s consider one example of each:
Aragon is one of the earlier protocols built on Ethereum. A few weeks ago, the Aragon team announced that they’re going to expand the reach of their protocol by building on the Cosmos SDK, while continuing to support the Aragon protocol on Ethereum. They cited high and variable fees as their primary motivations for switching (I noted that fees would be one of the primary drivers forcing teams away from Ethereum in The Unbundling of Ethereum).
Looking across the Web3 ecosystem, I see the rate of fragmentation accelerating. Although most developers consider Ethereum before any other chains, many teams have requirements that Ethereum cannot support. This is creating lots of opportunities for the protocol developers of other chains, and the challenger chains are moving as quickly as they can to take to support application developers.
This fragmentation is being exacerbated by the uncertainty around both Eth 1.0 and 2.0. For example, the Ethereum core developers recently delayed (indefinitely?) state rent on the 1.0 chain. While this is good for existing contracts, it’s arguably bad for the Ethereum ecosystem in the long run because it leaves even more questions unanswered for a longer period of time. Meanwhile, it’s clear that the Eth 2.0 spec is still far from being finalized; the shard count for Eth 2.0 was recently reduced from 1,024 to 64.
Developers don’t want to continually worry about the underlying protocol introducing breaking changes.
There will be a real opportunity for the first chain that can offer all of the following:
- High throughput, low latency, low fees, sufficient consensus-layer decentralization, and clear scaling solution
- A robust execution environment and dev tooling
- Minimal application/shard/layer 2 complexity
- Strong assurances about backwards compatibility and ongoing future stability
Developers don’t want to continually worry about the underlying protocol introducing breaking changes. They want a reliable foundation on top of which they can build.
Observation #2: The Rise Of Middleware
In the 2018 Edition, I highlighted the middleware stack on the right side of the stack. In the 2019 Edition, I segmented the middleware between on-chain protocols and off-chain services.
Over the last year, there’s been an explosion in middleware, most notably in the form of Open Finance (aka DeFi) in the Ethereum ecosystem. While there are some questions about value capture for some types of Open Finance protocols like Set, others like Compound and Maker have clear value capture mechanisms.
To the best of my knowledge, none of the on-chain middleware protocols have yet been ported over to other chains. However, some off-chain services are porting across chains. Loom is running across Ethereum, EOS, and Tron, and even allows users to transport DAI across all three chains. With the uncertainty around Eth 2.0, the rise of the Cosmos ecosystem, and the growth of new ecosystems, I expect we’ll see an acceleration in the growth of cross-chain services over the next 12 months. For example, services like Keep’s tBTC are naturally going to be used to port BTC to Ethereum and Binance Chain, among many others.
Some services will be ported as is across chains, and will still offer largely the same functionality. For example, Keep’s tBTC is fundamentally the same service, regardless of which chain tBTC is ported to. Meanwhile, other off-chain services like dFuse and The Graph become better as they support more chains. As these services add support for use-case specific chains like Arweave (pay once and receive permanent file storage built on IPFS) and Handshake (decentralized DNS), these services increasingly act as a single abstraction layer for developers regardless of where the underlying data lives. As such, the proliferation of these kinds of off-chain services will accelerate the rate of development of the entire ecosystem.
The other common theme across off-chain services is that they generally seem to be adopting the work token model. This reflects a consensus view among developers that application-specific payment currencies without velocity sinks will not capture value, and that work tokens provide a quantifiable way to value of an off-chain service.
In addition to bespoke off-chain services, both the Cosmos and Polkadot ecosystems are embracing the work token model. In the Cosmos ecosystem, each Zone is going to be secured using its native staking token, while validators are likely to generate most of their income from transaction fees on more liquid payment tokens such as tBTC and stablecoins. Since most Cosmos Zones won’t have native, liquid payment currencies, It’s expected that each Zone will leverage Cosmos’s Inter Blockchain Communication (IBC) protocol to port tBTC and stablecoins to each zone for use in payments and smart contracts. Moreover, ATOMs, the native token of the Cosmos Hub, is a work token that will generate fees from passing messages between many Zones. Polkadot’s DOTs are analogous to ATOMs: they perform the same function - passing messages between Parachains - in exchange for fees.
Lastly, to be clear, I believe that middleware protocols and services can capture value in a separate and modular way from layer 1 smart contract platforms. Because the value of middleware protocols can be valued using traditional discounted cash flow (DCF) models, middleware protocols and services should be able to capture value regardless of which underlying chain wins. However, most general purpose Layer 1’s are ultimately competing to be non-sovereign money, and value capture at Layer 1 will be independent of value capture for middleware layers.
Web3 Stack 2019 Edition: Single Chain, Flat Visualization
This first image is an updated version of the Web3 stack I illustrated last year:
The most important changes are:
Categorizing on-chain protocols and off-chain services. The eventual vision is that all of the mechanical infrastructure enabling Web3 is abstracted such that developers can focus their efforts on higher level problems. As such, an increasing percentage of apps are building on top of other protocols on a single chain, leveraging the modularity of on-chain smart contracts. This is clear in Ethereum’s open finance ecosystem. Modularity and composability are the defining characteristics of Open Finance. Most of the on-chain protocols shown in this diagram are Open Finance related.
The Web3 stack runs across many different physical computers organized into separate logical networks. The 2018 Edition showed the whole stack as if it ran on a single piece of hardware. The 2019 Edition breaks out where each layer of the stack runs using the segmentation on the left. This makes it much easier to follow and see where different physical machines are interacting with one another.
I removed a number of the optional components from the core stack—side chains, Interledger Protocol (ILP), and state channels—and listed them as optional components on the right instead. This makes the image as a whole easier to read, and presents a more consistent logical representation of the stacked networks, as I show in the next image in the 2019 Edition.
I also created a version of this illustration with companies building in the Web3 ecosystem.
Web3 Stack 2019 Edition: Single Chain, Layered Visualization
The second image in the 2019 Edition is fundamentally showing the same pieces of the stack as the first. However, whereas the first illustrates the stack flatly, the second shows the stack as networks of physical computers. This visualization makes a few things more clear than the first image: where each sub-stack starts and stops, this one more clearly shows the layering of the sub-stacks across different logical networks, and shows API call flows across networks.
In this image, I showcase three example middleware networks: a query layer network such as The Graph, a side-chain network such as Skale, and a permanent storage network such as Arweave (which can also be used as a data availability layer for any other network). Depending on the specific application, there could be many other middleware networks involved. I highlighted these three because they’re the networks I expect will be the most widely used. This is why we invested in all three.
Some other interesting observations: First, the layers aren’t strictly ordered. For example, the query layer can index data from side chains and storage networks. Second, end-user clients don’t have to rely strictly on middleware networks. They can query data from layer 1 networks directly (although this often results in a poor UX, and as such we expect it to be less common overtime as query layers become more robust and widely adopted). Third, an independent data availability network can act as a data availability layer for a Layer 1 (this is not visualized).
Web3 Stack 2019 Edition: Multi-Chain, Flat Visualization
As I alluded to above, the Web3 ecosystem is becoming more heterogenous rather than homogenous. This is only natural as more Layer 1’s launch. This image attempts to illustrate what the ecosystem may look like as more chains launch and get connected to one another:
While the Cosmos team expects there to be multiple hubs over time, it’s impossible to know which chains will connect with which hubs ahead of time. I included two Cosmos hubs because 1) I couldn’t fit all the non-Polkadot parachains around a single hub 2) the expectation that there will be many hubs. Obviously only one of the hubs can be powered by ATOMs. The second could be Iris, or could be some other hub. Binance Chain (which is built using the Cosmos SDK) itself could even become a hub, especially if Binance DEX develops enough liquidity to act as a trust-minimized price oracle for all other chains.
Given how early the interoperability mechanisms are, this illustration doesn’t tell us much. Rather, it presents a vision for what the future could look like. The vision I’m projecting is rather clean; in reality it’s likely that things will be messier. For example, Binance Chain already facilitates more economic activity than every chain other than Bitcoin and Ethereum. Moreover, BNB has a higher market cap and is far more liquid than ATOMs, meaning that Binance Chain is likely to offer much more consensus safety than an ATOM based chain. And lastly, Binance Chain is primarily a DEX, which can (with enough liquidity) act as a trust-minimized price oracle. With these three structural advantages, it’s possible that the Cosmos SDK becomes the de facto standard in development, and that Binance Chain and BNB accrue all the value.
I also included a single Interledger Protocol (ILP) bridge between Bitcoin and the Ethereum 1.0 (in the bottom right area) to show that not all forms of interoperability need to be in the form of atomic messages passed through hub chains. While ILP can theoretically bridge every chain illustrated, I chose not to illustrate that as it would make the image unreadable.
Web3 Stack 2019 Edition: Multi-Chain, Layered Visualization
The final image is a combination of the previous two images. The purpose of this visualization is to highlight that middleware networks will operate across a few Layer 1s:
For readability purposes, I: 1) dropped ILP 2) didn’t include blue arrows between various end user client and middleware stacks.
The most incredible thing about the Web3 stack is that it’s coming together without any centralized coordination. The development itself is decentralized. There is no master architect. This stands in stark contrast to virtually every other development stack on the planet. There just a handful of people at the Linux Foundation setting the direction of Linux. The same is true at Google with regards to Android, and at Apple regarding iOS, etc. A few senior people at the top of these organizations dictate the overall architecture of these massive ecosystems.
Given the lack of centralized coordination, it’s honestly incredible that any of this works at all. Things are still clunky, sure, but the developer and user experiences are improving rapidly throughout the stack.
Big shifts tend to happen slowly, then all at once. The current development paradigm for the Web3 is likely to follow a similar pattern. It’s hard to forecast when exactly the hockey stick will turn upwards, but at least today the market can see the basic shapes and outlines of all the major pieces, and there’s a general understanding in the developer community of how it will all fit together.