1kx: How to estimate the cost of DePIN projects to better create a growth flywheel

Compiled by: Elvin, ChainCatcher 

Summary

A 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, the key decision about cost optimization is obvious. For example, Livepeer's switch from Ethereum to Arbitrum in 2022 was a good choice without controversy, and thus reduced settlement costs by more than 95%. In other cases, DePIN managers may need external help to assess the cost of operating a node when they have limited R&D resources.

• If nodes continue to lose money, operators will stop running nodes, resulting in a reduction in the 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 R&D efforts to reduce costs for node operators before the network service supply begins to decline.

• For protocol managers, estimating network operating costs can be difficult 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:

1. Define network contributors, which can be targeted to specific roles

2. Identify node-related cost components

3. Consider differences in cost structures when evaluating combinations of 1 and 2

In addition to an overall estimate of current costs, the framework provides:

• A breakdown by role and cost component to help identify the biggest cost drivers

• How estimates change under different assumptions and scenarios for increasing demand/network capacity

Case studies demonstrate how to apply the framework. For example, a joint survey with the POKT network revealed ongoing struggles by node operators to further scale service nodes. Nonetheless, remaining barriers to economic scalability (including demand generation) are addressed by decentralizing their gateways.

Introduction: What is DePIN and why are we talking about costs

DePINs are a family 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. a 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 Digital Resource Networks (DRNs), contributors direct 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 a lot of initial interest due to their token framework design. For example, Helium rewards contributors with HNT tokens for helping run wireless networks via 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 an incentive to operate the DePIN infrastructure. Therefore, the DePIN founding team must help node operators optimize costs.

DePIN Flywheel

A typical flywheel for the DePIN token economy is as follows:

• Build the supply side of services, such as storage or 5G antennas

• Inflationary token rewards incentivize node operators to provide the required infrastructure, even if demand is not yet sufficient to cover costs

• Over time and as demand grows, monetizing network activity may increase node operator revenues, even as token rewards taper off

• Continued monetization of network activity and increased node operator revenues further incentivize supply, creating the DePIN flywheel

A visual representation of the DePIN flywheel is as follows:

As we described earlier in our analysis of reward issuance schedules, 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 may look something like this:

So, how do reward issuance relate to costs?

As mentioned above, if the 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 DePIN's operating expenses are paid in fiat currency, which makes the dollar value of the token rewards important and tied to overall market performance. Despite any well-planned token issuance measures, in the worst case, the situation may turn out like this:

This will cause node operators to exit, which will further translate into higher latency, lower reliability, and worse user experience. Ultimately, stagnant demand will close the flywheel.

The good news is that there are many ways to deal with this situation. 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 the DePIN network and its biggest drivers, you can initiate governance discussions and R&D 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 typically tracked on-chain, other costs involved in running a node are not public (e.g. infrastructure fees). This means we need to use assumptions and estimates about available data points.

In this post, we will address this challenge and introduce 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 for managers of the DePIN network as a methodology for evaluating 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 aggregate them to arrive at 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 services and the physical infrastructure they require (e.g. servers, antennas, dashcams, etc.). For example, Filecoin’s storage providers, Helium’s hotspots, or Livepeer’s transcoders.

• Validators/Observer Nodes/Anglers: They check the work done by the 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 provided work/services 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’ll discuss this in more detail in another post). For example, Livepeer’s Arbitrum or the 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, Orchestrators in Livepeer or 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 not common at the moment, and evaluating the costs associated with running the protocol, such as governance costs, is a topic for another article.

 Note that not every DePIN has both delegation and gateways, 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 therefore 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 the actual physical infrastructure, e.g. dashcams

• Labor: Costs associated with time spent setting up and operating the infrastructure

• Bandwidth, Power, and Other OPEX: Costs associated with data exchange, and other operational costs, e.g. power, datacenter rent

• Staking: (Opportunity) cost of not investing elsewhere

The last point refers to capital costs: it is nearly impossible to obtain information on the debt/financing costs associated with these operations on a broad scale. However, there is a portion related to capital costs that we can evaluate: 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 including the costs associated with accounting layer transactions. Assessing this is not simple and depends on several moving parts. Generally speaking, the network decides to what extent to outsource bookkeeping off-chain. But for the settlement layer record keeping 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 also included (however, we try to separate them when possible - see POKT Network in the example).

• Proprietary L2, better known as appchains or application-specific rollups: The costs of the 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 are no hardware and labor costs for 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 not usually easy to separate these transactions. We map these costs into bandwidth and other costs.

Putting 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 role 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 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, this 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 come up with a working theory.

When evaluating 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 corresponding shares of the entire network. This also involves the capital cost in a lease or financing agreement. Assuming there is no capital cost, we recommend ignoring these differences.

• Another cost difference is related to the time of purchase (buying storage gets cheaper over time, buying H100s might not) or the location of operation. We suggest 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 exactly the 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 in operation, compared to people who have just joined. Unless we have direct data points from a survey, we ignore this aspect.

• Differences in attribution and calculation: Although node operators are equal on the first two points, they may view their contribution on a different cost basis, so the final costs will be different. For example, one considers their participation as part-time and does not track any time spent, while another considers it as main business and pays a salary based on time spent on the project. We account for this difference by providing a wider error margin for the "part-timer" side (as they are usually underestimated), but assuming the same time investment for each node operation (see also economies of scale effect).

