How Morpheus Pays for Inference

Compute Providers 24%

Code Contributors 24%

Capital Providers 24%

Community Builders 24%

Protection Fund 4%

Someone runs a GPUGPUGraphics Processing Unit. Originally designed to render video game graphics, GPUs turned out to be exceptionally good at the massively parallel math that AI models need. Modern AI training and inference runs almost entirely on GPUs.Like a factory with 10,000 workers doing the same simple task in parallel, versus a CPU which is more like 10 workers each doing different complex tasks. AI training involves doing simple math a million times per second on a million numbers, which is exactly what the GPU factory is designed for.Read more →, serves an AI promptPromptThe text you give an AI model to tell it what to generate. A prompt can be a simple question, a long instruction, a chunk of context plus a task, or a conversation history the model uses to produce its response.Like a brief you give to a junior designer. A vague brief gets a vague result. A detailed brief with context, constraints, and examples gets something usable. The quality of the output depends heavily on the quality of the brief.Read more → through Morpheus, and gets paid in MOR. The money does not come from the person who sent the prompt. It comes from the protocol’s 24% compute emission, the slice pulled out above. That one fact reshapes how you read the whole inference market, and it’s the part the headline tokenomics usually skip.

This piece traces the money on the compute side only: the 24% Compute pillar and the inference marketplace. The builder pillar and BuildersV4 are a separate emission with the same confusing name, covered in How Morpheus Builder Subnets Work. It does reappear once here, at the API gateway, and I flag it when it does. The capital side (stETH staking and protocol-owned liquidity) sits in How MOR Actually Works.

I hold MOR (capital pool, six-year Power Factor lock) and stake MOR for inference access through the gateway. Disclosed. None of this is financial advice.

Who Pays, Who Earns, From Where

The inference marketplace lives in one contract, the Lumerin Diamond, deployed on Base at 0x6aBE1d282f72B474E54527D93b979A4f64d3030a and also on Arbitrum. A provider runs a Morpheus-Lumerin node and serves prompts. A user, or the gateway acting for them, opens a session against that contract, and the session is where the payment logic sits.

Two separate pools of MOR move when a session runs, and mixing them up is the most common error in Morpheus explainers. The user puts up MOR as a deposit. The provider gets paid from protocol emissions. The two pools never touch.

When a session opens, the user’s MOR is pulled into the contract and held as a deposit. When the work finishes and the session closes, two things happen together: the deposit is returned to the user, after a short timelock if they closed early, and the provider is paid separately out of a protocol funding account topped up by the 24% compute emission. We confirmed this by indexing the deployed contract directly. The provider’s pay comes from that funding account, not from the user’s deposit, and that is how the overwhelming majority of sessions settle.

No MOR is burned to run inference. Staked access returns the user’s MOR in full, direct payment hands it to the provider, and the provider’s reward is drawn from the compute emission.

Two Ways to Get Inference

There are two ways to pull inference out of Morpheus, and they sit at different levels. You can deal with the marketplace contract yourself by running a node, or you can use the hosted API gateway and let it deal with the contract for you. Which one you pick decides whether you ever touch MOR at all.

Run your own node. You operate a proxy-router and talk to the contract directly, which means holding MOR. From there you have two on-chain modes:

• Stake for access. Your MOR is held as a deposit and returned when you withdraw. In exchange you get a daily inference allowance sized to your share of the compute budget. Nothing is consumed; the deposit is a claim ticket on that daily budget.
• Pay directly. Your MOR goes to the provider instead of coming back to you. What it does not do is buy you a longer session. _validateSession sizes the session from stakeToStipend whether or not the direct-payment flag is set, so the same deposit buys the same access time either way, and choosing direct payment simply means you funded it rather than the emission pool. On the deployed contract this path is strictly worse for the user, which is the likeliest reason almost nobody takes it.

Use the API gateway. Most consumers will never run a node. They use the hosted gateway at app.mor.org, which opens and manages sessions for them and bills in plain US dollars. No wallet is required. It gives you three ways to pay, and only one of them involves MOR at all:

• Stake MOR for credits. Per the Morpheus docs, this stakes into the gateway’s own builder subnet, the community-builder pillar rather than the compute pillar, and pays you a daily US-dollar credit allowance sized to your share of that subnet’s reward pool. Your MOR stays staked and withdrawable.
• Pay by card. Buy credits with a card through Stripe. The credits don’t expire and you never hold MOR.
• Pay by crypto. Buy credits with USDC or other crypto through Coinbase Commerce. Again, no MOR ever sits in your wallet.

