How dApp Value Capture Will Distribute Across Decentralized Infrastructure

This article was originally published on Smart Content and appears here with permission.

Decentralized applications (dApps) are a new type of digital application built on blockchains. Unlike most Apps today, which consist of closed-source code running on centralized servers, dApps are open-source software running on decentralized networks. Decentralization is desirable because it removes any single point of control or failure in the dApp’s execution, generating strong determinism — the dApp will run exactly as originally coded without counterparty tampering, network downtime, or administrative censorship. Determinism is critical to multi-party process automation, especially when billions to trillions of dollars exchange hands without human intervention.

dApps are built using smart contracts — programs with coded logic that run deterministically on blockchains (if x event happens, execute y action). Most dApps combine several smart contracts to form an application with a specific use case. Some examples of dApps include:

• Bancor — a decentralized exchange (DEX) that uses an automated market maker (AMM) to provision on-chain liquidity for asset swaps. Users stake their assets in liquidity pools, which traders and other dApps leverage to swap between assets instantaneously, paying small fees to the liquidity providers (LPs).
• Aave — a decentralized money market where anyone can permissionlessly take out an overcollateralized loan in seconds. Lenders supply assets into liquidity pools to earn interest, while borrowers obtain loans from liquidity pools by depositing collateral and paying interest.
• PoolTogether — a no-loss savings game where users deposit their interest-bearing tokens into a lottery pool, which accrues interest over the lottery’s duration and distributes it all to a random winner. Afterward, users can withdraw their deposits in full.
• Fei Protocol — an algorithmic stablecoin that aims to maintain a value of $1 USD in a decentralized manner. It has an adjustable supply, which mints and burns stablecoins to financially incentivize arbitrageurs to return FEI to its $1 peg when it’s over/under $1.

These are just a few examples of the many dApps currently running live across various blockchains. However, dApps are still in their infancy, meaning they are likely to undergo continual upgrades, and new advanced dApps will emerge that are still yet to be imagined.

Instead of focusing on the benefits to dApp users (demand-side) or why cryptocurrency tokens exist, this article examines how value capture from dApps will be distributed across decentralized infrastructure (supply-side). In a simple sense, what functionalities do dApps require that come with costs, and what layers of infrastructure are best equipped to service those functionalities and capture dApp fees as a result?

This article goes about answering those questions by first identifying all the potential functionalities needed by dApps. It then outlines several macrotrends that will affect dApp value capture. Finally, it lays out a generalized framework of four layers where dApp value is likely to consolidate.

Notes:

First, these are merely approximations from our research using incomplete and continually expanding datasets. The dApp ecosystem evolves rapidly, so our analysis may change over time. Second, we often denote that users will incur costs, yet realize that most dApps are currently subsidizing many of these costs with initial token supplies to bootstrap their network effects. However, with a 5–10 year outlook, we assume that users will incur most of these costs over the long term. Thus, we may interchangeably state dApps and/or users incur underlying infrastructure costs.

Potential Value Capture Functionalities for dApps

Before looking at how value capture will be distributed, let’s outline all the possible functionalities that dApps may require to run competitively end-to-end. Every functionality provides a pivotal service to the dApp that has a cost to generate. People don’t work for free, so each service is performed for a profit that is captured by the dApp, underlying blockchain, off-chain oracles, external service providers, or some combination of the four.

dApps will vary in what services they require and how critical each service is to their success. Additionally, the cost of each service will depend on how frequently it’s used, how much value it secures, how it’s architected, and the overall quality of the dApp itself. With that in mind, listed below are the six most basic functionalities required by all dApps.

Settlement

dApps are essentially sub-ledgers within the overall blockchain ledger. They are made up of smart contracts that assign asset ownership and define how deposited assets can interact within the dApp. Settlement represents a permanent state change to the dApp, meaning the dApp’s sub-ledger undergoes an irreversible update. State changes happen through on-chain transactions that are processed by the dApp’s underlying blockchain, such as to transfer ownership of assets, augment the code of upgradable smart contracts, verify off-chain proofs, post hashes of external state, or simply store raw calldata. Each state change requires satisfaction of the dApp’s smart contract conditions, which can be as simple as a signature verification or involve more complex computation checks.

