How Compute Networks Turn Usage Into Token Value, and Why Morpheus Doesn't Burn

A decentralised compute network has to answer one question, and the answer decides whether its token is worth holding. When someone uses the network, how does that usage turn into value for the token? Get it right and demand scales the token with adoption. Get it wrong and the token is a subsidy coupon that inflates while the product runs.

There are three working answers in the market today, and they sit on different mechanisms. This piece compares the architectures, then spends most of its time on the outlier. Morpheus is the only one of the four networks here where the value engine is separate from the service it sells, and it removed the compute burn its original design contained. That decision is defensible, but it leaves a gap, and there’s a clean way to close it.

I hold MOR (capital pool, six-year Power Factor lock) and stake MOR for inference access. I also hold AKT and RENDER, and I don’t hold IO. All disclosed, and none of this is investment advice: it’s analysis of protocol mechanics. MOR in particular is a small-cap token with thin liquidity and an unproven demand thesis, so size any position for that reality.

The Three Archetypes

Strip the marketing off each network and you get three distinct designs for converting usage into token value.

The first two route usage straight into the token. The third routes around it. That structural fork is the whole article, so it’s worth taking each in turn before judging Morpheus against them.

Archetype One: Burn-Mint Equilibrium

Burn-Mint EquilibriumBurn-Mint EquilibriumA tokenomics model where network fees burn tokens while new tokens are minted and paid to suppliers. The system tries to balance burns and mints so circulating supply stays roughly stable when usage scales.Like a business that spends a dollar of revenue for every dollar of wages it pays. Money flows in and out at the same rate, so the total cash in the company stays flat. The rate of flow tells you how big the business is.Read more → (BME) decouples the price a user pays from the token’s price. The user pays in stable or work-denominated units, the protocol mints new tokens to reward providers, and it burns tokens in proportion to actual usage. The user gets price stability, the provider gets paid, and the token gets a sink that scales with demand. It solves the paid-in-a-volatile-token problem and creates a usage-scaled burnBurnPermanently removing tokens from circulation by sending them to an address that no one controls. Burns reduce total supply, which (all else equal) makes each remaining token worth more of the network's value.Like a company buying back its own shares and shredding them. The company's total value stays the same, but each remaining share now represents a slightly bigger slice of that value.Read more → in one mechanism, which is why it’s the design most compute networks have converged on.

Akash switched on BME (AEP-76) on 23 March 2026. A tenant funds compute, AKT is burned at the oracle price, a dollar-pegged compute credit is minted, and the provider is paid in reminted AKT at the settlement price. If AKT rises between top-up and settlement, fewer tokens are reminted than burned, and the network nets a burn.

Render runs its own BME: a creator pays for a render job, 95% of the RENDER spent is burned, 5% goes to OTOY, and operators are paid from a separate declining emission. Two implementations, one principle: usage removes supply.

Here’s the limit the BME case usually skips. BME captures demand into token value, but it can’t manufacture demand. A burn beats the mint only once usage clears a threshold; below that, the network is net inflationary.

• Akash booked $3.15M of on-chain revenue across 2025 (Messari, +128% year on year), enough to drop effective inflation from 8% to roughly 7.1% at current usage, not enough to reach net deflation. Usage softened into Q4 2025 (Messari Q4 2025: quarterly revenue around $463,200, active GPU leases down), so the sink shrank with it.
• Render still emits roughly 492,000 RENDER a month against burns near 121,000 (September 2025, Render Foundation), an eight-to-one gap, despite burns growing 279% year on year.

So BME is a value-capture mechanism, not a demand-creation one. Akash and Render depend on paying usage exactly as Morpheus does. The difference is that BME pipes that usage straight into the token, and it needs a payer to do it: someone has to spend value that gets converted to a burn.

Archetype Two: Dollar-Target Payouts

