This article discusses the most common questions and considerations discussed with the founders when exploring the new DePIN network.
Written by: SHAYON SENGUPTA, TUSHAR JAIN
Translated by: DeepTech TechFlow
In April 2022, we published a paper on the Proof of Physical Work (PoPW) network (now more commonly referred to as "Decentralized Physical Infrastructure Network," abbreviated as "DePIN"). In that article, we wrote:
The PoPW network incentivizes people to do verifiable work to build real-world infrastructure. These permissionless and trust-neutral protocols, as compared to traditional capital forms used for building physical infrastructure:
- Can build infrastructure faster—often 10-100x faster in many cases;
- More closely match native market demand;
- May be more cost-effective.
We were the first major institution to invest in this argument, and since then, we have seen the DePIN network explode in a wide range of categories such as energy, logistics, mapping, telecommunications, and more. Recently, we have also observed the emergence of more targeted categories focused on specific-purpose resource networks, specifically for digital goods such as computing, storage, bandwidth, and consumer data aggregation. Each network hides a structural cost or performance arbitrage, uniquely enabled by native capital formation in cryptocurrency.
There is significant overlap in design patterns and best practices within the DePIN network. Founders and communities have several key questions to consider when thinking about network design. Should the network hardware be consumer-facing, or should it guide professional installers? How many nodes are needed to onboard the first paying customer? 10? 1000? Should the network be fully decentralized, or should it be managed through trusted intermediaries?
These decisions must be made early in the network's design, and they need to be right. Hub issues often determine the success or failure of the DePIN network, and small changes at the hardware level, token level, allocation level, or demand activation layer can have a huge impact on the success or failure of the network.
At Multicoin, we remain optimistic about DePIN and expect many new, definitive category networks to launch in the coming years. This article will explore the trade-offs we see DePIN founders and communities most commonly consider, hoping to help the next generation of DePIN founders and communities design networks more successfully. We present three essential considerations for building DePIN: hardware, threshold scale, and demand generation. In each aspect, we discuss key issues that will affect critical design decisions and outline their broad implications for token design.
Hardware Considerations
Most DePIN networks coordinate physical infrastructure—real hardware. However, this is not always the case. Some networks manage virtual resources such as computing, storage, or bandwidth (these networks are sometimes referred to as "Decentralized Virtual Infrastructure Networks" or "DeVIN"). But for the purposes of this section, we assume your network has real hardware, so you need to answer some key network design questions.
Who manufactures the hardware?
DePIN networks that make and distribute their own hardware can better control the supply side of the network. They can also build direct relationships with contributors (sometimes leading to a stronger community). However, over time, these companies face the risk of becoming bottlenecks or single points of failure in the manufacturing and distribution process, which could limit the network's ability to scale.
Another option for making and distributing your own hardware is to open-source your hardware specifications and ask the community to build it for you. This allows founders and communities to expand the supply side while decentralizing supply chain risk. The challenge with this approach is that incentivizing third-party manufacturers to build hardware for a new market is difficult and expensive. Another aspect to consider is hardware quality and support. Assuming you have successfully built a strong hardware manufacturer ecosystem, you still need to maintain quality in devices and support.
Helium is an interesting case study. They initially built their own hotspots to help kickstart the network, then quickly open-sourced their hardware specifications and incentivized a strong ecosystem of third-party hardware builders. Despite having a large number of third-party hardware manufacturers, Helium suffered severe supply chain bottlenecks during critical growth stages, with some manufacturers providing poor support.
On the other hand, Hivemapper (decentralized mapping of indoor spaces using smartphones) chose to build and distribute their own hardware cameras. This allowed them to have complete control over hardware production, enabling rapid iteration of camera firmware and faster enablement of passive video uploads, which in turn accelerated map coverage and the commercial value of data. As a trade-off, having a company control hardware production has a centralized impact on the supply chain, which could make the supply chain more fragile.
Summary —— We note that the expansion speed of the DePIN network is much faster when hardware specifications are open-sourced and deployed without permission. When the network is mature enough, open hardware development to decentralize and expand the network certainly makes sense. However, early control of hardware to ensure quality and support is wise.
Is your hardware active or passive?
Some DePIN networks are set-and-forget, while others require more sustained user engagement.
For example, in the case of Helium, setting up a hotspot takes about 10 minutes from unboxing. After that, the device sits quietly and provides passive coverage to the network without requiring much additional work from the user. On the other hand, networks like Geobyte (decentralized mapping of indoor spaces using smartphones) require users to actively do something to create value (capturing video of indoor spaces using smartphone sensors). For contributors on the supply side, the time invested in active networks clearly sacrifices time that could be devoted to other income-generating activities or simply living. Therefore, contributors to active networks must earn more through tokens or network design (in most cases) to justify their time and opportunity cost. This also means that, due to its design, active networks reach threshold scale (which we will discuss in detail below) slower than passive networks.
On the positive side, because active DePIN networks require some level of sustained engagement, they typically have more committed and knowledgeable contributors to the network. Conversely, this also means that active networks are limited by the number of people willing and/or able to contribute.
Summary —— We note that if contributors pay a one-time cost (time or money) at the outset rather than ongoing costs, the expansion of the DePIN network will be easier; passive networks are easier to set up and therefore easier to expand.
Becoming an active network is not a death sentence; they just require creative thinking and incentive design. For example, active networks like Geobyte, Dronebase, FrodoBots, and Veris are more like "perpetual games" than traditional infrastructure networks.
How difficult is it to install your hardware?
Various DePIN networks differ in the ease of the hardware installation process. On one end, it can be as simple as plugging a device into a wall socket, while on the other end, it may require professional installers.
On the simpler end of the difficulty range, gamers can connect their GPUs to the Render Network, a distributed computing network, by simply running a bash script, which is ideal as the computing network requires tens of thousands of geographically distributed GPUs to properly serve data center offload.
In the middle of the difficulty range, installing Hivemapper cameras takes 15-30 minutes. Hundreds of such vehicles are needed in a given geographical area to build a robust real-time map, so this installation must be a simple upfront time investment and easy to operate thereafter.
On the other hand, at the difficult end of the difficulty range, XNET is building an operator-grade CBRS wireless network. Their network radios need to be installed by professional personnel from local ISPs and require the choice of commercial property owners to join. However, despite this, their network is still expanding, as only a few such arrangements are needed to cover a city area, and can serve for carrier offload and data roaming use cases.
Summary —— The expansion speed of your network is directly affected by the difficulty of hardware installation. If your network requires thousands of devices worldwide, you need to simplify hardware installation as much as possible. If your network can quickly expand with only a few nodes, you can choose to focus on attracting professional contributors rather than retail contributors to the network. In general, when the installation complexity is low enough for ordinary people to easily become contributors, the expansion speed of the DePIN network is fastest.
Impact of Hardware on Token Design
When considering building a network, early supply-side contributors are one of the most important stakeholders you need to consider. Depending on the hardware decisions you make, the configuration of supply-side contributors can lean towards ordinary people, professionals, or "semi-professionals" in between.
We observe that professional contributors tend to consider their immediate dollarized returns in the early stages of the network and are more likely to cash out their tokens early. On the other hand, early retail contributors are more likely to focus on long-term outcomes and are more likely to want to accumulate as many tokens as possible, regardless of short-term price fluctuations.
For networks with a large base of professional contributors, alternative solutions such as locking tokens or dollarizing income shares can be attempted in addition to traditional spot token incentives.
Regardless of the contributor group, the supply side of the network must cover capital investments and operating costs in dollar terms when mature. Balancing the incentives for early adopters in the startup phase and ensuring a balance between rewarding contributors with tokens in the later mature stages of the network is a tricky but important task.
Threshold Scale Considerations
We use the term "threshold scale" to describe when the supply side of the network becomes commercially viable for the demand side. DePIN networks are inherently disruptive because tokens can be used to reward early contributors to deploy infrastructure to reach threshold scale.
Some networks can start serving demand from day one with one or a few nodes (e.g., storage and computing markets), while others need to reach a certain scale to serve their demand (e.g., wireless networks, logistics and delivery networks). As the magnitude of demand expands, the minimum set of nodes required to meet this incremental demand also expands.
Does location matter?
Some DePIN networks do not derive substantial revenue from physical distribution, while others absolutely require it. In most cases, if a network needs to coordinate physical resources, it is sensitive to location, so reasoning about the minimum viable coverage becomes a critical factor when determining when demand generation should occur.
Some networks are very sensitive to location, while others are not. For example, energy markets (such as Anode) and mapping networks (such as Hivemapper) are very location-sensitive. Wireless networks like Helium IOT are less sensitive to location, as the hotspot range is large. Bandwidth markets like Filecoin Saturn, Fleek, or Wynd are even less sensitive to location, as they only require general geographic coverage and not specific location nodes.
On the other hand, decentralized virtual infrastructure networks (DeVIN) such as the Render Network or Filecoin storage markets are not location-sensitive. In these networks, guiding supply-side contributors to reach threshold scale is easier because the entry is not geographically restricted.
Summary —— We note that if a network is location-sensitive, it should incentivize supply-side contributors to contribute to target areas to reach threshold scale, with the aim of unlocking a serviceable market. Once achieved, the network should take a "land expansion" approach and replicate that strategy in other different areas.
Does network density matter?
Building on the above about minimum viable coverage, some DePIN networks have the concept of "network density," usually defined in terms of the number of hardware units (or nodes) or a total aggregation unit of a specific resource within a particular area.
Helium Mobile is a web3 mobile operator that defines its network coverage as the number of mobile hotspots in each community. Network density is very important for Helium Mobile, as the network requires a high density of mobile hotspots to provide continuous coverage in an area.
Teleport is a permissionless ride-sharing protocol that defines density as the number of active drivers within a 5-10 mile radius of city hotspots. Network density is important for Teleport, as no one wants to wait more than 10 minutes for a ride. However, unlike Helium Mobile, Teleport's hotspots can drive to pick up passengers, so Teleport does not need as high a native density as Helium Mobile.
Hivemapper defines network density as the number of mappers in a given city, as the network needs enough mappers in the city to provide continuously updated mapping data. But Hivemapper does not need the level of density that Teleport does, as map refreshes can tolerate longer delays than hailing a ride.
A simple way to consider density in the context of threshold scale is to consider at what threshold in a geographical area the network can make its first sale or attract the first demand-side customer? What about the tenth? The hundredth?
For example, XNET, a decentralized quasi-permissioned mobile operator, may only need 100 large, professionally installed radios to serve a city area. However, Helium Mobile's radios are smaller and require more radios to cover the same city area—having hundreds of small base stations in the Helium Mobile network is of low value, but having tens of thousands of base stations is of very high value. Due to its hardware design decisions, the threshold scale of Helium Mobile is higher than that of XNET.
Summary —— We note that networks that require higher density require more contributors to reach threshold scale. Conversely, networks with lower density can leverage more complex hardware and/or professional contributors.
Impact of Token Design
We observe that, due to some combination of location sensitivity or network density requirements, networks with higher threshold scale require more token incentives to build the supply side of the network. In contrast, networks with relatively lower threshold scale have greater flexibility to set token incentives more conservatively and can allocate them in later threshold scale milestones.
In general, token allocation has two common strategies: time-based strategies and utilization-based strategies. For networks with a higher threshold scale, time-based strategies work best, while for networks with a relatively lower threshold scale, utilization-based strategies work best. Helium adopts a time-based token issuance schedule, while Hivemapper adopts a utilization-based issuance schedule.
Time-based strategies involve proportionally distributing a fixed number of tokens to contributors within a given time to measure their contribution to the network. These strategies are more suitable if time to market for infrastructure construction is important and needs to reach threshold scale faster than competitors. Utilization-based strategies should be considered if the network is not the first mover in a winner-takes-all market. (Note that this approach often requires the network to explicitly distribute hardware through an elastic supply chain.)
Based on Utilization-based token allocation is a more flexible mechanism that allows for the distribution of tokens based on network growth. Reward mechanisms include providing more tokens for network construction in specific locations, specific times, or for providing specific types of resources. The trade-off here is that while this gives the network the choice to distribute tokens to the most valuable participants, it brings income uncertainty to the supply side, which may lead to lower conversion rates and higher churn rates.
For example, Hivemapper has rewarded the mapping of 10% of the U.S. area with less than 2% of the total token issuance. Therefore, they can now very cautiously build bonus challenges to reach threshold scale in specific areas, continue to expand the map, and improve density in strategic areas.
Considerations for Demand Generation
When DePIN networks reach threshold scale, they can start seriously selling to the demand side of the network. This raises the question of who should do the selling?
DePIN networks are only valuable when consumers and businesses can easily access the network's aggregated resources. Consumers and businesses typically do not want to buy directly from a permissionless network and are more willing to buy from traditional companies. This creates opportunities for value-added resellers to package network resources into products and services that customers understand and are willing to purchase.
Network creators can also choose to operate value-added resellers on the network. The company operates on top of the network, owning the relationship with customers and everything related to it—product development, sales, customer acquisition and retention, ongoing support, and service legal agreements. The advantage of building a value-added reseller on the network is the ability to capture the full difference between the product sales cost (to the customer) and the raw resource cost provided by the network. This approach makes the network full-stack and allows for closer product iteration, as continuous feedback can be obtained from demand-side customers.
On the other hand, you do not have to be a value-added reseller or operate on top of the network. You can outsource demand-side relationships to the network ecosystem. This approach allows you to focus on core protocol development, but reducing touchpoints with customers may hinder product feedback and iteration.
Should you be a value-added reseller or outsource?
Different DePIN teams consider this question from many angles.
For example, Hivemapper Inc. is currently the primary value-added reseller of the Hivemapper Network. They operate on top of the network mapping data and provide enterprise-level logistics and mapping data through commercial APIs.
For Helium, the Helium Mobile Network is serviced by a single value-added reseller, Helium Mobile, which originated from Helium Systems Inc., while the Helium IoT Network is commercialized by a series of value-added resellers, such as Senet, whose business includes helping customers deploy hotspots, purchasing sensors and coverage, and verifying data packet transmission.
Unlike Hivemapper or Helium, the Render Network outsources the commercialization of network resources to public compute customers, who then resell these resources to institutions and artists for rendering and machine learning jobs. The Render Network itself does not provide different orchestration layers for proof of compute integrity, privacy guarantees, or processing specific program packages or library workloads. These are all provided by third-party customers.
Summary —— We note that adding services or trust guarantees can stimulate demand. The network can provide these services itself, but investing in these services too early—before reaching a certain critical scale—can lead to waste of time, energy, and funds. At scale, these services are best handled by third parties, who can customize products for the customers they serve.
We also observe that as networks begin to expand and commercialize network resources, they typically take the following forms:
Phase One: At the first threshold scale milestone or shortly thereafter, the core team manages all aspects of demand-side relationships. This ensures that early customers receive the highest quality products possible.
Phase Two: In addition to the first set of threshold scale milestones, the network can begin to build a third-party ecosystem to resell the aggregated network resources. Third parties handling resource integration can enter the network and mediate relationships between demand and supply.
Phase Three: At a certain stable state, there are many participants packaging and selling resources to a broad set of network participants. At this stage, the network becomes a platform for other service companies to enter and directly serve customers, purely as a resource layer.
Impact of Token Design
If your network relies on specific aspects to expand demand generation, specifying protocol incentive measures for these network participants may be helpful. Tokens used for third-party demand generation activities are usually milestone-based, allocating tokens to reward these aspects when the network and third parties achieve some common goals. You should always construct token issuance mechanisms with partners in a way that aligns the value they bring to the network with the tokens they ultimately receive.
Looking Ahead
This article explores the most common questions and considerations we discuss with founders when exploring new DePIN networks.
We expect to see new, category-defining DePIN networks emerge in the coming years and believe that core attributes such as token allocation, hardware, threshold scale, and demand generation should be thoroughly explored to effectively build supply-side resources and serve demand-side customers. These networks are fundamentally markets, and every trade-off will have a ripple effect, either enhancing their inherent network effects or creating a gap for new entrants to compete.
Ultimately, we view DePIN as a way to reduce the cost of building valuable infrastructure networks through the formation of encrypted native capital. We believe there is a broad design space for networks that explicitly balance and serve subsets of large-scale markets such as telecommunications, energy, data aggregation, carbon reduction, physical storage, logistics, and delivery.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
