DePIN Playbook

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:

• Choosing a blockchain for your DePIN
• What to use blockchain for in a DePIN
• Minting and managing a token
• Staking
• Rewards Distribution
• Proof of Contribution
• Storage
• Logging on-chain demand
• Governance
• Migrations
• Examples & reference code

Choosing a blockchain for your DePIN (and why you should choose Solana)

There are many reasons to build on Solana, including the deep DeFi ecosystem, the opportunity to collaborate with the world's biggest DePIN projects, and the incredible community of early adopters and deployers. Below, we focus at a high level on some of the technical tradeoffs builders should consider when building a DePIN and reasons to build on Solana from a technical perspective:

• Scalability, combined with market access: Solana's architecture processes thousands of transactions per second–all on a single global state. Solana is unique in its ability to offer best in class scalability, combined with broad access to internet capital markets. Solana's DeFi ecosystem is second to none, simplifying access to the world's biggest internet capital markets.
• Affordability: Solana average transaction costs are ~.00025SOL, enabling microtransactions that are unfeasible on many other chains. Compression technologies like merkelization, cNFTs, and zk proofs also offer opportunities for further cost reduction.
• Ready-made-tooling: Solana offers SDKs, oracles (like Pyth), and frameworks for DeFi and NFTs, to accelerate development cycles.
  • Development framework: Anchor framework provides type safety, IDL integration, and standardized program architecture, reducing boilerplate code by ~40%.
  • Existing protocol integrations: Native interfaces for oracles (Pyth, Switchboard), cross-chain messaging (Wormhole), and identity verification (Solana Attestation Service) reduce integration effort.
• Strong consumer UX: Solana offers a range of best-in-class consumer wallets, including Phantom, Solflare, and Backpack.

Some DePIN teams consider rolling their own chains. Launching a proprietary chain comes with significant added complexity and cost, both from the up front build and requiring continued maintenance. These are some considerations teams should think through:

• Exchange Integration Pipeline: Rolling your own chain requires maintenance of custom node implementations for centralized exchange APIs (approximately 1-2 FTEs annually). This applies to DeFi protocols as well.
• Hardware Security Modules: Developing and maintaining signing applications for hardware wallets like Ledger (3-6 months of engineering work)
• Bridge integration: Proprietary integration with bridges like Wormhole, Chainlink, LayerZero, versus taking advantage of existing infrastructure. These bridges will often charge significant amounts for integration.
• Infra/research talent recruitment: Teams must manage and recruit their own talent to improve the core L1 experience.
• Explorers and analytics integrations
• Custodian and community infrastructure integration: Fireblocks, for example, has a long integration backlog and will charge for integrations.
• Existing DePIN community: It's much easier to gain early adopters among existing DePIN holders, and the largest such community is already on Solana.

We recommend this in-depth technical analysis of why major DePINs have been migrating to Solana. It includes a deep dive on the impact of migrations of major projects onto Solana, including throughput and blockspeed, node growth, and transaction cost.

Notably, Helium started out as a proprietary L1 and migrated to Solana after concluding that running their own chain was too burdensome.

What to use blockchain for in a DePIN

In DePIN, blockchains are particularly good for rewards distribution. DePINs reward node operators for their contributions to the network. These rewards happen in discrete (often small) amounts, are distributed globally, and need to be linked directly to one's contributions to the network. These are all good use cases for blockchain.

DePIN Node operators provide a service that often requires additional computing resources. For example, a mapping company requires somewhere to store data collected through the process of map creation. Unless there's a strong reason otherwise, this mapping data generally should not be stored on a blockchain–it's expensive and a poor use of what blockchain is good at.

Teams often believe that data collected through the servicing of a DePIN should be stored on chain for verifiability purposes (ie, in order to ensure the accuracy of the data and that it was collected without cheating, it must be stored on chain). There are almost always ways to ensure the verifiability of data without storing it all on chain. For example:

• The data can be stored on a decentralized blockchain, unlike Solana, that specializes in data storage (such as Filecoin)
• You can utilize proofs to verify individual nodes' contributions to the network
• Data can be saved on chain using a trusted oracle that allows for saving verifiable proofs of data on chain instead. Tools like Data Anchor from Termina can help with this process.

When building your DePIN, we encourage you to consider what parts of your project belong on chain and which do not. Generally, rewards distributions should happen on chain, and not much else. Rewards are typically distributed in the form of a token, which brings us to token minting and management.

Minting and Managing a Token

Issuing rewards before token launch

TGEs (token generating events) are a business decision, and deciding whether, when, and how to conduct one is your team's prerogative.

Many DePIN projects launch without a live token, in order to make progress in their business before doing a TGE. These projects make their product available to beta users and identify another way (such as points) to track users' contributions to the network, so they can reward them commensurately after tokens are launched. Teams that make this choice often cite the need to better understand the supply/demand dynamics and tackle major bugs in their project before going live.

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.

For most developers, we recommend using the Token Program, unless your team is Solana native and has a deep understanding of the Token22 program, its tradeoffs, and a specific reason why Token22 would be useful to your 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 or Utila for their on chain treasury management, and leverage features such as multi-sig and time-based lockups. Squads allows for multisig setups for treasury wallets and governance and large transfers approval.

One option to manage internal token distributions and vesting is Pulley. For distributions at the protocol level (for example, distributing tokens to contributors), you might check out Magna.

