The DePIN Utility Trilemma

Why speculative tokens undermine real infrastructure adoption

Author

Steven Johnson

Published

January 9, 2026

Keywords

DePIN, decentralized infrastructure, blockchain infrastructure, token economics, DePIN tokenomics, enterprise blockchain, Web3 infrastructure, decentralized storage, decentralized compute, Filecoin, Helium, Arweave

Decentralized infrastructure networks (DePIN1) promise something ambitious: real-world utility (storage, compute, AI, bandwidth, etc), priced and coordinated by crypto-native tokens.

The theory is well known. Tokens incentivize supply, price demand, and align participants without central control.

But this is how I have seen it play out:

Scenario 1: The Budget Meeting

A CTO at a Web3 company proposes switching from AWS to decentralized storage. The numbers are compelling: 30% cost reduction, censorship resistance, aligns with company values.

CTO: “Annual infrastructure cost would be $500,000 at current prices.”

COO: (checks phone) “What token price are you using?”

CTO: “$0.45.”

COO: “It’s at $0.32 now. Wouldn’t that make it $355,000?”

CTO: “Well, yes, at this exact moment, but—”

CFO: “The number is changing while we’re in this meeting?”

CTO: “Markets are volatile, but over the long term—”

CEO: “I can’t present a budget to the board where the cost changed while I was presenting it. We’re staying with AWS.”

The technology worked. The economics didn’t.

Scenario 2: The Architect’s Dilemma

An architect designs a new service. The requirements point to decentralized compute: better reliability, lower cost, no vendor lock-in.

She runs the numbers: AWS EC2 costs $200K/year. The decentralized alternative costs $100K at current token prices. SLIs comparable or better.

She submits the proposal.

Procurement rejects it: “We only use AWS EC2.”

She escalates: “But it’s half the cost and meets all requirements.”

Procurement: “AWS costs are predictable. Your solution’s costs aren’t. Denied.”

The cheaper, better solution lost to predictability.

Scenario 3: The Startup’s Plateau

A startup builds decentralized AI infrastructure. The technology is impressive: promises better SLIs than centralized alternatives, 40% cheaper, resistant to censorship, enhanced privacy.

VCs fund it. The token appreciates. Early crypto-native users adopt enthusiastically.

Then they target enterprises. The conversations follow a pattern:

Enterprise: “This is interesting. Tell us more.”

[Technical evaluation]

Enterprise: “The technology looks solid.”

[Pricing discussion]

Enterprise: “We’ll get back to you.”

[Silence]

The startup optimized for token upside. They believed passionately in decentralization. They had superior technology, economics and privacy.

But they couldn’t get past “interested” to “deployed.”

Casual users adopted. Enterprises ghosted.

The Pattern

I work in Web3 infrastructure. I see variations of these stories constantly.

The pattern is always the same:

  1. Technology works
  2. Crypto-native adoption succeeds
  3. Enterprise evaluation begins
  4. Enterprise chooses centralized alternative
  5. Project plateaus

This isn’t poor execution. It’s structural.

I believe there’s a DePIN Utility Trilemma that explains why.

A decentralized infrastructure token cannot simultaneously achieve:

  1. Budgetable Price Stability
  2. Free-Floating Token Value
  3. Credible Decentralization

You can pick two.
No DePIN system I am aware of today achieves all three.

Why This Matters

I care deeply about decentralization succeeding. I want centralized services to lose their monopoly over infrastructure. I want censorship-resistant infrastructure to be real, not rhetorical.

But we’re losing ground not because our technology doesn’t work—it does—but because we’re optimizing for the wrong things. We built systems that traders can use, not systems that organizations can rely on.

This isn’t a call to abandon DePIN. It’s a call to be honest about the constraints we face, so we can design systems that actually achieve the adoption we claim to want.

The Three Axes

1 - Budgetable Price Stability

Serious organizations operate on budgets.

Infrastructure spend must be:

  • forecastable over years,
  • bounded in downside risk,
  • defensible to boards and auditors.

