Why DApps matter — an attempt to draw parallels
Developer-centric ecosystems
Most tech driven and developer centric ecosystems develop and grow in a similar pattern and within a comparable framework.
First there is the infrastructure and its early believers who start building key pillars and building blocks of that very infrastructure. Once the infrastructure is mature enough to turn into platforms, these platforms attract developer talent. In every developer centric ecosystem this is an important turning point — developers then start to build products, products attract users, users generate usage and (ideally) revenue streams, which can be re-invested into products and so on and so on.
In my previous company apprupt — a mobile advertising platform, which started with a focus on app developers in the early days of the ecosystem in 2009/2010 shortly after the app stores launched — we had been in the heart of such an ecosystem for multiple years.
The mobile ecosystem developed from something that was largely driven by scrappy WAP based browsing experience on palm handhelds into an ecosystem formed by more sophisticated and powerful mobile devices (first and foremost the iPhone), a certain density of mobile data plans, mobile software development kits (SDKs) and its respective app stores forming the building blocks which laid the foundation for what would become a huge wave of developer driven app innovation as we all know.
While I am well aware that in today’s decentralized ecosystem there are obviously fundamental technological (and ideological) differences to the early days of mobile, I will try to make a case why I believe that we will see a similar pattern in how innovation and economic value will work its way up across the ecosystem’s technology stack from the base infrastructure / layer 1 protocol into the app layer where most of it is going to be captured in the long term.
Fat Protocols and thin Applications?
In 2016 Joel Monegro published the infamous fat protocol thesis. He stated that the market cap of the underlying protocol always grows faster than the combined value of the applications built on top, saying that success of the application drives further speculation at the protocol layer. Over the last 20+ years, web 1.0 and 2.0 Internet protocols have provided massive value, while it was the application layer on top of that which captured most of the value — GAFA’s strong footprint is probably the most obvious evidence today.
The decentralized web ecosystem appeared to have turned this pattern upside down with most of its value being captured in base / layer 1 protocols (like Ethereum).
While I clearly shared this view until recently, looking at the DApp developer community across all major platforms today, a lot of the conversations and observations I have had over the past 6 months brought back memories of the early days of the mobile app ecosystem and the time when we started apprupt.
I would not necessarily say that the fat protocol thesis turned out to be fully incorrect in retrospect, but at the very least that we should rather try to take a more differentiated view on where to draw the line between what we define as being protocol and what we define as being application.
In an abstract perspective a protocol is a set of rules, patterns and standards that specify communication and behavior between two or more participants of a network. As Jake Brukham points out, in a technology stack this means that every layer of functionality is eventually a protocol to the layer above and an application to the layer below. Using Augur as an example, it would therefore be a protocol for the stack above it and an application of the stack below it, e.g. the Ethereum blockchain.
Since every transaction in the Augur application is a transaction on Ethereum, Augur projects its utilization onto Ethereum as the underlying protocol through transaction and network fees. Any additional value of Augur is captured within REP as a reflection of future discounted cash flows of the application’s trading platform.
Hence, if one intends to capture the value of Augur he or she should buy and hold REP while the value of Ethereum as the underlying protocol would be captured by ETH as the native token, which in turn is a reflection of the protocol’s future discounted cash flows, the gas payments.
Managing Gas
This differentiated view becomes even clearer when we look at applications that unlike Augur don’t come with a proprietary application protocol or token but are rather built natively on top of Ethereum, utilizing the platform in a very pure and plain fashion.
There is a growing number of these kind of DApps — for now these are mainly games and casino applications. In a very simple shape and form, these games are not more than a smart contract with a scrappy design living on the blockchain and accepting Ether for you to start interacting and playing.
With these applications the end consumer is exposed in relatively high proximity to the base protocol itself while almost directly interacting with it — management of gas and transaction fees will be a key element in the customer experience, more so avoiding over- and more importantly underpaying gas.
Developers will most likely find themselves in a position where they will end up managing gas (having it managed or staking “it”) for end users who interact with their products to minimize user exposure to the concept of gas in order to enhance costumer experience, in particular taking away the risk of underpaying gas and not having transactions go through, which is an element of that concept that can be quite confusing if not frustrating for the (average) end consumer.
To developers (and their respective users likewise) managing gas will only make (economic) sense, if the actual gas price will be not more than a fraction of the transactional value, giving them the opportunity to generate decent profits out of utilizing the platform and launching products on top of it — otherwise no one will use DApps, let alone bother to build them.
Such a differentiated view on the unit economics of an application’s transaction cost against its transaction value should also apply within a more holistic perspective on the overall economics of the ecosystem. If the transactional value of one individual application will necessarily have to surpass the transaction cost owed to the underlying platform for all of this to make economic sense and to be able to grow and prosper, then the total aggregated value of all transactions should also surpass the respective total amount of transactional costs for all applications in the ecosystem.
When you consider this, it seems even more obvious that a large proportion of long term economic value of this very ecosystem will be captured on the application layer — either attached to a proprietary protocol token or as an aggregation of cash flow and profits sitting within DApp developers’ wallets. And that is exactly what can be witnessed with some of these early scrappy DApps — take Etherroll for instance, one of the early and more “frequented” Ethereum based games sitting on a current balance of 5,300+ ETH, which is a lot for a rather poorly designed game with an average of < 50 DAU and most likely in violation of gambling regulation.
Fork it till you make it — the commoditization of base protocols
In the early days of apprupt we would provide early app developers with a proprietary advertising SDK that would allow us — once integrated into the app — to aggregate all ad placements, serve ads to an app’s user base, optimize ad delivery and increase advertising yield for the developer. As a venture backed startup it seemed unthinkable not to develop a technology platform ourselves and we would pride ourselves in front of the developer community on being able to provide them with a proprietary element of ad infrastructure.
While an ad-serving platform is not anywhere near to being comparable to a blockchain protocol, I still believe that there is a parallel dynamic in all of this when looking at developer sentiment.
Ad-serving systems as an underlying processing layer for digital ads within a developer’s app turned out to be commoditized once the ecosystem matured and the app developer community grew. There was no emotional advantage one platform had over the other and also those developers who we had approached early in their process of launching their very first app turned out not to grant us any infinite first mover advantage.
There was a certain lock-in you had once integrated with a developer’s apps, but in the end all that mattered to them was price (in terms of generated ad revenue), performance and stability. Once there was another vendor that would be able to generate more ad revenue with equal performance and stability, developers would kick you out and switch with no signs of remorse what so ever.
At the end of the day, from my observation similarly all that matters to DApp developers will be price, security and scalability — equally secure and scalable platforms will compete over price and we can probably even expect developers to build platform-agnostic DApps sometime in the future, which will drive pressure on transaction costs even further.
The possibility and ease of forking as well as the potential interoperability and interchangeability between protocols and chains will presumably increase commoditization even further and more competition amongst layer 1 protocols will only drive costs further down. All of this will lead to commoditization of the base protocol layer as a plain processing layer -on a much bigger scale but in a similar way than the ad serving system as the processing layer for an app’s advertising space.
While forks in general create more innovation and open competition in a decentralized ecosystem, this also means that individual protocols might target more niche and vertical use cases in the future and by doing so will individually capture even less value by being a processing layer that facilitates only a very specific type of transaction.
At the end of the day all layer 1 protocols will compete over and operate under the ultimate (ideological) tradeoff between scalability and security. Some DApp developers will sacrifice scalability over security and others will favor scalability over security, but most will find themselves somewhere in between depending on their individual use case and market requirements to implement their products. A developer building a decentralized dice game has probably other requirements than someone building a decentralized marketplace to trade securities and might not need a platform that is built to survive a nuclear war with no government able to take down the system.
Forking a protocol bears certain risks and increases fragmentation but might also develop into a standard procedure to cater specific use cases with rather niche requirements towards handling that very tradeoff if and when individual opportunities in those niche markets become big enough.
On the other side this will probably only lead to even less value being captured per individual protocol shifting value away from (niche) protocol processing layer(s) onto the application layer, which is where we will see a high concentration of developer driven innovation over the coming years — with the same economic implication for the ratio of transaction cost against transactional value on a “DApp per DApp” basis as well as aggregated for the whole ecosystem across all layers in its stack.