The two staking options also pay out differently, and not by a little. Staking against your own node gives you a claim on the compute budget directly, at the protocol’s own rate. Staking through the gateway earns credits from a single builder subnet that you then spend at the gateway’s listed per-token prices, which carry its running costs on top. Run the same MOR through Morpheus’s own staking calculator both ways and the node comes out well ahead, buying materially more inference per MOR staked.

“Staked, not spent” holds for the staked path and only the staked path. It’s tempting to repeat it as a blanket property of Morpheus inference, but direct payment does spend MOR, and the gateway’s card and crypto routes spend dollars. The gateway charges US-dollar prices per token today. So the demand side now gives you a signal worth reading: dollars are changing hands for inference, the question is how many.

Provider Economics

A provider’s revenue for a session is the bid price multiplied by elapsed time, paid from the funding account. Substitute the contract’s own duration formula into that and the bid cancels: getSessionEnd sets duration to stakeToStipend(amount) / pricePerSecond, so the product returns the stipend itself. Bidding higher earns the same MOR for a shorter session and bidding lower earns the same MOR for a longer one, until the seven-day cap binds. Providers compete on how much service they hand over per MOR, and the payout is fixed by the depositor’s stake.

That makes the bid the staker’s cost per unit of inference. stipendToStake runs the conversion the other way and is linear in the bid price, so the MOR you must post for a fixed quantity of inference moves in direct proportion to what providers charge. The deposit still comes back on the staked path, so your cost is the lockup and the yield you forgo rather than the token itself. Cheaper bids buy more inference from the same deposit.

Verified against the deployed contract, 15 August 2026: getTodaysBudget returns getComputeBalance / 100, currently a daily budget of 27,995 MOR. stakeToStipend converts a deposit at amount x computeBalance / (totalMORSupply x 100), so it takes roughly 339 MOR staked to command 1 MOR of provider payment in a session. _rewardUserAfterClose then holds the stake behind that day’s consumption until the next UTC midnight, and that hold is what enforces the daily ration, standing in for the getSpendBalance counter the Lumerin Model specifies and the Diamond never registered. Read from SessionRouter.sol against the Lumerin Diamond at 0x6aBE1d282f72B474E54527D93b979A4f64d3030a on Base.

The number that decides whether running a node is worth it lives off-chain: the gap between MOR earned and fiat cost.

Fact: A provider’s earnings are denominated in MOR (emission share times bid price times session length). Their costs (GPU time, power, bandwidth) are denominated in fiat.

Take: Margin is MOR price times emission share minus those fiat costs. When MOR is strong, the subsidy carries thin demand comfortably. When MOR is weak, a provider can be serving sessions and still losing money, because the emission they’re paid in is worth less than the electricity they burned to earn it. That’s the owner-side risk a headline “providers earn MOR” line hides.

There’s an operational failure mode on top of the price risk. The provider is paid out of a separate treasury, a 5-of-9 multisig that holds MOR and grants the contract a spending allowance, so if that treasury runs short or its allowance lapses, the payout reverts and the session can’t close cleanly. The provider goes unpaid and the user’s deposit stays locked in an open session. Nothing in the protocol auto-refills that treasury from the emission schedule, so anyone running a node or staking for access is trusting the multisig to keep it funded and approved.

Sustainability

Compute is an emission subsidy first. The 24% Compute pillar pays providers whether or not a single external customer pays for a session. That’s a fair bootstrap design, and it’s the honest way to describe the market today: usage is mostly the protocol paying itself to keep providers online while paying demand is built.

The subsidy runs past the 16-year mark, too. The Compute pillar follows the same Epoch 1 linear decay as the rest of MOR (a day-1 share of 3,456 MOR a day, dropping by 0.59255872824 MOR daily), and undistributed emissions are designed to bank and re-emit in a later epoch. The post-2040 epoch mechanism covers that in full; the point here is only that the compute subsidy has a longer tail than the headline curve implies.

Long-run viability rests on two things. One is MOR price, because every provider incentive is denominated in it. The other is paying demand growing into the subsidy, and that demand now has two faces: MOR holders spending directly on-chain, and people who never hold MOR paying the gateway in dollars or USDC. The MOR-denominated subsidy per unit of compute trends down as emissions decay and participation grows, so the market has to grow paid demand into that shrinking subsidy or it stays circular.

Supply and Demand Reality

