By decentralizing these networks, we can not only create a more free society but also achieve a more efficient and prosperous society.
Author: Guy Wuollet
Translation: Deep Tide TechFlow
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 speeding up 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 telecom companies demonstrate this. In developing countries, the situation is even worse: many such services are either nonexistent or expensive and scarce.
We can do better. Decentralized physical infrastructure networks provide us with an opportunity to move beyond the existing monopoly system, enabling the construction of stronger, more investable, and more transparent networks. The DePIN (Decentralized Physical Infrastructure Network) 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 an important 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 building DePIN protocols, particularly verification issues.
What is DePIN?
Decentralized Physical Infrastructure Network (DePIN) refers to any sufficiently decentralized network that utilizes cryptographic technology and mechanism design to ensure that clients can request physical services from a set of service providers, thereby breaking natural monopolies and bringing the benefits of competition (which we will explore in detail below). Clients are typically end users but can also be applications operating 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, “decentralization” refers to the decentralization of power and control, not just the decentralization of physical distribution or data structures.
If designed properly, DePIN protocols can encourage users and small businesses to participate in the physical infrastructure network and jointly govern its development over time while providing transparent incentives for contributions. Just as the internet is dominated by user-generated content, DePIN offers an opportunity for the physical world to be led by user-generated services. More importantly, just as blockchain is breaking the “attract-extract” cycle of monopolistic tech companies “attract-extract”, DePIN protocols can also help break utility monopolies in the physical world.
Practical Case of DePIN: Energy Grid
For example, in energy, the U.S. energy grid is moving towards decentralization even in a non-crypto environment. Transmission bottlenecks and long delays in connecting new generation capacity to the grid have created a demand for decentralized generation capacity. Households and businesses can deploy solar panels to generate power at the edge of the grid or install batteries to store electricity. This means they not only purchase energy from the grid but can also sell energy back to the grid.
With the proliferation of edge generation and storage, many devices connected to the grid are no longer owned by utility companies. These user-owned devices can greatly benefit the grid by storing and releasing energy at critical moments, so why are they not being fully utilized? Existing utility companies cannot effectively obtain the status information of these devices or purchase control over them. The Daylight protocol is providing a solution to the fragmentation problem in the energy industry. 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 outcome could lead to a more robust and efficient energy grid, user-owned generation capacity, better data, and fewer trust assumptions than centralized monopolies. This is the promise of DePIN.
Guidelines for Building DePIN
DePIN protocols have great potential to improve the core physical infrastructure we interact with daily, but achieving this requires overcoming at least three major challenges:
Determining whether decentralization is needed in specific situations;
Market promotion;
Verification issues, which is the most challenging aspect.
I deliberately omitted any specific technical challenges in particular physical infrastructure fields. This is not because these challenges are unimportant, but because they are domain-specific. In this article, I focus on building 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 building DePIN protocols are: reducing capital expenditures (Capex) for hardware deployment and aggregating dispersed resource capacity. Additionally, DePIN protocols can create neutral developer platforms on top of physical infrastructure that unlock permissionless innovation, such as open energy data APIs or neutral ride-hailing markets. Through decentralization, DePIN protocols achieve censorship resistance, eliminate platform risk, and promote permissionless innovation—this composability and permissionless innovation are key reasons for the thriving of Ethereum and Solana. Traditionally, deploying physical infrastructure networks is costly and often requires a centralized company to accomplish, while DePIN decentralizes costs and control through distributed ownership.
1.1 Capital Expenditure (Capex)
Many DePIN protocols reduce the significant and 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 viewed as natural monopolies, and reducing capital expenditures provides a structural advantage for DePIN protocols.
Taking the telecommunications industry as an example. The adoption of new network standards is often hampered by the high capital expenditures required to deploy new hardware. For instance, one analysis predicts that deploying 5G cellular networks in the U.S. alone will require up to $275 billion in private investment.
In contrast, the DePIN network Helium has successfully deployed the largest long-range, low-power network (LoRaWAN) globally without a single entity making large-scale 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 connectivity and earning rewards in return. Currently, Helium is focused on expanding its 5G cellular network coverage.
If deploying an IoT network like Helium, one would face significant upfront capital expenditure risks and bet on whether there is a sufficiently large customer base willing to purchase connection services for the new network. However, as a DePIN protocol, Helium has verified its market supply side in a decentralized manner and significantly reduced its cost structure.
1.2 Resource Capacity
In some cases, there exists a large amount of potential idle capacity in physical resources, but due to complexity, existing companies find it difficult to effectively integrate them. For example, free space on hard drives. On any single hard drive, this space may be too small to attract the attention of storage companies like AWS. However, when aggregated through a DePIN protocol like Filecoin, these dispersed spaces can transform into a cloud storage service provider. DePIN protocols can leverage blockchain technology to coordinate resources from ordinary users, allowing them to contribute to large-scale networks.
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 local power company grids. Compared to reducing capital expenditures or integrating resource capacity, the potential of permissionless innovation is often underestimated.
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 the pace of innovation in the physical realm (“atoms”) is disappointing. DePIN provides developers and investors with an important pathway to make “atoms” more like “bits.” When anyone in the world with an internet connection can propose new ways to organize and coordinate the physical systems that run our world, smart and creative people can invent better solutions than those currently available.
1.4 Composability
The reason permissionless innovation can accelerate the transformation from “atoms” to “bits” lies in composability. Composability allows developers to focus on creating optimal single-point solutions that can be easily integrated. We have witnessed this power in the “money legos” of decentralized finance (DeFi). Similarly, in DePIN, “infrastructure legos” can have a comparable impact.
2. Go-to-Market: Opportunities and Challenges
Building DePIN protocols is more challenging than building blockchains because it requires addressing the dual challenges of decentralized protocols and traditional business simultaneously. Bitcoin and Ethereum started relatively independently of traditional finance and cloud computing, while most DePIN protocols do not have such luxury; they are closely related to existing problems in the physical world.
Most DePIN fields must interact with existing centralized systems from day one. For example, utility companies, cable companies, ride-hailing services, and internet service providers are often protected by regulatory policies and have strong network effects. New entrants often find it difficult to compete. Just as decentralized networks are a natural antidote to internet monopolies, DePIN networks are a natural antidote to monopolies in physical infrastructure.
However, DePIN developers need to first find entry points that can add value and gradually expand from there, ultimately challenging the existing physical networks as a whole. 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 resistant to running full blockchain nodes and often struggle with self-hosting or on-chain transactions. They typically do not understand the significance or value of cryptographic technology.
One approach is to demonstrate the value that DePIN protocols can bring—without mentioning that they run on cryptographic technology. When existing participants seriously consider integration or can understand the value brought by the new protocol, they are more likely to accept cryptographic technology. More broadly, developers should adjust the value proposition of the protocol based on different audiences and design narratives that resonate emotionally with the audience.
Tactically, interfacing with existing networks often requires some degree of early mediation and thoughtful entity structure design, which heavily depends on the specific physical domain targeted by the protocol.
Enterprise sales also pose a challenge for DePIN protocols. Enterprise sales are often “white-glove,” time-consuming, and require customized services. Customers typically want a “accountable” direct contact. However, in a DePIN network, no individual or company can represent the entire network, nor can they run traditional enterprise sales processes.
One solution is to have DePIN protocols partner with centralized companies as initial distribution partners, who then resell the services. For example, a centralized telecom company can sell services directly to ordinary consumers and charge them in dollars, while the actual service is provided by the underlying decentralized telecom network. This way, complex crypto wallet and self-hosting issues are abstracted away, and the “crypto” features are 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 difficult part of building DePIN protocols is verification. Verification is crucial: it is the only clear way to ensure that customers receive the services they pay for while also ensuring that service providers are compensated correctly 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 provider.
An alternative is the peer-to-peer model, where customers request services directly from providers. This requires customers to find a set of service providers and choose one to collaborate with. At the same time, customers pay fees directly to the provider.
In the peer-to-pool model, verification is more important than in the peer-to-peer model. In the peer-to-peer model, although providers or customers may lie, since customers pay fees directly to providers, both parties can discover issues without needing to prove to the network that the other party is lying and can choose to stop the transaction. In the peer-to-pool model, 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.
DePIN projects choose the peer-to-pool design for two reasons. First, the peer-to-pool model makes it easier to provide subsidies using native tokens. Second, it can optimize user experience (UX) and reduce the off-chain infrastructure required to use the network. A similar example can be found outside of DePIN, namely the difference between peer-to-pool decentralized exchanges (DEXs, like Uniswap) and peer-to-peer DEXs (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 to establish network effects. These subsidies can sometimes be direct economic incentives (like lower costs) or non-scalable value-added services. Tokens often provide an economic subsidy while also helping to build community and give customers a voice in the direction of network development.
The peer-to-pool model allows users to pay an amount of X, while the service provider receives a reward of Y, where X > Y. This is often facilitated by the native token created by the DePIN project, which rewards service providers through that token. As speculators purchase tokens and assign them a market price higher than the initial value (which is often very low or even zero when the network is not yet in use), the token rewards Y can exceed the amount X paid by customers.
The ultimate goal is: as service providers improve service efficiency, DePIN projects achieve X > Y through building network effects, thus taking the difference between X and Y as protocol revenue.
In contrast, the peer-to-peer model makes it more difficult to implement token rewards as subsidies. If customers pay X, and providers receive Y, where X > Y, and customers and providers can interact directly, then providers may disguise themselves as customers to purchase services from themselves through “self-dealing.” This behavior is difficult to avoid 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 solving the cold start problem for the network more difficult.
When the cost for self-dealers to provide services to themselves is zero (which is often the case), the harm of self-dealing is particularly severe. One common method to address self-dealing is to require service providers to stake tokens (usually native tokens) and allocate customer requests to service providers based on staking weight.
Although the staking mechanism can alleviate the self-dealing problem, it does not completely resolve it. The reason is that large service providers (those who stake a significant amount of tokens) may still profit from some customer requests allocated to themselves. For example, if a service provider's reward is five times the cost paid by the customer, then a provider who stakes 25% of the tokens will earn five tokens for every four tokens spent.
This situation assumes that the cost for self-dealers to provide services to themselves is zero, and that they do not gain any benefits from requests allocated to other providers. If self-dealers can derive some benefit or value from requests allocated to other providers, then under a specific ratio of customer costs to provider rewards, 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.
Consensus Mechanism
Most blockchains adopt a consensus mechanism (often combined with anti-sybil attack mechanisms, such as Proof of Work [PoW] or Proof of Stake PoS). Reframing “consensus” as “re-execution” may be more helpful for understanding, as it highlights that each node in a blockchain network typically must re-execute every computation processed by the network to form consensus. (This rule does not fully apply to modular blockchains or blockchain architectures that separate consensus, execution, and data availability.)
Re-execution is usually necessary because each node in the network is generally assumed to potentially exhibit Byzantine behavior (Byzantine behavior). In other words, nodes need to check each other's work because they cannot trust one another. When there is a new state change proposal, each node validating the blockchain must execute this state change. This can lead to a significant amount of re-execution! For example, as of the writing of this article, there are over 6000 nodes in the Ethereum network.
Re-execution is typically transparent unless the blockchain uses Trusted Execution Environments (Trusted Execution Environments, abbreviated as TEE, sometimes referred to as hardware or secure enclaves) or Fully Homomorphic Encryption (Fully Homomorphic Encryption). For more information on these two technologies, see below.
Proof of Correct Execution (e.g., validity rollups, ZEXE, etc.)
Rather than 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 correctly executed the state change. This proof of correct execution is faster to verify than directly executing the computation (this property gives the proof succinctness). 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 (Zero-Knowledge Proof), which complete the proof without revealing any information about the statement being proven. Therefore, when used to compress 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 (L2) that inherits the security of an underlying blockchain. ZKR batches transactions, generates a proof indicating that these transactions were executed correctly, and then publishes that proof to a layer 1 blockchain (L1) for verification.
Proof of correct execution is typically used to enhance the blockchain's scalability and performance, privacy, or both. zkSync, Aztec, Aleo, and Ironfish are typical examples in this regard. Additionally, proof of correct execution can 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 (ML inference), training (ML training), and authentication.
Random Sampling / Statistical Measurement
Another method to address verification issues in DePIN projects is to randomly sample service providers and measure whether they correctly respond to customer requests. This “challenge request” is typically allocated based on the service provider's stake weight in the network, which not only helps with verification but also mitigates the self-dealing problem.
Since many DePIN projects offer high rewards for service provider availability (availability rewards are often higher than the rewards for servicing customer requests), random sampling can ensure that service providers are indeed available. The network occasionally sends challenge requests to service providers, and if the provider correctly responds to the request and the hash 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 regular customer requests and challenge requests.
Certain 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, as 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 decentralized verification in DePIN projects is addressing the oracle problem, which is how to bring data from the physical world into the blockchain in a trustless or minimally trusted 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 a deep defense strategy. The most common Trusted Execution Environments (TEEs) include Intel SGX, Intel TDX, and ARM TrustZone. Blockchain projects such as Oasis, Secret Network, and Phala utilize TEEs, and the SAUVE project also plans to use TEEs.
Whitelisting and Auditing
For verification, the most pragmatic and technically least complex solution is often to whitelist specific physical devices to participate in the DePIN protocol while ensuring that service providers correctly serve customers through manual audit logs and telemetry data.
In practice, this typically involves building custom hardware that embeds signing keys and requiring all hardware participating in the network to be purchased from verified manufacturers. The manufacturers would then whitelist a set of embedded keys. Only data signed with keys from the whitelist would be accepted by the network. This approach assumes that extracting embedded keys from devices is extremely difficult and that manufacturers can accurately report which keys are embedded in which devices. Addressing these challenges typically requires manual auditing.
To further ensure the correctness of services, DePIN protocols often elect an “auditor” through protocol governance, responsible for identifying malicious behavior and reporting their findings to the protocol. Auditors are human and can recognize clever attacks that standardized protocols may not detect, and once identified, these attacks may seem quite obvious to humans. Typically, 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 also facing the challenges of human incentives involved in any social consensus.
Optimal Solution?
Faced with various potential verification options, a new DePIN protocol often struggles to determine the best solution.
Consensus mechanisms and proofs of correct execution are typically not feasible for verification. DePIN protocols involve physical services, while consensus or proofs can only provide strong guarantees for state changes in computation (i.e., digital rather than physical). To use consensus or proofs for verification in a DePIN protocol, oracles must be introduced, which come with their own set of (often weaker) trust assumptions.
Random sampling is well-suited for DePIN protocols because it is efficient and aligns 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 and have a lower likelihood of long-term success.
Why DePIN is Crucial
The popularity of cryptocurrencies stems from the desire to liberate monetary control from the hands of the state, but in reality, more critical services—such as basic internet connectivity, electricity supply, and access to water—concentrate power in the hands of a few. By decentralizing these networks, we can not only create a freer society but also achieve 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 the other essential network-based services we use every day.
Author Introduction
Guy Wuollet is a partner at the a16z crypto investment team, focusing on investments across the full stack in the crypto space. Before joining a16z, Guy conducted independent research in collaboration with Protocol Labs, working on building decentralized network protocols and upgrading internet infrastructure. He holds a Bachelor’s degree in Computer Science from Stanford University and was a key member of the university's rowing team.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
