Article Rewrite:
Summary:
Framework for Cost Estimation:
Step 1: Identify Network Contributors
Step 2: Evaluate Cost Components
Step 3: Assess Cost Structure Differences and Summarize
Case Study
Key Points
To ensure the continued participation of nodes in decentralized physical infrastructure networks (DePINs), network managers (founders, DAO members, etc.) must consider the costs incurred by 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 an undisputed good choice and reduced settlement costs by over 95%. In other cases, DePIN managers, with limited development resources, may need external help to assess the costs of operating nodes.
If nodes continue to operate at a loss, operators will cease to run nodes, leading to an overall reduction in node supply. Understanding the operational costs of the DePIN network and its key drivers can enable network operators to initiate governance discussions; moreover, cost estimation can provide information for development work to reduce the costs of node operators before the supply of network services begins to decline.
For protocol managers, estimating network operating costs can be challenging due to the anonymity of contributors (these networks are typically permissionless, meaning anyone can contribute and leave at any time) and a lack of publicly available data related to costs.
To guide managerial decisions, we propose a three-step framework for cost estimation:
Define network contributors and place them in specific roles.
Identify cost components related to nodes.
Consider cost structure differences when evaluating the combination of steps 1 and 2.
In addition to an overall estimation of current costs, this framework also provides:
A breakdown by role and cost component to help identify the major cost drivers.
Scenarios of estimated changes and increased demand/network capacity.
Case studies will demonstrate how to apply this framework. For example, a joint investigation with the POKT network revealed ongoing efforts by node operators to expand their service nodes. However, decentralizing their gateways addressed remaining barriers to economic scalability, including demand generation.
Introduction: What is DePIN and why discuss costs?
DePINs are a set of decentralized networks that provide hardware resources (physical infrastructure) for a wide range of use cases such as computing, storage, wireless networking, or data measurement. DePINs utilize a Web3 incentive model (token reward system) 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-fungible) 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 guide hardware to provide (fungible) digital resources, with physical location not being the primary criterion. This includes:
Computing (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 to help operate wireless networks through hotspots, while Filecoin allows users to rent out their excess storage space. While this was sufficient to get many DePIN projects off the ground, token rewards may not be enough to ensure long-term participation of nodes in the network.
If running nodes becomes unprofitable, node operators will no longer have an 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, although demand is not yet sufficient to cover costs.
Over time and with growing demand, monetizing network activities may increase node operator revenues, even as token rewards gradually decrease.
Sustained monetization of network activities and increased node operator revenue 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 heavily influenced by overall market sentiment. Thus, they may look like this:
Or, depending on when you enter a bull market, it may look like this:
So, what does reward issuance have to do with costs?
As mentioned above, if token rewards and income from user demand are not sufficient to achieve a balance of income and expenses, 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 tied to overall market performance. While there may be well-planned token issuance measures in place, in the worst-case scenario, the situation may look like this:
This would lead to the exit of node operators, resulting in higher latency, lower reliability, and a worse user experience. Ultimately, stagnant demand would 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 the monetization of the network (see here for KPI-based issuance). Another approach is to address cost issues to make the overall network more efficient, thus reducing sensitivity to token price declines. Our dynamic chart will show this as follows:
Key Assertion: If you know the costs of operating a DePIN network and its major cost drivers, it can initiate governance discussions and development work to reduce node operator costs before the supply of network services declines.
Given the decentralized and permissionless nature of DePINs, assessing the cost base is not easy. While token rewards and user demand income are usually tracked on-chain, other costs associated with running nodes are not publicly disclosed (e.g., infrastructure costs). This means that we need to make assumptions and estimates based on available data points.
In this article, we will address this challenge and introduce a framework for estimation.
Step 1: Network Contributors
Step 2: Cost Components
Step 3: Evaluate the Cost Structure of Network Contributors
Framework
We propose the following framework as a methodology for managers of DePIN networks to assess the operational costs involved in running infrastructure nodes.
Using this framework, cost estimation for DePINs is broken down into three steps:
Identify network contributors.
Evaluate cost components (e.g., hardware, labor).
Evaluate the above cost structures and summarize to obtain an overall cost estimate.
Step 1: Identify Network Contributors
Although DePINs provide various services (e.g., computing, network coverage, mobile data, etc.), the roles required to provide these services are the same (see here for an overview of DePIN supply-side roles in over 30 networks):
Service Nodes/Producers: They provide services and the physical infrastructure (e.g., servers, antennas, dashcams) required for them. For example, Filecoin storage providers, Helium hotspots, or Livepeer transcoders.
Validators/Observers/Fishermen: They verify the work done by service nodes, either directly or through an accounting layer. The results of these checks are then sent to the accounting layer. For example, Filecoin storage providers (as they also validate storage proofs of other providers) and Helium hotspots and oracles (performing coverage proofs for other hotspots).
Compute Layer: Tracks the flow and status of the work/service provided and the corresponding payments. Note that the protocol itself defines the computation logic, such as how to track and store work and payments on the blockchain (we will discuss this in detail in another article). For example, 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 (such as data in sensor networks) and are also related to the accounting layer. For example, Livepeer’s Orchestrators or Gateways in the POKT Network.
Delegators: Can participate in the economy of service or observer nodes by staking.
Roles related to the demand side (such as sales teams) are not common at the moment, and assessing costs related to running the protocol, such as governance costs, is the subject of another article.
Note that not every DePIN has delegation and gateways, and not all roles need to be separate. For example, Filecoin storage providers (SP) are classified as service nodes and validators, and they also operate the Filecoin chain, thus forming the accounting layer. Arweave miners are also the same.
Step 2: Evaluate Cost Components
Each of the above roles can be associated with a node that performs and incurs costs, which can be divided into any of the following four cost components (most have multiple):
Hardware/Infrastructure: Costs associated with the actual physical infrastructure, such as dashcams.
Labor: Costs related to the time spent setting up and operating the infrastructure.
Bandwidth, Power, and Other Operational Expenses: Costs associated with data exchange and other operational costs, such as electricity and data center rent.
Staking: The (opportunity) cost of holding tokens that are not invested elsewhere.
The last point refers to the cost of capital: It is almost impossible to obtain information on the debt/financing costs associated with these operations on a wide scale. However, a part related to the cost of capital 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, and even if we assume that the amount can be recovered when leaving the network, holding these tokens has an opportunity cost compared to investing capital elsewhere.
Our assessment of cost components will be incomplete without considering costs related to transactions with the accounting layer. Assessing this is not straightforward and depends on several variable factors. In general, the network decides to what extent it will outsource bookkeeping off-chain. However, for records of the settlement layer and on-chain transactions, there are three options:
Proprietary L1: The network runs 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 (however, we will try to separate them if possible – see the example of POKT Network in the case study).
Proprietary L2, better known as an app chain or app-specific Rollup: Costs of the Rollup infrastructure (sequencer, etc.) and adjacent infrastructure (block explorers, wallet integrations, etc.) can usually be mapped to these four cost components. In unclear cases, such as when using a Rollup-as-a-service provider (RaaS), they will be mapped to bandwidth and other costs.
Public L1/L2: These outsource the settlement layer, meaning there are no hardware and labor costs for the network. However, service nodes, validator nodes (and users/payers) pay directly based on usage. Assessing the network-related costs of these transactions poses some challenges, so there are some limitations: Not all transactions are related to the accounting layer, such as exchanges or other DeFi transactions, which are generally not easy to separate. We map these costs to bandwidth and other costs.
Taking all these elements 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 figure below, but we also need to consider that not all node operators have the same cost structure. Determining an overall cost estimate is more complex than simply multiplying the number of node operators in the network by an estimate for one node operator.
Step 3: Evaluate Cost Structure
When we talk about cost structure, we refer to the key differences that affect costs. These key differences make assumptions crucial. Of course, this is a trade-off: making assumptions simplifies the process but may sacrifice accuracy. That being said, given how many factors are involved, certain assumptions must be made to arrive at a feasible theory.
When evaluating cost structure, there are three main factors to consider:
Differences in setup: A typical example is one operator using bare-metal servers while another operates in the cloud (buying vs. renting). We usually consider these differences when we know the respective shares 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 becomes cheaper over time, buying H100s may not). We suggest considering these differences.
Considering the time aspect by using current prices is important for labor costs, and location plays a significant role in DePIN as it can recruit contributors from all over the world where wage levels may differ greatly, making it difficult to evaluate the time invested in these jobs. However, we have made a simplifying assumption in our framework version that the hourly wages of all node operators are the same.
Efficiency differences: Node operators can have the exact same setup, but if one operates more nodes, their costs per node may be lower due to economies of scale. In our framework, we need to first assess the node distribution of each node operator to address these impacts. Then, to understand and estimate cost impacts, a survey is needed 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 are therefore more efficient in operations compared to newcomers. Unless we have direct data points from surveys, we will disregard this aspect.
Differences in attribution and computation: Although node operators are equal in the previous 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 person may consider it as their main business and pay wages based on 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 equal time investment for each node operator (also considering economies of scale).
This is relevant to the benefits of the sharing economy, which is common for DePIN: operators can use the same setup across multiple networks (and therefore hardware, labor, and operational expenses such as 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 difficult to identify but also challenging to quantify which network benefits the most in terms of cost and how the savings are allocated. In accounting terms, we will decompose the total cost into monthly amounts. To simplify, we assume that we amortize the total amount over the entire lifespan with the same terms and allocate the same amount per month for all node operators.
Of course, there are more subtle 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 to apply it to multiple different 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 the extent to which 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 on Pocket, the storage volume on Arweave or Filecoin, or the percentage of road network mapping on 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 develops at an increasing pace, estimating the various cost components of different DePINs is challenging. In addition to the known power laws about hardware costs and capacity changing over time, estimating cryptocurrency-specific costs such as gas fees and throughput capacity for settlement layers is also not a simple task.
Knowing the relationship between current costs and reward issuance and demand-side revenue, understanding how the major cost drivers 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 linked to 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 – Examples illustrating the 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 details here).
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 the summer of 2023 (e.g., details 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 labor cost estimation described in the table, the monthly cost of 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 the settlement costs on Arbitrum range from 0.5-2 ETH per month. This represents more than a 95% cost savings compared to the situation in the first quarter of 2022 before the migration. Additionally, as of today, transactions on Livepeer have grown 2-3 times. Relatively speaking, the settlement layer now accounts for approximately 5% of total costs, compared to around 80% before the migration, which was a major cost driver.
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 stimulate 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 a potential scenario presented in the estimation spreadsheet, an increase in demand for transcoding minutes by 3 times would only increase the overall costs by 20%. It is worth noting that bandwidth is the main driver of cost increases.
If we assume similar price levels (with 1 ETH at $3,000), this should be enough to bring the network into the breakeven region. However, if transcoding prices drop by 50%, the network-level fee income would be around $45,000 per month, thus lower than the lower end of the cost estimation. How the costs and revenues dynamics 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 concerning 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 the summer of 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 serving nodes (approximately 75% of costs).
Since we have access to historical data on the number of active nodes in the network and data points with different cost compositions over time, we can put the cost estimation of the network on a timeline, showing three larger cost reductions being addressed:
– Node consolidation after entering the bear market in mid-2022 and reducing token rewards (especially USD-based token rewards)
– Introducing improvements within the network, such as Geomesh and LeanPOKT, significantly reducing operational costs, as well as personal improvements to the setups by node operators
– Decentralized gateway role reducing bandwidth costs through the introduction of simpler gateway setups
Due to our cost framework linking cost estimations with 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, gateways would account for 60% of the total cost base, approximately $400,000 per month (currently around $200,000). It is worth noting that this is a 2x increase in costs compared to a 5x increase in demand. This is because serving nodes are able to improve their setups and thus meet the growing demand on a roughly similar cost base.
If we further assume that the share of new gateways running on a lower cost base increases to, for example, 50% (currently 30%) of the total number of relays served, then the overall network cost would be $300,000 per month.
With the decentralization of gateways, gateway operators can define their own pricing points. If we assume an average price of $4 per million requests, the overall scenario for the POKT network would generate $300,000 per month, thus achieving a breakeven essentially.
Dfinity/ICP
Dfinity/Internet Computer Protocol (ICP) is designed as the “blockchain of blockchains,” providing computational resources for executing smart contracts (called canisters) organized in subnets (see details in https://internetcomputer.org/whitepaper.pdf). The pillar is to provide storage, computation, and bandwidth to replicate all canisters, state, and subnet computations on nodes machines.
The step-by-step application of the framework is as follows. Most cost estimations are based on data from documentation and forum posts.
ICP is one of the few networks that incorporate costs based on fiat currencies into token reward mechanisms, making cost estimation easier. Currently, it is operated by approximately 85 operators with around 1,400 node machines. We do not have data points for larger operators in terms of economies of scale, so our overall estimation range is quite broad: the monthly cost of operating the ICP network is estimated to be between $400,000 and $900,000, with an average of around $600,000.
While 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 active node machines, we estimate the current demand (expressed as a burn rate per cycle) to be around 2% of total capacity. This means that the network can handle, for example, a 25x increase in demand 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 businesses 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 were 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 monthly cost per connected car, ranging from $0.6 to $1.5, can be attributed to DIMO’s operations. For the gateway, we assume monthly hardware costs of approximately $4,000 and labor costs related to the above operations of around $11,000 per month. Overall, this adds up to expenses of approximately $180,000 per month, as shown in the table. Most of the costs are related to bandwidth and other costs, with about 1/3 related to settlement costs on Polygon and the remaining 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 by using estimates based on the global automotive data market and associated automotive data revenue, it shows that the current revenue per car is around $150 to $185, which could grow to $500 to $600 by 2030. If DIMO can capture 10-15% of that revenue, the resulting revenue range would cover the operating costs, amounting to $110,000 to $180,000 per month.
However, data monetization itself does not seem to be the actual goal of the protocol; instead, DIMO focuses on providing infrastructure for building applications on top of the network (https://docs.dimo.zone/overview), which is reflected in the latest discussions about DIMO nodes and token upgrades. The changes in the discussions may impact the cost structure mentioned above.
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 opinions.
