The DePIN Sector Is a Tale of Two Extremes
The headlines paint a rosy picture: $19.2B market cap, 270% growth, $740M in VC investment. But when you dig into the project-level data, the DePIN sector looks far more fragile than the sector-level metrics suggest.
The Revenue Reality Check
Let me lay out actual revenue data for notable DePIN projects:
Top Performers:
- Helium: 600K+ subscribers, growing revenue, AT&T integration. Genuine product-market fit.
- Render: Peaked at $746K monthly revenue (December 2024). Real GPU compute demand.
- Grass: Growing data collection revenue for AI training datasets.
Concerning Declines:
- Hivemapper: Revenue dropped from $195K/month (December 2024) to $6K/month (March 2025). That’s a 97% decline in three months. Despite contributor growth of 36% and new hardware launches, the demand for decentralized mapping data hasn’t materialized.
Pre-Revenue or Negligible Revenue:
- The vast majority of the 250 tracked DePIN projects generate little to no revenue
- Many exist primarily as “deploy hardware, earn tokens” schemes without enterprise customers
- Combined DePIN weekly protocol revenue only recently hit $443K — for an entire 250-project sector
The Math That Should Worry You
Let’s do some back-of-envelope math:
- DePIN sector market cap: $19.2 billion
- Combined sector weekly revenue: ~$444K → ~$23M annualized
- Price-to-Revenue ratio: ~835x
For comparison:
- AWS annual revenue: ~$100B, valued at ~$750B (~7.5x)
- Cloudflare annual revenue: ~$1.7B, valued at ~$35B (~20x)
- Traditional telecom: Typically 2-5x revenue
The DePIN sector is priced at 835x revenue. Even if you assume 10x revenue growth in 2 years, you’re still at 83x — far above any comparable infrastructure business.
Where the $740M in VC Money Went
The VC investment breakdown is telling:
- Most capital went to AI-adjacent DePIN (compute, data collection)
- Much less went to physical infrastructure DePIN (energy, wireless, sensors)
- VCs are betting on DePIN-as-AI-infrastructure, not DePIN-as-telecom-alternative
This means the “DePIN growth story” is largely an “AI compute growth story” wearing a DePIN label.
The Hivemapper Case Study
Hivemapper deserves special attention because it illustrates the DePIN failure mode:
- Great idea: Crowdsource mapping data using dashcam-equipped vehicles. Compete with Google Maps.
- Real hardware deployed: Thousands of dashcams mapping roads worldwide.
- Revenue collapse: $195K/month → $6K/month despite contributor growth.
- The problem: Enterprise demand for decentralized mapping data was assumed, not validated. Google Maps is free. TomTom and HERE have decades-long enterprise contracts. Hivemapper’s data quality and coverage can’t compete with established providers.
This is the EigenLayer pattern applied to physical infrastructure: scale supply (contributors/hardware) before validating demand (enterprise customers willing to pay).
What Separates Helium From the Rest
Helium succeeded where others haven’t because:
- Validated enterprise demand first: AT&T, Telefonica needed overflow coverage
- Built consumer product second: Helium Mobile as a direct-to-consumer offering
- Cost advantage is structural: Community-deployed hotspots are genuinely cheaper than carrier-deployed small cells
- Network effects are real: More coverage → more subscribers → more revenue → more hotspot deployments
Most DePIN projects have #3 (cost advantage from crowdsourcing) but lack #1 (validated enterprise demand). Without enterprise customers paying real money, the “revenue” is just token emissions recycled as “rewards.”
Is DePIN real? For Helium and maybe 3-4 other projects, yes. For the sector as a whole, the 835x P/R ratio tells you the market is pricing in hopes, not reality.
Chris’s 835x P/R ratio is damning, but I want to provide technical context on why some DePIN categories are fundamentally harder to monetize than others.
DePIN Category Analysis: Technical Viability vs. Revenue Potential
Tier 1: High Revenue Potential (Validated Demand)
Wireless (Helium): Telcos have a structural cost problem with last-mile coverage. Crowdsourced deployment genuinely solves this at lower cost. Enterprise demand is validated.
GPU Compute (Render, Akash): AI/ML training and inference creates massive compute demand that exceeds supply. Decentralized GPU networks offer lower cost and geographic distribution. Revenue potential is real but competitive (AWS, GCP, specialized providers).
Tier 2: Moderate Revenue Potential (Demand Exists but Unproven)
Data Availability (EigenDA, Celestia): L2s need DA but the market is small and pricing is trending toward zero.
Storage (Filecoin, Arweave): Archival storage demand exists but S3 is so cheap that the DePIN cost advantage is minimal for hot/warm data. Cold/permanent storage is the niche.
Tier 3: Low Revenue Potential (Demand Not Validated)
Mapping (Hivemapper): Chris nailed this — Google Maps is free, enterprise mapping is locked in long-term contracts. The 97% revenue drop tells the story.
Sensors/IoT (most sensor networks): Crowdsourced sensor data has quality and calibration issues that make it unreliable for enterprise use cases.
Energy (most energy DePIN): Regulated industry with complex grid interconnection requirements. Decentralized energy trading is mostly theoretical.
The Technical Differentiation Test
For any DePIN project, ask: What can a decentralized network do that a centralized provider cannot?
- Helium: Deploy small cells at 100x lower cost via community operators. Clear advantage.
- Render: Aggregate idle GPUs globally for burst compute. Advantage in specific use cases.
- Hivemapper: Collect mapping data from dashcams. But Google already has Street View cars, satellite imagery, and phone sensor data. No clear advantage.
Chris’s 835x P/R ratio reflects the market’s failure to distinguish between DePIN projects that have genuine technical advantages and those that are just “centralized service but on blockchain and more expensive.”
The sector will mature when the market prices each project based on its specific revenue trajectory rather than the “DePIN narrative” collectively.
Chris’s revenue analysis exposes the core token economics problem that plagues most DePIN projects. Let me unpack it.
The DePIN Token Sustainability Trap
Most DePIN projects follow the same economic model:
- Issue tokens to incentivize hardware operators
- Token price rises on speculation → operators are profitable
- Operators deploy more hardware → network grows
- Revenue from customers is supposed to replace token incentives
- ??? → Sustainable business
Step 4 is where most projects fail. The revenue never materializes at a scale that replaces the token subsidies.
The Math of Sustainable DePIN
For a DePIN network to be sustainable without token emissions, the revenue from customers must exceed the operating costs of all hardware operators. Let’s model this:
Hivemapper example:
- Hardware operators: ~10,000+ dashcam contributors
- Average operator cost: ~$30/month (dashcam amortization + data upload)
- Total network operating cost: ~$300K/month
- Actual revenue: $6K/month (March 2025)
- Revenue covers 2% of operator costs
Without token emissions subsidizing operator rewards, 98% of Hivemapper operators would shut off their dashcams tomorrow. The network is entirely emissions-dependent.
Helium comparison:
- Hardware operators: Hundreds of thousands of hotspots
- Average operator cost: ~$8/month (Steve’s data)
- Revenue from data transfer: Growing, approaching meaningful share of total rewards
- With AT&T/Telefonica and subscriber revenue, Helium is on a path where revenue could cover operator costs
The key metric for any DePIN project: customer revenue as a percentage of total operator rewards. If this is below 30%, the project is emissions-dependent and the token economics are unsustainable long-term.
What Investors Should Ask
Before investing in any DePIN token, demand answers to:
- What percentage of operator rewards come from customer revenue vs. token emissions?
- At what emission rate does the network break even on customer revenue alone?
- Who are the paying customers, and what’s the contract duration?
- What happens to operator economics after the next emission halving?
Chris’s 835x P/R ratio is the market’s failure to ask these questions. The handful of projects with real customer revenue (Helium, Render) deserve premium valuations. The majority with zero customer revenue deserve… much less.
Chris’s data-driven skepticism is necessary medicine for the DePIN sector. Let me add the entrepreneur’s defense of why early-stage DePIN metrics can be misleading.
The Startup Stage Comparison Problem
Chris’s 835x P/R ratio for DePIN is accurate but potentially misleading. For comparison:
- Amazon in 1999: Revenue $1.6B, Market cap $30B → ~19x P/S. But AWS (which didn’t exist yet) would eventually generate $100B+/year.
- Uber in 2015: Losing $2B/year, valued at $50B. Today generates $37B+ in revenue.
- Tesla in 2013: $2B revenue, $20B market cap → 10x P/S. Revenue is now $95B+.
Infrastructure companies often look obscenely overvalued during the build-out phase because the market is pricing in the POTENTIAL of the infrastructure, not its current utilization.
The Hivemapper Counter-Argument
I agree Hivemapper’s 97% revenue drop is alarming. But context matters:
- Hivemapper is pre-enterprise at scale — they’re still building coverage that enterprise mapping customers need
- Google Maps took 10 years and billions of dollars to build comprehensive mapping coverage
- Hivemapper’s contributor base growing 36% despite revenue decline suggests operators believe in the long-term thesis
That said, Chris is right that contributor growth without revenue growth is a warning sign. At some point, you need paying customers.
What I Look For in DePIN Investments
As someone who evaluates startups for a living:
- The enterprise discovery call: Has the DePIN project had conversations with enterprise customers? Not “partnership announcements” — actual procurement discussions.
- The competitive advantage test: Can this decentralized network genuinely outperform centralized alternatives on cost, coverage, or capability? If the answer is “it’s the same but on blockchain,” that’s not enough.
- The 3-year burn rate: At current emission rates and revenue trajectory, when does the token subsidy need to end? If it’s before enterprise revenue is likely to be meaningful, the project has a runway problem.
Chris is right that most DePIN projects fail these tests. But Helium, Render, and a handful of others pass. The sector isn’t uniformly broken — it’s a power law distribution where the top 5% of projects hold almost all the genuine value.
Chris’s revenue analysis highlights a security dimension that I want to flag: the risk surface of DePIN projects is fundamentally different from pure software protocols, and the sector isn’t adequately addressing it.
Physical Infrastructure Creates Physical Attack Surfaces
Most blockchain security analysis focuses on smart contract vulnerabilities. DePIN introduces an entirely different category: physical infrastructure risk.
Hardware Integrity
- Helium hotspots rely on community-deployed hardware. There’s no guarantee that a hotspot operator hasn’t modified their antenna, spoofed their location, or tampered with firmware.
- Hivemapper dashcams collect data that enterprises rely on. A malicious contributor could submit fabricated mapping data.
- Render GPU nodes process compute jobs. A malicious operator could return incorrect computation results.
Each of these represents a Sybil attack vector that traditional smart contract audits don’t cover.
The Location Spoofing Problem
Helium has historically struggled with location spoofing — operators claiming their hotspots are in high-reward locations when they’re actually clustered in a warehouse. The network has implemented anti-spoofing measures, but it’s an ongoing arms race.
For AT&T offload to work reliably, Helium needs to guarantee that a hotspot claiming to be near a stadium is actually near a stadium. If location verification fails, the entire enterprise use case collapses.
Data Quality Risk
Chris’s point about Hivemapper’s revenue decline connects to a data quality problem. Enterprise customers need verifiable data quality. Crowdsourced data inherently has noise — incorrect labels, outdated captures, inconsistent coverage. Without robust quality assurance mechanisms, enterprise customers won’t pay for DePIN data regardless of price.
The security lesson: DePIN projects need physical verification mechanisms (proof of location, data quality attestation, hardware integrity checks) that are as rigorous as smart contract audits. Most DePIN projects treat these as afterthoughts, which limits their enterprise credibility.
The projects that solve physical verification at scale — proving that real hardware in real locations is doing real work — will be the ones that survive Chris’s revenue reality check.