Users have to pay blockchain miners/validators for any settlement functions performed on-chain since they are the entities that produce blocks and secure the blockchain network. While many blockchains have block rewards to subsidize the work done by miners/validators, users still have to pay a base fee to prevent Denial of Service (DoS) spam from halting the network. Additionally, users may have to pay tips to miners/validators to get their transactions processed quicker when the demand for blockspace exceeds the supply. Settlement costs for dApps will depend on the settlement frequency, settlement complexity, on-chain data storage requirement, underlying blockchain network congestion, finality needs, and more.

Generally, high-throughput blockchains with greater hardware requirements (100 to 1,000 nodes) are likely to settle each user’s transaction on the underlying blockchain directly and individually, while more decentralized (10,000 to 100,000+ nodes), lower-throughput blockchains will bundle multiple user transactions off-chain and settle them on the blockchain as a single aggregated settlement transaction to improve overall throughput (upwards of 100x to 10,000x).

The layer-1 blockchain is the final settlement layer for dApps; (source).

Computation

Each dApp has smart contracts with logic that need to be processed before the final state change is generated. While settlement involves transferring assets or storing finalized state directly on the ledger, computation consists of running the dApp’s code to check if various conditions were met for settlement. Simply put, computation determines what the final update to the sub-ledger will be (state change), while settlement performs a simple verification of the state change and executes it on the blockchain.

Example: An undercollateralized loan in a decentralized money market.

• Computation — checks the collateralization of the loan by referring to a price feed to calculate the outstanding loan value compared to the collateral value. If the loan’s collateralization is found to be under the predefined threshold (e.g., 150%), it will signal a liquidation is possible.
• Settlement — checks the liquidator’s transaction signature and the results of their computation. If valid, the blockchain will liquidate the user’s collateral by paying down the debt and transferring ownership of liquidated collateral to an external entity(s).

dApps on high-throughput blockchains may simply run computation and settlement together on-chain. However, decentralized blockchains are beginning to separate the computation and settlement processes. Separation is achieved by computing transactions off-chain in layer-2 networks, then batching those transactions together (e.g., rollup) and settling them on-chain via a single aggregated transaction. This reduces on-chain costs since the blockchain only has to store a small amount of data and process a single compressed proof to verify all the state changes for settlement instead of performing computation work for each individual transaction.

Users will need to pay blockchain miners/validators for any computation done on-chain (similar to settlement) and pay layer-2 validators for any computation done off-chain.

Example of a zkRollup, which performs computation off-chain and stores the state on-chain; (source).

Storage

dApps require storage solutions to host user interfaces (UI) so users can interact with dApps in their web browser. Website hosting can be done through traditional cloud services like AWS or decentralized alternatives like Ethereum Name Service (ENS) and the InterPlanetary File System (IPFS). Although anyone can run a full blockchain node to interact with dApps without any UI, most users will not, necessitating the need for such interfaces. Since ENS and IPFS are unmonetized networks, they offer little value capture potential unless an incentivization layer is built on top (e.g., Filecoin offers financial incentives to store files persistently).

dApps also need to store data associated with the application, such as raw transaction data. The location of this data will depend on where the dApp’s computation takes place. If computation occurs exclusively on-chain, then the data is stored on-chain, and fees go to miners/validators (sometimes with state rent to minimize bloat). If computation is performed off-chain in a layer-2 network, then dApps can store transaction data either on-chain or off-chain, depending on the trust assumptions desired by the dApp.

Some dApps will store all transaction data on-chain so anyone can reconstruct any state changes, but with the trade-off of paying higher fees to miners/validators to store the data. Other dApps will store only the final state root on-chain, and store the raw transaction data off-chain at a lower cost, such as through a committee of layer-2 validators or decentralized storage networks. Users will need to pay storage providers to both keep the data (persistence) and allow for on-demand queries of specific pieces of data (availability).

A simple framework of the different approaches that layer-2 networks take to store data and verify their off-chain computation; (source).

Additionally, some dApps may pay for off-chain storage solutions to store other forms of data required for their use case. For example, user profile data and analytics may be stored off-chain and used to generate reputation scores that are made available back on-chain through an oracle. Ultimately, dApps have many options regarding where they store their data.

Capital

