Multicoin Capital: What factors should successful DePIN projects consider?
TechFlow Selected TechFlow Selected
Multicoin Capital: What factors should successful DePIN projects consider?
This article discusses the most common questions and considerations when talking with founders during the exploration of new DePIN networks.
Navigating Web3 tides with focused insightsAuthors: SHAYON SENGUPTA, TUSHAR JAIN
Translated by: TechFlow
In April 2022, we published a paper on Proof-of-Physical-Work (PoPW) networks (now more commonly referred to as “Decentralized Physical Infrastructure Networks,” or “DePIN”). In that article, we wrote:
PoPW networks incentivize people to perform verifiable work to build real-world infrastructure. Compared to traditional forms of capital formation used to build physical infrastructure, these permissionless and trust-minimized protocols:
-
Can build infrastructure faster—often 10–100x faster;
-
Better align with native market demand; and
-
May be more cost-effective.
We were the first major firm to invest in this thesis, and since then, we’ve seen an explosion of DePIN networks across broad categories such as energy, logistics, mapping, and telecommunications. More recently, we’ve also observed the emergence of more targeted categories centered around networks for specific-use digital resources—such as compute, storage, bandwidth, and consumer data aggregation. Behind each network lies a structural cost or performance arbitrage uniquely enabled by crypto-native capital formation.
There is significant overlap in design patterns and best practices within DePIN networks. Founders and communities must consider several key questions when thinking about network design: Should the network hardware target consumers, or should it instead bootstrap a network of professional installers? How many nodes are required before launching the first paying customer—10? 1,000? Should the network be fully decentralized, or managed through trusted intermediaries?
These decisions must be made early in network design—and they need to be right. Hub decisions often determine the success or failure of a DePIN network, as small changes at the hardware, token, distribution, or demand activation layers can have massive impacts on network outcomes.
At Multicoin, we remain bullish on DePIN and expect many new, category-defining networks to emerge in the coming years. This article explores the most common trade-offs DePIN founders and communities consider, with the hope of helping the next generation of DePIN builders design more successful networks. We propose three essential considerations for building DePINs: hardware, threshold scale, and demand generation. For each, we explore key questions that influence critical design decisions and outline their broad implications for token design.
Hardware Considerations
Most DePIN networks coordinate physical infrastructure—that is, real hardware. However, this isn’t always the case. Some networks manage virtual resources like compute, storage, or bandwidth (these are sometimes called “Decentralized Virtual Infrastructure Networks” or “DeVINs”). But for the purposes of this section, we’ll assume your network involves real hardware, meaning you must answer several key network design questions.
Who manufactures the hardware?
DePIN networks that manufacture and distribute their own hardware gain greater control over the supply side of the network. They can also establish direct relationships with contributors (sometimes leading to stronger communities). However, over time, these companies risk becoming bottlenecks or single points of failure in manufacturing and distribution, potentially limiting the network’s ability to scale.
An alternative to self-manufacturing is open-sourcing your hardware specifications and asking the community to build them. This allows founders and communities to decentralize supply chain risks while scaling the supply side. Of course, the challenge here is that incentivizing third-party manufacturers to produce hardware for a nascent market is difficult and expensive. Another consideration is hardware quality and support. Even if you successfully cultivate a robust ecosystem of hardware makers, you still need to ensure consistent device quality and ongoing support.
Helium serves as an interesting case study. It initially built its own hotspots to kickstart the network, then quickly open-sourced its hardware specs and incentivized a strong ecosystem of third-party manufacturers. Despite having numerous third-party vendors, Helium suffered severe supply chain bottlenecks during critical growth phases, with some manufacturers delivering poor support.
In contrast, Hivemapper—which uses smartphones for decentralized indoor mapping—chose to build and distribute its own camera hardware. This gave them full control over production, enabling rapid firmware iteration and faster rollout of passive video uploads, accelerating map coverage and the commercial value of the data. The trade-off is that centralizing hardware production introduces supply chain centralization, which may make it more vulnerable.
Summary — We observe that DePIN networks scale significantly faster when hardware specifications are open-sourced and deployed permissionlessly. While opening hardware development to decentralize and scale makes sense once the network matures, maintaining control early on ensures quality and support.
Is your hardware active or passive?
Some DePIN networks are one-time setup efforts, while others require sustained user engagement.
For example, in Helium’s case, setting up a hotspot takes about 10 minutes from unboxing. After that, the device sits quietly, providing passive coverage to the network with minimal ongoing user effort. In contrast, networks like Geobyte—which uses smartphone sensors to capture indoor space video—require users to actively contribute value. For supply-side contributors, active networks involve time that could otherwise be spent on other income-generating activities or daily life. As a result, contributors to active networks must earn more—through tokens or network design—to justify their time and opportunity cost. This also means that, by design, active networks reach threshold scale (discussed in detail below) more slowly than passive ones.
On the upside, because active DePIN networks require ongoing participation, they typically attract more engaged and technically proficient contributors. However, this also means active networks are limited by the number of people willing and able to contribute.
Summary — We observe that DePIN networks scale more easily when contributors incur a one-time cost (in time or money), rather than recurring costs; passive networks are easier to set up and thus easier to scale.
Being an active network isn’t a death sentence—it just requires creative thinking around incentive design. For instance, active networks like Geobyte, Dronebase, FrodoBots, and Veris resemble “perpetual games” more than traditional infrastructure networks.
How hard is your hardware to install?
DePIN networks vary widely in how easy or difficult it is to install hardware—from simply plugging a device into a wall socket to requiring professional installation.
On the simpler end, gamers can connect their GPUs to the Render Network—a distributed computing network—by running a single bash script. This is ideal, as compute networks require tens of thousands of geographically distributed GPUs to properly offload data center workloads.
Mid-range difficulty includes installing the Hivemapper camera, which takes 15–30 minutes. Since hundreds of vehicles are needed in a given geographic area to build a robust real-time map, the installation must represent a simple upfront time investment and be easy to operate afterward.
On the more complex end, XNET is building a carrier-grade CBRS wireless network. Their radio units require professional installation by local ISPs and opt-in from commercial property owners. Yet, despite this complexity, the network continues to expand because only a few such installations are needed to cover a city area, serving use cases like carrier offloading and data roaming.
Summary — The speed at which your network scales is directly impacted by how easy the hardware is to install. If your network requires thousands of devices worldwide, you must simplify installation as much as possible. If your network can scale rapidly with only a few nodes, you can focus on attracting professional rather than retail contributors. Generally, DePIN networks scale fastest when installation complexity is low enough that ordinary people can easily become contributors.
Token Design Implications for Hardware
When designing a network, early supply-side contributors are among the most important stakeholders to consider. Depending on your hardware decisions, the profile of contributors may skew toward average individuals, professionals, or semi-professionals somewhere in between.
We observe that professional contributors tend to prioritize immediate dollar-denominated returns in the early stages and are more likely to cash out their tokens early. In contrast, early retail contributors are more likely to focus on long-term outcomes and prefer accumulating as many tokens as possible, regardless of short-term price volatility.
Networks with a large base of professional contributors might experiment with alternatives beyond traditional spot token incentives—such as vesting schedules or revenue-sharing agreements.
Regardless of contributor type, at maturity, the supply side must generate sufficient dollar-denominated revenue to cover both capital investment and operational costs. Striking the right balance between incentivizing early adopters during launch and ensuring sustainable rewards for contributors in later stages is a tricky but crucial task.
Threshold Scale Considerations
We use the term “threshold scale” to describe when the supply side of a network becomes commercially viable for demand-side users. DePIN networks are inherently disruptive because tokens can reward early contributors who deploy infrastructure to reach threshold scale.
Some networks can serve demand from day one with just one or a few nodes (e.g., storage and compute markets), while others need to reach a certain scale before fulfilling demand (e.g., wireless, logistics, and delivery networks). As demand grows in magnitude, the minimum node set required to meet incremental demand also expands.
Does location matter?
Some DePIN networks gain little benefit from physical distribution, while others absolutely depend on it. In most cases, if a network coordinates physical resources, it is location-sensitive, so reasoning about minimum viable coverage becomes a critical factor when determining timing for demand generation.
Some networks are highly location-sensitive, while others are location-agnostic. For example, energy markets (like Anode) and mapping networks (like Hivemapper) are highly location-sensitive. Wireless networks like Helium IoT are less sensitive due to wide hotspot range. Bandwidth markets like Filecoin Saturn, Fleek, or Wynd are even less location-sensitive, requiring only general geographic coverage rather than nodes in specific locations.
In contrast, compute markets like Render Network or storage markets like Filecoin (as DeVINs) are location-agnostic. In these networks, because entry is not geographically constrained, bootstrapping supply-side contributors to threshold scale is easier.
Summary — We observe that if a network is location-sensitive, it should incentivize supply-side contributions in targeted areas to reach threshold scale and unlock a serviceable market. Once achieved, the network should adopt a “land grab” strategy and repeat the process in other regions.
Does network density matter?
Building on the concept of minimum viable coverage, some DePIN networks have a notion of “network density,” typically defined by the number of hardware units (or nodes), or the total aggregated units of a particular resource within a given area.
Helium Mobile, a web3 mobile carrier, defines its network coverage by the number of mobile hotspots per community. Network density is crucial for Helium Mobile because it needs high hotspot density to provide continuous coverage in an area.
Teleport, a permissionless ridesharing protocol, defines density as the number of active drivers within a 5–10 mile radius of city hotspots. Density matters for Teleport because no one wants to wait more than 10 minutes for a ride. However, unlike Helium Mobile, Teleport drivers can drive to pick up passengers, so Teleport doesn’t require the same level of native density.
Hivemapper defines network density as the number of mappers in a given city, since the network needs enough mappers to deliver continuously updated map data. But Hivemapper doesn’t require the same density level as Teleport, as map refreshes can tolerate longer delays than ride requests.
A simple way to think about density in the context of threshold scale is: How many contributors in a given geographic area are needed before the network can make its first sale or attract its first demand-side customer? The tenth? The hundredth?
For example, XNET, a decentralized quasi-permissioned mobile operator, may need only 100 large, professionally installed radios to serve a city area. In contrast, Helium Mobile uses smaller radios and requires many more to cover the same area—its network has little value with just hundreds of small base stations but immense value with hundreds of thousands. Due to its hardware design choices, Helium Mobile has a higher threshold scale than XNET.
Summary — We observe that networks requiring higher density need more contributors to reach threshold scale. Conversely, lower-density networks can leverage more sophisticated hardware and/or professional contributors.
Token Design Implications
We observe that networks with higher threshold scales—due to location sensitivity or density requirements—need more token incentives to bootstrap supply. In contrast, networks with relatively lower threshold scales have greater flexibility to set conservative token incentives and can reserve allocations for later milestones.
Broadly, there are two common token allocation strategies: time-based and utilization-based. Time-based strategies work best for high-threshold-scale networks, while utilization-based strategies suit lower-threshold-scale networks. Helium adopted a time-based token issuance schedule, whereas Hivemapper uses a utilization-based model.
Time-based strategies involve distributing a fixed amount of tokens proportionally over time based on contributors’ network participation. These are better suited when time-to-market is critical and reaching threshold scale faster than competitors is essential. A time-based approach should be considered if the network isn’t first-mover in a winner-take-all market. (Note: this method usually requires the network to explicitly distribute hardware via a scalable supply chain.)
Utilization-based token distribution is a more flexible mechanism that allocates tokens based on network growth. Reward mechanisms include issuing more tokens for building infrastructure in specific locations, at specific times, or providing specific types of resources. The trade-off is that while this gives the network optionality to distribute tokens to the most valuable participants, it introduces revenue uncertainty for supply-side actors, potentially leading to lower conversion and higher churn.
For example, Hivemapper has mapped 10% of the U.S. using less than 2% of its total token supply. This allows them to carefully design bonus challenges to reach threshold scale in specific areas, continue expanding map coverage, and improve density in strategic zones.
Demand Generation Considerations
Once a DePIN network reaches threshold scale, it can begin selling seriously to demand-side users. This raises a key question: Who should do the selling?
Ultimately, DePIN networks are only valuable when customers can easily access the aggregated resources. Consumers and enterprises typically don’t want to buy directly from a permissionless network—they prefer buying from traditional companies. This creates opportunities for value-added resellers (VARs) to package network resources into products and services that customers understand and are willing to pay for.
Network creators can also choose to operate as a VAR themselves. The company builds a business on top of the network, owning the customer relationship and everything that comes with it—product development, sales, customer acquisition and retention, ongoing support, and legal agreements. The advantage of being a VAR is capturing the full margin between product sale price (to the customer) and the underlying cost of network resources. This makes the network vertically integrated and enables tighter product iteration, as continuous feedback can be gathered from demand-side customers.
Alternatively, you don’t have to be a VAR or run a business atop the network. You can outsource the demand-side relationship to the network ecosystem. This lets you focus on core protocol development, but reduced customer touchpoints may hinder product feedback and iteration.
Should you be the network VAR or outsource?
Different DePIN teams approach this question from various angles.
For example, Hivemapper Inc. currently acts as the primary VAR for the Hivemapper Network. It operates atop the network’s mapping data, offering enterprise-grade logistics and mapping data via commercial APIs.
In Helium’s case, the Helium Mobile Network is served by a single VAR—Helium Mobile, spun out from Helium Systems Inc.—while the Helium IoT network is commercialized by a series of VARs, such as Senet, which helps customers deploy hotspots, purchase sensors and coverage, and verify packet transmission.
Unlike Hivemapper or Helium, Render Network outsources the commercialization of network resources to public compute clients, who then resell those resources to studios and artists for rendering and machine learning jobs. Render Network itself does not provide compute integrity proofs, privacy guarantees, or orchestration layers for specific software packages or libraries—these are all handled by third parties.
Summary — We observe that adding services or trust assurances can stimulate demand. Networks can provide these services themselves, but investing too early—before reaching critical scale—can waste time, energy, and capital. At scale, these services are best handled by third parties who tailor products to their specific customer segments.
We also observe that as networks begin to scale and commercialize resources, they typically evolve through the following stages:
-
Stage One: Shortly after or at the first threshold scale milestone, the core team manages all aspects of the demand-side relationship. This ensures early customers receive the highest-quality product possible.
-
Stage Two: Beyond the initial threshold scale milestones, the network can begin cultivating a third-party ecosystem that resells aggregated network resources. Third parties handling integration can enter the network and mediate the relationship between demand and supply.
-
Stage Three: At a stable state, multiple participants package and sell resources to a broad set of network users. At this stage, the network becomes a platform for other businesses to enter and serve customers directly, acting purely as a resource layer.
Token Design Implications
If your network relies on specific actors to scale demand generation, allocating protocol incentives to these participants may be helpful. Tokens for third-party demand generation are typically milestone-based, disbursing when the network and partner achieve shared goals. Token issuance mechanisms with partners should always be structured so that the value they bring to the network aligns 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 new, category-defining DePIN networks to emerge in the coming years, and believe core attributes such as token distribution, hardware, threshold scale, and demand generation are critical and should be thoroughly explored to effectively build supply-side resources and serve demand-side customers. These networks are fundamentally markets, and every trade-off creates ripple effects—either amplifying inherent network effects or creating gaps for new entrants to compete.
Ultimately, we view DePIN as a way to reduce the cost of building valuable infrastructure networks through crypto-native capital formation. We believe there is a vast design space for networks that make deliberate trade-offs and serve subsegments of massive markets—including telecommunications, energy, data aggregation, carbon reduction, physical storage, logistics, and delivery.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Multicoin Capital
