What Morpheus Doesn't Disclose About Builder Subnets

Morpheus ships something most decentralised AI protocols only talk about. Anyone can spin up a builder subnet, claim a share of MOR emissionsEmissionsNew tokens created and distributed by a blockchain protocol over time as rewards to validators, stakers, or miners. Emissions fund network security and participation at the cost of diluting existing holders.Like a company that pays employees partly in newly printed shares. Every year the total number of shares goes up, which means existing shareholders own a slightly smaller slice of the same company unless the company grows faster than the printing.Read more →, and offer depositors whatever they like in return. I hold MOR and I think the design is right. Letting operators compete on what they build, rather than prescribing it from the protocol, is the genuinely hard part and Morpheus shipped it.

Two things about that marketplace are not disclosed anywhere a depositor would look, and both are visible only by reading the deployed contract. The first is how much of the builder pillar actually reaches subnets. The second is what a depositor is owed when they stake. Neither needs a redesign. Both need disclosure.

I hold MOR in the capital pool on a six-year Power Factor lock, and I stake MOR for inferenceInferenceRunning a trained AI model to produce an answer. Inference is what happens when you type a prompt into ChatGPT and get a response. The model takes your input, computes a best guess, and returns it.Like asking an expert for their opinion. The training was the decades they spent becoming an expert. The inference is the 30 seconds it takes them to answer your specific question.Read more → access through the Morpheus Marketplace API gateway. Disclosed.

24 percent allocated, 19.2 percent distributed

Morpheus allocates 24 percent of MOR emissions to the Community Builders pillar. The daily emission splits five ways: 24 percent each to capital providers, code contributors, compute providers and community builders, and 4 percent to a protection fund. That pillar share is fixed in the RewardPool curve and has not changed.

What the deployed BuildersV4 contract changes is the rate at which the pillar reaches subnets. Before any subnet is credited, the contract multiplies the bucket’s daily emission by a parameter called networkShare. At its current setting that parameter is 80 percent, so 80 percent of the 24 percent pillar is distributed to subnets. The other fifth of the pillar, 4.8 percent of total MOR emissions, is held back. Of the protocol’s 24 percent builder allocation, 19.2 percent of total emissions actually reaches the subnets a depositor stakes into.

networkShare is set by the contract owner, a Gnosis Safe multisig requiring five of nine signatures. The parameter has moved twice: set to 100 percent on 22 December 2025, then cut to 80 percent on 5 January 2026, both executed through the Safe. It can be set anywhere from zero to 100 percent.

I could not find networkShare described anywhere a builder or depositor would read. It is absent from the MRC governance proposals, from the gitbook, and from the new node documentation at nodedocs.mor.org. A Morpheus Discord admin, asked directly, confirmed the same: he had not seen the parameter documented anywhere either. It is visible only by reading the contract.

The 24 percent figure is the pillar allocation. The 19.2 percent figure is what the contract distributes onward to subnets. Both are true; only the first is documented.

Where the withheld emissions go

If 80 percent of the builder pillar is distributed to subnets, the other 20 percent is not. That withheld MOR does not reach stakers either, and it is not burned. It accumulates in the Builders Treasury, which as of 29 May 2026 holds around 215,000 MOR that has not been distributed onward. The same Morpheus Discord admin described the flow plainly: the protocol claims the emissions, stores them in the Builders Treasury, and the builders contract sends them onward to subnets, with the rate cut sitting at the last step.

Because networkShare is capped at 100 percent, the contract cannot later release that balance to subnets by raising the parameter past full. Whatever the withheld emissions are for, the contract gives stakers no path to them.

Why the rate was cut is not formally documented. The Discord admin offered his own reading: that the distribution rate was cut to reduce sell pressure. That reads as his framing; the protocol has not published anything to that effect. The narrower point stands and is on-chain: the allocation the gitbook advertises and the allocation the contract distributes are 4.8 percentage points apart, and the gap is governed by a multisig parameter nobody wrote down.

The bigger gap: a depositor cannot tell what they bought

The emission reduction is the smaller problem. The larger one is that the contract pays a subnet’s full claimable rewards to whatever wallet the operator nominates, with no on-chain logic splitting anything to depositors. The depositor’s principal is safe: MOR staked into the BuildersV4 contract stays under the depositor’s control and is withdrawable on request once the 7-day deposit lock clears. What the operator sets entirely off-chain is the reward, the return a depositor is paid for staking.