dApps often have a native digital asset and/or leverage other user-deposited digital assets as part of their services. The capital is used across many functions, such as liquidity provisioning within decentralized exchanges and money markets, built-in insurance backstops for synthetic asset platforms and decentralized stablecoins, external insurance to hedge unforeseen smart contract failures, and/or staking incentives to encourage usage of the platform. With Decentralized Finance (DeFi) being the most significant product-market fit for dApps thus far, liquidity plays a prominent role in lowering slippage for users and allowing for greater amounts of economic activity to occur.

Users often need to pay fees directly to capital/liquidity providers when utilizing a dApp that benefits from this deposited capital. Oftentimes, this fee is a static percentage of the transaction’s value (e.g., 0.3% of trade size). dApps may also use a portion of their fixed token supply or implement an ongoing inflationary token supply to subsidize key service providers, including end-users directly, specific LPs, and/or governance token holders. For example, yield farming is a popular way of bootstrapping the supply side of a DeFi dApp by directly rewarding users and/or LPs with the dApp’s newly minted tokens (i.e., governance tokens).

The DeFi ecosystem leverages liquidity in various forms to generate value for users; (source).

Services

Most dApps need several supplementary off-chain services to support their on-chain functions and continual maintenance, such as access to external data, transaction ordering, privacy generation, retail bank payments, enterprise backend systems, other blockchains, keeper bots, arbitrageurs, data indexing, traditional APIs, verifiable randomness, proof of reserves, blockchain abstraction layers, or any type of off-chain data or service not available or practical to run on the native blockchain itself.

dApps have to pay for services, pay to initiate them from on-chain, and/or pay to make the results of the services available on-chain for use in the dApp. dApps may use a single off-chain service or combine multiple services to expand their utility and/or lower costs for users. Generally, these services are run by the dApp’s development team, outsourced to anyone in a permissionless manner using financial incentives, or outsourced to specific knowledgeable/capable entities through on-chain or off-chain agreements. Decentralized Oracle Networks (DONs) have absorbed many services, acting as a universal on-chain gateway to any off-chain service.

Example of how off-chain services (data and compute) enhance on-chain dApps; (source).

DONs often abstract services away for dApps, such as handling payments to both miners (posting information on-chain) and off-chain APIs (subscriptions to off-chain resources) as part of the fees DONs take in from dApps to provision services for them.

Governance

dApps have some form of governance that controls important development and maintenance decisions. Some dApps are run by a foundation or development company that’s supported via an initial allocation of the dApp’s native token supply. Other dApps elect for on-chain governance via direct voting from governance tokens holders, delegating representatives via on-chain voting, performing non-binding off-chain votes to gauge rough consensus of its community, or forking a token and issuing an airdrop in a worst-case disagreement.

dApps that issue governance tokens allow users to shape the future direction of the protocol and capture part of its revenue. Sometimes, a portion of the dApp’s transaction fees is distributed to governance token holders, akin to receiving a dividend based on the amount of equity you own in the dApp or a stock buyback when transaction fees are burned instead of distributed. In token-weighted voting processes, owning more governance tokens allows users to become more powerful board members that can influence the protocol’s future.

As protocols scale, governance decisions may become more lucrative to control, although it’s difficult to calculate the true value, especially if no revenue stream is attached. It’s also unclear how much decentralization and participation make for good governance, likely varying from one dApp to another and producing different results. Interestingly, decentralized governance experiments could strongly influence the future of political science as many new governance models are tested in production.

Example of a token-driven voting governance process to adapt an on-chain protocol; (source).

Macro Trends That Will Impact Value Capture

With a comprehensive list of all the key functions that may capture value from dApps, let’s examine some general macro trends that will impact long-term value accrual across decentralized infrastructure

Trend 1: Network Effects

If there is value to be captured, it will attract competition. However, consolidation of dApps, blockchains, and various other decentralized networks will happen over time, and it’s likely that only a few winners will remain for each, akin to power law distributions. Some market verticals could even be a winner-take-all dynamic when the underlying networks are sufficiently generalized, decentralized, and self-sustaining. The main driver of consolidation will be network effects — a phenomenon where every additional user to a network leads to more value being generated for users of that network.

