Multicoin Three Necessary Considerations for Building the DePIN Network – Hardware, Supply Thresholds, and Demand

Multicoin's Three Considerations for DePIN Network - Hardware, Supply, and Demand

Authors: Shayon Sengupta & Tushar Jain, Partners at Multicoin Capital; Translation: LianGuaixiaozou

In April 2022, we published an article about Physical Proof of Work (PoPW), now more commonly referred to as Decentralized Physical Infrastructure Network (DePIN). In the article, we wrote:

“(The PoPW network) incentivizes people to perform verifiable work and build real-world infrastructure. These permissionless and reliable protocols have the following characteristics compared to traditional capital formation for physical infrastructure:

• They can build infrastructure faster – often 10-100 times faster in many cases;

  • Delphi Digital Co-founder ZK May Be the Endgame, Pondering My Unsolved Mystery
  • Microsoft launches AI Copilot for Windows 11
  • Based on the understanding of the exchange business logic, why does Binance’s aggregated wallet need to consume hundreds of ETH?

• They are more adaptable to hyper-local market demand;

• They offer greater cost-effectiveness.”

We were among the first major investors in this view, and since then, we have witnessed a Cambrian explosion of DePIN networks in various fields such as energy, logistics, mapping, telecommunications, and more. Recently, we have observed the emergence of more subcategories around specialized resource networks, particularly in the digital goods space, such as computation, storage, bandwidth, and consumer data aggregation. These networks all have implicit structural costs or performance arbitrage unique to native crypto capital formation.

There is significant overlap in the design models and best practices across DePIN networks. Founders and communities need to consider several key questions when thinking about network design. Should the network hardware be consumer-oriented or require professional installation? How many nodes are needed to attract the first, tenth, or one thousandth paying user? Should the network be completely permissionless or managed through trusted intermediaries?

These decisions must be made early in the network design process and must be made correctly; pivotal decisions often determine the success or failure of DePIN networks, and slight changes in hardware, tokens, distribution, or demand activation layers can have a significant impact on the network’s success.

At Multicoin, we remain bullish on DePIN and anticipate many new category-defining networks entering the market in the coming years. This article will explore the most common trade-offs that DePIN founders and communities consider, aiming to help the next wave of DePIN founders and communities design their networks more successfully. We present three essential considerations for building DePIN: hardware, threshold ranges, and demand generation. For each aspect, we will discuss key questions that provide information support for critical design decisions and outline their broad token design implications.

1. Hardware Considerations

Most DePIN networks align with physical infrastructure (i.e., real-world hardware). However, this is not always the case. Some networks manage virtual resources such as computation, storage, or bandwidth (these networks are sometimes referred to as Decentralized Virtual Infrastructure Networks or DeVINs). But for the purpose of this section, we will assume that your network has real hardware, so you need to answer some key network design questions.

(1) Who manufactures the hardware?

DePIN Network manufactures and distributes its own hardware, giving them greater control over the supply side of the network. They also have privileges to establish direct relationships with contributors, which sometimes leads to a stronger community. However, over time, these companies may become bottlenecks or single points of failure in the manufacturing and distribution process, potentially limiting the network’s scalability.

Another option for manufacturing and distributing your own hardware is to open source your hardware specifications and have the community build it for you. This allows founders and the community to expand the supply side of the network while also dispersing supply chain risks among many companies. Of course, the challenge with this approach is incentivizing third-party manufacturers to build hardware for a new market, which can be difficult and expensive. You also have to consider another factor – hardware quality and support. Assuming you successfully build a reliable hardware manufacturer ecosystem, you still need to maintain quality across devices and support.

Decentralized wireless network Helium is a very interesting case study. They first established their own hotspots to help launch the network, and then quickly open sourced their hardware specifications and incentivized a reliable third-party ecosystem to build hardware for them. Despite having a large network of third-party hardware manufacturers, Helium faced serious supply chain bottlenecks and poor support from some manufacturers during the critical growth phase of the network.

On the other hand, Hivemapper, a decentralized mapping network, chose to build and distribute their own hardware dashcams. This allowed them to have full control over hardware production, enabling them to quickly iterate on the dashcam firmware and achieve faster passive video uploads, accelerating map coverage and increasing the commercial value of the data. The downside is that a single company controlling hardware production introduces centralization risks to the supply chain, which could make it more fragile.