If the pricing unit for infrastructure can swing wildly in purchasing power relative to the relevant cost base, it cannot be approved as OPEX2 or CAPEX3, regardless of its current comparative value compared to Saas alternatives. A system whose costs cannot be budgeted cannot be relied upon for infrastructure, regardless of how innovative its incentives are.

This is not a crypto-specific constraint. It is how organizations function.

Procurement doesn’t optimize for cheapest infrastructure. It optimizes for predictable infrastructure, and even perceived stability is worth a premium.

“Budgetable price stability” must be bilateral: both purchaser and supplier must be able to predict costs and revenues in their respective budget currencies.

If either side is forced to bear speculative token volatility, budgeting fails.

Some DePIN systems stabilize the purchaser (via fiat-pegged credits) while leaving suppliers paid in volatile tokens. This is not bilateral stability. It merely shifts volatility risk onto providers.

This is especially critical in decentralized systems because participants budget in different currencies. A purchaser budgeting in USD and a supplier budgeting in JPY can both tolerate normal FX drift. Neither can tolerate that baseline risk plus a settlement token that can 10× or drop 90% on short timescales. When token volatility dominates operating margins, suppliers are forced into speculation, not infrastructure provision.

2 - Free-Floating Token Value

A free-floating token is one whose value is set entirely by external markets:

  • no peg,
  • no stabilizing reference,
  • no supply or demand constraints tied to an external index,
  • thin liquidity relative to global capital.

DePIN projects rely on free-float to bootstrap: speculative upside attracts early capital and incentivizes infrastructure providers to invest in hardware before utility demand exists. Without the promise of token appreciation, how do you fund network buildout?

But this creates the volatility that prevents enterprise adoption.

USD is also a floating currency, but the comparison breaks down immediately.

USD is stabilized by:

  • sovereign taxation and spending,
  • deep bond and FX markets,
  • global hedging instruments,
  • legal mandate.

A DePIN token has none of these. In this context, “floating” means unbounded volatility, not gradual macro drift.

3 - Credible Decentralization

This is the mission: removing dependency on institutions that can be compelled, censored, or fail. Its the first part of the name DePIN (Decentralized Physical Infrastructure Network)

If stability is achieved through:

  • a custodian,
  • a discretionary treasury,
  • a foundation with emergency powers,
  • a freeze or blacklist authority,

then decentralization is compromised.

What “credible” means:

Decentralization exists on a spectrum. For this analysis, credible decentralization means:

  • Permissionless participation (anyone can join as provider or user)
  • No censorship authority (privileged set of participants can block transactions or freeze accounts)
  • No required intermediaries (users can interact directly with the network)
  • Survives the founding team (network continues if the original company/foundation disappears)

This is stronger than:

  • Multiple servers (still centrally controlled)
  • Federated systems (requires trusting the federation)
  • “Decentralized” services that route through company gateways

Decentralization also implies that a third party can run an independent gateway / client and fully participate without using a hosted endpoint or centrally issued credentials.

The DePIN Utility Trilemma

The tension between these three properties can be visualized as a simple “pick two” constraint:

The DePIN Utility Trilemma - Pick Two
    1. Budgetable Price Stability + (2) Free-Floating Token Value
    1. Free-Floating Token Value + (3) Credible Decentralization
    1. Budgetable Price Stability + (3) Credible Decentralization

What Each Pairing Actually Produces

(1) Budgetable Price Stability + (2) Free-Floating Token Value

Outcome: Centralized infrastructure with market-priced services

This is AWS, Google Cloud, and every traditional cloud provider (collectively known as Hyperscalers).

The “token” is USD (or EUR, etc.) which is free-floating on global currency markets and budgetable for enterprises because of deep liquidity, hedging instruments, and sovereign backing.

Services are priced in fiat. Enterprises can budget confidently.

But decentralization is entirely sacrificed:

  • A Hyperscaler controls the infrastructure
  • They set the rules unilaterally
  • They can terminate service at will
  • Governments can compel them
  • Single point of institutional control

Hyperscalers are highly distributed (data centers globally) but highly centralized (one company controls it all).