One of the main advantages of network effects is economies of scale, where every additional user lowers the costs for each existing and future user. It occurs when users and service providers concentrate on a single standardized protocol, leading to service providers earning the most revenue and users obtaining the highest quality services at the lowest cost. Direct benefits to dApp users include access to deeper liquidity and more robust security, while service providers can get more user fees and less extraction from their profits.

In comparison, when resources spread out across multiple protocols, costs go up, quality gets diluted, and/or revenue decreases. dApps wanting to remain competitive are likely to leverage external infrastructure with economies of scale instead of paying full costs and taking on additional risks to build their own. Economies of scale are particularly critical for open-source technology that’s easily replicated, forcing dApps to drive down margins, remove unnecessary fees, and remain minimally extractive.

Various examples of network effects, one of which includes economies of scale; (source).

The other benefit of network effects is development standards — a situation where a large ecosystem of diverse users come together to build, use, and improve upon the same technology. Standards bring many benefits to developers like more secure tech, faster integrations, sophisticated tooling, better documentation, and general comfort around relying on widely tested, adopted, and battle-hardened infrastructure. Standards feed into the lindy effect, which asserts that the longer something exists, the more likely it will continue to exist in the future. Whether it’s because standard implementations are time-tested or popular with one’s peers, new users are more likely to commit time and resources to networks that they believe are and will continue to be industry standards.

Trend 2: Tokenization Advantage

Most decentralized infrastructure requires subsidies to bootstrap the services provided by the network, or at the very least, to remain competitive. Blockchains have block rewards, oracle networks utilize dynamic subsidies, and dApps offer liquidity mining incentives. Each of these financial incentives comes from a network’s initial or inflationary supply of native tokens and is used to grow the network to the point of self-sustainability and/or build a network effect too large to overcome. Each decentralized network with a token will perform better than those without tokens, simply because they can bootstrap adoption without taking on debt. They can also cultivate excitement and notoriety by having communities that want to benefit from the project’s potential success financially.

However, these subsidy allocations will not last forever for fixed supply tokens, and their effectiveness reduces with scale. Reduction in initial subsidy allocations will force decentralized infrastructure to implement inflationary token supplies or effectively capture the full operating cost of services over the long term through user fees. The rate at which fees are passed on to users depends on how much capital the network/dApp starts with and how that capital is managed.

User fees generated from crypto projects with native tokens (dApps in pink); (source).

It’s advantageous to prolong the subsidization period, so proper capital management by foundations, development companies, or DAOs can make networks more competitive over extended periods of time. Even with great capital deployment, large network effects that take in more user fees will outpace those with higher subsidies. Additionally, non-reliance on a subsidy can signal strong network effects, further increasing its attractiveness to users and service providers with long-term outlooks.

Trend 3: Inter-Layer Creep

Network effects can lead to dApps and decentralized infrastructure gaining particular advantages, empowering them to expand into more functions within their specific layer. Inter-layer expansion is most likely to occur across three dimensions: blockchains, liquidity, and hybrid service providers.

Blockchains that successfully evolve in a timely and targeted manner can eat into the value proposition of slow-evolving blockchains optimized for specific purposes. For example, highly decentralized blockchains could generate large network effects with well-designed and widely adopted scaling and privacy solutions. This would make it challenging for specialized blockchains that are optimized for scalability or privacy to compete. However, it could also be that optimization is too great to overcome and blockchains are relegated into well-defined niches — similar to the thesis of numerous specialized blockchains coexisting and connected through a standard generalized interoperability solution.

The Blockchain Trilemma is the notion that blockchains can optimize for two of the three features (scalability, decentralization, and security), but not all three. However, advancements are beginning to emerge that may challenge this notion (e.g., sharding) or mitigate the need for the base layer to provide all three; (source).

Liquidity can give dApps advantages over other dApps, resulting in opportunities for those dApps to broaden the range of services they provide. For example, dApps with a lot of liquidity could decide to add a DEX to their money market or vice versa, bringing dual utility to their platform and more value capture to their native token. Similarly, liquidity may affect blockchain adoption, although cross-chain DEXes and wrapped tokens can mitigate this to a degree.

The last consolidation layer is hybrid services, defined as off-chain computations performed on behalf of smart contracts yet securely anchored to blockchains for heightened determinism. Hybrid services represent a broad range of functions, but generally, involve any service outsourced by dApps because it’s not possible or practical to do on-chain due to the blockchain’s financial or technical limitations.

