DePIN (Decentralized Physical Infrastructure Network) refers to blockchain-based networks that incentivize the deployment, operation, and sharing of real-world physical infrastructure through decentralized mechanisms. These networks leverage tokens to reward participants for contributing to and maintaining the infrastructure, creating a decentralized alternative to traditional centralized systems. Examples include wireless, content delivery, and mapping networks.
For instance, Helium creates a wireless network more cheaply than traditional carriers by enabling individuals to deploy and maintain network hotspots. This approach eliminates the need for centralized infrastructure investments and operational costs, allowing the network to scale more cost-effectively.
While each DePIN network has a unique product focus, most DePIN networks utilize Solana for a common set of use cases. This guide is meant to help builders get oriented to these common on-chain DePIN use cases. Topics covered include:
Minting and Managing a Token #
Token Minting #
When minting a token on Solana, there are two token programs to choose from: the Token program or the Token22 program. There are tradeoffs to consider (discussed here). The recommended selection between the two options ultimately reduces to whether the features in the token extensions program would be of use to the application.
Token Listing #
In order to have your token appear in explorers, decentralized exchanges, and other ecosystem token lists, getting the token verified through Jupiter Verification is recommended.
Modeling Token Distribution #
For DePIN teams looking to optimize the way they allocate their token across various needs and stakeholders (rewards for participating / supplying network resources, private or public token sales etc.), tools like Forgd can be used to model out and refine token distribution strategies.
Token Management #
Most teams utilize Squads for their onchain treasury management, and leverage features such as multi-sig and time-based lockups.
Rewards Distribution #
There are two common paths for rewards distributions: Merkle claims and ZK compression. Each of these optimize the cost of distributing a potentially small value of tokens to a large set of users by allowing the application to do so in a single transaction per claim period.
Merkle Claims #
Rewards can be distributed using a Merkle tree structure, allowing for efficient batch processing of claims. This approach is used to minimize the number of transactions on the blockchain by allowing users to claim their rewards based on a published Merkle root.
The application constructs a Merkle tree on a regular basis and publishes the root onchain. Each leaf node represents a recipient’s rewards.
In order for users to claim their rewards, they generate a Merkle proof that demonstrates a particular leaf is part of the published Merkle root. Once their claim is verified, the rewards are distributed to the user’s wallet.
See example code and Jupiter’s Merkle distributor for an additional reference.
Automatic Distribution #
An alternative to having users proactively claim rewards is automating rewards distribution. On a regular basis, this “rewards crank” fetches rewards for an associated set of users by querying and constructing transactions to distribute rewards to the specified accounts. Merkle tree updates can be posted by the automated process, allowing for the reward distribution mechanism to remain permissionless.
ZK Compression #
For networks that anticipate needing to distribute rewards to tens of thousands (or more) of nodes, participants, or contributors, a newer approach to rewards distribution is to use ZK compression. Instead of regular accounts, compressed accounts are generated for reward recipients, minimizing the state and rent costs associated with account creation.
Implementing ZK compression is often cheaper in terms of storage costs. However, because it is a relatively new feature, the level of ecosystem support and tooling is not yet as extensive.
See example code.
Cost analysis #
Let's estimate the cost of distributing rewards using both the Merkle tree approach and the ZK compression option. We'll consider transaction fees, rent costs, and storage costs.
In both approaches, updating the rewards per claim period requires a single transaction by the application, so the cost difference is minimal, as it doesn’t scale per the number of users. Both strategies require one transaction per user to claim their rewards.
ZK compression is more cost-effective in storage costs, due to the reduced storage requirements of compressed data. Here is a hypothetical cost analysis to compare the storage costs.
If we assume a reward distribution to 10,000 users, with an average reward amount per user of 100 tokens, and the transaction fee on Solana to be 0.000007 SOL (7,000 lamports):
Storage Costs using a Merkle tree distribution strategy:
- The Merkle tree requires storing the leaf nodes and the internal nodes
- Leaf Nodes: 10,000 * 32 bytes = 320,000 bytes
- Internal Nodes: (2^14 - 1) * 32 bytes = 524,256 bytes
- Total Storage Cost: (320,000 + 524,256) * 0.00000348 SOL/byte (per epoch) = 2.94 SOL
- Total Cost (Merkle Tree): 0.050005 SOL + 0.00007323 SOL + 2.94 SOL = 2.99 SOL
Storage Costs using a ZK compression distribution strategy:
-
Compressed Token Account: The compressed token account stores the compressed reward data
- Compressed Data Size: Assuming a compression ratio of 50%, the total compressed data size would be approximately 500 KB
-
Total Storage Cost: 500 * 1024 * 0.00000348 SOL/byte (per epoch) = 1.78 SOL
-
Total Cost (ZK Compression): 0.050005 SOL + 0.00000223 SOL + 1.78 SOL = 1.83 SOL
We can extrapolate this across different numbers of reward distributions.
| Number of Distributions | Merkle Tree Storage Cost (SOL) | ZK Compression Storage Cost (SOL) |
|---|---|---|
| 1,000 | 0.06 | 0.03 |
| 10,000 | 0.58 | 0.29 |
| 100,000 | 5.80 | 2.90 |
| 1,000,000 | 58.00 | 29.00 |
| 5,000,000 | 290.00 | 145.00 |
Proof of Contribution #
DePIN networks generally need a way to prove the contribution from network participants. The application needs a method of verifying that participants have provided the resource in question honestly and consistently.
Reporting the contributions through Solana makes it possible to use the blockchain’s inherent security properties to enable the secure validation of the contribution.
While almost all DePIN networks require proof-of-contribution in some form, the exact mechanism can vary significantly from protocol to protocol. A number of teams are building tooling to help DePIN projects develop their proof of contribution models: Proof of Location by Witness Chain, Proof of Coverage by Helium.
Governance #
DePIN protocols tend to follow a path of measured, gradual decentralization that shifts decision-making for the protocol to onchain governance by token holders over time. This could take the form of a social framework like a DAO or leverage liquid restaking.
For examples, see Modular Governance by Helium or Network Governance by Hivemapper.
Migrations #
If you are a DePIN builder who has historically only been familiar with building on EVM, not to worry! A number of large DePIN teams who began on EVM chains have successfully migrated to Solana (see Render, Geodnet, and Xnet, amongst others). There are specific resources to help developers make the transition from EVM to SVM. Bridge infrastructure like Wormhole’s NTT streamline the process of shifting your tokens to Solana.