Summary – In general, we observe that if hardware specifications are open source and deployment is permissionless, the DePIN network can scale much faster. When the network is mature enough, it makes sense to have open source hardware development for decentralization and network expansion. However, in the early stages, controlling hardware to ensure quality and support is reasonable.

(2) Is your hardware active or passive?

Some DePIN networks are set and forget, while others require more ongoing user engagement.

For example, in the case of Helium, the time cost of setting up a hotspot is approximately 10 minutes after unboxing. After that, the box just sits there, passively providing coverage to the network without requiring the host to do much additional work. On the other hand, networks like Geobyte (which uses smartphones to decentralized map indoor spaces) require users to actively do something that adds value (capturing videos of indoor spaces using smartphone sensors). For supply side contributors, the time invested in an active network is clearly sacrificing time that could be spent on other revenue-generating activities or, more broadly, a part of life. Therefore, contributors to active networks must earn more income (usually through tokens or network design) to justify their time and opportunity costs. This also means that active networks, due to their design, will take longer to reach threshold ranges compared to passive networks (which we will discuss in more detail below).

One positive aspect is that DePIN networks typically have more loyal and mature contributors because they require a certain level of ongoing participation. On the other hand, the total number of people willing and/or able to contribute to an active network is limited.

In summary, we observe that if contributors pay a one-time cost (time or money) upfront rather than an ongoing cost, DePIN networks are more easily scalable; passive networks are easier to establish and therefore easier to scale.

An active social network does not mean failure; it just requires creative thinking and incentive design. For example, compared to traditional infrastructure networks, active networks such as Geobyte, Dronebase, FrodoBots, and Veris appear more like “eternal games”.

(3) How difficult is it to install hardware?

The difficulty of hardware installation varies for different DePIN networks. Some can be as simple as mounting a box on the wall, while others require professional installers.

In simple cases, players can connect their GPUs to the Render Network (a distributed computing network) by running a bash script. This is ideal because the computing network requires thousands of geographically distributed GPUs with different performance and bandwidth to properly relieve data center loads.

In moderate difficulty cases, installing the Hivemapper dashcam takes 15-30 minutes. To establish a reliable real-time map in a specific geographical area, hundreds of vehicles with Hivemapper installed are needed. Therefore, the upfront time investment for installation must be simple and easy to operate.

In contrast, XNET is building an operator-grade CBRS wireless network, which requires professional installation by local internet service providers and the selection of commercial sites. However, despite this, their network is still expanding as only a few such arrangements are needed to fully cover urban areas and provide data roaming use cases.

In summary, the speed of your network expansion is directly influenced by the difficulty of hardware installation. If your network requires thousands of devices worldwide, you need to make your hardware installation as easy as possible. If your network can quickly expand with just a few nodes, you can focus on introducing professional contributors rather than individual contributors. Generally, when the installation complexity is low enough for ordinary people to easily become contributors, DePIN networks can expand the fastest.

(4) Token design implications

When considering building a network, early supply-side contributors are critical stakeholders that need to be considered. Depending on the hardware decisions you make, supply-side contributors may lean towards ordinary people, professionals, or some “professional consumers” in between.

We observe that professional contributors tend to consider their income in terms of instant returns denominated in US dollars and are more likely to monetize their tokens in the early stages of the network. On the other hand, early retail investors are more likely to focus on long-term results and may want to accumulate as many tokens as possible regardless of short-term price fluctuations.

Networks with more professional contributors can explore alternative solutions to traditional spot token incentives, such as locking tokens or dollar-denominated revenue-sharing agreements.

Regardless of the situation of contributors on the supply side, the supply side of the network must calculate capital investment and operating costs in US dollars when the network matures. Ensure that tokens can reward contributors in the later stages of network maturity while balancing the startup incentives for early adopters, which is tricky but crucial.

2. Consideration of Threshold Range

We use the term “threshold range” to describe when the supply side of the network starts to have commercial viability for the demand side of the network. The DePIN network is essentially disruptive because tokens can be used to incentivize early contributors to deploy infrastructure to the threshold range.

Some networks can meet demand from the beginning with one or a few nodes (e.g., storage and computing markets), while others can meet demand with minimal scale (e.g., wireless networks, logistics and distribution networks). As demand expands by orders of magnitude, the minimum feasible set of nodes required to meet incremental service demand will also expand.