io.net activated its Incentive Dynamic Engine (IDE) on 11 June 2026, and it’s the most interesting variation because it does two jobs at once. On the supply side, GPU providers now receive USD-pegged payouts funded from reserves, so their realised income holds even when IO swings (io.net’s litepaper). That de-risks the provider directly, rather than burning usage into the token and hoping the token holds its value. It’s a different answer to the volatility problem BME solves by indirection.

On the value side, io.net bolts a burn onto the same engine. After suppliers are paid, at least 50% of the leftover revenue funds automated buybacks, and the repurchased IO is burned (io.net). The company guides to a minimum 12M IO burned in the IDE’s first year, on current earnings and pipeline. Treat that as guidance, not a result: io.net’s revenue is self-reported and not independently audited, a verification gap I’ve covered before, so the burn that depends on it inherits the same discount.

The point for the comparison is that io.net pairs a payout stabiliser with a revenue burn. It stabilises what the provider earns and ties token value to revenue at the same time. That makes it a managed version of archetype one, not a third thing entirely. The token still scales with usage through a buyback rather than a direct burn, and that buyback-from-a-paid-tier idea is exactly what Morpheus is missing.

Archetype Three: Morpheus, The Structural Fork

Morpheus splits its daily MOR emissions five ways: 24% each to Capital, Code, Compute, and Community, plus 4% to a Protection Fund. Akash and Render put the value engine in the compute pillar, where usage burns the token. Morpheus puts it in the capital pillar instead.

Deposited yield does the work. A capital provider stakes stETH (and, since September 2025, USDC, USDT, or WBTC via Aave), keeps the principal, and the yield is redirected: under MRC43, roughly 75% buys MOR on the AMMAMMAutomated Market Maker. A type of decentralised exchange that uses liquidity pools and a pricing formula to enable token trading without an order book. Anyone can deposit tokens into the pool and earn fees from trades.Like a vending machine that sets its own prices based on how much stock is left. As one type of token gets bought and depleted, the machine raises its price for that token automatically. As the other type accumulates, its price drops. No human operator needed.Read more → and the rest pairs as protocol-owned liquidityProtocol-Owned LiquidityLiquidity that a protocol owns directly instead of renting from outside providers. The protocol funds and holds its own AMM position, so the trading depth is permanent and can't be pulled when farming rewards dry up.Like a marketplace that owns the building its traders work in, rather than renting stalls week to week. Renters pack up the moment a better deal appears elsewhere. An owner stays put, so the floor never empties out from under the people trying to buy and sell.Read more →. That bid exists whether or not a single inference runs.

Compute, meanwhile, is designed to be free to the user. On the staked-access path, which is about 96% of sessions, the user’s MOR deposit is returned in full at session close, and the provider is paid from the 24% compute emission. The service is subsidised by emissions, not bought by users.

So compute is monetised only indirectly, through holding-demand. You hold MOR to receive an inferences-per-second quota, an access right rather than a spend. The architectures end up answering the value question in opposite ways.

That fork is the centre of the design, and it cuts both ways. It’s a strength, because inference can be free, and free private inference is the whole demand thesis. It’s a weakness too, because compute usage accrues no value directly to the token, leaning on soft holding-demand instead of a hard usage sink. Of the four networks here, only Morpheus detaches the value engine from the service, and it did so deliberately.

The Compute-Burn Gap, Confirmed

There is no burn tied to compute use in Morpheus. The only protocol burn is MRC43, on the capital side: deposited yield buys MOR, pairs it as protocol-owned liquidity, and of the MOR left after each liquidity event, half is permanently burned and half is reserved for tail emissions. That burn scales with TVL and yield, not with inference. Roughly 275,000 MOR has reached the burn address to date (June 2026), and the rate has slowed as deposits fell.

On the compute side, nothing burns. The staked-access path returns the user’s MOR in full, and the direct-pay path (about 4% of sessions) transfers MOR 1:1 to the provider, which is a transfer, not a burn. The full payment trace, indexed off our own node, is in How Morpheus Pays for Inference. The MRC index shows no active or in-progress proposal adding a compute-use burn.

