Intro to Blockchain: Breaking Down Decentralized Applications

This post is part of a three part series on blockchain. Part 1 included two posts that walked through the history of both the modern internet and blockchain technology.

Part 2 is focused on how the technology works and will include one post on blockchain protocols (which you can find here), this post on decentralized applications, and a third post on the process of raising capital through initial coin offerings. Part 3 will then highlight a few of the most attractive areas for investment in the space. If you’ve enjoyed these posts and want to see more VC-related content, please follow my publication on twitter! Alright, enough of the overview, let’s dive in.

Decentralized Applications (aka DApps)

In my opinion, decentralized applications are where blockchain technology gets particularly interesting. Why? Because they are the first blockchain products that will be truly consumer facing. As a result, they have the ability to bring blockchain technology to the masses rather than to just the early adopters.

What exactly is a DApp?

At a high level, a DApp is an application that uses a distributed network for its back end functionality (i.e. to store information and process transactions), rather than a traditional server. Before we dig in and explain exactly what that means, let’s walk through a couple of examples so that you can understand the potential use cases and benefits of a decentralized model.

Example 1: Ride Sharing

Consider Uber. As you know, Uber is an application that connects riders with drivers at a relatively low cost. For every transaction that occurs, Uber takes a portion of the payment as compensation for its role in connecting the rider and the driver. This allows it to cover its relatively high fixed costs and hopefully make a profit for its investors. Now, let’s consider a decentralized version of Uber. Let’s call it DUber. To the consumer, DUber looks and feels exactly the same as Uber; however, it is 100% open sourced and powered by a decentralized network. This means there is not a centralized organization that takes a slice of each transaction. Instead, the payment goes directly from rider to driver, with just a very small fee used to process the transaction on the underlying blockchain. That fee is required to compensate the nodes that mine the transaction and is much smaller than the fee that is charged by a centralized company like Uber, which needs to cover its relatively high cost structure.

Example 2: Social Applications

Social applications like Facebook and Instagram provide you with a means of sharing a significant amount of personal information with your friends and family. Unfortunately, your friends and family aren’t the only ones consuming that information. The company that runs the centralized social application is also collecting this personal information and selling it to targeted advertisers for a hefty price (as evidenced by Facebook’s bottom line…). If consumers use a decentralized social application instead, they would have control over the dissemination of their personal information and would be able to decide whether they want to keep that information private or sell it to advertisers.

While these services don’t actually exist yet, they are helpful in illustrating a few of the potential use cases of decentralized applications. As you can see, there are a couple of benefits to using a decentralized approach. First, DApps can reduce inefficiency by eliminating unnecessary third parties that store, mine and/or monetize user data. Second, DApps provide additional security to end users. Instead of requiring users to blindly trust a centralized entity to properly secure their personal information, DApps are built on top of blockchain protocols, which use advanced encryption methods to process transactions and secure data. If you want a more detailed explanation of how these blockchain protocols secure data, please read through my prior post, which you can find here.

What does it take for an application to qualify as a DApp?

According to Siraj Raval, an application must adhere to four criteria to be considered a DApp:

  1. The application must be open sourced, meaning there cannot be a centralized entity that decides the future of the application. Any changes to the application need to be proposed to, and gain consensus from, the user base.
  2. The application must run on an internal currency (like a token or coin). In our DUber example above, the token would be how the rider would pay the driver for the service. These tokens are vital for incentivizing developers to create decentralized applications and encouraging network participation. Developers are incentivized because they can typically retain a significant number of tokens in the ICO process (I’ll provide more detail on this in my next post). Therefore, if the application increases in popularity, the token will increase in value and the developer stands to make a substantial amount of money. This internal currency also encourages network participation because it enables trustless, contractual payments between the provider and recipient of the service.
  3. The application must be powered by a decentralized consensus mechanism. This allows the application to keep track of events / transactions that have occurred and come to agreement on the current state of the world without the use of a third party arbiter. For a gaming app, this might mean that the underlying blockchain could keep an accurate record of each player’s high scores. For DUber, that means that the underlying blockchain could keep track of each user’s rating and payment history.
  4. The application must not have a central point of failure. DApps should be run across a large network of independent nodes so that the network can continue to function if any nodes are removed. Effectively, this means that the application cannot be shut down.

So what qualifies as a DApp under this definition? Technically, base protocols like Bitcoin and Ethereum qualify as they (i) are open source, (ii) use a consensus algorithm, (iii) have an internal currency in the form of a token or coin, and (iv) are fully decentralized with no central point of failure.