(1) How important is geographical location?

Some DePIN networks do not benefit from physical distribution, while others absolutely require physical distribution. In most cases, if a network needs to coordinate physical resources, it is location-sensitive, so reasoning about the minimum feasible coverage range becomes a fundamental factor in making demand response decisions.

Some networks are heavily dependent on location, while others are location-independent. For example, energy markets like Anode and mapping networks like Hivemapper are heavily dependent on location. Wireless networks like Helium IOT also depend on location, but due to the extensive coverage of hotspots, the degree of location dependence is lower. Bandwidth markets like Filecoin Saturn, Fleek, or Wynd are less sensitive to location because they only require general geographical coverage and do not need nodes in specific locations.

On the other hand, DeVINs (such as Render Network for computing markets or Filecoin for storage markets) are not location-sensitive. In these networks, it is easier to guide supply-side contributor resources to a point in the threshold range because the top of the funnel is not limited by geography.

Conclusion – In general, we observe that if a network is location-sensitive, it should incentivize supply-side contributors to contribute to target regions that are built according to the threshold range, with the goal of opening a serviceable market. Once the goal is achieved, the network should adopt a “land-and-expand” approach and replicate this strategy in other different areas.

(2) How important is network density?

Based on the above view on minimum viable coverage, some DePIN networks have the concept of “network density”, which is usually defined based on the total number of hardware units (or nodes) or specific resources in a specific area.

Helium Mobile is a web3 mobile operator that defines its network coverage as mobile hotspots in each community. Ultra-local density is very important for Helium Mobile because the network requires a huge density of mobile hotspots to provide continuous coverage in an area.

Teleport is a permissionless ride-sharing service protocol that defines density as the number of active drivers available within a 5-10 mile radius of a city hotspot area. Density is important for Teleport because no one wants to wait for a taxi for more than 10 minutes. However, ultra-local density is not important for Teleport because drivers can obviously drive to pick up passengers, while Helium mobile hotspots cannot move to “pick up” user cellular traffic.

Hivemapper defines network density as the number of mappers in a given city, as the network needs enough mappers in a city to provide continuously updated map data. However, Hivemapper does not require the same density as Teleport because map updates can tolerate greater latency than taxi pick-ups and drop-offs.

A simple way to consider density in the context of threshold range is: consider under what circumstances the network can make its first sale or acquire its first demand-side customer with a contributor threshold in a geographic area? The tenth sale or tenth demand-side customer? The one hundredth?

For example, XNET, an anonymous permissionless decentralized mobile operator, may only need 100 large, professionally installed radio devices to serve a city area; however, Helium Mobile’s radio devices are smaller and installed by individual users, requiring more radio devices to cover the same city area – a Helium Mobile network with 100 small base stations has little value, but a Helium Mobile network with 100,000 base stations has significant value. Due to their hardware design decisions, the threshold range for Helium Mobile is higher than the threshold range for XNET.

Summary – in general, we observe that networks with higher density requirements require more contributors to reach the threshold range. In contrast, low-density networks can leverage more complex hardware and/or professional contributors.

(3) Token design implications

We note that due to a combination of location sensitivity or network density requirements, networks with higher threshold ranges require more token incentives to build the supply side of the network. In contrast, networks with relatively lower threshold ranges can flexibly handle their token incentives more conservatively and can disperse them into later threshold range milestones.

In general, there are two common token distribution strategies: time-based strategies and utilization-based strategies. Time-based strategies are best suited for networks with high threshold ranges, while utilization-based strategies are best suited for networks with relatively lower threshold ranges. Helium adopts a time-based token distribution plan, while Hivemapper adopts a distribution plan based on network utilization.

Time-based strategies involve creating tokens and distributing them proportionally based on contributors’ network contributions within a given time period. If the listing time is important for infrastructure development, this is a better choice, and it is crucial to reach the threshold range faster than competitors. If the network is not a pioneer in a winner-takes-all market, a time-based strategy is a good option to consider. (Please note that this approach typically requires a clear roadmap for the network and the allocation of hardware through an elastic supply chain.)

Token distribution based on network utilization is a more flexible mechanism that allows tokens to be distributed based on network growth. Reward mechanisms include providing a large number of tokens at specific locations and times for building the network or providing specific types of resources to the network. The trade-off involved here is that while it preserves the selectivity for the network to distribute tokens to the most valuable participants, it also brings revenue risks to the supply side, which may result in lower conversion rates and higher churn rates.