Hybrid services consolidate particularly well in generalized oracle networks because they have a large pool of general-purpose, compute enabled, and highly reliable nodes that developers can combine into custom networks to perform specific jobs like fetching external data, performing secure off-chain computations, automating contract functions, operating cross-chain bridges, and more. A hybrid service layer for doing any supportive off-chain function can generate strong economies of scale, ease of use, and resource accessibility advantages for dApps.

Trend 4: Geographic Adoption

While network effects are important, technology adoption sometimes falls upon geographic lines, mainly due to political or cultural barriers. It’s easily observable in the U.S. and China tech giants, with each country having its own version of the same technology: Google/Baidu, Amazon/Alibaba, and Twitter/Weibo. However, it’s not just a U.S./China phenomenon; it’s found all over the world.

China has its own version of many popular U.S.-based apps used by the rest of the world; (source).

As a parallel, it’s not hard to imagine a scenario where certain blockchains become popular simply because they are focused on specific countries or regions of the world or because their founders have close political connections. Similarly, dApps may specialize in geographic markets, such as providing better liquidity in locally used currencies, having native language options within their dApp’s UI, or implementing regulation checks compliant with specific political regions.

Value Capture to Consolidate Within Four Layers

Considering the various dApp functions required and the macro trends that will affect value capture, let’s look at how value capture may consolidate over a long time horizon across four primary layers.

Blockchains (On-Chain Function Layer)

The first and most obvious piece of infrastructure that will capture dApp value is the underlying blockchain. Blockchains are likely to consolidate around providing the following on-chain functions for dApps:

• Checking private key signatures for asset transfers between users, within a dApp, and between dApps.
• Verifying validity proofs, fraud proofs, threshold signatures, and TEE attestations derived from off-chain computations and layer-2 networks.
• Computing smart contract logic; more or less depending on the throughput of the blockchain.
• Updating the state of smart contracts and storing calldata or real-world data on-chain.

Blockchains capture dApp value by earning block rewards and user fees for performing on-chain functions, both of which are denominated in the blockchain’s native asset. Block rewards are distributed to miners for expending energy to produce valid blocks (Proof of Work) or become accessible to validators that produce valid blocks while staking a certain amount of the blockchain’s native token (Proof of Stake). Base user fees go directly to miners/validators or get burnt as indirect payments to token holders via supply deflation. Miners/Validators can also receive extra user fees as incentives by dApp users to process their transactions quicker (i.e., fast gas prices to get into the next block) and, in some blockchains, capture Miner/Maximum Extractable Value (MEV) by reordering transactions within blocks.

The seven-day moving average of revenue generated by Bitcoin and Ethereum miners; (source).

In effect, blockchains can capture a portion of value from every dApp running on their network. This value capture is likely to come from very low-cost, high-frequency individual transactions on high-throughput chains and higher-cost, lower-frequency batched transactions on decentralized blockchains. Overall, the key for blockchains to capture dApp value is to support many successful dApps with active users.

Blockchains do have some limitations though. First, they only capture value from the dApps running on their blockchain. In an increasingly multi-chain world, dApps may fractionalize their usage by deploying across many chains, reducing the possible value capture for any one blockchain. Second, blockchains are optimized to provide certain features, such as generating on-chain scalability at the expense of decentralization or transparency at the expense of privacy. As such, dApps may only deploy on blockchains with certain optimizations or simply route specific functions off-chain, reducing a single blockchain’s total value capture. Finally, blockchains have purposely limited computational capabilities, so more advanced dApp computations will likely never run on-chain directly. However, the blockchain’s native token may accrue value from some off-chain compute systems like layer-2 fraud proofs or validity proofs.

Oracles (Hybrid Service Layer)

The second and more misunderstood piece of infrastructure to capture value from dApps are the oracles performing trust minimized off-chain functions, referred to as hybrid services. Since blockchains create determinism through isolation (i.e., blockchains only keep track of internal state using internal data), they have no built-in capability to connect off-chain. Blockchains require oracles to interact with off-chain resources in a manner that preserves their determinism.