The history is the sharp part. The original 2022 whitepaper did contain a compute burn: a pro-rata MOR fee burned by each compute provider as proof of status, a burn-to-earn mechanism. The Yellowstone model, written by Erik Voorhees and published on 3 January 2024, deliberately removed per-inference transactions to fix gas costs and the user experience, and the burn went with them. Morpheus stripped out its compute-linked burn on purpose; it didn’t omit it by accident.

Fact: Morpheus settles roughly 208 MOR a day to providers (OYM inference tracker, 30 days to 8 June 2026), about 96% of it on the staked path that burns nothing, on a provider set of two to seven addresses most days.

Take: At that volume, a compute-use burn would burn almost nothing, so its absence costs almost nothing today. What binds the token now is weak demand, and a sink does nothing about that. The sink matters later, once usage scales, and a design you add under load is harder than one you reason about now.

Should Morpheus Add A Compute-Use Burn?

The case for is straightforward. A compute burn would tie MOR value directly to inference demand, which is the link the valuation is missing. It would add a usage-scaling sink, the feature that makes BME attractive. And it would help the token’s value equation invert sooner, the day demand and sinks finally exceed emissions.

The tension is that a naive BME bolt-on would break the one thing that makes Morpheus different. A burn needs a payer, and there are only two candidates, both bad:

• Charge the user a burn per inference. You reintroduce the per-inference cost and gas friction Yellowstone existed to remove, and you lose the free private inference thesis that is Morpheus’s main demand argument.
• Make the provider pay it from their emission. You worsen already-thin provider economics and shrink supply, on a marketplace that runs near a single active provider on most days.

And a burn only bites once real demand exists, so it doesn’t fix today’s problem, which is the absence of demand, not the absence of a sink. So what would actually work? Three options preserve the free-inference position while adding the value link:

• Burn a slice of the compute emission itself, scaled to inference served. Issuance self-cannibalises as usage grows, with no cost to the user. The more the network serves, the faster its own emission shrinks.
• Burn only on the direct-pay tier. A payer already exists there, so a BME-style burn fits without touching the free staked path. The catch is that direct-pay is a rounding error today.
• Add a paid inference tier for agents and enterprises, and attach the burn to that tier. Given the move toward USDC reserves under the recent MRC work, there’s a cohort that will pay: regulated and agent workloads that need confidential, attested inference. Burn against that tier, leave the free staked tier intact.

That last option is the coherent one. A free staked tier for sovereignty-minded users, plus a paid-with-burn tier for buyers who’ll pay anyway, captures the value-accrual benefit of BME without sacrificing free private inference. It’s the same shape io.net just shipped: revenue from those who pay funds a buy-and-burn, while the headline service stays cheap. It’s MRC-worthy, and it’s the constructive version of this whole critique.

Valuing MOR From The Design: Five Lenses

No price target here, and nothing that follows is advice. These are five frames for reasoning about where MOR value comes from, each with its own assumptions stated.

Capital-engine lens. The structural demand floor is a function of TVL, yield, and the buy share. Near the mid-2024 peak around $579M TVL at a blended 3 to 4% yield, MOR buybacks ran on the order of $8 to 12M a year. At roughly $13M TVL today, the same maths gives something closer to $200,000 to 300,000 a year. The collapse from $579M to about $13M is the single largest problem for the value thesis today, larger than the compute question, and TVL is the most informative single number to track because it’s the leading indicator of that structural bid.

Access-token lens. Value MOR as a claim on daily inference capacity. Holding-demand approximates inference dollar throughput divided by a velocity-adjusted access value. It’s near zero today. This is the option that has to come good for the compute side of the thesis to mean anything.