In practice that produces three different things sold under one word, stakingStakingLocking up a cryptocurrency to help secure a blockchain network, usually in exchange for rewards. The locked tokens act as a security deposit that can be taken away if the staker misbehaves.Like putting down a large rental deposit for an apartment. You get the money back if you behave, you earn interest while it's locked, and the landlord takes it if you trash the place.Read more →:

• A project token. The original builder-subnet design assumed each builder launches its own token. MOR emissions seed the project’s liquidity, and depositors earn the project’s token while MOR sits underneath as the trading pair.
• A MOR pass-through. The operator claims the subnet’s MOR and hand-pays a share back to depositors. This is the headline-APY pitch, and it is a promise from the operator that nothing on chain enforces.
• Service or access. The deposit buys a product. The official Marketplace API gateway converts a depositor’s share into daily inference credits, with the MOR principal staying locked and withdrawable after the deposit lock. The return is the service, and the yield is incidental.

These three carry different risks and different time horizons. A token launch lives or dies on the new token. A pass-through lives or dies on an operator keeping a promise. A prepaid service lives or dies on the product staying up. Nothing on chain, and nothing in the disclosure a depositor reads, tells them which one they are looking at.

A disclosure standard already exists, half-built

Morpheus does not have to invent a disclosure regime. One is already drafted. MRC22, the builder-staking proposal, carries a 16-field template each builder is meant to publish:

• Identity: Name, Team, Website, Documentation, Socials, Description
• Security: Audits
• Token: Token, Token Contract, Circulating Supply, Max Supply
• Staking program: Tokens Set Aside for Stakers, Duration of Staking Program, Staking Program Start Date, Staking Program Schedule, Additional Token Notes

Two problems. MRC22 is still marked “In Progress” and the template is voluntary, so nothing requires a live subnet to publish any of it. And the fields assume the project-token model: “Tokens Set Aside for Stakers” and “Staking Program Schedule” describe a token-reward program, and they say nothing useful about a pass-through subnet or a service subnet, which are most of what is actually live today.

MRC22 also sketched a reward mechanic referencing circulating supply and a phased rollout. That was the proposal. The contract that shipped reduces builder emissions through networkShare instead, which is exactly why a disclosure standard has to describe the deployed parameter rather than the draft. A template that documents a mechanism the chain never adopted is worse than no template, because it reads as authoritative.

What I would propose

Three changes, none of which touches the permissionless design:

• Make the 16 fields mandatory and machine-checkable. A subnet that has not published them does not appear in the official UI. Disclosure becomes a listing requirement, the way a token listing requires a contract address.
• Key the template to the three return types. Add a required field declaring which a subnet is: project token, MOR pass-through, or service. Each type then carries its own follow-on disclosures: token contract and vesting for the first, pass-through rate and claim cadence for the second, the service and its terms for the third.
• Surface the contract truths a depositor cannot see. Publish the live networkShare and the resulting effective allocation, the receiver address each subnet pays to, and a restaking metric showing how much of staked MOR is actually being recycled, on the same ranking a depositor uses to choose.

Permissionless and opaque are separate choices

Morpheus made the hard choice well. Letting anyone build, and letting operators compete on what they offer, is the part most protocols never reach. The disclosure gap is the easy half, and it is the half still open.

A depositor staking into a builder subnet today is underwriting one of three different bets, against a pillar whose distribution to subnets has been cut by a fifth without documentation, governed by a parameter they have no way to find. Closing that gap costs the protocol nothing it values. It is the difference between a permissionless marketplace and an investable one.

The networkShare, treasury and Safe figures in this piece were read from the deployed Morpheus contracts on Base on 29 May 2026. A Morpheus Discord admin has responded confirming the parameter is not documented and offering the sell-pressure interpretation cited above. Further questions remain with the team and this piece will be updated as detail emerges.

---

Related reading: How Morpheus Builder Subnets Work covers the marketplace mechanics in full. How MOR Actually Works walks through the capital side of the same protocol. The Morpheus project review carries the full Freedom and Returns scoring.