For example, Hivemapper has mapped 10% of the United States, yet the rewards for mapping contributors account for less than 2% of the total token issuance. Therefore, they can now think about building reward challenges in a very targeted manner to reach the threshold range in specific areas, in order to continue building maps and increase the density of strategic regions.

3. Considerations for demand generation

When the DePIN network reaches the threshold range, they can start seriously selling to the demand side of the network. This raises a question, who is responsible for sales?

The DePIN network only becomes valuable when customers can easily access the aggregated resources of the network. Consumers and businesses usually do not want to buy directly from an unauthorized network, but would rather buy from traditional companies. This creates an opportunity for value-added resellers (VARs) to package network resources into products and services that customers understand and are willing to purchase.

Network creators can also choose to operate a network VAR, a company built on top of the network with customer relationships and everything that comes with it – product development, sales, customer acquisition and retention, ongoing support and service agreements, etc. The advantage of building a VAR on the network is the full price difference between the product sales cost (to customers) and the original resource cost of the network. This approach makes the network full-stack, allowing for tighter product iterations as there is continuous feedback from demand-side customers.

Alternatively, you don’t have to become a VAR or build on top of the network. You can outsource the demand-side relationships to the network ecosystem. This approach allows you to focus on core protocol development but reduces touchpoints with customers, hindering product feedback and iteration.

(1) Choosing to become a network VAR or outsourcing?

Different DePIN teams have conducted research on this question from different perspectives.

For example, Hivemapper is currently the main VAR of the Hivemapper network. They are built on top of network map data and provide enterprise-level logistics and map data through commercial APIs.

In the case of Helium, the Helium mobile network is provided by a VAR (Helium Systems’ Helium Mobile), while the Helium IoT network is provided by a VAR ecosystem (such as Senet) for commercial services, including helping customers deploy hotspots, purchasing sensors and coverage, verifying data packet transmission, and so on.

Unlike Hivemapper or Helium, Render Network outsources the commercialization of network resources to open computing clients, which then resell these resources to institutions and artists engaged in rendering and machine learning work. Render Network itself does not provide proof of computational integrity, privacy guarantees, or handling of specific workloads for data packets or databases; these are provided by third-party clients.

Summary – In general, we observe that layered services or trust guarantees can drive demand. Networks can choose to provide these services themselves, but investing prematurely in these services – before reaching a certain critical mass threshold – will result in wastage of time, energy, and funds. In the case of scale, it is best for these services to be handled by third parties who can customize services to suit their target customers.

We also find that as the network begins to expand and network resources become commercialized, the network typically takes the following forms:

• Phase 1: In the first milestone and around it, the core team manages all aspects of the demand-side relationship. This is to ensure that early users get the highest quality product possible.

• Phase 2: After the first set of milestone ranges, the network can start opening up to third-party ecosystems to resell the network’s aggregated resources. Curating third parties can enter the network and act as intermediaries between the demand and supply sides.

• Phase 3: In a certain stable state, many entities package and sell resources to a variety of network participants. At this stage, the network is a platform for other service companies to directly contact and serve customers, purely acting as a resource layer.

(2) Token Design Implications

If your network relies on specific parties to expand demand generation, assigning protocol incentives to these network participants can be beneficial. Tokens used for third-party demand generation activities are typically milestone-based, and tokens are created to reward all parties when the network and third parties achieve certain common goals. You should always carefully arrange token distribution to partners so that the value they bring to the network is commensurate with the tokens they ultimately receive.

4. Summary

This article discusses the most common questions and considerations we have discussed with founders when exploring new DePIN networks.

We expect to see new, category-defining DePINs emerge in the coming years, and we believe that the core features of token distribution, hardware, milestone ranges, and demand generation are crucial and should be fully explored in order to effectively build up supply-side resources and better serve demand-side customers. These networks are essentially markets, and each trade-off will have ripple effects, either strengthening their inherent network effects or creating competition space for newcomers.

Ultimately, we believe that DePIN is a method to reduce the cost of building critical infrastructure networks through encrypted native capital formation. We believe that in large markets such as telecommunications, energy, data aggregation, carbon removal, physical storage, logistics, and delivery, each network has different trade-offs and the design space is very broad.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!