Summary
Framework for Cost Estimation:
Step 1: Identify Network Contributors
Step 2: Evaluate Cost Components
Step 3: Assess Cost Structure Variations and Summarize
Case Study
Key Points
To ensure the continued participation of nodes in the decentralized physical infrastructure network (DePIN), network managers (founders, DAO members, etc.) must consider the costs incurred by node operators when operating nodes.
In some cases, key decisions regarding cost optimization are obvious. For example, Livepeer’s move from Ethereum to Arbitrum in 2022 was a clear and beneficial choice, reducing settlement costs by over 95%. In other cases, DePIN managers may need external assistance to evaluate the costs of operating nodes, especially when resources for research and development are limited.
If nodes continue to incur losses, operators will cease to run nodes, resulting in a decrease in overall node supply. Understanding the operational costs of the DePIN network and its key drivers can enable network operators to initiate governance discussions and provide information for research and development work to reduce the costs of node operators before the supply of network services begins to decline.
Estimating the network’s operational costs can be challenging for protocol managers due to the anonymity of contributors (these networks are typically permissionless, meaning anyone can contribute and leave at any time) and the lack of publicly available data related to costs.
To guide decision-making, we propose a three-step framework for cost estimation:
Define network contributors and assign them to specific roles
Identify the cost components associated with nodes
Consider cost structure variations when evaluating the combination of Steps 1 and 2
In addition to an overall estimate of current costs, this framework provides:
A breakdown by role and cost component to help identify the largest cost drivers
Scenarios of estimated changes under different assumptions and increased demand/network capacity
A case study demonstrates how to apply this framework. For example, a joint investigation with the POKT Network revealed ongoing efforts by node operators to expand service nodes. However, decentralizing their gateways resolved residual barriers to economic scalability, including demand generation.
Introduction: What is DePIN and Why Discuss Costs
DePIN is a collection of decentralized networks that provide physical infrastructure resources for various use cases, such as computing, storage, wireless networks, or data measurement. DePINs utilize Web3 incentive models (token reward systems) to incentivize the construction of physical infrastructure networks. As of May 2024, the total market capitalization of all DePIN tokens is $29 billion.
DePINs contribute to both digital and physical resource networks:
In the Physical Resource Network (PRN), contributors deploy location-specific hardware to provide (non-replaceable) services. This includes:
Wireless networks (e.g., Helium, World Mobile, XNET, Nodle)
Sensor networks (e.g., Dimo, Hivemapper, Silencio, Onocoy)
Energy networks (e.g., Starpower, PowerLedger, Arkreen)
In the Digital Resource Network (DRN), contributors direct hardware to provide (replaceable) digital resources, with physical location not being a primary criterion. This includes:
Compute (e.g., ICP, Livepeer*, Akash Network, POKT Network*, Covalent*, Lit protocol*)
Storage (e.g., Arweave*, Filecoin, Sia)
Bandwidth and Privacy (e.g., NYM*, Hopr, Orchid, Mysterium, Fleek)
AI (e.g., Bittensor, Fetch.ai, Modulus Labs*)
Early DePIN projects generated significant initial interest due to their token framework design. For example, Helium rewards contributors with HNT tokens for helping operate wireless networks with hotspots, while Filecoin allows users to rent out their excess storage space. While this was enough to get many DePIN projects started, token issuance may not be sufficient to ensure long-term participation of nodes in the network.
If running nodes becomes unprofitable, node operators will no longer have the incentive to operate DePIN infrastructure. Therefore, DePIN founding teams must help node operators optimize costs.
DePIN Flywheel
The typical flywheel of DePIN token economics is as follows:
Establish the supply side of the service, such as storage or 5G antennas
Inflationary token rewards incentivize node operators to provide the necessary infrastructure, even though demand is not enough to cover costs
Over time and with growing demand, monetizing network activities may increase node operators’ income, even as token rewards gradually decrease
Continued monetization of network activities and increased node operator income further incentivize supply, creating the DePIN flywheel
The visual representation of the DePIN flywheel is as follows:
As described in our previous analysis of reward issuance schedules, the USD value (token price) of these token rewards is significantly influenced by overall market sentiment. Therefore, they may look like this:
Or depending on when you entered the bull market, it could look like this:
So, what does reward issuance have to do with costs?
As mentioned earlier, if token rewards and income from user demand are not sufficient to achieve a break-even point, node operators may decide to stop supporting the network. A significant portion of DePIN’s operating costs is paid in fiat currency, making the USD value of token rewards important and linked to overall market performance. Despite any well-designed token issuance measures, in the worst-case scenario, the situation could turn out like this:
This would result in node operators exiting, leading to higher latency, lower reliability, and a worse user experience. Ultimately, stagnating demand will shut down the flywheel.
The good news is that there are many ways to address this situation. One approach is to make token issuance more flexible to align with network monetization (see KPI-based issuance here). Another approach is to address cost issues to make the overall network more efficient and less sensitive to token price drops. Our dynamic chart would look like this:
Key Assertion: Knowing the costs of operating the DePIN network and its major cost drivers can initiate governance discussions and research and development work to reduce node operator costs before the supply of network services decreases.
Given the decentralized and permissionless nature of DePINs, assessing the cost base is not easy. While token rewards and income from user demand are usually tracked on-chain, other costs associated with running nodes are not publicly available (e.g., infrastructure costs). This means that we need to make assumptions and estimates based on available data points.
In this article, we address this challenge and present a framework for estimation.
Step 1: Network Contributors
Step 2: Cost Components
Step 3: Evaluating the Cost Structure of Network Contributors
Framework
We propose the following framework as a methodology for network managers of DePIN networks to assess the operational costs involved in running infrastructure nodes.
Using this framework, the cost estimation for DePINs is broken down into three steps:
Identify network contributors
Evaluate cost components (e.g., hardware, labor)
Evaluate the above cost structure and summarize to obtain an overall cost estimation
Step 1: Identify Network Contributors
Although DePINs provide various services (e.g., computing, network coverage, mobile data), the roles required to provide these services are the same (see an overview of DePIN supply-side roles in over 30 networks here):
Service Nodes/Producers: They provide services and the physical infrastructure (e.g., servers, antennas, dashcams) required for them. Examples include storage providers in Filecoin, hotspots in Helium, or transcoders in Livepeer.
Validators/Observers/Fishermen: They check the work done by service nodes, either directly or through the accounting layer. The results of these checks are then sent to the accounting layer. Examples include storage providers in Filecoin (as they also validate storage proofs of other providers) and hotspots and oracles in Helium (performing coverage proofs of other hotspots).
Computation Layer: Tracks the flow and status of the work/service provided and the corresponding payments. Note that the protocol defines the computation logic itself, such as how to track and store work and payments on the blockchain (we will discuss this in detail in another article). Examples include Livepeer’s Arbitrum or POKT Network’s POKT-chain (operated by POKT validation nodes).
Gateways: They function as coordinators/balancers when it comes to user, service node, and management access or aggregation of services (e.g., data in sensor networks) and are related to the accounting layer. Examples include Livepeer’s Orchestrators or Gateways in the POKT Network.
Delegators: Participants who contribute economically by staking for service or observer nodes.
Roles related to the demand side (such as sales teams) are not common at the moment. Assessing costs related to running the protocol, such as governance costs, is the subject of another article.
Note that not every DePIN has delegators and gateways, and not all roles need to be separated. For example, storage providers (SP) in Filecoin are categorized as both service nodes and validators, and they also operate the Filecoin chain, forming the accounting layer as well. Arweave miners are also an example of this.
Step 2: Evaluate Cost Components
Each of the above roles can be performed by nodes, and their costs can be categorized into any of the following four components (most have multiple):
Hardware/Infrastructure: Costs related to the actual physical infrastructure, such as dashcams
Labor: Costs related to the time spent setting up and operating the infrastructure
Bandwidth, Electricity, and other operational expenses: Costs related to data exchange and other operational expenses, such as electricity and data center rent
Staking: (Opportunity) costs incurred by holding tokens that are not invested elsewhere
The last point refers to the cost of capital, where it is nearly impossible to obtain information on debt/financing costs associated with these operations on a broad scale. However, a part related to capital costs is something we can assess: many DePINs follow a pattern of staking to gain access to work tokens and require node operators to stake some tokens to be allowed to contribute. Acquiring these tokens is an investment, even if we assume that the amount can be recovered when leaving the network, but holding these tokens incurs an opportunity cost compared to investing capital elsewhere.
Our assessment of cost components would be incomplete without considering the costs associated with transactions on the accounting layer. Assessing this is not straightforward and depends on several variable factors. Generally, the network decides to what extent it outsources accounting off-chain. However, for recording of settlements and on-chain transactions, there are three options:
Proprietary L1: The network operates its own blockchain. Examples include Arweave, Filecoin, and POKT Network. Typically, service nodes and validator nodes also cover this role, which is why the associated costs are included (though we will try to separate them if possible – see the example of POKT Network in the case study).
Proprietary L2, more commonly known as application chains or application-specific rollups: Costs of rollup infrastructure (sequencers, etc.) and adjacent infrastructure (block explorers, wallet integrations, etc.) can usually be mapped to these four components. In unclear cases, such as when using a Rollup-as-a-service provider (RaaS), they would be mapped to bandwidth and other costs.
Public L1/L2: These outsource the accounting layer, meaning there are no hardware and labor costs for the network. However, service nodes, validator nodes (and users/payers) directly pay (based on usage). Assessing the network-related costs of these transactions poses some challenges, so there are limitations: not all transactions are related to the accounting layer, such as swaps or other DeFi transactions, but it is generally difficult to separate these transactions. We map these costs to bandwidth and other costs.
Taking all these factors into account to create a cost estimate is a challenging task. We not only need to come up with estimates for each cost component for each role in the network, as shown in the diagram below, but we also need to consider that not all node operators have the same cost structure. Determining the overall cost estimate is more complex than simply multiplying the number of network node operators by an estimate for one node operator.
Step 3: Assess Cost Structure Variations
When we talk about cost structure, we refer to the key differences that impact costs. These key differences make assumptions crucial. Of course, it is a trade-off: making assumptions simplifies the process but may sacrifice accuracy. That being said, considering how many factors are involved, certain assumptions must be made to arrive at a workable theory.
When evaluating cost structure, there are three main factors to consider:
Setup Differences: A typical example is one operator using bare-metal servers, while another operates in the cloud (buying vs. leasing). We can usually account for these differences when we know the corresponding share in the entire network. This also involves capital costs in leasing or financing agreements. Assuming no capital costs, we suggest ignoring these differences.
Another cost difference is related to the time of purchase (buying storage gets cheaper over time, buying H100s may not). We suggest assuming a 3-5 year depreciation period for hardware.
Location of operation is also a cost difference factor. We suggest assuming an average location, or if possible, using the corresponding average costs.
Other cost differences are generally ignored due to the complexity of accurate assessment (e.g., differences in electricity prices, labor costs, etc.).
Taking into account all these factors and making assumptions, we can evaluate the cost structure.Considering the time aspect by using current prices is crucial for labor costs, where location plays a significant role. DePIN can recruit contributors from all around the world, and there is a significant wage difference based on the local labor market, making it difficult to assess the time invested in these tasks. However, we make the simplifying assumption in our framework version that all node operators have the same hourly wage.
Efficiency differences: Node operators can have identical setups, but if one operates more nodes, their cost per node may be lower due to economies of scale. In our framework, we need to evaluate the node distribution for each node operator to address these effects. To understand and estimate the cost impact, surveys need to be conducted with both larger and smaller operators or other available data points, such as bulk discounts for promotions.
Another example is long-time supporters of the network who progress faster on the learning curve and, therefore, are more efficient in their operations compared to newcomers. Unless we have direct data points from surveys, we overlook this aspect.
Differences in attribution and calculation: While node operators are equal in the first two points, they may view their contributions with different cost bases, resulting in different final costs. For example, one person may consider their involvement as part-time and not track any time spent, while another may treat it as their main business and pay wages based on the time spent on the project. We consider this difference by providing a wider margin of error for the “part-timers” side (as they are usually underestimated), but assume an equal time investment for each node operator (also see economies of scale).
This relates to the benefits of the sharing economy, which is common for DePIN: operators can use the same setup in multiple networks (thus also hardware, labor, and operating expenses like bandwidth and electricity), for example, Livepeer with Ethereum and Filecoin operations, io.net with Render, Filecoin, and other GPU networks. For cases where hardware is critical to operations, we do not consider cost savings related to the sharing economy. They are not only hard to identify but also challenging to quantify which network benefits the most in terms of costs and how the savings are allocated. In accounting terms, we will decompose the total cost into monthly amounts. For simplicity, we assume that we amortize the total amount over the entire lifecycle with the same term and allocate the same amount per month for all node operators.
Of course, there are more nuanced differences that we will explore in more detail in the DePIN repository.
This adds a third dimension to our “execution plan” and creates 60 different combinations to consider:
Overall, while this formula is comprehensive and provides multiple options for cost structures, it is most useful when applied to multiple time points rather than a static time point. The most powerful model is one that links operational costs to network capacity. This allows us to understand how costs vary with changes in capacity or utilization. Network capacity is related to the services provided by the network, such as the number of RPC requests in Pocket, the storage volume in Arweave or Filecoin, or the percentage of road network mapping in Hivemapper.
Please note that this formula requires a significant amount of publicly available information, and we recommend obtaining this information through documentation provided by the networks, forum/Discord posts, and if possible, through surveys.
Conclusion and Next Steps
As DePIN evolves at an increasing pace, estimating the cost components of various DePINs is challenging. In addition to the known power laws about hardware costs and capacity changing over time, estimating cryptocurrency-specific costs like gas and throughput capacity of settlement layers is not a simple task.
Knowing the relationship between current costs and reward issuance and demand-side revenue, understanding the major cost drivers and how they change with varying assumptions, and how costs increase with increasing demand are useful indicators.
To help guide governance decisions about DePIN’s economic design, cost estimation needs to be associated with reward issuance and usage revenue. While I plan to provide more examples of cost estimation for DePINs, I welcome feedback on the proposed framework, its assumptions and summaries, and potential improvements to the cost estimations provided.
Appendix – Example Illustrations of Framework
Livepeer
Livepeer provides decentralized video infrastructure for real-time and on-demand streaming. Recently, Livepeer started enabling idle GPU resources for AI model training use cases (see here for details).
Here is the step-by-step application of the framework. Most cost estimations are based on surveys and community information with node operators (Orchestrators) conducted in summer 2023 (e.g., here).
The total estimated cost of operating the Livepeer network is approximately $85,000 per month. A detailed breakdown of the average cost shows that hardware and labor account for roughly equal shares (around 40%). If we consider the uncertainty in the labor cost estimation described in the table, the monthly cost for the network’s 100 Orchestrators, their transcoders, and settlement costs on Arbitrum is estimated to be around $40,000, on the lower end of the estimation range. It is worth noting that the cost of $40,000 per month is not far from the current fee income of approximately 5-10 ETH per month (corresponding to ETH prices of $3,000-$4,000). However, Orchestrators do not have negative profits as a larger portion of their income actually comes from staking rewards.
It is worth noting that due to settlement on Arbitrum, the settlement layer costs fall within the range of 0.5-2 ETH per month. This represents a cost savings of over 95% compared to the situation in Q1 2022 before the migration. Additionally, as of today, transactions on Livepeer have grown 2-3 times. Relatively, the accounting layer now accounts for approximately 5% of the total cost, whereas it was a major cost driver before the migration (accounting for around 80% of the total cost).
Recently, an algorithm was adjusted that determines the work allocation and places more emphasis on the per-pixel prices offered by Orchestrators. This puts downward pressure on transcoding prices and may help drive demand, but discussions in the forum show that price levels need to be further reduced. On the other hand, the recently launched AI-subnets may contribute to additional monetization opportunities for the network.
In one of the potential scenarios in the cost estimation spreadsheet, an increase in demand for transcode minutes by a factor of 3 would only increase the overall cost by 20%. It is worth noting that bandwidth is the main driver of cost increase.
If we assume similar price levels (with 1 ETH at $3,000), this should be enough to bring the network into breakeven territory. However, if the transcode price were to drop by 50%, the fee income at the network level would be around $45,000 per month, thus lower than the lower end of the cost estimate. How the dynamics of costs and revenues on the Livepeer network will change with the emergence of new use cases (thus increasing monetization opportunities) remains to be seen.
POKT
At its core, the POKT network provides decentralized remote procedure call (RPC) endpoints. Recently, the POKT network announced its expansion into more use cases related to AI model inference. The step-by-step application of the framework is as follows. Most cost estimations are based on surveys with node operators and subsequent interviews with these node operators and gateway operators conducted in summer 2023.
Based on approximately 15,000 nodes providing RPC endpoints and four gateway operators, we estimate the current monthly cost of the POKT network to be around $200,000 (+/- $80,000) to serve approximately 500 million relays per day. Currently, the largest portion is attributed to the service nodes (accounting for approximately 75% of the cost).
Since we have historical data on the number of active nodes in the network and different data points for cost components over time, we can put the cost estimation of the network on a timeline, showing three significant cost reductions being addressed:
Integration of nodes due to the bear market in mid-2022 and reduced token rewards (especially USD-based token rewards)
Rollout of improvements within the network, such as Geomesh and LeanPOKT, significantly reducing operating costs, as well as individual improvements to the setup by node operators
Decreased bandwidth costs due to the decentralization of gateways
As our cost framework links cost estimations to network capacity and demand, we can assess changes in the cost structure. For example, if the demand increases from the current 500 million relays per day to, for example, 2.5 billion relays per day, the gateways would account for 60% of the total cost base, around $400,000 per month (currently around $200,000). Please note that this is a cost increase of 2 times, while the demand growth is 5 times. This is because service nodes are able to improve their setup and thus meet growing demand on a relatively similar cost base.
If we further assume that the share of new gateways operating at a lower cost base increases to, for example, 50% (currently 30%) in the total number of relays serviced, the overall network cost would be $300,000 per month.
With the decentralization of gateways, gateway operators can define their pricing points individually. If we assume an average price of $4 per million requests, the overall scenario for the POKT network would generate $300,000 in revenue per month, thus essentially achieving breakeven.
Dfinity/ICP
Dfinity/Internet Computer Protocol (ICP) is designed as a “blockchain of blockchains” that provides computational resources for executing smart contracts (called canisters) organized in subnets (details in https://internetcomputer.org/whitepaper.pdf). The pillar is to provide storage, compute, and bandwidth to replicate all canisters, their state, and their subnet computations on node machines.
The step-by-step application of the framework is as follows. Most cost estimations are based on documentation and forum posts.
ICP is one of the few networks that incorporate costs based on fiat currencies into the token reward mechanism, making cost estimation easier. Currently, with approximately 85 operators running around 1,400 node machines, we estimate the total monthly cost of operating the ICP network to be between $400,000 and $900,000, with an average of around $600,000.
Although appropriate revenue estimation deserves a separate article, we estimate the current monthly revenue to be around $25,000. Compared to the estimated costs, this seems low, but it is due to low utilization: with only 559 node machines active, we estimate the current demand (measured in cycles burned) to be around 2% of the total capacity. This means that the network can tolerate a demand increase of, for example, 25 times and still not increase the current cost base. A forum post actually estimates that the demand in the next two years will reach 15-25 times, which would then result in ICP generating these fees per month.
DIMO
DIMO is a decentralized network that empowers drivers to manage their vehicle data. At the same time, DIMO enables enterprises and developers to build innovative mobility-related applications (and profit from them). Data measurements are done through special devices (Autopi, Macaron) or applications. While the above examples of DePINs are digital resource networks, DIMO is the first example of a physical resource network included in this analysis.
The step-by-step application of the framework is as follows. Most cost estimations are based on online (device) price information, Dune data, and forum posts.
For the settlement layer, we assume that half of the average cost per connected car spent on settlement in Q1 2024, ranging from $0.6 to $1.5, can be attributed to DIMO’s operation. For the gateway, we assume a monthly hardware cost of approximately $4,000, with labor costs related to the above operations amounting to around $11,000 per month. Overall, this adds up to approximately $180,000 in monthly expenses, as shown in the table. The majority of costs are related to bandwidth and other costs, with approximately 1/3 related to settlement costs on Polygon and 2/3 related to the monthly cost share of smart car integrations.
We do not have clues about the actual revenue of the network, but estimating it based on the global automotive data marketplace and related automotive data revenue shows that the current revenue per car is around $150 to $185, which could increase to $500 to $600 by 2030. If DIMO is able to capture 10-15% of this revenue, the generated revenue range would cover the operational costs, amounting to $110,000 to $180,000 per month.
However, data monetization itself does not seem to be the actual protocol objective; instead, DIMO focuses on providing infrastructure for building applications on top of the network (https://docs.dimo.zone/overview), which is reflected in the recent discussions about DIMO node and token upgrades. Changes in the discussions may affect the above cost structure.
Special thanks to my contributors: Mihai (Messari), Raullen (IoTeX), Nodies Team, Grove Team, Pocket Network Foundation, DIMO Team, Diana Biggs, and Christopher Heymann for their contributions to feedback and insights.
*The standard project is the 1kx portfolio.