While oracles are typically thought of in a limited sense as only relaying external data on-chain (e.g., price feeds), generalized oracle networks like Chainlink can be leveraged to provide dApps with any type of hybrid service — off-chain computation that uses decentralization, cryptography, financial incentives, and/or trusted hardware to provide highly secure and reliable services for smart contracts in a manner that’s verifiable and enforceable on-chain.

If the blockchain layer is akin to decentralized computers, then the oracle layer is like a web of decentralized Internet protocols. However, oracles go beyond securely connecting disparate systems of value; they also supplement on-chain computations and off-chain resources by refining them. For example, oracles can provide scalability and privacy to dApp computations and bootstrap on-chain connectivity and reliability to traditional API services through data aggregation and staking. Notably, both of these refinement services require no changes to underlying blockchains or APIs.

dApps will require a wide range of hybrid services from decentralized oracle networks (DONs), including to:

• Fetch data from external APIs and deliver it on-chain.
• Relay smart contract outputs to external APIs like fiat payment systems.
• Aggregate data to harden it against single points of failure.
• Automate DevOps and smart contract maintenance functions (Keepers) like triggering liquidations, rebases, limit orders, yield harvesting, balance top-ups, etc.
• Generate verifiable random numbers for provably fair on-chain randomness.
• Perform scalable smart contract and data computation using layer-2 technology.
• Generate privacy for smart contract computation and data.
• Order user transactions according to a pre-defined notion of fairness to prevent frontrunning and harmful forms of MEV.
• Operate cross-chain and proof of reserve bridges for wrapped tokens and tokenized real-world assets.
• Serve as a blockchain abstraction layer to read/write data to any blockchain.

Decentralized Oracle Networks communicate bidirectionally between on-chain and off-chain environments; (source).

DONs capture value from dApps by getting paid for each hybrid service performed. Payments are predominately denominated in the DON’s native token, no different than miners/validators getting paid in the blockchain’s native token. The cost will vary greatly depending on the frequency, complexity, and quality of the hybrid service, along with the amount of value the service secures and the crypto-economic security backing it. DONs can provide crypto-economic security by requiring oracle nodes to stake the oracle network’s native tokens in on-chain service agreements, which can be slashed for malicious activity or simply failing to meet the predefined on-chain obligations (e.g., downtime, outlier data, faulty proofs, etc.).

An overwhelming majority of dApps need hybrid services, with most dApps requiring multiple hybrid services like scalable contract computation, external data, DevOps automation, and more. It makes the scope of a blockchain-agnostic oracle layer arguably more extensive than any single blockchain since it can capture value from most dApps on most blockchains across many independent services and monetize the entire existing API economy.

We believe the hybrid service layer will consolidate most around Chainlink. Not only does Chainlink already have a significant network effect as the market-leading oracle solution, but it’s a fully generalized, blockchain-agnostic, and permissionless protocol with a heterogeneous network architecture. In this sense, Chainlink is an infinitely scalable network of independent DONs, where each DON can consist of any custom combination of nodes tasked with providing any type of hybrid service to dApps on any blockchain/layer-2. As outlined in the Chainlink 2.0 whitepaper, Chainlink DONs can have their own consensus mechanisms, data structures, external connections, governance frameworks, and trust assumptions. However, they are not permanent, generalized ledgers like blockchains. Instead, DONs are standalone, application-specific services for smart contracts on existing blockchains and layer-2 networks.

A generalized, heterogeneous oracle network like Chainlink is well-positioned to achieve network effects because it can service any use case; there are no enforced design patterns, network scalability bottlenecks, or co-dependencies between DONs. Such network architecture makes it possible to create a common hybrid services marketplace where developers can leverage existing DONs or combine reliable node operators, external APIs, and computational adapters together to quickly bootstrap hybrid services for their dApp. With a diverse marketplace also comes reputation frameworks for filtering the quality of DONs and their individual components and a common reservoir for documentation on how any on-chain and off-chain system can interact through DONs.

Only a network effect in the hybrid service layer can open up all the world’s existing data and systems to blockchain developers, as well as cultivate a large pool of highly reliable general-purpose nodes for computing upon those off-chain resources. Universal resource accessibility would vastly accelerate the time it takes to build and launch dApps in production since developers can focus on their core business logic and manage one token to do anything off-chain. There are also major economies of scale effects because many types of DONs can be collectively used and funded by multiple dApps, resulting in the most secure DONs for the lowest costs thanks to user fee aggregation.