This is the incumbent model DePIN is trying to disrupt.

(2) Free-Floating Token Value + (3) Credible Decentralization

Outcome: A volatile asset that cannot serve as an infrastructure pricing unit

This is where most DePIN systems live today.

The token:

  • floats freely,
  • is traded speculatively,
  • has no stabilizing authority.

This preserves decentralization. No one can intervene.

The cost:

  • unbounded volatility,
  • no way to budget usage,
  • providers exposed to FX-like risk they cannot hedge,
  • boards unable to approve long-term commitments.

Utility demand becomes secondary to trading volume. Adoption therefore tends to plateau at hobbyist, ideologically motivated, or speculative use.

Some organizations will adopt DePIN on philosophical grounds despite volatility. That is a real market. But it is not the adoption DePIN pitches when it claims it will replace mainstream infrastructure. Mainstream infrastructure adoption requires budgetable pricing and bounded risk.

Example: The CFO Question

A company evaluating decentralized storage today faces this:

  • Current cloud storage: $5,000/month, predictable
  • DePIN alternative: 100 tokens/month
  • Token price today: $50 (so $5,000/month—competitive!)
  • Token price 6 months ago: $200 (would have been $20,000/month)
  • Token price 18 months ago: $15 (would have been $1,500/month)

The CFO asks: “What will our Q3 and Q4 budget be?”

There is no answer. The service works perfectly. The pricing is unusable.

This is not a hypothetical. How many Web3 companies exist that run their infrastructure on Google Cloud or AWS because they cannot get budget approval for speculative infrastructure costs?

(1) Budgetable Price Stability + (3) Credible Decentralization

Outcome: A non-floating, non-speculative pricing unit

This is the theoretical target DePIN has not reached.

Achieving both requires:

  • a pricing unit stable enough for budgeting for both supplier and purchaser,
  • no custodian or discretionary authority,
  • and no speculative free-float behavior.

It implies abandoning the idea that the token itself should behave like an investable asset.

No deployed DePIN system I am aware of has demonstrated this successfully.

Why “Utility-Bounded Tokens” Don’t Stay Bounded

A common DePIN thesis goes like this:

Token value is bounded by utility.
Storage costs X, so rational providers sell at X plus margin.

This assumes utility demand dominates token price formation.

It does not.

Once the token floats freely:

  1. Speculative volume overwhelms utility volume.
    Market price is set by traders, not users.

  2. Every participant resets cost at buy-in.
    Real cost is always:
    fiat price of token at purchase × tokens required for service.

  3. Providers inherit unhedgeable FX risk.
    They must constantly reprice to survive volatility, or absorb losses.

Even if the service is stable, the pricing unit is not. The theoretical utility bound collapses.

NoteA Note on Exchange Value vs Use Value

This phenomenon (where speculative exchange value overwhelms actual use value) echoes a pattern Marx identified in Capital (1867).

Marx observed that when commodities are produced for exchange rather than direct use, their market price (exchange value) can diverge from and dominate their actual utility (use value).

In DePIN, tokens are designed to serve both functions simultaneously:

  • as infrastructure pricing units (use value); and
  • as speculative assets (exchange value).

As Marx stated, and we can observe on any CEX, the exchange value invariably dominates.

This isn’t unique to crypto. It happens with any commodity that becomes financialized. But crypto makes it explicit by designing tokens to be both utility instruments and investment vehicles.

The problem compounds when the utility itself is scarce or tradable:

When the resource being priced has its own scarcity dynamics, such as naming rights, blockspace, limited compute slots, then there are now two independent sources of volatility:

  1. the resource’s scarcity and demand,
  2. the token used to pay for it.

This is speculation squared.

No board can price that risk.
No long-term contract can survive it.

The Consequence

If you choose free-float and decentralization, you exclude serious utility users.
If you choose stability, you introduce central control.
If you attempt all three, one of them is illusory.

This is the DePIN Utility Trilemma.

It explains why DePIN systems generate attention but rarely become infrastructure.

Why This Isn’t Just “Early Days”

