Data Flight: Why ‘Fat Protocols’ Doesn’t Make Sense
Part I | Value Capture in Web 3.0
Argument in Brief | TL;DR
Understanding value creation and capture is vital to investors. ‘Fat Protocols’ best represents the consensus view on this. I disagree — this three-part series outlines why. Part I is published here. Parts II and III are forthcoming.
Part I | Data Flight: Why ‘Fat Protocols’ Doesn’t Make Sense
‘Fat Protocols’ assumes that data is generated by applications but stored by protocols (in a shared data layer), allowing the latter to capture value. This isn’t what actually happens. App data the same thing as shared data. Shared data is a small subset of app data. This is because, as app data makes its way down to the protocol layer, some of it flees to where it’s better suited. There are three types of data flight: flight to exclusivity, flight to efficacy, and flight to economy. Taken together, they diminish the value captured by protocols and give apps the opportunity to build defensible businesses.
Forthcoming: Part II | Web 2.0 vs 3.0: Why It’s a Poor Comparison
Forthcoming: Part III | Centralization & the Spotted Egg: How Value Capture Should Be Understood
Argument in Full | Value Capture in Web 3.0
Why this is important.
Understanding value creation and capture is a crucial, yet complex component of understanding any industry. This is especially true when investing. I’ve been thinking a lot about this as it relates to Web 3.0, or the blockchain ecosystem. Of everything out there, Joel Monegro’s USV blog post, ‘Fat Protocols,’ is one of the most popular views on the topic, making it the closest representation of consensus. I disagree with this view and have a different take on how value will get created and captured in the space. This three-part series walks you through my thoughts.
What consensus thinks.
Though most of you are already familiar, here’s a quick primer for those who aren’t.‘s asserts that, in Web 3.0, protocols — not applications — will capture the most value. Monegro’s ‘Fat Protocols’ asserts that blockchain applications, since they use a common protocol and thus share a common data layer, can be easily substituted for one another. As such, Web 3.0 applications¹ — unlike Web 2.0 applications — will have no proprietary data, preventing them from capturing much of the value they help create. As a result, value — since it chases data — will accrue primarily at the protocol layer, making protocols ‘fat’ and applications² ‘thin.’
Why this doesn’t make sense: data flight.
The reason this seemingly sound logic isn’t so sound is that it assumes apps share a common data layer. This isn’t quite true. Let’s look at how data moves through the blockchain ecosystem to better understand why.
Data enters at the application layer, where its generated by users. Users don’t care about protocols — they care about getting their needs met. So when an application meets their needs, they use it, whereby generating data within the app. Since these apps are ‘powered’ by protocols, people think that all of the data they generate is pushed down to and stored in a shared data layer. They think that app data equals shared data. This is illustrated in Figure 1a.
The problem is that what people think happens isn’t actually what happens. All the data generated by applications — app data — doesn’t actually make it down to the shared data layer. On its way down, some of it ‘flees,’ as shown in Figure 1b. I call this data flight.
There are three types of data flight.
- Flight to Exclusivity: Some data is incredibly valuable to the application and its ability to be useful to its users. Users’ preferences, for instance, are a type of data that would be advantageous to keep proprietary. Preference data isn’t something you need to use a protocol, so it doesn’t need to be stored in a shared data layer. But, it is something you need if you’re trying to build a defensible business with competitive advantage. Flight-to-exclusivity happens when this type of data is siphoned off and stored outside the blockchain ecosystem where is can be kept exclusive to the app.
- Flight to Efficacy: Some data is completely useless when stored on a blockchain. Since blockchains are unstructured databases, storing data that needs to be searchable and organized on a shared data layer wouldn’t make any sense. It’d be ineffective. Flight-to-efficacy happens when data that’s useless on a blockchain is stored in structured databases, etc. so it can be more useful.
- Flight to Economy: Storing data on blockchains is expensive. While it’s technically possible to store non-text files on blockchains, it’s prohibitively expensive. (My cofounder, Jonhnson Nakano, writes about how storing an average, 75kb email would cost $75 here.) Flight-to-economy occurs when data that’s uneconomical to store on a blockchain is stored using cheaper options like AWS.
These three different types of data flight have one very important ramification: the data that ends up in the protocol layer is a fraction of the data generated at the application layer. This is illustrated in Figure 1c.
This means that the value captured by the protocol layer will be substantively less than what’s suggested by ‘Fat Protocols.’ On the flip side, the value potentially captured by the application layer is substantively more.
Footnotes
¹Web 3.0, blockchain applications are sometimes referred to as dApps, or decentralized applications, in order to differentiate them from Web 2.0 applications (Facebook, Uber, Google, Airbnb, etc.). Web 3.0 apps are different than the Web 2.0 apps we’re more familiar with in that they run on a P2P-esque network of computers (making them decentralized), rather than a single computer (making them centralized). They often — but not always — are open-source and make use of cryptographic tokens generated by a cryptographic algorithm.
²I do NOT call Web 3.0, blockchain applications ‘dApps’ as I find the term to be poorly defined and confusing. Web 3.0 applications have varying degrees of centralization — some are completely open-source and depend heavily on underlying protocols, while others are closed ecosystems and use blockchain protocols selectively. I think this variation is important, but more on that later.
Disclaimer. This post is intended for informational purposes only. The views expressed in this post are not, and should not be construed as, investment advice or recommendations. All opinions in this post are my own and do not represent, in any manner, the views of Decipher Capital Partners or affiliated companies.