Custodial solutions like Fireblocks or DFNS can be used for internal treasury management, but are much more expensive.

Staking

DePINs can implement staking mechanisms for nodes in the underlying network. This enables the ability to introduce a higher set of staked nodes to participate in consensus protocol (see below) and/or utilize stake to coordinate work and rewards across devices, ensuring economic alignment in the network. Jito Network currently operates Solana's largest stake pool and is building staking infrastructure to enable any DePIN to build custom proof of stake protocol. See the full documentation here.

For example, DAWN is using Jito Network's staking infrastructure to build its proof of bandwidth protocol. In this construction, a set of staked "challenger" node operators are running ping tests on DAWN devices to measure backhaul metrics. This node operator set builds a log of accounts and backhaul metrics, performs an operation on the results to calculate rewards for each device, and submits a log containing claimants, metrics, and rewards to an onchain program to facilitate rewards distributions on Solana. Stake and/or rewards can be slashed or refunded based on results and post-consensus operations.

Rewards Distribution

A critical decision in DePIN architecture design is how and how often to distribute your token. There are three major approaches to rewards distributions:

1. Claim based: Users have to claim their reward. This can be done in multiple ways, detailed further below.
2. Push based: Rewards are directly sent to contributors. It's the most expensive structure, due to the direct nature of the reward distribution.

Of these, a claims-based model is strongly recommended, given its efficiency. There are also ways to combine these models, such as allowing users to automate claiming-on-demand (Helium does this). However, it's recommended to start with one model and then add customizations as your solution scales.

Below, we dig in deeper on how the push and claim based approaches work, and compare the costs of each approach.

Claim based distribution

Users have to claim their reward. This can be done in multiple ways:

• Via an off chain oracle that signs messages that people can use to claim in combination with on chain accounts that save the already claimed rewards
• By co-signing claim transactions via an oracle
• Saving the whole data on chain and calculating the rewards on the demand
• Web2 backend where people authenticate and register with their wallet addresses and sending transactions from the backend on demand

Costs can be reduced by using Merkle tree airdrop on a customizable reward cadence.

Reward distribution via Merkle tree allows 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.

You can also use Tuktuk, a primitive published by Helium, to push reward claims via remote oracle.

Push based 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.

Dispatch is a reference implementation for efficient and secure distribution of PYUSD to many recipients for applications such as Universal Basic Income (UBI) and can be adapted for push-based distribution.

An alternative to Merkle Trees - 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

Storage Costs without compression:

• Saving the claimed amount in a normal Solana account state
• Saving authority, device pubkey and claimed amount comes down to 72 bytes -> 0.001392 SOL in rent cost per account
• Not scaling very well for big networks but has less complexity and the costs can be distributed to the users theoretically

We can extrapolate this across different numbers of reward distributions:

Proof of Contribution / Consensus

DePIN networks generally need a way to prove contributions from network participants. The application needs a method of verifying that participants have provided the resource in question honestly and consistently. As DePIN networks scale, proof of contributions are critical to ensuring the data or resource you're providing are real, a necessary step for teams who want to scale to serve major companies or institutions.

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 model (check out Proof of Coverage by Helium).

In addition, DePINs can incrementally decentralize these offchain proof of contribution processes by introducing node operators that achieve consensus on contributions.

Jito Network is building infrastructure to enable implementing custom consensus protocols (called node consensus networks) that decentralize proof of contribution models. E.g. a distributed set of staked node operators can participate in proof of coverage and achieve consensus on contributions to inform the correct distribution of rewards (and enforce economic penalties). (See "Staking" section above). For more information about Jito's staking infrastructure, see their docs and this implementation guide to walk through key components for building NCNs.

Storage

DePIN networks use a range of options for storage. Remember, it's important to separate between your needs for what needs to happen on chain (primarily, rewards distribution), versus off chain (often, storage of data collected from running nodes, such as photos or video).

One option to store data off chain but verify its existence is Data Anchor, an open-source toolset by Nitro that lets DePIN teams manage off-chain data in a way that's verifiable, tamper-proof, and cheap to anchor on chain.

Logging on-chain demand

DePINs are two sided marketplaces. Supply is facilitated by your node operators, and reflecting supply on chain is a more straightforward process, since it's demonstrable in the token rewards distributed to node operators.

As your project grows, reflecting demand on chain is an important step to bring transparency and trust into your project and the blockchain infrastructure.

There are many ways to reflect demand on chain. One method is through IO.net's model of "Total Network Earnings" or TNE. TNE makes it simple for users to track:

• Total network earnings over time
• Daily earnings trends
• On chain transactions

Helium Mobile takes a similar approach through their Helium World explorer, which maps global hotposts, monthly revenue, daily users, and data transfers.

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.

Read the proposal for Render Network's migration here.

DePIN Migration to Solana

Source: Why Every Major DePIN Project is Migrating to Solana

Examples and reference code

Check out these sample reference implementations that might be useful as you build your DePIN:

• Reward Distribution examples using an offchain oracle and an anchor program writing temperature data and rewarding the users in SPL tokens
• Rewards Distribution "How to" video
• Data Anchor by Termina: Anchor large batches of device data directly on Solana using Termina
• Write Sensor data on chain: How to write sensor on chain using a Solana Pay transaction request
• Claiming Rewards (Helium's approach)

Access the full Solana Foundation DePIN examples repo.

Case studies

Helium's Noah Prince explains how Helium works and the details of Helium's migration to Solana.