Key Takeaways
What are DePINs and why talk about costs
The framework to come up with a cost estimate:
Step 1: Identify network contributors
Step 2: Assess cost components
Step 3: Evaluate differences in cost structures and aggregate
Examples

• To ensure continued participation of nodes in a Decentralized Physical Infrastructure Network (DePIN), it is crucial for network stewards (founders, DAO members, etc) to consider costs incurred by operators when running nodes.

• In some cases, key decisions on cost optimization are straightforward. For example, Livepeer switched from Ethereum to Arbitrum in 2022, an uncontested choice which reduced settlement costs by more than 95%. In other cases, DePIN stewards with limited R&D resources may benefit from external help to evaluate the costs of running nodes.

• If nodes operate at a continued loss, operators will stop running them, decreasing the overall node supply. Knowing the cost of operating a DePIN network and its largest drivers can equip network operators to kickstart governance discussions; simultaneously, cost estimates may inform R&D efforts to reduce node operator costs prior to the supply of network services starting to degrade.

• Estimating the costs of network operations may be difficult for protocol stewards given the anonymity of contributors (these networks are often permissionless, meaning anyone can contribute and come/go at will) and the lack of public data related to costs.

• To guide stewards’ decisions,  we propose a framework with three steps to estimate costs:

• Besides the overall estimate of current costs, this framework gives:

  1. A breakdown per role and cost component, helping to identify the largest cost drivers

  2. Indications of how this changes with different assumptions underpinning the estimates and scenarios on increasing demand/network capacity

• Examples serve as a walkthrough of how to apply this framework. For instance, a joint survey with the POKT Network revealed continued efforts by node operators to further scale service nodes. That said, the remaining block for economic scalability (including demand generation) was tackled with the decentralization of their gateway.

DePINs are decentralized networks of nodes providing hardware resources (physical infrastructure) for a wide range of use cases like compute, storage, wireless networks, or data measurement. DePINs leverage Web3 incentive models (ie, token reward systems) to incentivize the buildup of physical infrastructure networks. As of May 2024, the market capitalization of all DePIN tokens was $29B.

DePINs contribute to both digital and physical resource networks:

• In Physical Resource Networks (PRN), contributors deploy location-dependent hardware to offer (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 (DRN), contributors direct hardware to offer (fungible) digital resources where the physical location is not the main criteria. This includes:

Early DePIN projects generated substantial initial interest due to their token framework designs. For instance, Helium rewards contributors with HNT tokens to help run the wireless network via hotspots, and Filecoin allows users to rent out their excess storage space. While this was sufficient to get many DePIN projects off the ground, token emissions may not be enough to guarantee the long-term participation of nodes in networks.

If running a node becomes unprofitable, node operators will no longer be incentivized to operate DePIN infrastructure. It is therefore essential for DePIN founding teams to help optimize costs for node operators.

The typical flywheel for the DePIN token economy goes like this:

1. Build up the supply side for services, e.g., storage or 5g antennas

2. Inflationary token rewards incentivize node operators to provide the required infrastructure while demand isn’t yet sufficient to cover costs alone

3. Over time, as demand picks up, monetizing network activity may increase node operators’ income even as token rewards decline

4. Continued monetization of the network activity and increase in node operator income further incentivize the supply, thus creating the DePIN flywheel

A visual depiction of what the DePIN flywheel should look like:

As we described in our analysis of the reward emission schedules, the dollar values of those token rewards (the token prices) are heavily influenced by overall market sentiment. Hence, they might look like this:

Or this, depending on when you enter the bull market:

So, What do Token Reward Emissions have to do with Costs?

As mentioned above, if token rewards and income from user demand do not suffice to break even, node operators may decide to stop supporting the network. A large part of operational bills for DePINs are paid in fiat, which makes the dollar value of token rewards important and tied to general market performance. Despite any measure of well-planned token emissions, dynamics could look like this in a worst-case scenario:

This would lead to node operators falling off, which would translate into higher latency, lower reliability, and worse user experience for the end-user. Eventually, stagnating demand would turn off the flywheel.

The good news is that there are many ways to counter this. One way is to make the token emissions more flexible so they are more in line with the monetization of the network (see KPI-based emissions here). The other way is to tackle costs in order to make the overall network more efficient and hence less sensitive to decreasing token prices. Our dynamic would then look like this:

Key Proposition: If you know the cost of operating your DePIN network and its largest drivers, you can kickstart governance discussions and R&D efforts in order to reduce node operator costs before the supply of network services degrades.

Given the decentralized and permissionless nature of DePINs, assessing the cost base is no easy task. While token-based rewards and income are often tracked on-chain, other costs involved in running a node aren’t public (e.g. infrastructure bills). This means we need to use assumptions and estimates around the available data points.

In this article, we will tackle this challenge and walk you through the framework to come up with an estimate

• Step 1: Network contributors

• Step 2: Cost components

• Step 3: Evaluate cost structures of network contributors

We propose the following framework for stewards of DePIN networks as a methodology to assess the operational costs involved in running infrastructure nodes.

Using this framework, the cost estimation of DePINs is broken down into three steps:

1. Identify network contributors

2. Assess cost components (e.g. hardware, labor)

3. Evaluate cost structures for the above and add it up to derive the overall cost estimate

Step 1: Identify network contributors

Despite the various services DePINs provide (e.g. compute, network coverage, mobility data, etc), the roles needed to provide these services are the same (see here for an overview of DePIN supply side roles in 30+ networks):

• Service nodes/producer: they provide the service and its required physical infrastructure (e.g. servers, antennas, dashcams, etc). Examples include storage providers for Filecoin, Hotspots for Helium, or Transcoders for Livepeer.

• Validators/watcher nodes/fishermen: they check the work done by service nodes, either directly or via the accounting layer. The result of those checks is then sent to the accounting layer. Examples include storage providers for Filecoin (as they also validate storage proofs of other providers) and Hotspots and Oracles for Helium (performing the proof of coverage of other hotspots).

• The accounting layer: this tracks the flow and status of work/services provided and corresponding payments. Note that protocols define the accounting logic themselves, e.g. how work and payments are tracked and stored on the blockchain (we will examine this in a separate article). Examples include Arbitrum for Livepeer or the POKT-chain for POKT network (operated by POKT validator nodes).

• Gateway: they function as an orchestrator/balancer between users, service nodes, and also the accounting layer when it comes to managing access or aggregating services (e.g. data in sensor networks). Examples include Orchestrators for Livepeer or the Gateways in POKT network.

• Delegators: can participate in the economies of service - or watcher nodes, via staking.

Roles related to the demand side (such as sales teams) are not common yet and assessing the costs related to running the protocol, like governance costs, is a topic for a separate article.

Note that not every DePIN has delegation and gateways, nor do all roles need to be separated. For example, Filecoin storage providers (SP) are classified as both service nodes and validators and also operate the Filecoin chain, therefore also forming the accounting layer. The same applies to Arweave miners.

Step 2: Assess cost components

Each of the aforementioned roles can be performed via nodes whose costs come in any of the following four components (most have more than one):

• Hardware/infrastructure: costs related to the actual physical infrastructure, e.g. dashcam

• Labor: costs related to time spent in setting up and operating the infrastructure

• Bandwidth, power and other OPEX: costs related to data exchange as well as other operational costs, e.g. power, datacenter rental

• Staking: the (opportunity) cost of not investing elsewhere

The last point refers to the cost of capital: Obtaining information around debt/financing costs related to those operations is almost impossible on a broad scale. Yet, there is one part related to capital cost which we can assess: many DePINs follow the stake for access (work-token) model and require node operators to stake some tokens in order to be allowed to contribute. Acquiring these is an investment and even if we assume that this amount can be retrieved back when leaving the network, there is opportunity cost in holding these tokens vs. investing capital somewhere else.

Our evaluation of cost components would be incomplete without touching on costs related to transactions on the accounting layer. Evaluating this is not straightforward; it depends on several moving pieces. In general, networks decide the extent to which they aggregate book-keeping off-chain. But for track records of the settlement-layer and transactions on-chain, there are three options:

• Proprietary L1: The network operates its own blockchain. Examples are Arweave, Filecoin and POKT Network. Typically service and validator-nodes also cover this role, which is why the associated costs are included there as well (however, if possible, we try to separate them -  see POKT Network in the examples).

• Proprietary L2, better known as app-chain or app-specific rollup: The costs for the rollup infrastructure (sequencers, etc) and adjacent infrastructure (block explorers, wallet integration, etc.) are typically mappable into the four components. Less clear cases, e.g. when using rollup-as-a-service provider (RaaS), will be mapped into Bandwidth and other costs.

• Public L1/L2s: These outsource the settlement layer, meaning there is no cost for hardware and labor to the network. However, service- and validator-nodes (and users/payers) pay directly (usage based).  Assessing the network related costs for those transactions has some challenges and consequently limitations: not all transactions are related to the accounting layer, e.g. swaps or other DeFi transactions, yet it is often not trivial to separate these transactions. We map these costs into Bandwidth and other costs..

Putting all of these pieces 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 our network, like in the diagram below, we also need to consider that not all node operators have the same cost structure. Determining the overall cost estimate is more involved than simply multiplying the number of all network node operators by the estimate derived for one node operator.

Step 3: Evaluate cost structures

When we speak of cost structures, we refer to the key differences which impact cost. These key differences make it essential to rely on assumptions. Of course, this is a tradeoff: making assumptions simplifies the process, which can come at the expense of accuracy. That said, given how many factors are involved, certain assumptions must be made in order to achieve a working theory.

There are three primary considerations when evaluating cost structure:

1. Differences in setup: a typical example is one operator using a bare metal server vs.another one running on cloud (buy vs. rent). We can typically account for such differences when we know the corresponding shares across nodes of the overall network. It also relates to cost of capital when leasing or finance agreements are made. We recommend ignoring those differences and assume no cost of capital.
   
   Another difference in costs relates to the time of purchase (buying storage gets cheaper over time, buying H100s might not) or the location of operation. We recommend accounting for the time aspect by using current prices. For labor costs, the location matters: DePINs can source their contributors from all over the world with widely varying local wages for the (hard to assess) time invested. That said, we make the simplifying assumption of a general hourly wage across all node operators in our version of this framework.

2. Differences in efficiency: node operators can have the exact same setup, yet if one runs a lot more of the same nodes they likely have lower costs per node due to economies of scale. In our framework, we need to assess the distribution of nodes per node operator as a first step to account for these effects. Sizing those effects then needs a survey with larger and smaller operators or other available data points (e.g. promoted bulk discounts) to understand and estimate the cost impact.
   
   Another example are long term supporters of a network who are further along the learning curve and hence more efficient in their operations compared to someone who just joined. Unless we have direct data points from surveys, we ignore this aspect.

3. Differences in attribution and accounting: node operators being equal with respect to the two previous points could still view their contribution differently and hence end up with a different cost base. For example, one considers their engagement as a side-hustle not tracking any time spent whilst the other as their main business paying a salary based on the time spent on the project. We account for such differences via wider error margins for the “side-hustlers” side (given they are typically underrepresented), but assume similar time invested per node operated (see also economies of scale though)

There are, of course, more nuances , which we will dive into in a longer piece in our DePIN repository soon.

This adds the third dimension to our “execution plan”, creating sixty different combinations to consider:

Overall, while this formula is extremely comprehensive, leaving you with multiple cost structure options, it is most useful when also applied at several different points in time vs one static. The strongest model is one which ties the cost of operations to the capacity of the network. This enables us to understand the extent to which costs change with changing capacity or utilization. The capacity of the network relates to the service offered by the network, e.g. # of RPC requests for Pocket, TB of storage for Arweave or Filecoin, or percentage of road-network mapped for Hivemapper.

Note that this formula requires a lot of publicly available information, which we suggest obtaining  via documentation provided by the networks, from forum-/discord posts and, if feasible, surveys².

As DePIN is evolving at an increased pace, estimating the cost components of various DePINs is challenging. Besides known power laws on hardware costs and capacity over time, it’s not straightforward to estimate crypto-specific costs, e.g., gas and throughput capacity for settlement layers.

Knowing how current costs relate to reward emissions and demand side income, how the largest cost drivers change based on assumptions, and how costs increase with increasing demand are all useful indications

To help guide governance decisions around the economic design of DePINs, cost estimates need to be related to reward emissions and to income from usage. While I plan to provide more examples for cost estimates of DePINs, I welcome feedback on the presented framework, its assumptions and simplifications, as well as on the potential improvements to the cost estimates provided.

If you would like to walk through such an estimation together, please reach out to me.

A special thank you to my contributors: Mihai (Messari), Raullen (IoTeX), Nodies Team, Grove Team, Pocket Network Foundation, the DIMO team, Diana Biggs, and Christopher Heymann for feedback and input.

* denotes 1kx portfolio companies

Disclaimer: This article is for general information purposes only and should not be construed as or relied upon in any manner as investment, financial, legal, regulatory, tax, accounting, or similar advice. Under no circumstances should any material at the site be used or be construed as an offer soliciting the purchase or sale of any security, future, or other financial product or instrument. Views expressed in posts are those of the individual 1kx personnel quoted therein and are not the views of 1kx and are subject to change. The posts are not directed to any investors or potential investors, and do not constitute an offer to sell or a solicitation of an offer to buy any securities, and may not be used or relied upon in evaluating the merits of any investment. All information contained herein should be independently verified and confirmed. 1kx does not accept any liability for any loss or damage whatsoever caused in reliance upon such information. Certain information has been obtained from third-party sources. While taken from sources believed to be reliable, 1kx has not independently verified such information and makes no representations about the enduring accuracy or completeness of any information provided or its appropriateness for a given situation. 1kx may hold positions in certain projects or assets discussed in this article.

The Livepeer Network offers decentralized video infrastructure for live and on-demand streaming. Recently, Livepeer started to enable idle GPU resources for AI model training use cases as well (see details).

The framework applied step by step is provided here. Most cost estimates have been based on this survey conducted with node operators (i.e. Orchestrators) in summer 2023 and community information (like this).

The total estimated costs of operating the Livepeer network are about $85k per month. The breakdown of average costs shows that hardware and labor account for about the same share (~40%). If we account for the uncertainty around the labor cost estimates described in the spreadsheet, the monthly costs for the 100 Orchestrators of the network, their transcoders and settlement costs on Arbitrum add up to about $40k on the lower range of estimates. Notably, the $40k monthly cost is not too far from being offset by the current fee income of approximately 5-10 ETH per month ($20-40k at the corresponding ETH prices of  $3-4k). However, Orchestrators do not have a negative PnL, since a larger share of their income is actually from staking rewards³.

Notably, the accounting layer costs are in the range of 0.5-2 ETH per month since Livepeer’s transactions settle on Arbitrum. This is a >95% cost saving compared to prior to the Arbitrum migration in Q1 2022. Additionally, as of today, transactions on Livepeer grew 2-3x vs. prior to the Arbitrum migration. In relative terms, the accounting layer now accounts for ~5% of the costs, in contrast to being a major cost driver prior to the migration (~80% of costs).

Recently, the algorithm determining how work is distributed was adjusted, putting more weight on the price per pixel offered by the orchestrator. This puts downward pressure on transcoding prices and may consequently help fostering demand (see here), yet discussions in the forum show that price levels need to decrease even further. On the other hand, the recently launched AI-subnets might help adding further monetization avenues for the network.

A potential scenario in the estimation spreadsheet is a 3x in demand for minutes transcoded would only increase the overall cost by 20%. Notably, bandwidth is the main driver of the cost increase.

If we assume similar price levels (with 1ETH at $3k), this should suffice to bring the network into the breakeven region. However, should transcoding prices drop by 50%, the network-level fee income would be around $45k/month, thus below the lower end of cost estimates. With new use cases like AI-video generation in sight (and hence increased opportunities for monetization), it remains to be seen how cost and income dynamics on the Livepeer Network will change.

At its core, the POKT Network provides decentralized remote procedure call (RPC) endpoints. Recently, POKT Network announced its expansion into further use cases on AI model inference.

The framework applied step by step is provided here. Most cost estimates have been based on this survey conducted with node operators in summer 2023 and follow-up interviews with those and gateway operators.

Based on the ~15k nodes providing RPC endpoints and four  gateway operators providing access to those, we estimate that the POKT Network currently costs about 200k/$ per month (+/- 80k $) to serve about 500 M relays per day. The largest part currently is the service nodes (~75% of costs).

Since we can access historical data for the number of nodes active in the network and have different data points for cost components over time we can lay the network cost estimation on a timeline, showing three points when larger cost reductions have been tackled:

1. Node consolidation after token rewards (and esp. dollar based token rewards) have been reduced with the transition into the bear market mid 2022

2. Network-wide rollout of improvements like Geomesh and LeanPOKT significantly reducing operating costs as well as individual improvements on the setup by node operators

3. Decentralization of the gateway role reducing bandwidth costs by adding simpler gateways setups

Since our cost framework ties the cost estimates to the network capacity and demand, we can assess how the cost structure changes. For instance, if demand increases from currently 500M to e.g. 2.5 B relays per day, then the gateways make up 60% of a total cost base of ~400k $/month (vs. 200k currently). Note that this is a 2x in costs vs. a 5x in demand. This is due to the fact that service nodes were able to improve their setups, so increasing demand can be served at basically the same cost base. If we further assume that the share of new gateways operating at a lower cost base on the overall number of relays served increases further (currently 30%) to e.g. 50% then the overall network costs are 300k $/month.

With the decentralization of gateways, gateway operators can define their price points individually. If we assume an average price of $4 per million requests for the scenario the POKT Network as a whole would earn 300k $/month, so pretty much break even⁴.

Dfinity / the internet computer protocol (ICP) is designed as a “blockchain of blockchains”, providing compute resources for the execution of smart contracts (called canisters), organized in subnets (see details). The backbone are the node machines which provide the storage, compute and bandwidth to replicate all canisters, state and computation of their subnet.

The framework applied step by step is provided here. Most cost estimates have been based on data available in docs and forum posts.

ICP is one of the few networks, where fiat-based costs are baked into the token reward mechanism, which makes the cost assessment easier. There are currently about 1400 node machines run by ~85 operators. We don’t have data points on the economies of scale for the larger operators, hence our estimated range overall is quite wide: about 400k to 900k $ in monthly cost to operate the ICP network, average about 600k $.

Whilst a proper income assessment is worth a separate article, we estimate the current monthly revenue to ~25k $. This seems low in contrast to the estimated cost, yet is caused by low utilization: With just 559 node machines active we estimate the current demand (measured in cycle burn rate) is about 2% of total capacity. This means the network could take e.g. a 25x in demand and still not increase the current cost base. A forum post actually estimates a 15-25x in demand over the next two years which then (all else equal) would lead to a state where the ICP earns those monthly costs.

DIMO is a decentralized network that empowers drivers to manage their vehicle data. Simultaneously, DIMO enables businesses and developers to build innovative mobility-related applications (to then monetize on that). The data measurement happens via special devices (Autopi, Macaron) or via App. While the above DePIN examples were digital resource networks, DIMO is the first example  of a physical resource network included in this analysis.

The framework applied step by step is provided here. Most cost estimates have been based on (device) price information online, dune data and forum posts.

For the accounting layer, we assumed half of the average $0.6-$1.5 in gas spent per connected car in Q1 2024 to be attributable to the operations of DIMO. For the gateway, we assumed about $4k per month in hardware and about $11k in labor cost per month related to the operations outlined above. All in all, this adds up to about $180k in monthly expenditures as shown in the table below. The majority of costs are related to bandwidth and other costs, which are ~⅓ related to the settlement costs on Polygon and ⅔  the assumed shares of monthly costs for the smartcar integration.

We do not have indications on the actual income of the network, but some estimation using global market for car data and related revenue from car data shows that this could be around $150-$185 per car currently growing to $500-$600 in 2030⁵. Should DIMO be able to monetize 10-15% of that, the resulting income would range from $110k-$180k per month and thus cover the operating costs.

Yet, data monetization itself appears to be less of the actual protocol goal; instead, DIMO focuses on providing infrastructure to enable apps on top of the network, as reflected in the latest discussions around DIMO nodes and token upgrades. The discussed changes will likely impact the cost structure above.

Footnotes:

1. This probably needs to be revisited when there are more protocols that actively build upon aggregating resources from various other networks. Also, this is not to say we should ignore sharing economy benefits: most DePINs are well positioned to realize those in some form, hence we do account for those in the overall cost estimation (typically affecting all node operators equally). Simple cases occur when the hardware utilized to contribute to the network is widely available, like on smartphones or laptops. If we can assume those devices are not purchased with the network support in mind, then hardware cost can be considered zero. Similar logic is applied for labor cost and cost of bandwidth, power and other OPEX.

2. Some good starting points are depinscan, depinhub, depin ninja and wholovesburritos

3. Orchestrators have about 4-5% of LPT self bound currently and take on average 12% on the remaining delegated staging rewards (see appendix here). Based on the average 2.5M $ worth of staking rewards paid per month this amounts to about 380-400k $ in staking rewards. Since Orchestrators also share on average 40% of transcoding income with their delegates the income from staking rewards is over 95%.

4. Which o/c does not mean all roles and all node operators are break even.

5. According to MarketsAndMarkets study the estimated revenue from car-data is around 1600$ per car by 2035 and 120$ per 2023. This means a CAGR of 24%, so by 2024 we get ~150$ and by 2025 185$ per car.