However, the vastness of the hybrid service layer will see competition and niches carved out by other projects and variance in the hybrid services that dApps require. For example, some blockchains already have built-in cross-chain bridges like Polkadot’s XCMP or Cosmos’ IBC. Some dApps also use on-chain incentives to encourage hybrid functions like keeper bots and other dApps have less scalable computation needs because they run on high-throughput blockchains. While there will be a lot of competition, there is no doubt that a network effect in the oracle layer will bring the greatest benefit to developers wanting to build advanced dApps. Why? Because it gives developers on any blockchain access to a reliable node network to perform any custom computation in a secure, scalable, and confidential manner using any input and output.

External APIs (Off-Chain Resource Layer)

The third piece of infrastructure to capture dApp value is the external APIs utilized by dApps. External APIs are defined as any system or network existing outside the dApp’s underlying blockchain that natively generates a unique form of value, whether that be valuable data or services. External APIs encompass centralized systems, blockchains separate from the dApp’s own, and on-chain dApps that are leveraged off-chain. So while generalized oracle networks provide gateways to external resources and refine on-chain/off-chain services, external APIs generate many underlying datasets and computational services that dApps want to access.

Some examples of popular external API resources include:

• Data providers specializing in generating particular datasets, such as high-quality weather data or financial market information. The dApp can use this data through an oracle as an input to trigger the execution of its computation.
• Cloud infrastructure offering advanced computational capacities like high-performance machine learning algorithms and integrated IoT networks. The dApp can leverage cloud systems to process raw data, which is then relayed on-chain by an oracle as an input to trigger smart contract functions.
• Global payments infrastructure providing fiat payment rails and access to large customer bases. dApps can use traditional payment gateways to settle transactions off-chain in local fiat currencies.
• Storage solutions consisting of decentralized networks like Filecoin and Siacoin or centralized networks like DropBox and cloud systems. dApps can off-load large storage requirements to external networks to avoid more expensive on-chain costs and/or retrieve external data needed for computation.
• dApps creating in-demand services like The Graph’s on-chain data indexing to support UIs or other blockchains for external payments. dApps can utilize other on-chain systems to get new features or reach new users.
• Web hosting and domain registration solutions powering UIs and websites, allowing people to find and utilize dApps.

An example of a data provider’s pricing model for their financial market data; (source).

External resources capture value by dApps paying directly or indirectly for their data/services. Payments are made either off-chain using fiat currencies and traditional API subscription models or on-chain using the external dApp/network’s native token. Most dApps across all blockchains require some form of external data or computation, which almost always necessitates the use of oracles as a bridge between environments. These external resources can be quite crucial to the dApp’s success, particularly data and computation used in the dApp’s execution. As a whole, the value capture for external resources is relatively high. However, most external APIs are niche, so there are clear limitations to how much value any single external resource can capture from dApps.

As noted previously, oracles often abstract away external resource fees from dApps by baking them into the oracle fees paid by dApps. This makes it easier for dApps since they only need to manage a single payment stream for any off-chain resources. It also lowers costs since oracles can aggregate fees towards shared external services. Over time, external resource providers are likely to become oracle nodes themselves, something already seen on Chainlink today (e.g., Tiingo, dxFeed, and more).

Ultimately, it’s important for oracle networks to support external resources in two ways: 1) enable external resource providers to sell API connections to existing oracles in a backward-compatible manner and 2) allow external resource providers to launch their own oracle nodes to sell their APIs directly on-chain.

This dual approach model is essential for getting the broadest range of data on-chain while maintaining the strong reliability guarantees needed by time-sensitive dApps that secure billions of dollars in an automated fashion. It’s why Chainlink has both models running in production today, along with provisioning data aggregation and data privacy solutions to refine data for dApps. The reality is many API providers don’t want to run additional infrastructure or lack the capability to do so in a highly reliable manner. Thus, if nodes were required to run their own nodes, it would severely limit on-chain access to data and introduce potentially serious vulnerabilities to smart contracts (i.e. if API providers are not professional DevOps).

dApp Tokens (On-Chain Capital Layer)