This is related to the benefits of sharing economy, which is common for DePIN: operators can use the same setup (and therefore also hardware, labor and bandwidth, electricity, etc. operating expenses) 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 the cost savings related to 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 cost into monthly amounts. To simplify, we assume that we amortize the total amount over the lifetime with the same period, and assign the same amount to all node operators every month.

Of course, there are 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 to apply it to multiple different points in time, rather than one static point in time. The most powerful models are those that tie operating costs to network capacity. 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 web-provided documentation, forum/Discord posts, and, if possible, surveys.

Conclusion and Next Steps

As DePINs evolve at an increasing pace, estimating the cost components of various DePINs is challenging. Beyond the 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 matter.

Knowing how current costs relate to reward issuance and demand-side revenue, how the largest cost drivers change with changing assumptions, and how costs increase with increased demand are all useful metrics.

To help guide governance decisions about the economic design of DePINs, 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 - Illustrated 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 (see here for details).

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 about $85,000 per month. A detailed breakdown of the average cost shows that hardware and labor account for about the same share (about 40%). If the uncertainty of the labor cost estimate described in the table is taken into account, the monthly cost of the network's 100 Orchestrators, their transcoders, and settlement costs on Arbitrum is about $40,000, which is at the lower end of the estimated range. It is worth noting that $40,000 per month in costs is not far off from current fee revenue of around 5-10 ETH per month at an ETH price of $3,000-4,000. However, Orchestrators do not have negative margins as a larger portion of their revenue actually comes from staking rewards.

It is worth noting that since Livepeer’s transactions are settled on Arbitrum, the settlement layer costs are in the range of 0.5-2 ETH per month. This is a savings of over 95% compared to what it was in Q1 2022 before Arbitrum migrated. Additionally, transactions on Livepeer have grown 2-3x as of today. Relatively speaking, the accounting layer now accounts for ~5% of total costs, whereas it was a major cost driver before the migration (~80% of total costs).

Recently, it adjusted the algorithm that determines how work is allocated to place more emphasis on the price per pixel provided by 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 reduced further. On the other hand, the recent launch of AI-subnets may help add further monetization paths to the network.

One potential scenario in the estimation spreadsheet is that a 3x increase in demand for transcoding minutes would only increase overall costs by 20%. It is worth noting that bandwidth is the main driver of cost increases.

If we assume similar price levels ($3,000 for 1ETH), 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, and therefore below the lower end of the cost estimates. 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 of the 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 and four gateway operators providing RPC endpoints, we estimate that the POKT network currently costs ~$200,000 per month (+/- $80,000) 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 estimates on a timeline, showing the points at which three larger cost reductions were addressed:

• Node consolidation following the bear market into mid-2022 and reductions in token rewards (particularly USD-based token rewards)

• Network-wide rollout of improvements such as Geomesh and LeanPOKT, which significantly reduced operating costs, as well as individual improvements to setup by node operators

• Decentralized gateway role reduces bandwidth costs through the addition of simpler gateway setups

Since our cost framework ties cost estimates to network capacity and demand, we can assess changes in 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 account for 60% of the total cost base, which is about $400,000 per month (currently about $200,000). Note that this is a 2x increase in cost, while demand is growing 5x. This is because the Service Nodes are able to improve their setup so that the increased demand can be served on essentially the same cost basis.

If we further assume that the share of new gateways operating on a lower cost base increases to, say, 50% of the total number of relays 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 scenario for the POKT network as a whole would be to earn $300,000 per month, and therefore essentially break even.

Dfinity/ICP

Dfinity/Internet Computer Protocol (ICP) is designed as a "blockchain of blockchains" that provides computational resources for executing smart contracts (called canisters), which are organized in subnets (https://internetcomputer.org/whitepaper.pdf). The backbones are node machines that provide storage, computation, and bandwidth to replicate all canisters, state, and computation 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 operated by about 85 operators. We have no data points for economies of scale for larger operators, so our overall estimate ranges quite broadly: 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 the estimated costs, but this is due to low utilization: with only 559 node machines active, we estimate current demand (expressed in terms of periodic burn rate) to be around 2% of total capacity. This means that the network could withstand, for example, a 25x increase in demand and still not increase the current cost base. One forum post actually estimates that demand will be 15-25x over the next two years, which would then (all else being equal) result in ICP earning these 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 applications. 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 (device) price information, Dune data, and forum posts.

For the settlement layer, we assume that half of the $0.6-$1.5 spent per average connected car in Q1 2024 can be attributed to DIMO operations. For the gateway, we assume ~$4,000 in hardware costs per month and ~$11,000 in labor costs associated with the above operations. Overall, this adds up to ~$180,000 in monthly expenses as shown in the table below. Most of the costs are related to bandwidth and other costs, with ~1/3 related to settlement costs on Polygon and another 2/3 to the monthly cost share of smart car integration.

We have no clues 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 earn 10-15% of this, the revenue generated would range from $110k-$180k per month, covering 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. 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 feedback and comments.

*Standard projects are 1kx portfolios.