Float-and-sinks lens. Model circulating supply from the known curve (14,400 MOR a day at launch, declining a fixed 2.468994701 a day to zero on day 5,833, roughly 16 years out, against a 42M hard cap), then subtract burns and locked stake. The tail rule is the structural feature: each subsequent period emits 50% of the MOR burned in the prior one, capped at 16% of circulating supplyCirculating SupplyThe number of tokens currently in circulation and tradeable on the open market. Differs from total supply (which includes locked or unvested tokens) and max supply (the upper limit, if there is one).Like the number of cars on the road today versus the number ever produced. Some are in showrooms, some in junkyards, some still at the factory. Only the ones on the road count toward what people are actually driving.Read more →, so issuance is always less than was previously burned, making MOR scarcer each period, contingent on burns actually happening. The float is small and liquidity is thin (MOR trades down around 98% from its high), which means modest demand shifts move price disproportionately in both directions. A small float isn’t a value floor.

Reflexivity lens. The dollar compute budget (MaxIPS equals the MOR budget times MOR price divided by the IPS price) and the capital rewards both scale with MOR price, so MOR behaves like a levered option on the network reaching demand escape velocity. Strength compounds strength and weakness compounds weakness, with only the 4% Protection Fund and the asymptotic budget rule as counter-cyclical brakes. Discounted cash flow is the wrong tool here. Scenario and option framing fit the reflexivity better.

Sum-of-pillars lens. Net token value is, summed across the four pillars, demand created plus sinks created minus emission dilution. Today the pillars cost more in emission than they create, so MOR sits in net structural sell, and the bull case is simply that this inverts as compute demand, TVL, and burns scale. The sharpest way to pose it: at what date, if ever, does demand plus sinks exceed emissions, and what probability do you put on it? A compute-use burn is one of the few design changes that would bring that date forward.

One thing the lenses share is that locked supply is doing a lot of the work that demand should be doing. Several sinks constrain the float without requiring a single paying customer:

• Provider stake locked for a year.
• Capital rewards re-staked for the Power Factor multiplier (MRC42, up to roughly 10.7x after six years, though a fresh six-year lock today maxes nearer 8.8x against the 2024-anchored curve, and locks can only lengthen).
• Per-session staking locks on the access path.
• MRC22 meta-staking, where holders stake MOR to direct community emissions to chosen agents and earn those agents’ tokens.

That’s a real constraint on sell pressure. It’s also a floor built from holders agreeing not to sell, not from buyers needing to buy.

The Verdict

Three architectures, one question. Akash and Render burn usage into the token, io.net pegs payouts to a dollar target and burns from revenue, and Morpheus funds value from capital while keeping inference free. Morpheus is the outlier, and the fork is deliberate.

The compute mechanism (Yellowstone) is well designed and among the more coherent in DePIN: competitive bidding, demand-driven allocation, and a Power Factor that rewards conviction over speculation. The plumbing is sound. The weakness is elsewhere: the value thesis rests on a demand assumption that’s still unproven, the capital engine that anchors the structural bid is impaired, and there’s no usage sink on compute. Those are three separate risks, and only the first is shared with every other network here.

The constructive close isn’t a verdict on the token. It’s a design. A hybrid of a free staked tier and a paid-with-burn tier would graft BME’s value capture onto Morpheus without breaking the free private inference position that is its reason to exist. io.net just shipped a version of that idea.

The rails on Morpheus already exist: MRC43 buy-and-burn, direct-pay that settles in MOR, builder subnets gating access behind staked MOR. What’s missing is usage flowing through them at scale, and one MRC that points a burn at the buyers who’ll pay anyway.

---

Related reading: How Morpheus Pays for Inference traces the compute-side money flow with live on-chain data. How MOR Actually Works covers the capital pillar and the Power Factor in detail. RENDER vs AKT vs IO compares the three on revenue and verifiability. For the provider’s side of the same networks, see Where Should You Deploy Your GPU?. Full project reviews: Morpheus, Akash, io.net, Render.