This is the part no one else publishes, because it needs the data rather than the theory. We index every SessionClosed event on the Lumerin Diamond on Base and reconstruct the market from the receipts. The figures below are a snapshot from the live Morpheus inference tracker as of 8 June 2026, summing the trailing 30 days (9 May to 8 June 2026).

Three structural findings come out of that data, and none of them flatter the marketplace.

Provider supply is a near-monopoly. Only 12 distinct addresses have ever closed a session on this contract, most days run on two to seven, and the last 50 settled sessions in our snapshot all came from a single provider address. The marketplace is permissionless and the work settles on-chain, but the supply side is one operator wearing most of the hats on any given day.

The on-chain payment split looks emission-heavy. About 96% of sessions open as returnable deposits funded by the staked-access path, leaving roughly 4% on the direct-pay route where a user’s own MOR reaches a provider.

There’s a caveat that cuts both ways. The gateway opens every session itself, so a paid request and a free staked-access request settle on-chain identically, and its dollar billing runs off-chain through Stripe and Coinbase Commerce where our index can’t follow it. So the 4% direct-pay figure is a floor on external payment, and the gateway’s paid demand is something we can neither confirm nor size from the chain.

What we can see on the gateway is the other side: the cohort that stakes MOR for free metered access instead of paying. It’s small, a few dozen stakers. So the demand we can actually measure is that handful of stake-for-access accounts, while the paid-dollar demand the thesis needs sits off-chain, unpublished and unverified.

Sessions are small but on-chain. About 32,900 sessions in 30 days is steady activity, and the attested token counts (provider-signed, so a claim rather than a contract-enforced number) sit in the billions. This is a working marketplace operating at a small scale, honestly described, which is worth more than a market discussed only in the abstract.

Fact: As of 8 June 2026, Morpheus inference settles roughly 200 MOR a day to a provider set that is two to seven addresses on most days, with about 96% of sessions opening as staked-access deposits rather than direct MOR payment.

Take: The infrastructure works and the gateway charges for inference, but we can’t see a dollar of it. Its billing is off-chain, and the only gateway demand we can measure is a few dozen accounts staking for free access. Until paid spend is published or direct-pay climbs where the chain can see it, treat external paying demand as unproven for now. This is a well-built, emission-subsidised market still short of a verifiable customer.

The Picture Two Months On

The June snapshot above stands as a record of that window. By 15 August 2026 the numbers had moved enough to change the shape of the argument, so here is the same market re-read against the contract on that date.

Settlement to providers runs at roughly 800 MOR a day, against roughly 208 MOR a day in the June window. That is about 2.9% of the 27,995 MOR daily cap, so the cap has stopped being a distant abstraction. The compute pool peaked near 2,805,000 MOR in mid-July and has since fallen to 2,778,186 MOR, a decline of about 900 MOR a day, because provider claims now run ahead of the 2,912 MOR a day the compute pillar accrues. That crossover matters more than the growth rate: the reservoir stopped filling.

Access capital moved further. MOR committed to inference access, counting the gateway’s opener wallet alongside everything held in the Diamond as session stake and holds, went from 123,259 MOR on 16 June to 777,023 MOR on 15 August. The gateway is drawing close to the full daily ration its stake entitles it to, which is why the position had to grow. Demand for access is visible on-chain now, and it binds.

The verdict on paid demand is unchanged. Users posting their own MOR for access shows token demand, and revenue is a separate question. The gateway’s dollar billing still settles off-chain through Stripe and Coinbase Commerce, where our index cannot follow it, so external paying demand stays unproven. What has changed is that the subsidy is being consumed faster than it accrues, which puts a clock on the question.

Fact: The Morpheus compute pool peaked in mid-July 2026 and had fallen to 2,799,521 MOR, as provider claims of roughly 800 MOR a day overtook the 2906 MOR a day the compute pillar emits.

Take: the emission reservoir was the thing that made this subsidy look open-ended, and it has started draining. At this rate the pool still lasts years, so read it as a change of direction rather than a cliff. The sustainability question now carries a deadline, and the funding Safe that actually pays providers holds about 32 days of claims at the current rate.

The plumbing is sound and verifiable down to the contract call. What it’s waiting on is paid demand showing up where the data can see it. When it does, this dataset will show it first.

---

Related reading: How Morpheus Builder Subnets Work covers the other “subnet”, the builder pillar. How MOR Actually Works covers the capital side. The Morpheus project review carries the full Freedom and Returns scoring, and the live inference tracker refreshes the data above daily.