However, when most people discuss decentralized applications, they are referring to “Layer 2” applications. Layer 2 applications are applications that are built on top of an existing blockchain network and use that blockchain for back end functions like transaction processing and storage. A real world example of this would be Golem. Golem is attempting to create a DApp that serves as a decentralized supercomputer. The DApp would allow users to tap into the processing power of a global network of computers to render complex images, train artificial intelligence models, or complete other computationally intensive tasks. The decentralized supercomputer would be powered by a network of normal people like you and me that offer the spare processing power of their phones and laptops. The users would pay the service providers for their computing power through Golem’s GNT token. Golem is considered a “Layer 2” application because it is built on top of the Ethereum blockchain and uses the blockchain for task validation and payment processing.

How do these decentralized applications actually work?

Alright, now that we understand the potential use cases of DApps and have defined what elements need to be incorporated to qualify as one, the next question is: how do these things actually work? What does it mean for an application to be built “on top of” a blockchain network? To answer that question, let’s start by thinking about how centralized applications work. Centralized applications have a “front end” and a “back end”. The front end is what consumers interact with. To create the front end, web developers use HTML, CSS and Javascript. The back end is a database. This is where the application houses all of its users’ information. The front end application then communicates with the back end database through an Application Program Interface (commonly known as an “API”).

Surprisingly enough, DApps aren’t too different. A DApp’s front end application is programmed in the exact same way (using HTML, CSS and Javascript). This is important because it means that end users have the exact same user experience with a decentralized application as they did with a centralized application.

While the front end application is the same, DApps differ in (i) what they use for the back end and (ii) how the front end communicates with the back end. First, instead of using a centralized database like traditional applications, DApps use blockchain protocols to store information and process transactions. Second, instead of using an API like traditional applications, DApps use smart contracts to interact with the underlying blockchain.

Muhammad Noor summed it up well with the following depiction (you can find his article here):

  1. Centralized Applications: Front End API Database
  2. Decentralized Applications: Front End Smart Contract → Blockchain

How are developers incentivized to build a killer DApp?

The final piece we need to understand about DApps is the incentive mechanism. When I began learning about DApps, I was a bit confused why developers would want to create a product that essentially cuts out the middle man. Why would they want to build a product that does not earn a fee when transactions occur or have the ability to monetize the data in some way? What is their financial incentive?

The answer is that developers are incentivized by the potential price appreciation of a DApp’s token. Typically when a DApp completes an ICO, the company or person that created the DApp retains a portion of the tokens. Therefore, if the price of a token significantly appreciates, this person / company could earn a substantial amount of money. So what would cause the price of a token to appreciate? The laws of supply and demand. To use the service, consumers have to pay service providers with the DApp’s token. As a result, the demand for the DApp’s token will increase proportionately with the demand for the DApp. At the same time, there is typically a fixed supply of tokens because DApps usually set a token cap when they complete their ICO. Therefore, if the DApp becomes wildly popular, the value of the token will increase proportionately with the demand for the DApp.

As an example, let’s briefly go back to DUber. With DUber, riders pay drivers through DUber tokens. Therefore, as more riders and drivers join the platform, the demand for DUber tokens will increase, driving up the price of each token. Because the person or company that created the DUber DApp retained a number of tokens, they will directly benefit from this increase in value.

I do need to point out that some people are skeptical these tokens will actually accrue value. Their argument is that people will not want to hold these tokens. Instead, users will only access the tokens when they want to access the service. In the case of DUber, riders will only buy the amount of tokens they need for their ride and drivers will immediately convert those tokens to a currency after getting paid. If this proves to be the case, the value of the token would not increase proportionately with demand for the DApp. For more on cryptoasset valuations, I highly recommend checking out this article by Chris Burniske.

Before we wrap up, I need to highlight one more thing on DApp monetization. I’ve recently read several posts where people have proposed new methods for monetizing decentralized applications, including (i) selling advertising space, (ii) taking small transaction fees, and even (iii) selling user data. However, I don’t think any of these monetization strategies are realistic. If a DApp tried to implement any of these methods, it is highly likely that somebody else would simply fork the DApp’s code and eliminate that feature.

Wrapping Up

That wraps up my post on decentralized applications, I hope you found it interesting! Stay tuned for my next post, which will break down the process of raising capital through initial coin offerings. If you enjoyed this post and would like future posts sent directly to your email, please subscribe to my distribution list or reach out to me at

Also, if you have an interest in venture capital and want to read more VC-related content, please follow my publication “All Things Venture Capital” on twitter. Please also reach out if you are interested in adding to the publication! My goal is to continue to add high quality content (articles, podcasts, videos, etc.) from aspiring and current venture capitalists that want to share their perspective. Thanks for reading!