Fat Protocols and Value Capture Over Time (Part 2 of 2): Stack Abstraction

Part one of this post delved into how the shared data layer isn’t as open as described by Monegro in ‘Fat Protocol.’ In this part — part two — I’ll explore how, over time, protocol layer abstraction will transfer value from it to the application layer.

To understand how this will happen, we must first understand that Ethereum and other emerging protocols are nothing but technology platforms. They’re just abstractions that help developers utilize the language that they sit on top of. For these platforms to be successful, we need developers that know how to build things on both the platform and the underlying programming language. In short, for Ethereum to be successful, we’re going to need developers to adopt it and built on top of it.

The adoption of tech platforms is something we’ve seen countless times. We’ve seen it with everything from iOS and Android to Twilio and AWS. And every time, the common ingredient for success is developers. Here’s what Steve Ballmer has to say about this.

That said, developers don’t just appear out of the blue. They appear because the platform made a concerted effort to nurture the developer community. This is what led to adoption and real usage.

I used to be a Javascript developer and only recently have I started questioning why Javascript became the language of choice for web development. Looking at Javascript’s origin during the ‘dot com’ days and comparing it to where we are now helped me understand how the ecosystem around blockchain might evolve.

Evolution of a Programming Language

Javascript succeeded because it was light, easy to use, and integrated within Netscape (which, at the time, was the most popular web browser). This made it really easy for consumers to access web sites and developers to reach consumers. As more and more of these web apps got built, tools/libraries got more and more sophisticated. This attracted startups to build even more web apps and hire even more web developers. It became a virtuous cycle of adoption, a result of which was additional abstractions on top of Javascript.

As this virtuous cycle kept evolving, developers released open source libraries like jQuery, Mootools, etc., which abstracted a lot of manual functionality on top of Javascript and made it a lot simpler and easy to use.

By 2007, jQuery adoption exploded and many developers started to build jQuery plugins. These jQuery plugins are like “ready-made features” that developers can simply integrate instead of having to build a feature from scratch. Today, there are Javascript plugins for almost anything you can think of (calendars, email forms, sliders, etc.).

If we look at the web development ecosystem today, it is highly abstracted. Consumers don’t build directly with programming languages. They build with abstracted platforms. WordPress is a great example of this. WordPress powers more than 30% of all websites because it’s abstracted away the complexity of having to build and host a website. There’s even further abstraction on top of WordPress through all the themes and plugins that are readily available in the WordPress ecosystem.

Amazon’s Chief Evangelist, Jeff Barr, describes this abstraction on top of abstraction as the creation of a “platform for platforms”. In Barr’s post, he notes

“Amazon Web Services (AWS) is not only a rich platform to build solutions but also a platform for building specialized platforms. Customers can choose to either use the AWS cloud directly or take advantage of these value-added platforms” (Barr 2009).

Heroku and Engine Yard are two such examples of ‘value-added platforms’ that have abstracted away complexity, in their case they’ve made it super easy for developers to manage Ruby on Rails deployments on AWS.

This pattern of how a growing ecosystem expands through abstraction has been shown time and time again. It’s been shown that, as an ecosystem evolves, there will be further abstractions that allow for the facilitation of certain functionalities of those that came before it.

Evolution of Blockchain Protocols

This same pattern will emerge for Blockchain protocols — there will be abstractions up the stack that will facilitate the development of the underlying blockchain for certain verticals or niches. This is already starting to happen with 0x, Augur, etc. 0x is the ‘Ethereum for DEX’s’ and Augur is the ‘Ethereum for prediction markets.’ Now, if someone wants to build a decentralized exchange, he or she can use 0x instead of building one from scratch.

As these abstractions get more and more sophisticated, protocols will become thin as apps get fatter. This evolution will look something like what’s shown below.

Some of these abstractions may even abstract away so much complexity (think “Wordpress for Ethereum”), that users will flock to the abstraction instead of having to deal with the complexity of the base layer protocol. WordPress is a lot easier to use than learning web development, so people will obviously use WordPress. As blockchain protocols get more and more abstracted, protocols will start to lean out over time while the dApps will have the opportunity to capture more value.

In addition to this vertical abstraction, there’ll be horizontal abstraction. This will come in the form of interoperability. Interoperable blockchains — like Polka Dot and Cosmos — will make cross-chain transactions — transactions between two different blockchains from different protocols — possible. Imagine not being constrained to just one blockchain protocol. This would be a game changer. Interoperable blockchains are a game changer because they can essentially commoditize base layer protocols.

Just as we don’t care about Facebook or any other app’s backend, dApp users won’t care what protocol their favorite app is built on. Facebook users will continue to use Facebook regardless of whether it uses PHP or Ruby on Rails. Consumers only care about a seamless user experience. This might mean the dApp with the best user experience and lowest transaction fees (or even free transactions) will win the hearts of users.


A lot of investors believe in the fat protocol narrative. However, it’s unfair to compare the end of a sophisticated Web 2.0 to the beginning of a nascent Web 3.0. The blockchain ecosystem will evolve through both vertical and horizontal abstraction, ultimately making it a lot easier to develop and use.

We are early enough in the blockchain era that the infrastructure around protocols still needs to be developed. That said, we shouldn’t be ruling out dApps — there will be huge opportunities for them to create and capture value in a more mature version of Web 3.0.

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. This document is not an offer, nor the solicitation of an offer, to buy or sell any of the assets mentioned herein. All opinions in this post are my own and do not represent, in any manner, the views of Decipher Capital Partners or affiliated companies.

Please follow and like us:

Fat Protocols and Value Capture Over Time (Part 1 of 2)

If you’ve been involved with blockchain, then you’re probably familiar with the Fat Protocol thesis in which Joel Monegro postulates about value capture in the blockchain era, Web 3.0. He notes that, in Web 2.0 (the social internet era), value accrued to the ‘application layer’ (i.e. in apps like Facebook, Google, Amazon, etc.). Meanwhile, the ‘protocol layer’ — HTTP, FTP, SMTP, etc. — captured little to no value.