Original title: Evaluating token economics for DePINs: cost estimation
Original author: Robert, 1kx
Original translation: Elvin, ChainCatcher
Summary
Framework for estimating costs:
Step 1: Identify network contributors
Step 2: Evaluate cost components
Step 3: Evaluate and summarize cost structure differences
case analysis
Key Takeaways
To ensure continued participation of nodes in the Decentralized Physical Infrastructure Network (DePIN), network managers (founders, DAO members, etc.) must consider the costs incurred by operators when operating nodes.
In some cases, key decisions about cost optimization are obvious. For example, Livepeers switch from Ethereum to Arbitrum in 2022 was an undisputed good choice, reducing settlement costs by more than 95%. In other cases, DePIN managers may need external help to evaluate the cost of operating a node when they have limited RD resources.
If nodes continue to lose money, operators will stop running nodes, resulting in a reduction in overall node supply. Understanding the operating costs of the DePIN network and its main drivers can enable network operators to initiate governance discussions; at the same time, cost estimates can inform RD efforts to reduce costs for node operators before network service supply begins to decline.
Estimating network operating costs can be difficult for protocol managers due to the anonymity of contributors (these networks are often permissionless, meaning anyone can contribute and leave at any time) and the lack of public data related to costs.
To guide managers’ decisions, we propose a three-step framework for estimating costs:
Define network contributors, who can be targeted to specific roles
Identify the cost components associated with a node
When evaluating the combination of 1 and 2, consider the difference in cost structure
In addition to an overall estimate of current costs, the framework provides:
Breakdown by role and cost component to help identify the biggest cost drivers
Changes in estimates under different assumptions and scenarios for increasing demand/network capacity
Case studies demonstrate how the framework can be applied. For example, a joint survey with the POKT network revealed ongoing efforts by node operators to further scale service nodes. Nonetheless, remaining barriers to economic scalability (including demand generation) were addressed by decentralizing their gateways.
Introduction: What is DePIN and why we talk about costs
DePIN is a series 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 leverage the Web3 incentive model (i.e. 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 a Physical Resource Network (PRN), contributors deploy location-dependent 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 a Digital Resource Network (DRN), contributors direct hardware to provide (fungible) digital resources, where physical location is not 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 a lot of initial interest due to their token framework design. For example, Helium rewards contributors with HNT tokens for helping run wireless networks through hotspots, while Filecoin allows users to rent out their excess storage space. While this is enough to get many DePIN projects off the ground, token issuance may not be enough to guarantee long-term participation of nodes in the network.
If running a node becomes unprofitable, node operators will no longer have the motivation to operate the DePIN infrastructure. Therefore, the DePIN founding team must help node operators optimize costs.
DePIN Flywheel
The typical flywheel of the DePIN token economy is as follows:
Building the supply side of services, such as storage or 5G antennas
Inflationary token rewards incentivize node operators to provide the needed infrastructure, even if demand is not yet sufficient to cover costs
Over time and as demand grows, monetizing network activity could increase node operator revenues, even as token rewards taper off.
Continued monetization of network activity and increased node operator revenue further incentivizes supply, creating the DePIN flywheel
A visual representation of the DePIN flywheel is as follows:
As we described previously in our analysis of the rewards issuance schedule , the USD value (token price) of these token rewards is heavily influenced by overall market sentiment. Therefore, they may look something like this:
Or depending on when you entered the bull market, it could be:
So, what does reward issuance have to do with cost?
As mentioned above, if token rewards and revenue from user demand are not enough to break even, node operators may decide to stop supporting the network. A large portion of DePINs operating expenses are paid in fiat currency, which makes the dollar value of token rewards important and tied to overall market performance. Despite any well-planned token issuance measures, in the worst case scenario, the situation may turn out like this:
This will cause node operators to exit, which will further translate into higher latency, lower reliability, and a worse user experience. Eventually, stagnant demand will close the flywheel.
The good news is that there are many ways to deal with this. One way is to make token issuance more flexible so that it is more aligned with the monetization of the network (see KPI-based issuance here ). Another way is to address costs so that the overall network is more efficient and therefore less sensitive to token price drops. Our dynamic graph will look like this:
Key claim: If you know the cost of operating a DePIN network and its biggest drivers, you can initiate governance discussions and RD efforts to reduce node operator costs before network service provision decreases.
Given the decentralized and permissionless nature of DePIN, assessing the cost base is not easy. While token rewards and user demand revenue are generally tracked on-chain, other costs involved in running a node are not public (such as infrastructure fees). This means we need to use assumptions and estimates based on available data points.
In this article, we 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
frame
We propose the following framework for managers of the DePIN network as a methodology for evaluating the operational costs involved in running infrastructure nodes.
Using this framework, the cost estimation of DePINs is broken down into three steps:
Identifying Network Contributors
Evaluate cost components (e.g. hardware, labor)
Evaluate the above cost structures and summarize them to produce an overall cost estimate
Step 1: Identify network contributors
While DePINs provide a variety of services (e.g. compute, network coverage, mobile data, etc.), the roles required to provide these services are the same ( see an overview of DePIN supply-side roles in 30+ networks here ):
Service Nodes/Producers: They provide the service and the physical infrastructure it requires (e.g. servers, antennas, dashcams, etc.). For example, a storage provider for Filecoin, a hotspot for Helium, or a transcoder for Livepeer.
Validators/Observer Nodes/Anglers: 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. For example, Filecoin’s storage providers (because they also verify other providers’ storage proofs) and Helium’s hotspots and oracles (perform other hotspots’ proofs of coverage).
Computation layer: tracks the flow and status of work/services provided and corresponding payments. Note that protocols themselves define the computation logic, such as how work and payments are tracked and stored 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 validators).
Gateways: They function as coordinators/balancers between users, service nodes, and manage access or aggregate services (e.g. data in sensor networks), and are also related to the accounting layer. For example, Livepeer’s Orchestrators or the Gateways in the POKT network.
Delegators: can participate in the economy of service or observation nodes through staking.
Roles related to the demand side (such as sales teams) are currently uncommon, and evaluating the costs associated with running a protocol, such as governance costs, is a topic for another article.
Note that not every DePIN has both a delegate and a gateway, nor do all roles need to be separated. For example, Filecoin’s storage providers (SPs) are classified as service nodes and validators, while also operating the Filecoin chain and thus also forming an accounting layer. The same is true for Arweave miners.
Step 2: Evaluate cost components
Each of the above roles can be performed by a node, and its cost can be broken down into any of the following four components (most have more than one):
Hardware/Infrastructure: Costs associated with actual physical infrastructure, such as dashcams
Labor: Costs associated with the time spent setting up and operating the infrastructure
Bandwidth, power, and other operating expenses: Costs associated with data exchange and other operating costs, such as electricity, data center rental
Collateral: The (opportunity) cost of not investing elsewhere
The last point refers to capital costs: it is almost impossible to obtain information on the debt/financing costs associated with these operations on a broad scale. However, there is a section related to capital costs that we can assess: many DePINs follow a staking-for-access (work token) model 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 this amount can be recovered when leaving the network, there is an opportunity cost to holding these tokens compared to investing capital elsewhere.
Our assessment of the cost components would not be complete without also including the costs associated with accounting layer transactions. Assessing this is not simple and depends on several moving parts. Generally, the network decides to what extent to outsource bookkeeping off-chain. But for the settlement layer records and on-chain transactions, there are three options:
Proprietary L1: The network runs its own blockchain. Examples include Arweave, Filecoin and POKT Network. Usually, service nodes and validator nodes also cover this role, which is why the associated costs are also included (however, we try to separate them if possible - see POKT Network in the example).
Proprietary L2, better known as AppChain or Application-Specific Rollup: The costs of Rollup infrastructure (sequencers, etc.) and adjacent infrastructure (block explorers, wallet integrations, etc.) can generally be mapped into these four components. Less clear cases, such as when using a Rollup-as-a-service provider (RaaS), will be mapped into bandwidth and other costs.
Public L1/L2: These outsource the settlement layer, meaning there is no hardware and labor cost to the network. However, service nodes, validators (and users/payers) pay directly (based on usage). There are some challenges in assessing the network-related costs of these transactions, and therefore some limitations: not all transactions are related to the accounting layer, such as swaps or other DeFi transactions, but it is often not easy to separate these transactions. We map these costs to bandwidth and other costs.
Pulling all of these elements together to create a cost estimate is a challenging task. Not only do we need to come up with estimates for each cost component for each actor in the network, as shown in the figure below, we also need to take into account that not all node operators have the same cost structure. Determining an overall cost estimate is more complex than simply multiplying the number of all network node operators by the estimate for one node operator.
Step 3: Evaluate your cost structure
When we talk about cost structure, we are referring to the key differences that affect cost. These key differences make it critical to rely on assumptions. Of course, there is a trade-off: making assumptions simplifies the process, but may sacrifice accuracy. That is, given how many factors are involved, certain assumptions must be made to arrive at a workable theory.
When evaluating your cost structure, there are three main considerations:
Differences in setup: A typical example is that one operator uses bare metal servers and another runs on the cloud (purchased vs. leased). We can usually take these differences into account when we know the respective shares of the entire network. This also involves capital costs in leasing or financing agreements. Assuming there are no capital costs, we recommend ignoring these differences.
Another cost difference is related to the time of purchase (buying storage gets cheaper over time, buying H100s may not) or the location of operation. We propose to account for the time aspect by using current prices. For labor costs, location is important: DePIN can recruit contributors from all over the world, where local wage levels vary widely, and the time invested in these jobs is difficult to assess. Nevertheless, we make a simplifying assumption that all node operators have the same hourly wage in our version of the framework.
Efficiency differences: Node operators can have the exact same setup, but if one runs more identical nodes, they may have lower costs per node due to economies of scale. In our framework, we need to first assess the node distribution of each node operator to account for these effects. Then, to understand and estimate the cost impact, a survey with larger and smaller operators or other available data points (e.g., bulk discounts from promotions) is needed.
Another example is long-term supporters of the network, who progress faster on the learning curve and are therefore more efficient operationally, compared to people who have just joined. Unless we have direct data points from surveys, we would ignore this aspect.
Differences in attribution and calculation: Although node operators are equal on the first two points, they may view their contributions on different cost bases, so the final costs will be different. For example, one person treats their participation as part-time and does not track any time spent, while another treats it as a main business, paying a salary based on time spent on the project. We account for this difference by providing a wider error range for the part-timer side (as they are often underestimated), but assuming the same time investment for each node operation (see also economies of scale effects).
This is related to the benefits of the sharing economy, which is common for DePIN: operators can use the same setup (and therefore also hardware, labor and operational expenses such as bandwidth, electricity, etc.) in multiple networks, such as Livepeer with Ethereum and Filecoin operations, io.net with Render, Filecoin and other GPU networks. For cases where the hardware is critical to the operation, we do not consider cost savings related to the sharing economy. Not only are they difficult to identify, but it is also difficult to quantify which network benefits the most in terms of costs and how to allocate the savings. In accounting terms, we will want to break down the total costs into monthly amounts. To simplify, we assume that we amortize the total amount over the same period throughout the lifetime and allocate the same amount to all node operators every month.
Of course, there are many more nuances, which we explore at greater length in the DePIN repository .
This adds a third dimension to our “execution plan”, creating 60 different combinations to consider:
In summary, while this formula is very comprehensive and gives multiple options for cost structures, it is most useful when applied to multiple different points in time, rather than a static point in time. The most powerful models are those that relate operating costs to the capacity of the network. This allows us to understand the extent to which costs change with changes in capacity or utilization. The capacity of a network is related to the services provided by the network, such as the number of RPC requests for Pocket, the amount of storage for Arweave or Filecoin, or the percentage of the road network mapped for Hivemapper.
Note that this formula requires a lot of publicly available information, which we recommend obtaining through documentation available on the web, forum/Discord posts, and, if possible, surveys.
Conclusion and Next Steps
As DePIN evolves at an increasing pace, estimating the various DePIN cost components is challenging. In addition to known power laws regarding hardware costs and capacity over time, estimating cryptocurrency specific costs, such as gas and throughput capacity of the settlement layer, is also not a simple task.
Knowing how current costs relate to reward issuance and demand-side revenue, how the largest cost drivers change as assumptions change, and how costs increase as demand increases are all useful metrics.
To help guide governance decisions about DePIN economic design, cost estimates need to be tied to reward issuance and usage revenue. While I plan to provide more examples of cost estimates for DePINs, I welcome feedback on the proposed framework, its assumptions and summary, and potential improvements to the cost estimates provided.
Appendix - Example Framework
Livepeer
Livepeer provides decentralized video infrastructure for live and on-demand streaming. Recently, Livepeer started enabling idle GPU resources for AI model training use cases ( read more here ).
A step-by-step process for applying the framework is provided here . Most cost estimates are based on surveys conducted with node operators (i.e., orchestrators) in summer 2023 and community information ( 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 approximately the same share (~40%). If the uncertainty of the labor cost estimate described in the table is taken into account, the monthly cost of the networks 100 Orchestrators, their transcoders, and settlement costs on Arbitrum is approximately $40,000, which is at the lower end of the estimated range. It is worth noting that the monthly cost of $40,000 is not far from the current fee income of approximately 5-10 ETH per month (corresponding to an ETH price of $3,000-4,000). However, Orchestrators do not have negative profits because a larger portion of their income actually comes from staking rewards.
It is worth noting that since Livepeer transactions are settled on Arbitrum, the cost of the settlement layer is in the range of 0.5-2 ETH per month. This is a cost savings of over 95% compared to the situation in Q1 2022 before Arbitrum migrated. In addition, transactions on Livepeer have grown 2-3 times as of today. Relatively speaking, the accounting layer now accounts for ~5% of total costs, while it was a major cost driver before the migration (accounting for ~80% of total costs).
Recently, the algorithm that determines how work is distributed was adjusted to place more emphasis on the price per pixel provided by the Orchestrator. This has put downward pressure on transcoding prices and may help boost demand, but discussions in the forum suggest that price levels need to be lowered further. On the other hand, the recent launch of AI-subnets may help add further monetization avenues for the network.
One potential scenario in the estimation spreadsheet is that a 3x increase in the need for transcoding minutes would only increase overall costs by 20%. It is important to note that bandwidth is the primary driver of cost increases.
If we assume similar price levels ($3,000 for 1 ETH), this should be enough to bring the network into breakeven territory. However, if transcoding prices dropped by 50%, network-level fee revenue would be around $45,000 per month, thus below the lower end of the cost estimate. It remains to be seen how the cost and revenue dynamics on the Livepeer network will change as new use cases such as AI video generation emerge (thus increasing monetization opportunities).
POKT
At its core, the POKT Network provides decentralized remote procedure call (RPC) endpoints. Recently, the POKT Network announced that it will expand to more use cases around AI model inference. The framework for step-by-step application is as follows . Most cost estimates are based on a survey conducted with node operators in the summer of 2023 and subsequent interviews with these node operators and gateway operators.
Based on ~15,000 nodes providing RPC endpoints and four gateway operators, we estimate that the POKT network currently costs ~$200k per month (+/- $80k) to serve ~500 million relays per day. The largest portion by far is serving nodes (~75% of the cost).
Since we have access to historical data on the number of active nodes in the network, and have data points for different cost components over time, we can put the network cost estimate on a timeline, showing the points at which the three larger cost reductions were addressed:
After entering the bear market in mid-2022 and reducing token rewards (especially USD-based token rewards), node consolidation
Network-wide rollout of improvements such as Geomesh and LeanPOKT, which significantly reduce operational costs, as well as individual improvements to setup for node operators
Decentralizing the gateway role reduces bandwidth costs by making gateway setup simpler
Since our cost framework ties cost estimates to network capacity and demand, we can evaluate changes in the cost structure. For example, if demand increases from the current 500 million per day to, say, 2.5 billion relays per day, then gateways would represent 60% of the total cost base, or about $400,000 per month (compared to about $200,000 currently). Note that this is a 2x increase in cost for a 5x increase in demand. This is because service nodes are able to improve their setup so that they can meet the increased demand at essentially the same cost base.
If we further assume that the share of new gateways operating on a lower cost basis increases to, say, 50% of the total trunks served (currently 30%), then the overall network costs would be $300,000 per month.
With the decentralization of gateways, gateway operators can individually define their price points. If we assume an average price of $4 per million requests, the POKT network as a whole would earn $300,000 per month, thus essentially breaking even.
Dfinity/ICP
Dfinity/Internet Computer Protocol (ICP) is designed as a blockchain of blockchains that provides computing resources for executing smart contracts (called canisters), which are organized in subnets (details https://internetcomputer.org/whitepaper.pdf ). The backbones are node machines that provide storage, computation, and bandwidth to replicate all canisters, states, and computations of their subnets.
The framework for step-by-step application is shown here Most cost estimates are based on data from documentation and forum posts.
ICP is one of the few networks that incorporates fiat-based costs into the token reward mechanism, which makes cost assessment easier. There are currently about 1,400 node machines running by about 85 operators. We have no data points for economies of scale for larger operators, so our overall estimate range is quite wide: the cost of operating the ICP network per month is about $400,000 to $900,000, with an average of about $600,000.
While a proper revenue assessment deserves a separate article, we estimate current monthly revenue to be around $25,000. This may seem low compared to estimated costs, but this is due to low utilization: with only 559 node machines active, we estimate current demand (expressed in terms of cycle burn rate) to be around 2% of total capacity. This means that the network could sustain, for example, a 25x increase in demand and still not increase the current cost base. One forum post actually estimates that demand will reach 15-25x over the next two years, which would then (all else being equal) result in ICP earning those fees monthly.
DIMO
DIMO is a decentralized network that gives drivers the ability to manage their vehicle data. At the same time, DIMO enables businesses and developers to build innovative mobility-related applications (and then profit from them). Data measurement is done through special devices (Autopi, Macaron) or apps. While the DePIN example above is a digital resource network, DIMO is the first example of a physical resource network included in this analysis.
The framework for step-by-step application is shown below . Most cost estimates are based on online (equipment) price information, Dune data, and forum posts.
For the settlement layer, we assume that half of the $0.6-$1.5 spent per connected car in Q1 2024 on average can be attributed to DIMO operations. For the gateway, we assume monthly hardware costs of approximately $4,000 and labor costs associated with the above operations of approximately $11,000 per month. Overall, this adds up to approximately $180,000 in monthly expenses as shown in the table below. Most of the costs are related to bandwidth and other costs, with approximately 1/3 related to settlement costs on Polygon and another 2/3 related to the monthly cost share of smart car integration.
We have no clue about the actual revenue of the network, but estimates using the global car data market and related car data revenues show that the current revenue per car is about $150-$185, which could grow to $500-$600 by 2030. If DIMO can capture 10-15% of this, the revenue generated would be in the range of $110k-$180k per month, covering the operating costs.
However, data monetization itself does not seem to be an actual protocol goal; instead, DIMO focuses on providing infrastructure to build 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 under discussion 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 feedback and comments.
*Standard project is a 1kx portfolio.
