DePIN Revenue vs Emissions: Monthly Burn and Mint Report
Each month, the tokens every major DePIN network burned for usage set against the tokens it emitted as rewards, cited to the chain.
Multi-chainSolanaTable · StrataPlanned
DePIN Revenue Leaderboard: On-Chain Fees and Burns
Which DePIN networks earn the most revenue on-chain?
DePIN networks ranked by revenue paid on-chain through burns, fees and lease payments, with off-chain reported revenue labelled apart.
ShareEmail it
Blueprint
What the table will hold.
The table as it will open in Strata. Each figure is named here and arrives with its receipt; until its data is published, its place stays empty.
One row One row per DePIN network, over the latest 30 complete daysSorted by On-chain revenue, 30 days, highest first
| Network | Category | Chain | On-chain revenue, 30 daysUSD | Paid through | Tokens burned, 30 daystokens | Emissions, 30 daysUSD | Revenue to emissionsratio | Reported off-chainUSD | Change on prior 30 days | Receipt |
|---|---|---|---|---|---|---|---|---|---|---|
- Network network Text
- The DePIN network and its token.
- Category category Text
- What the network sells: wireless, compute, mapping, storage or energy.
- Chain chain Chain
- The chain where its customer payments settle.
- On-chain revenue, 30 days revenue_30d Exact amount
- Customer payments for usage over the last 30 days, from burns, fees or lease settlements, valued at the time of each payment.
- Paid through revenue_type Text
- How customers pay on-chain: token burn, stablecoin fee or escrow lease.
- Tokens burned, 30 days burned_30d Exact amount
- Network tokens burned for usage over the last 30 days, in the token's own units.
- Emissions, 30 days emissions_30d Exact amount
- Value of the tokens issued to operators and stakers over the last 30 days.
- Revenue to emissions revenue_to_emissions Number
- On-chain revenue divided by the value of emissions over the same days; one means usage covers rewards.
- Reported off-chain offchain_revenue Exact amount
- Revenue the network reports off-chain, with its period and source, never added to on-chain revenue.
- Change on prior 30 days change_30d Percent
- On-chain revenue against the 30 days before.
- Receipt receipt Link
- The burns, payments and price reads behind the row.
Filter by Category, Chain, Paid through.
About
What it answers, and for whom.
Decentralized physical infrastructure networks sell real services, such as wireless coverage, GPU compute, map data and storage, and many collect payment on-chain. Some burn their token when a customer pays, some take a fee in stablecoins and some settle leases from escrow. This table ranks networks by the revenue that can be read from those transactions.
Revenue is kept to what customers paid for usage. Token emissions to operators are shown beside it, not added to it, and revenue that a network reports off-chain, from enterprise contracts or card payments, sits in its own column and is labelled as reported. The ratio of on-chain revenue to emissions shows how much of what a network pays its operators is covered by usage.
Filter by category to compare networks of the same kind, such as wireless with wireless or compute with compute, and open any figure to see the burns, payments and prices it was summed from.
Method
How it will be measured.
Every figure will be read at a block, kept with its source and its exact read, and open a receipt anyone can re-check.
How receipts work →- Helium revenue is the USD value of Data Credits burned for network usage on Solana. Data Credits are minted only by burning HNT at a fixed dollar price, so the burn measures what customers paid; onboarding and location fees are counted apart.
- Render revenue is RENDER burned for completed work under its burn-and-mint model, and Hivemapper revenue is HONEY burned for map credits, both read from their burns on Solana.
- io.net revenue is customer payments and IO burns read from their transfers on Solana, and Akash revenue is lease settlements from its escrow module on the Akash chain.
- Burned tokens are valued at DEX pool prices at the burn block; payments in stablecoins are counted at face value.
- Off-chain reported revenue is recorded with its source and period and is never added to on-chain revenue.
The data it needs
Chain data, with some off-chain sources
- depin_networks_dailyTo buildDePIN networksUsage and token flows of decentralized physical infrastructure networks: burns for usage, emissions to operators, and active nodes where on-chain.
- protocol_revenue_dailyTo buildProtocol fees, revenue and buybacksFees users paid to each protocol and the part kept by the protocol or its token holders, per protocol and day, including buybacks.
- dex_swaps_dailyTo buildDEX volumeSwap counts and volume per DEX, pool and chain per day, decoded from Swap events, valued with stablecoin legs and oracle prices.
- Helium Data Credit burns on Solana
- Render burn-and-mint burns per epoch on Solana
- Hivemapper HONEY burns for map credits on Solana
- io.net IO burns and customer payment transfers on Solana
- Akash escrow lease settlements on the Akash chain
- Token USD value at burn time from DEX pool prices
- Network-reported off-chain revenue, labelled as off-chain
Questions
Questions people ask.
What is DePIN revenue?
The money customers pay a decentralized physical infrastructure network for its service, such as data transfer, compute time or map data. Here it counts only what is paid for usage, not the tokens issued to operators.
Why are token burns counted as revenue?
In burn-and-mint networks, customers pay by burning the network's token, often after buying it, in exchange for credits priced in dollars. The value burned is what customers spent, so it is the network's on-chain revenue.
What is the difference between revenue and emissions?
Revenue is what customers pay. Emissions are new tokens the network issues to operators as rewards. A network can pay operators far more in emissions than it earns, so the two are always shown apart.
Why is some DePIN revenue off-chain?
Some networks sell to businesses under contracts paid by bank transfer or card, and move value on-chain later, if at all. That revenue is shown as reported, with its source, because it cannot be read from transactions.
Which DePIN networks are included?
Networks whose customer payments can be read on-chain: Helium, Render, Hivemapper, io.net and Akash at first, with more added as their payment contracts are mapped. Each row names the chain and the contracts its revenue comes from.
- DePIN
- Decentralized physical infrastructure network: a network that pays operators in tokens to provide real-world services such as wireless coverage or compute.
- Burn-and-mint equilibrium
- A token model in which customers burn tokens to pay for usage and the network mints new tokens to reward operators.
- Data Credits
- Helium's usage credits, created only by burning HNT and spent to send data over the network.
Related
More apps like this.
Helium Network Stats: Data Credit Burns and Hotspots
Helium's Data Credit burns, HNT burned against HNT emitted and hotspots onboarded by subnetwork, all read from Solana.
SolanaDecentralized GPU Compute: Render, io.net, Akash Usage
What customers pay on-chain for decentralized GPU compute each month on Render, io.net and Akash, beside the rewards each emits.
Multi-chainSolanaDeFi Protocol Revenue and Fees Ranking
DeFi protocols ranked by the fees their users pay and the revenue they keep, over 24 hours, 30 days and a year, with each one's take rate.
Multi-chainEthereumBase+3Crypto Token Buybacks Ranked by Amount Spent
Which protocols spend the most buying back or burning their own tokens, what pays for it and what share of supply the purchases remove.
Multi-chainHyperliquidSolana+4Hivemapper Network Stats: HONEY Burns, Rewards and Mapping
HONEY burned for map data and issued to contributors each week on Solana, the network's net supply change and reported mapping coverage.
SolanaBuild DePIN Revenue Leaderboard: On-Chain Fees and Burns on verified data.
Start free in Voltfin Studio: boards, tables and reports where every number opens its receipt. Tell us which data you need first and we will build it next.