Why is DePIN Crucial?
Existing physical infrastructure networks, such as telecommunications, energy, water resources, and transportation, are often natural monopoly markets—where the cost for a single company to provide products or services is far lower than the cost required to encourage competition. In most developed countries, these networks are controlled by complex government regulations and rules. However, this model has little incentive for innovation, let alone improving customer experience, optimizing user interfaces, enhancing service quality, or accelerating response times. Additionally, these networks are often inefficient and poorly maintained. For example, the California wildfires led to PG&E’s bankruptcy, or the regulatory policies protecting existing telecommunications companies illustrate this point. In developing countries, the situation is even worse: many such services are either nonexistent or prohibitively expensive and scarce.
We can do better. Decentralized physical infrastructure networks offer us an opportunity to transcend the existing monopoly system, enabling the construction of more robust, investable, and transparent networks. The Decentralized Physical Infrastructure Network (DePIN) protocol is a service owned and operated by users, where anyone can contribute to the core infrastructure that runs our daily lives. These protocols have the potential to become a significant democratizing force driving society towards greater efficiency and openness. In this article, I will explain what DePIN is and why it is important. At the same time, I will share a framework for evaluating DePIN protocols and discuss the questions that need to be raised when constructing DePIN protocols, particularly verification issues.
What is DePIN?
A Decentralized Physical Infrastructure Network (DePIN) refers to any sufficiently decentralized network that utilizes cryptographic technology and mechanism design to ensure that users can request physical services from a pool of service providers, thereby breaking natural monopolies and bringing about the benefits of competition (which we will explore in detail below). Users typically refer to end-users but may also include applications acting on behalf of end-users. Service providers are usually small businesses but may also include gig workers or even large traditional companies, depending on the network. Here, “decentralized” refers to the decentralization of power and control, not just the physical distribution or data structure.
If designed properly, DePIN protocols can encourage user and small business participation in physical infrastructure networks and govern their development over time, while providing transparent incentive mechanisms for contributions. Just as networks dominated by user-generated content exist, DePIN provides an opportunity for a user-generated service-driven approach in the physical world. More importantly, just as blockchain is breaking the cycle of monopolistic tech companies’ “attract-extract,” DePIN protocols can help dismantle utility monopolies in the physical world.
Case Study of DePIN: Energy Grid
Taking energy as an example, the American energy grid is moving toward decentralization even in a non-crypto environment. Transmission bottlenecks and long delays in integrating new generation capacity into the grid have created a demand for decentralized generation capacity. Homes and businesses can deploy solar panels to generate power on the grid’s edge or install batteries to store energy. This means they not only purchase energy from the grid but can also sell energy back to it.
As edge generation and storage become more prevalent, many devices connected to the grid are no longer owned by utility companies. These user-owned devices can significantly benefit the grid by storing and releasing energy at critical moments, so why are they not being fully utilized? Existing utility companies cannot effectively capture the status information of these devices or acquire control over them. The Daylight protocol is addressing the fragmentation issue in the energy sector. Daylight is building a decentralized network that allows users to sell the status information of their grid-connected devices and enables energy companies to pay for temporary control of these devices. In short, Daylight is creating a decentralized virtual power plant.
This could lead to a more robust and efficient energy grid, with user-owned generating capacity, better data, and fewer trust assumptions than centralized monopolies. This is the promise of DePIN.
Guidelines for Building DePIN
DePIN protocols hold immense potential in improving the core physical infrastructure we interact with daily, but achieving this goal requires overcoming at least three major challenges:
1. Determining whether decentralization is needed in specific situations;
2. Market promotion;
3. Verification issues, which are the most challenging aspect.
I deliberately refrain from discussing specific technical challenges in any particular physical infrastructure domain. This is not because these challenges are unimportant but because they are domain-specific. In this article, I focus on constructing decentralized networks from an abstract level and provide advice applicable to all DePIN projects across different physical industries.
1. Why Choose DePIN?
Two common reasons for constructing DePIN protocols are to reduce capital expenditures (Capex) for hardware deployment and to aggregate dispersed resource capacity. Furthermore, DePIN protocols can create neutral developer platforms above physical infrastructure, unlocking permissionless innovations, such as open energy data APIs or neutral ride-hailing markets. Through decentralization, DePIN protocols achieve censorship resistance, eliminate platform risk, and foster permissionless innovation—this composability and permissionless innovation are key reasons for the thriving of Ethereum and Solana.
Traditionally, deploying physical infrastructure networks has been costly, often requiring a centralized company to do so, whereas DePIN distributes costs and control through decentralized ownership.
1.1 Capital Expenditures (Capex)
Many DePIN protocols reduce the substantial, often unfeasible capital expenditures typically borne by centralized companies by encouraging users to purchase hardware and participate in network operations. High capital expenditures are one reason many infrastructure projects are seen as natural monopolies, while reducing capital expenditures gives DePIN protocols a structural advantage. In the telecommunications industry, for example, the adoption of new network standards often stalls due to the high capital expenditures required to deploy new hardware. For instance, one analysis predicted that deploying a 5G cellular network in the U.S. alone would require up to $275 billion in private investment.
In contrast, the DePIN network Helium successfully deployed the world’s largest long-range, low-power network (LoRaWAN) globally without a single entity making massive upfront hardware investments. LoRaWAN is a standard well-suited for Internet of Things (IoT) use cases. Helium collaborated with hardware manufacturers to develop LoRaWAN routers, allowing users to purchase these routers directly from manufacturers. Subsequently, these users became the owners and operators of the network, providing services to customers needing LoRaWAN connections and earning rewards. Currently, Helium is focused on expanding its 5G cellular network coverage.
Deploying an IoT network like Helium’s would typically involve huge upfront capital expenditure risks and betting on whether there is a sufficiently large customer base willing to purchase connections to the new network. However, as a DePIN protocol, Helium verified its market supply side through decentralization and significantly reduced its cost structure.
1.2 Resource Capacity
In some cases, there exists significant potential idle capacity in physical resources, but due to complexity, existing companies struggle to effectively integrate it. For example, consider the idle space on a hard drive. On any single hard drive, this space may be too small to attract the attention of storage companies like AWS. However, when aggregated through DePIN protocols like Filecoin, these dispersed spaces can transform into a cloud storage service provider. DePIN protocols are capable of coordinating resources from ordinary users using blockchain technology, enabling them to contribute to a large-scale network.
1.3 Permissionless Innovation
The most critical feature unlocked by DePIN protocols is permissionless innovation: anyone can build on the protocol. This stands in stark contrast to monopolistic infrastructures like traditional local utility company grids. The potential for permissionless innovation is often underestimated compared to reducing capital expenditures or integrating resource capacity. Permissionless innovation allows physical infrastructure to evolve at the speed of software. We often hear that the pace of innovation in the digital realm (“bits”) is astonishing, while that in the physical realm (“atoms”) is disappointing.
DePIN provides a significant pathway for developers and investors to make “atoms” behave more like “bits.” When anyone in the world with internet connectivity can propose new ways to organize and coordinate the physical systems that run our world, clever and creative individuals can invent solutions superior to existing ones.
1.4 Composability
Innovation Accelerates the Transition from “Atoms” to “Bits”
The reason innovation can accelerate the transition from “atoms” to “bits” lies in its composability. Composability allows developers to focus on creating optimal point solutions that can be easily integrated. We have already witnessed this power in the “money legos” of decentralized finance (DeFi). In DePIN, “infrastructure legos” can also produce similar effects.
2. Go-to-Market: Opportunities and Challenges
Building DePIN protocols is more challenging than building blockchains, as it requires addressing the dual challenges of decentralized protocols and traditional businesses simultaneously. Bitcoin and Ethereum started relatively independent of traditional finance and cloud computing domains, while most DePIN protocols do not enjoy such a luxury; they are closely related to existing problems in the physical world.
Most DePIN domains must interact with existing centralized systems from day one. For example, utility companies, cable providers, ride-hailing services, and internet service providers are existing networks often protected by regulatory policies and possess strong network effects. New entrants often find it difficult to compete. Just as decentralized networks are a natural remedy for internet monopolies, DePIN networks are a natural remedy for monopolies in physical infrastructure.
However, DePIN developers must first find a value-adding entry point and gradually expand from there, ultimately challenging the entirety of existing physical networks. Finding the right entry point is crucial for future success. DePIN developers also need to understand how their networks will interact with existing alternatives. Most traditional companies are reluctant to run full blockchain nodes and often struggle with self-custody or on-chain transactions. They often do not grasp the significance or value of cryptographic technology.
One approach is to demonstrate the value that DePIN protocols can bring—without mentioning that they operate on top of cryptographic technology. When existing participants seriously consider integration or can understand the value brought by new protocols, they will be more willing to embrace cryptographic technology. More broadly, developers should adjust the value proposition of their protocols based on different audiences and design narratives that resonate emotionally with those audiences.
From a tactical perspective, interfacing with existing networks often requires a degree of early intermediaries and thoughtful physical structure design, which is heavily dependent on the specific physical domain the protocol targets.
Enterprise sales are also a challenge for DePIN protocols. Enterprise sales are often “white glove,” time-consuming, and require customized services. Customers usually want a direct accountable person. However, in a DePIN network, no individual or company can represent the entire network or operate traditional enterprise sales processes.
One solution is to have the DePIN protocol partner with centralized companies as initial distribution partners, allowing these companies to resell the services.
For example, a centralized telecommunications company can sell services directly to regular consumers and charge them in dollars, while the actual service is provided by the underlying decentralized telecom network. This way, complex issues related to crypto wallets and self-custody are abstracted, and the “crypto” aspect is hidden. This model of distributing DePIN network services through centralized companies can be referred to as the “DePIN mullet,” similar to the popular application of the “DeFi mullet” model in financial services.
3. Challenges of DePIN: Verification
The most challenging part of building DePIN protocols is verification. Verification is crucial: it is the only clear way to ensure customers receive the services they pay for while also ensuring that service providers are compensated fairly for their work.
3.1 Peer-to-Pool vs. Peer-to-Peer
Most DePIN projects adopt a peer-to-pool model. In this model, customers make requests to the network, which selects a provider to respond to the customer’s needs. More importantly, this means that customers pay fees to the network, which then pays the service providers.
Another option is the peer-to-peer model, where customers directly request services from providers. This requires customers to find a set of service providers and choose one to collaborate with. Meanwhile, customers pay fees directly to the providers.
In the peer-to-pool model, verification is more important than in the peer-to-peer model. In the peer-to-peer model, although either party may lie, since customers pay directly to providers, both parties can discover issues independently without needing to prove the other’s dishonesty to the network and choose to stop the transaction. In the peer-to-pool model, however, the network needs a mechanism to adjudicate disputes between customers and providers. Typically, providers agree to serve any customers assigned by the network when they join, so the only way to prevent or resolve disputes between customers and providers is to adopt some form of decentralized verification method.
There are two reasons why DePIN projects choose a peer-to-pool design. First, the peer-to-pool model makes it easier to provide subsidies using native tokens. Second, it optimizes the user experience (UX) and reduces the off-chain infrastructure needed to use the network. A similar example can be found outside of DePIN, namely the distinction between peer-to-pool decentralized exchanges (DEX, like Uniswap) and peer-to-peer DEX (like 0x).
Tokens are important because they help address the cold start problem when building networks. Whether in Web2 or Web3, projects often provide strong value to users through some form of subsidy, thus establishing network effects. These subsidies are sometimes direct economic incentives (like lower costs) and sometimes non-scalable value-added services. Tokens often provide an economic subsidy while also helping to build community and giving customers a voice in the direction of the network’s development.
The peer-to-pool model allows users to pay an amount of X, while the provider receives a reward of Y, where X < Y. This is often due to the native tokens created by DePIN projects, which reward service providers through that token. As speculators buy tokens and assign them a market price above the initial value (where the initial value of the tokens is often very low or even zero when the network has not yet been used), the token reward Y can exceed the amount X that customers pay.
The ultimate goal is that as service providers enhance service efficiency, DePIN projects achieve X > Y through the establishment of network effects, thus using the difference between X and Y as protocol revenue.
In contrast, the peer-to-peer model makes it more challenging to realize token rewards as subsidies. If a customer pays X, while a provider receives Y, where X < Y, and both the customer and provider can interact directly, the provider might disguise themselves as a customer and purchase services from themselves through "self-dealing." This behavior is difficult to prevent in decentralized DePIN protocols unless some degree of centralization is introduced or the peer-to-pool model is adopted.
3.2 Self-Dealing
Self-dealing refers to users simultaneously acting as both customers and service providers, attempting to extract value from the network by trading with themselves. This behavior is clearly harmful to the network, so most DePIN projects attempt to address this issue.
The simplest solution is to not provide subsidies or token incentives, but this makes resolving the cold start problem for the network even more challenging.
The harm of self-dealing is particularly severe when the cost of providing services to oneself is zero (which is often the case). One common approach to addressing self-dealing is to require service providers to stake tokens (usually native tokens) and allocate customer requests to service providers based on their stake weight.
Although staking mechanisms can alleviate self-dealing issues, they do not completely resolve the problem. This is because large service providers (those staking a significant amount of tokens) may still profit from some of the requests allocated to their customers. For example, if the provider’s reward is five times the cost paid by the customer, then a provider who has staked 25% of the tokens will earn five tokens in rewards for every four tokens spent.
This scenario assumes that self-dealers incur zero costs when providing services to themselves and do not gain any benefits from requests allocated to other providers. If self-dealers can gain some benefit or value from requests allocated to other providers, then under specific customer cost and provider reward ratios, self-dealers may extract more value.
3.3 Verification Methods
Having understood why verification is a critical issue, let’s discuss the different verification mechanisms that DePIN projects can consider.
Re-execution
The term “re-execution” may be more helpful for understanding, as it highlights that each node forming consensus within a blockchain network typically must re-execute every computation of the network processing. (This rule does not completely apply to modular blockchains or blockchain architectures that separate consensus, execution, and data availability.)
Re-execution is often necessary because each node in the network is generally assumed to potentially exhibit Byzantine behavior.
In other words, nodes need to check each other’s work because they cannot trust one another. When there is a proposal for a new state change, each node that verifies the blockchain must execute this state change. This can lead to a significant amount of re-execution! For example, at the time of writing, there are over 6,000 nodes in the Ethereum network.
Re-execution is usually transparent unless the blockchain uses Trusted Execution Environments (TEE, sometimes referred to as hardware or secure enclaves) or Fully Homomorphic Encryption. For more information on these two technologies, please see below.
Proof of Correct Execution
Instead of requiring every node in the blockchain network to re-execute every state change, it is more efficient to have a single node execute a given state change and generate a proof that indicates the node has correctly executed the state change. This proof of correct execution can be verified much more quickly than executing the computation directly (this property makes the proof succinct).
The most common forms of such proofs are SNARK (Succinct Non-Interactive Argument of Knowledge) or STARK (Succinct Transparent Argument of Knowledge). SNARKs and STARKs are often extended to Zero-Knowledge Proofs, which complete the proof without revealing any information about what is being proven. Thus, when used for compressing computational proofs, the terms SNARK/STARK and Zero-Knowledge Proofs (ZK Proofs) are often used interchangeably.
The most well-known type of blockchain based on proof of correct execution may be Zero-Knowledge Rollups (ZKR). ZKR is a Layer 2 blockchain that inherits the security of a certain underlying blockchain. ZKR batches transactions, generates a proof indicating that these transactions have been correctly executed, and then publishes that proof to a Layer 1 blockchain for verification.
Proof of correct execution is typically used to enhance the scalability and performance of blockchains, privacy, or both. Examples include zkSync, Aztec, Aleo, and Ironfish. Additionally, proof of correct execution can also be applied in other scenarios. For example, Filecoin uses ZK-SNARKs in its Proof of Storage. In recent years, proof of correct execution has begun to be applied in areas such as machine learning inference, training, and authentication.
Random Sampling / Statistical Measurement
Another method to address the verification issues in DePIN projects is to randomly sample service providers and measure whether they respond correctly to customer requests. These “challenge requests” are typically allocated according to the stake weight of the service provider in the network, which not only aids in verification but also alleviates the self-dealing problem.
Many DePIN projects offer high rewards for service provider availability (availability rewards are often higher than the rewards for serving customer requests), and random sampling can ensure that service providers are indeed available. The network occasionally sends challenge requests to service providers, and if the provider responds correctly to the request, and the hash value of the request exceeds a certain difficulty threshold, then that provider will receive a reward equivalent to the block reward. This mechanism incentivizes rational service providers to respond correctly to customer requests, as they cannot distinguish between ordinary customer requests and challenge requests.
Some versions of random sampling have been most widely applied in DePIN projects focused on network functionality, such as Nym, Orchid, and Helium.
Compared to consensus mechanisms, random sampling may offer better scalability since the number of samples can be far less than the number of state changes in the network.
Trusted Hardware
Trusted hardware is useful not only for privacy protection (as mentioned above) but also for verifying sensor data. A significant challenge for DePIN projects regarding decentralized verification is the oracle problem, which is how to bring data from the physical world into the blockchain in a trustless or minimized-trust manner. Trusted hardware allows the network to adjudicate disputes between customers and service providers based on the results of physical sensor data.
Although trusted hardware often has vulnerabilities, it may serve as a pragmatic solution in the short to medium term, or as an additional layer of protection in deep defense. The most common Trusted Execution Environments (TEE) include Intel SGX, Intel TDX, and ARM TrustZone. Blockchain projects such as Oasis, Secret Network, and Phala utilize TEEs, and the SAUVE project will also employ TEEs.
Whitelisting and Auditing
The most pragmatic and least technically complex solution for verification is often to whitelist specific physical devices to participate in the DePIN protocol while ensuring service providers correctly serve customers through manual audit logs and telemetry data.
In practical terms, this often involves constructing custom hardware embedded with signature keys and requiring all hardware participating in the network to be purchased from verified manufacturers. Manufacturers will subsequently whitelist a set of embedded keys. Only data signed with keys from the whitelist will be accepted by the network. This method assumes that extracting embedded keys from the devices is extremely difficult and that manufacturers can accurately report which keys are embedded in which devices. To address these challenges, manual audits are typically required.
To further ensure service correctness, DePIN protocols often elect an “auditor” through protocol governance, tasked with identifying malicious behavior and reporting findings to the protocol. Auditors are human and can detect clever attacks that standardized protocols may fail to detect, and once identified, these attacks may appear quite obvious to humans. Generally, auditors are authorized to submit potential penalties (such as slashing staked funds) to protocol governance or directly trigger slashing events. This method also assumes that protocol governance will act in the best interest of the protocol while facing any challenges involving human incentives in social consensus.
Optimal Solutions?
Faced with various potential verification options, a new DePIN protocol often struggles to determine the best approach.
Consensus mechanisms and proofs of correct execution are often impractical for verification. DePIN protocols involve physical services, while consensus or proofs can only provide strong guarantees for computations (i.e., digital rather than physical) state changes. To use consensus or proofs for verification in DePIN protocols, oracles must also be introduced, which carry their own (often weaker) trust assumptions.
Random sampling is very suitable for DePIN protocols because it is efficient and aligns well with game-theoretic logic, making it applicable to physical services. Trusted hardware and whitelisting are often the best choices for initiation, as they are the simplest to implement, but they are also the most centralized solutions, with lower chances of long-term success.
Why DePIN Matters
The popularity of cryptocurrencies stems from the desire to liberate currency control from the state, but in reality, more important services—such as basic internet connectivity, power supply, and access to water—concentrate power in the hands of a few. By decentralizing these networks, we can create not only a freer society but also a more efficient and prosperous one.
A decentralized future means that many people—not just a privileged few—can contribute to proposing better solutions. This idea is rooted in the belief that potential human capital is ubiquitous. If you are excited about decentralized financial systems or decentralized developer platforms, consider further exploring other network-based essential services that we use daily.
About the Author
Guy Wuollet is a partner at the a16z crypto investment team, focusing on investments across the full stack of the crypto space. Prior to joining a16z, Guy conducted independent research in collaboration with Protocol Labs, working to build decentralized network protocols and upgrade network infrastructure. He holds a Bachelor’s degree in Computer Science from Stanford University and was a key member of the school’s rowing team.
This article is collaboratively reprinted from: Deep Tide.