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. Instead of a returnable deposit, your MOR is spent on the session and ends up with the provider. This is the contract’s direct-payment mode, and the MOR leaves your wallet for good.

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 is denominated in MOR and works out to roughly the bid price times the session length, drawn as a share of the daily compute budget. The bid price is the provider’s lever, not the staker’s cost. If you stake for access, the bid price only sets how fast your session draws down your allowance; your MOR comes back either way. Your only cost as a staker is the lockup and the yield you forgo while it’s locked.

Design note: The March 2024 design model sets the daily compute budget at roughly 1% of the compute balance per day and scales each user’s claim pro-rata to their MOR against total MOR. Treat those as the design model and check them against the live contract before quoting any specific budget number. The funding-account payment, the deposit return, and the early-close timelock are the parts confirmed on the deployed contract.

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 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.