The final layer to capture dApp value is the native token of the dApp and the various external dApp tokens that may be used in a dApp. Most dApps issue their own native tokens, which are linked to some value stream or governance power within the dApp to give the tokens value and used to bootstrap a two-sided marketplace. Alternatively, dApps offering support for non-native dApp tokens generally do so to attract capital, especially DeFi apps that require liquidity for a wide variety of assets. The most common ways dApp tokens are used today include:

• Providing liquidity for essential dApp services like token swaps and overcollateralized loans.
• Funding insurance pools to protect user funds in case of faulty services.
• Giving equity to holders by tacking on small transaction fees for specific user interactions within dApps.
• Allowing users token-weighted voting power in on-chain governance decisions.
• Functioning as a bridge currency between trades.
• Serving as the medium for payment and/or discounts for dApp services or purchases.

Annualized revenue generated from DeFi protocols based on a 30-day sample; (source).

dApp tokens capture value in various ways, sometimes with more than one value stream. Some dApp tokens simply give holders the right to vote on protocol modifications through the dApp’s native governance DAO. Other dApps distribute a portion of all transaction fees to governance token holders (dividend or burn) as a form of revenue for holding equity in the dApp. There are also dApps that issue inflationary rewards to holders that stake dApp tokens, whether exclusively for their own governance token holders or for some external dApp token holders to attract liquidity. Finally, some dApps get more creative by offering special privileges and discounts within their dApp that only their token holders can access.

dApp tokens can be considered somewhat limited in network effects since they can only capture value from the usage of their dApp, and must be careful when charging high fees given the ease of dApp replicability. However, certain dApps are built more like infrastructure than pure standalone applications, such as dApps using other dApps for token swaps or immediate on-chain liquidity. There’s also evidence that dApps with respected reputations and communities are very hard to displace. For example, many copycat forks of dApps exist today, yet most don’t amount to much because users don’t trust inexperienced teams and/or remain loyal to their favorite dApp due to social consensus or financial exposure.

The most successful dApps are likely those with original ideas built by strong teams. They are also likely to employ a multi-chain strategy, attract large long-term liquidity providers, support a passionate and active community, outsource hybrid services to solutions with the best network effects, tie revenue streams to their token, and become a popular token in other dApps.

Advanced dApps Require Infrastructure Consolidation to Tap Into Network Effects

dApps are primed to become the backbone of how people interact globally in a diverse set of social and economic processes. However, achieving a large ecosystem of successful dApps requires tapping into the benefits of network effects, which necessitates a consolidation in the decentralized infrastructure that supports dApps. Network effects are critical to provisioning an advanced development environment for dApp creation, maintenance, and evolution, both to expand the number of resources available to developers and to give dApps the highest quality services at the lowest costs.

Network effects are truly beneficial for dApps and all the layers that support them.

• Blockchains hosting successful dApps will generate more user fees, leading to increased security budgets capable of supporting more decentralized and tamper-resistant networks. dApps running on blockchains with a greater security budget are more secure and trusted by users.
• Oracle networks enabling a vast array of new dApps through hybrid services will attract larger pools of user fees, increasing the network’s security budget and extending the number of jobs available for node operators. Increased demand for oracle networks leads to competition between oracle nodes, resulting in more secure nodes, a wider range of services, and additional API data and computational services being made available on-chain through oracles.
• External resource providers benefit greatly from successful dApps and oracle networks because it opens up new markets for them to earn revenue. The more external resources and oracle computations available to developers, the faster dApps are developed, the more value they can secure, and the more advanced functionalities they can support.
• dApps backed by secure blockchains, augmented by advanced oracle computations, and connected to high-quality external inputs/outputs lead to more performant, cost-efficient, and cutting-edge dApps. The continual improvement of dApps leads to more demand from users, generating more income for dApp token holders.

So while different infrastructure layers may vie for value capture, successful dApps — regardless of where value capture aligns — will result in more value available for all infrastructure layers because the total pie is extensively larger. Ultimately, all four layers all interdependent and require the success of one another to not only maximize their own value capture but achieve the ultimate meta goal beyond material desires:

A society where people have the ability to control their own data and financial assets and participate in fair, open, transparent, and reliable contractual relationships with others.