Hungry Protocols vs Fat or Thin Protocols
The canonical writing about which layer captures the value -- the protocols vs the applications -- made the distinction between "thin" and "fat" protocols.[1]
"Thin" protocols like http and smtp didn't capture much of the value; instead, the applications built on top became financial successes (cash cows or rent extractors, depending on your point of view).
Web3 "Fat" protocols would do the reverse: these blockchains with a speculative token incentive would capture the value with growth driven by the applications.
The core dynamic could be summarized here:
the market cap of the protocol always grows faster than the combined value of the applications built on top, since the success of the application layer drives further speculation at the protocol layer. And again, increasing value at the protocol layer attracts and incentivises competition at the application layer. [2]
I want to double-click into this assumption, because I think without proper incentives and value distribution, the "fat protocols" will either starve or end up being a winner take all.
My counter-point is that protocols should focus on being "hungry" -- and the key to becoming an apex predator is less Hobbesian and more Tocqueville.
But first, let's ground this in an quote attributed (but unverified) to Bill Gates:
"A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it. Then it's a platform."
Before I get into the role of platforms and protocols, first, what is the playing field?
What is the game being played?
What is the Game?
A blockchain's immutability and permissionlessness enable it to act as a trust-minimized referee; especially with Turing-completeness and smart contracts, the referee in the game coordinates (play by the rules) and penalizes (slashing or something else).
What makes the game the game, though?
It's the underlying incentives, and there are a few parties at play in most games.
The actual players are incentivized to score points; the teams coordinating their players want to win games.
The owners of teams wants fans, which translates into revenue deals (tickets, concessions, brand deals, broadcast rights).
And franchises want to maximize engagement across all teams and compete on share of wallet and share of eyeballs against any other form of competition or spend. The NFL, for example, prefers more people watched their games than to play video games or go to the mall, for example.
In other words, different players have clear objective functions for what "winning" looks like, for what "keeping score" means to them.
However, most protocols focus on the defensive posture -- how do they maintain trustlessness and decentralization in an adversarial environment.
Is this necessary?
The Bitcoin protocol, especially for the game its playing, needed to solve for adversarial "Byzantine general" problems. As order of operations, it was a must: without sufficient security, there was no use-case.
But the trade-offs between security and growth/usage is a real tension, one felt through the IT industry's evolution.
The trade-offs depend upon the application use cases.
For example, HTTP didn't really need TLS to enable secure HTTPS for a long while when the information shared was academic journals, emo diaries, and cat pics.
However, one value was exchanged -- credit cards, passwords -- security was the blocker; when the protocol could be trusted, the e-commerce use case was unlocked.
The game, however, is not about being the best referee.
It's about creating a playfield for the different type of players to win.
Yes, the referees are important: they make sure there's some order, one of those being that players truly play basketball instead of baseball; but once order is understood, it's about building franchises, teams, individual players, and fans.
What is a Hungry Protocol?
A hungry protocol has an overall goal: be used by as many applications as possible.
Even though the web2 protocols had no economic incentive, and that were put together initially by academics and researchers, an underlying, likely unspoken, goal was growth by maximizing its core utility.
The early protocols made their utility function very clear in their naming (which is an interesting take on where things are now, which is more about branding than utility):
- SMTP (simple mail transfer)
- FTP (file transfer)
- IP (internet)
- HTTP (hyper text transfer)
The comparison of Bitcoin to SMTP illustrates what makes a good protocol.
Bitcoin is like SMTP in that it can be the bridge between different financial applications. A Venmo user could send money (in fiat, even) to a Square Cash user if these applications adopted the Bitcoin protocol in the background like AOL and Compuserve adopted SMTP in the early 90s. And just like with SMTP, Bitcoin will enable a lot of innovation by making it easier to create new kinds of global financial applications. [3]
In the case of SMTP, it was widely used, and many profitable businesses were built on it and benefitted from the open and permissionless specifications of the protocol.
Bitcoin illustrates one way in which the token could be a means of capturing an otherwise open source specification that gains in popularity.
The original creator of the protocol will make money to the extent that it is adopted and to the degree they have retained some of the tokens (so they can sell them at a higher price later on). [4]
While there are some nuances to the degree the protocol can make money based on the adoption and use of the tokens, a topic I'll explore another time, the important concept is what about the protocol enables mass adoption?
Protocols should be hungry for value creation, and going back to the Bill Gates quote, implicitly assuming accumulation of the value, more so than the applications, is not the right framing.
Protocols Need Platform Economics
The diagram below is imperfect, but as a first pass I can break down some concepts of how I think protocols both capture and unlock value that I see often missing in conversations:
What is different from the standard graphs of value capture between "thin" vs "fat" protocols?
The first is that this should change over some dimension, and for simplicity I selected the number of useful applications -- applications that leverage the protocol to deliver utility to some market or segment of the market.
In the beginning, and especially for the first product, the value should accrue to the application; this is why often the protocol developer is scratching their own itch to use the protocol.
Sometimes, these protocols take open concepts and build products on the design.
For example, Twitter essentially is a protocol for micro blogging communication; but it is enshrined in a product. When that protocol was opened via an API, it created platform risk for all the businesses that began to thrive on top of it and were later rugged.
But the initial stage is a proven model: the first application needs to capture more of the value (back to the Bill Gates quote).
In fact, I struggled with this first illustration because, potentially, a successful protocol, as a platform, always captures less total value than all the applications combined, and should look more like this:
In this scenario, the protocol asymptotically approaches the total value of applications, but always has "headroom" to create more value across all the application than itself captures; however, in doing so, it benefits from the overall growth of application-led utility.
In this construct, the early applications have comparatively more value capture than the applications; but over time, the platform's value, itself, comes from delivering high utility to the applications.
I am leaning towards a world where the underlying protocol, if it can achieve real platform effects, over time captures more value than the applications built on top if there is some game theoretic network effect....like Bitcoin.
Games Protocols Play
Bitcoin had no pre-mine, which most VC's do not like because they can't front run the rest of the market.
So by "protocol" we don't have a treasury, founders or VC investors who hold to capture the value in the case of Bitcoin. A close proxy though could be Satoshi's own wallet, and that wallet grows in value as the value of the token goes up.
Bitcoin is a bit of an anomaly; because the token, itself, is truly the product; the "applications" built on top, like Bitcoin exchanges, are more like UI wrappers to the core application, which is the Bitcoin itself.
So the analogy is less than perfect in that regard.
But it is an easier to understand dynamic for how the Bitcoin protocol will exceed any application because of the game theory enabled by the token price.
Sovereign nations, at some tipping point, will be competing against each other to hold Bitcoin.
If a sovereign nation blinks too late, it will come in only at the higher price than that paid by those who waded into the water sooner. When applied to a treasury or strategic reserve, this price action has implication on currency trading pairs and on actual international trade.
This dynamic of the protocol itself creating game-theory incentives captures the higher value because it imputes future value; in a similar vein to how the stock price of a company should capture not the current earnings but the forward-looking earnings. Those companies that have a great story, positioning in the market, growth trajectory compete against other companies for higher PE ratios (which in turn allow them to get greater share of market-weighted passive vehicles), a protocol which imputes through data or memes (or likely a combination of both) such future value captures much higher value than that captured by the applications themselves.
This means that for a protocol to be a true apex predator, truly hungry, it must be focused on enabling value for the builders. But it can't make it purely zero sum; it needs to enable value through the shared state.
For example, SMTP creates value for the Gmails, Proton Mails, and Hey's of the world: these applications build businesses because of the interoperability of email between email applications. SMTP can't sudden "rug" these applications the way Twitter rugs developers.
However, Gmail coming in first doesn't benefit game theoretically over the others due to the protocol. It can by competing out of the protocol, and it did so brilliantly by changing the economics of the email business from paid to free. By acting as its own aggregator on top of a free protocol, it captured value through advertising.
HTTP unleashed even bigger applications which captured the value outside of the protocol -- the entire ad business is based on people being able to read and write over HTTP at zero cost for distribution. This ended up being the perfect set up for advertising to capture out-of-protocol value.
Both HTTP and SMTP were, in the end, hungry protocols despite capturing none of the value: they enabled massive businesses to be built.
The nature of the businesses, however, depends very much on the underlying utility.
These early protocols were very specific in its utility.
The difference, however, in the size of businesses around FTP vs HTTPS, has much more to do with the products and their utility to the end-user.
In the End, it's About End Users
FTP enabled large file transfers, and for a while, was a common way to download music, games, large text files.
HTTPS enabled e-commerce.
In the race between FTP and HTTPS, the latter created more value because the application space for e-commerce was enormous in utility to the end-users -- buyers and sellers.
Hungry protocols, therefore, become apex predators when they are sufficiently focused on delivering value to the end-users, gaining pre-eminence over any other alternative.
Bitcoin's Turing-incompleteness is a feature, not a bug.
Its design mimics many of the attributes a strong store of value needs, including portability, scarcity, finality, and divisibility; these properties contribute to PMF for the utility for end-users -- a way to own a bearer asset that resists counter-party debasement.
Are general-purpose compute ledgers, like blockchains, sufficiently desired to launch killer apps for end-users?