Some will argue DePIN simply needs more time. That as markets mature, volatility will decrease and utility will dominate price discovery.

I don’t think time solves this.

The problem isn’t market immaturity. It’s structural incompatibility.

As long as:

  • tokens are freely tradable,
  • speculation is permissionless,
  • and global capital can flow in and out,

then utility demand will always be dwarfed by speculative volume. A DePIN token with $10M per year in actual infrastructure usage can have $100M or more in daily trading volume. Price formation is dominated by the larger flow.

“Waiting for maturity” means waiting for speculation to die. But speculation won’t die as long as tokens are designed to be investable assets. That’s the contradiction at the heart of current DePIN design.

What This Means for Builders

If you’re building DePIN today, this trilemma should inform your design choices from day one:

Be explicit about which two properties you’re choosing.

  • If you choose free-float + decentralization: acknowledge you’re building for ideologically motivated users, not Fortune 500 procurement departments. That’s a real market, but be honest about its size.
  • If you choose stability + free-float: acknowledge you’re introducing monetary policy functions. Design those functions transparently and enforce their constraints rigorously. You also should accept that your sacrificing decentralization.
  • If you choose decentralization + stability: Explain how you achieve stability without introducing centralization.
  • If you’re attempting all three: explain the mechanism. The industry needs solutions, not wishful thinking.

The failure mode isn’t choosing “wrong”. It’s choosing implicitly, then wondering why adoption doesn’t match the pitch.

An Open Problem

I am not claiming the trilemma is unbreakable.

I am saying this: No DePIN system that I have observed to-date has solved it.

The implication is uncomfortable: if DePIN wants enterprise adoption, projects must prioritize stability and decentralization over free-float. This means the infrastructure token cannot be a speculative investment with unlimited upside.

That’s difficult. Free-float enables the capital formation that bootstraps these networks. Without speculative upside, how do you incentivize early providers to invest in hardware?

This is the fundamental tension: the mechanism that builds the network prevents the network from being used.

If you believe a system can deliver:

  • budgetable stability,
  • credible decentralization,
  • and a pricing unit that does not collapse into speculation,

then show how.

Until then, every DePIN project must answer one question:

Which two properties did you choose, and which one are you pretending you didn’t sacrifice?

About the Author

Steven Johnson is Technical Architecture Manager - Project Catalyst at Input Output Group (IOG), where he works on Cardano’s decentralized funding mechanism. He has been professionally involved in blockchain systems since 2022. He cares deeply about decentralization succeeding at scale.

For discussion: X/Twitter | LinkedIn | Email

The views expressed here are the author’s own and do not represent IOG or Cardano.

Footnotes

  1. What I Mean by DePIN (for this article)

    DePIN (Decentralized Physical Infrastructure Network) refers here to a system that is decentralized at production scale, not merely at inception. For the purposes of this article, a system qualifies as DePIN only if:

    Operators are decentralized: the infrastructure is run by many independent parties, with permissionless entry and exit, and the network continues to function without operational dependence on the original company or foundation.

    Coordination is decentralized: users and operators can interact without mandatory company-hosted gateways, centrally issued access credentials, or discretionary off-chain control over pricing, rewards, or participation.

    Bootstrap centralization is temporary: early centralization may exist, but there must be a concrete, technically credible path to removing it once the system reaches production scale.

    Systems with decentralized operators but centralized coordination may be transitional, but they are not fully DePIN under this definition.↩︎

  2. OPEX (Operating Expenditure): Ongoing day-to-day costs required to run the business and deliver services within the current period; typically expensed on the income statement when incurred (e.g., salaries, rent, utilities, cloud hosting, routine maintenance, subscriptions, marketing).↩︎

  3. CAPEX (Capital Expenditure): Spending to acquire, build, or improve long-lived assets that provide benefit over multiple periods; typically recorded as an asset on the balance sheet and expensed over time via depreciation or amortization (e.g., servers/network equipment, leasehold improvements, purchased software licenses or internally developed software that qualifies for capitalization, major upgrades).↩︎