Morpheus Lumerin Node: How to Provide AI Compute for MOR

What you are building

A Morpheus Lumerin node turns your hardware into a decentralised AIDeAIDecentralised AI. An umbrella term for blockchain-based projects that build AI infrastructure (compute, data, inference, models, agents) without a single central provider controlling the system.Like the difference between streaming a movie from Netflix and sharing it via BitTorrent. Netflix is fast and polished but one company controls what you can watch and what you pay. BitTorrent is messier but no single operator can shut you out.DeAI in the glossary → inference provider. You host an AI modelModelA trained neural network that takes inputs (text, images, audio) and produces outputs (more text, classifications, generated content). In DeAI the model is the thing that actually does the work.Like a very experienced apprentice who has spent years watching thousands of masters make furniture. They can't explain how they know when a joint is right, but they can make a chair that looks and functions like a Chippendale. The training is invisible. The output is what matters.Model in the glossary →, register on-chain, and serve prompts to consumers who pay in MOR. The proxy-router handles encrypted P2P routing between you and consumers. Prompts and responses never touch the blockchain or any centralised relay.

The same software serves both providers and consumers. Any user can be a provider. The difference is whether you attach 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.GPU in the glossary → and a model.

For the full project assessment, see our Morpheus review.

How the system works

The architecture has four moving parts:

1. Your AI model server. llama.cpp, vLLM, or any OpenAI-compatible APIAPIApplication Programming Interface. A structured way for one piece of software to talk to another. In DeAI, APIs let applications request inference from a model without running the model themselves.Like a waiter in a restaurant. You don't walk into the kitchen and cook your own meal. You tell the waiter what you want, they tell the kitchen, the kitchen cooks it, and the waiter brings it back. The API is the waiter.API in the glossary → running on your hardware.
2. The proxy-router. A Go process that monitors the BASE blockchain, manages encrypted sessions between you and consumers, and routes inference traffic P2P.
3. The Diamond smart contractSmart ContractA program stored on a blockchain that runs automatically when its conditions are met. Smart contracts are how blockchains do anything beyond just transferring tokens — DeFi, NFTs, DAOs, and DeAI infrastructure all run on smart contracts.Like a vending machine. You put in the right input and it produces the expected output, no human operator required. The rules are fixed in the machine itself, anyone can use it, and nobody can stop a transaction in the middle.Smart Contract in the glossary → on BASE. An on-chain marketplace where providers register, post bids, and consumers purchase sessions.
4. MOR tokenTokenA digital unit of value or access rights tracked on a blockchain. Tokens can represent ownership in a project, a right to use a service, a share of future revenue, or simply a tradable asset with no underlying claim.Like a physical poker chip a casino issues. The chip itself has no value. What makes it worth something is what it lets you do at the casino, what the casino has promised, and how much other people will pay you for it.Token in the glossary →. Payment and 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.Staking in the glossary → medium for the entire system.

When a consumer wants AI inference, they browse available bids on-chain, purchase a session by staking MOR, and their proxy-router establishes a direct encrypted connection to your proxy-router. Traffic flows P2P. The blockchain only handles discovery and settlement.

The node also bundles a desktop UI (Electron), a CLI client, and IPFS (Kubo) for model storage. You do not need the UI to run as a provider.

What you earn

24% of all 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.Emissions in the glossary → go to compute providers. The daily emission started at 14,400 MOR/day in February 2024 and decreases by approximately 2.47 MOR per day. By mid-March 2026 (~day 766), that is roughly 12,511 MOR/day total, with approximately 3,003 MOR/day allocated to the compute pool.

The pool is paid in MOR, so its dollar value moves one-for-one with the token, and MOR trades about 99% below its May 2024 all-time high. Individual earnings depend on how many providers are active and how much consumer demand exists.

The data gap this guide first complained about has narrowed. Morpheus now publishes active.mor.org, a catalog of the live marketplace refreshed about every five minutes, and you can queryPromptThe 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.Prompt in the glossary → the Diamond contract’s getActiveProviders() function on BaseScan yourself. When we read the registry on 18 September 2026 it listed 61 active providers. Per-provider reward distribution still has no official view.

The Yellowstone reward model

Rewards are not distributed equally among all providers. The Yellowstone design (by Erik Voorhees) set out the intent like this:

1. Consumers hold MOR and receive a daily compute budget proportional to their balance. No per-inference payment from consumers.
2. Providers post bids on the marketplace specifying their price per second for each model they serve.
3. The Router matches consumers to the cheapest qualifying provider. If your bid is competitive and your uptime is good, you get selected more often.
4. You earn MOR from the compute pool only when you actually serve inference and the consumer reports a Pass result. No inference served, no reward.
5. The daily compute budget is 1% of the accumulated compute contract balance: asymptotic, so the budget decays rather than hitting zero.

This means rewards are proportional to inference actually delivered, not proportional to stake. Staking determines eligibility and reputation ranking, but the work earns the MOR.

Before you size a bid, note where the deployed contract departs from that design. The consumer’s allowance is sized by the MOR they stake into a session against total supply, rather than by the balance sitting in their wallet, so stakeToStipend on the Diamond is the function that decides what a consumer can draw. And the pool behind that 1% is finite in practice: provider claims overtook the compute pillar’s daily accrual during July 2026, so the balance peaked near 2,805,000 MOR in mid-July and fell to about 2,780,000 by mid-August. Claims have since dropped back below accrual, and the balance has recovered to 2,942,450 MOR.

Stake and ranking

The Yellowstone design gave providers a Power Factor multiplier for staking longer. The deployed system doesn’t apply one to providers: Power Factor lives in the capital and code-contributor claim locks, where it reaches 10.7x. Provider ranking happens in the consumer’s proxy-router, which scores throughput, time to first token, session duration, success rate and stake, then divides the total by your bid price. Stake stops adding to that score at 2 MOR, ten times the provider minimum.

Your staked MOR does cap your earnings. Stake 100 MOR and you can earn up to 100 MOR inside a rolling 365-day window, and topping up the stake raises the ceiling straight away. Payment arrives automatically as each session closes, at the seconds served times your bid price, so there is no wait for the window to end.

Bootstrapping incentive

During the first year after the capital contract bootstrapping period, the top 100 compute providers may receive a pro-rata 2.4% of MOR emissions (one-tenth of the compute bucket). The capital contract bootstrapping period was 90 days from February 2024, so this incentive window likely closed around May 2025. Whether it was extended is not documented. Check the Discord #compute-providers channel for current status.

Staking requirements

The barrier to entry is low in MOR terms:

Action	Minimum stake
Register as provider	0.2 MOR (refundable)
Register a model	0.1 MOR (refundable)
Post a bid	0.3 MOR (non-refundable fee, charged on every bid)
Total to start	0.6 MOR

That is a fraction of one MOR to register. Additional stake above the minimum raises your earning cap, and adds to your ranking only up to 2 MOR. To register as a subnet operator, you need 10,000 MOR. The node docs note these minimums are governance-controlled and can change.

No slashing

There’s no slashing mechanism in the current contracts. If your node goes offline, you stop earning but don’t lose stake. Failed inference results mean no payment, and that’s the economic penalty. The Provider Registry’s providerDeregister function returns your stake, less whatever you have earned in the current 365-day window, and the whole stake once that window closes. This may evolve as Pretty Good Verification matures.

Hardware for a provider node

The official docs recommend a dual RTX 3090 build (~$4,500 USD new). But you don’t need to start there. A single-GPU budget build is enough to serve 8B and 13B models and start earning.

Budget build: single RTX 3090 (~A$2,100-2,200)

Component	Pick	Price (AUD)
GPU	Used RTX 3090 24GB (eBay/Gumtree)	~$1,450
CPU	Intel i5-12400F	$209
Motherboard	B660M mATX DDR4	$139
RAM	32GB DDR4-3200	$107
PSU	850W 80+ Gold	$123
SSD	500GB NVMe	$49
Case	Mid-tower ATX	~$70

The CPU barely matters for inference; it just feeds data to the GPU. The money goes on the card. Check Gumtree and Facebook Marketplace first; they typically run 10-20% cheaper than eBay ($1,200-1,500 range for a working 3090).

This build delivers roughly 80-90 tokens per second on 8B models and 45-55 tok/s on 13B. That is competitive for Morpheus marketplace bids.

Official recommended build: dual RTX 3090 (~A$4,000-4,200)

Adds a second 3090, 1200W PSU, motherboard with two PCIe x16 slots, and a larger case. The dual setup gives 48GB combined VRAM, enough to run 70B Q4 models across both cards. The docs note they run open-case for thermal management. Dual 3090s generate serious heat.

Only worth the extra cost if you need 70B model capability or want to serve more parallel requests. Start with one card and upgrade if the economics justify it.

Why RTX 3090 specifically

The RTX 4090 is roughly 1.6x faster on inference but costs roughly 2x more used in Australia ($2,500-3,500 vs $1,400-1,800). Same 24GB VRAM. Performance per dollar favours the 3090 clearly. The RTX 3080 12GB is false economy: 12GB VRAM limits you to 8B models only, and TDP is nearly the same as the 3090.

Consumer nodes need minimal hardware. Any modern desktop or laptop runs the proxy-router and UI.

Network requirements

Your proxy-router must have a publicly accessible endpoint (IP:port or domain:port). Two ports need to be open:

• 3333 for proxy/routing (TCP)
• 8082 for Swagger API/management

The docs recommend running behind a proxy, load balancer, or VPN for IP obfuscation. Your endpoint is visible on-chain, so anyone can see your provider address.

Setting up the model server

Before touching the proxy-router, get your AI model servingInferenceRunning 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.Inference in the glossary →.

Install llama.cpp with CUDA

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make -j 8 LLAMA_CUDA=1

Download a model

Any GGUF-format model from HuggingFace works. The Hermes-3-Llama-3.1-8B is a good starting point, capable enough to be useful and small enough for a single GPU.

Start the model server

./llama-server \
  -m models/your-model.gguf \
  --host 127.0.0.1 \
  --port 8080 \
  --n-gpu-layers 99 \
  --ctx-size 8192 \
  --threads 8

For dual GPU with larger context:

./llama-server \
  -m models/your-model.gguf \
  --host 127.0.0.1 \
  --port 8080 \
  --n-gpu-layers 99 \
  --ctx-size 98304 \
  --parallel 16 \
  --flash-attn

Verify it is running at http://127.0.0.1:8080. You should see the llama.cpp API interface.

Setting up the proxy-router

Option 1: Binary (simplest)

Download the latest release for your platform from the MorpheusAIs GitHub releases. This guide was written against v7.0.0 (April 2026), with binaries for Windows x64, macOS (Apple Silicon and Intel), and Linux (x86_64 and ARM64). The latest mainnet release when we checked was v7.15.0, published 14 October 2026.

v6.0.0 (March 2026) added Phase 1 TEETEETrusted Execution Environment. A hardware-secured region of a CPU or GPU where code runs in isolation, so even the machine's operator can't read what's happening inside. TEEs give decentralised AI inference privacy guarantees.Like a bank vault inside a bank. The bank owns the building, staffs the lobby, and runs the security cameras. But what's inside the vault is invisible to everyone, including the bank staff, unless the customer opens it.TEE in the glossary → attestationAttestationA cryptographic proof that a piece of code is running on a specific hardware enclave in an unmodified state. Attestation lets remote users verify that a service is genuinely running what it claims to be running.Like a tamper-evident seal on a medicine bottle. The seal itself doesn't make the medicine safe, but it gives you a way to verify that nobody opened the bottle and swapped the contents before you bought it.Attestation in the glossary →: consumers cryptographically verify the provider’s proxy-router binary inside Intel TDX. v7.0.0 (April 2026) added Phase 2: the provider’s proxy-router attests its own backend LLM on every prompt, combining CPU TDX, NVIDIA NRAS GPU attestation, anti-replay nonce binding, TLS pinning, and workload measurements that prove loaded models match what the operator declared. Standard (non-TEE) deployment still works on any hardware. To run as a TEE-tagged provider you must deploy the v7.0 TEE Docker compose into a SecretVM (Intel TDX hardware) via the Secret Labs partnership; see the TEE Quick-Start Guide. GPU attestation is NVIDIA-only; the router has checked AMD SEV-SNP hosts alongside Intel TDX since v7.2.0 (2 June 2026). That check only fails closed from v7.15.0: before it, per the release notes, an empty measurement was skipped and any SEV host passed. Run v7.15.0 or later if you rely on TEE models.

On macOS, you may need to remove the quarantine flag:

xattr -c proxy-router

Option 2: Docker

docker run -d \
  --env-file proxy-router.env \
  -v /path/to/local/data:/app/data \
  -p 3333:3333 \
  -p 8082:8082 \
  ghcr.io/morpheusais/morpheus-lumerin-node:v7.0.0

Option 3: Akash

An SDL template (02.2-proxy-router-akash.yml) is available for fully decentralised hosting of the proxy-router on the Akash Network. This means your compute provision can itself be decentralised: model on your GPU, routing on Akash.

Configure the environment

Copy env.example to .env and set:

# Your wallet private key (funded with MOR + ETH on BASE)
WALLET_PRIVATE_KEY=your_private_key_here

# BASE mainnet
ETH_NODE_CHAIN_ID=8453

# Smart contracts
DIAMOND_CONTRACT_ADDRESS=0x6aBE1d282f72B474E54527D93b979A4f64d3030a
MOR_TOKEN_ADDRESS=0x7431aDa8a591C955a994a21710752EF9b882b8e3

# Your own RPC endpoint (Alchemy or Infura; a free tier works)
ETH_NODE_ADDRESS=wss://your-rpc-endpoint

Edit models-config.json to point at your model server endpoint. Set apiType to openai for llama.cpp. From v7.15.0 you can also set apiStack (llamacpp here), which publishes how your backend handles reasoning and JSON settings in /healthcheck; leave it out and the node detects the backend itself.

Two v7.15.0 changes matter if you go beyond a basic setup:

• Content variables overwrite files on every start. A non-empty COOKIE_CONTENT or MODELS_CONFIG_CONTENT replaces the stored file at each boot, so a password changed through the API reverts. Set your own admin password, and clear MODELS_CONFIG_CONTENT if you edit models-config.json directly.
• Delegated IPFS access needs IPFS_ALLOWED_DIRS. API users without full permissions can only read and write IPFS inside those folders, and can’t use IPFS at all while it’s empty.

The walletWalletSoftware that stores the private keys needed to control tokens on a blockchain. A wallet does not actually hold any tokens. The tokens live on the chain. The wallet holds the keys that prove you own them.Like the key to a safe deposit box. The key doesn't contain your valuables. The valuables sit in the bank's vault. The key is what proves you're allowed to open the box and take them.Wallet in the glossary → key concern. Your private key sits in a plaintext .env file or system keychain. If your server is compromised, that wallet is compromised. Use a dedicated wallet with only the MOR and ETH needed for operation. Do not use your main wallet.

Start and verify

./proxy-router

Check the logs for:

• HTTP http server is listening: 0.0.0.0:8082
• TCP tcp server is listening: 0.0.0.0:3333

Access the Swagger API at http://localhost:8082/swagger/index.html. This is your management interface for all on-chain operations.

Register on-chain

All registration happens through the Swagger API. You do not need to interact with the smart contracts directly.

1. Approve the Diamond contract

POST to /blockchain/approve with at least 600000000000000000 (0.6 MOR in wei) to cover all registration fees.

2. Register as a provider

POST to /blockchain/providers with:

• addStake: minimum 200000000000000000 (0.2 MOR)
• endpoint: your publicly accessible endpoint (e.g. mycoolnode.domain.com:3333)

3. Upload your model to IPFS

POST to /ipfs/add with your model file, then pin it. The returned CID is used in the model registration.

4. Register the model

POST to /blockchain/models with model name, IPFS CID, fee, stake (minimum 0.1 MOR), and tags.

Update your models-config.json with the returned composite model ID. From v7.12.0, POST to /config/models/reload to load it without a restart: open sessions carry on, and a file that fails to parse returns 400 and leaves the running model table in place. Older versions need a proxy-router restart, which cuts every open session.

5. Create a bid

POST to /blockchain/bids with your model ID and pricePerSecond. Minimum price is 10000000000 (0.00000001 MOR/sec). This is what consumers see when browsing the marketplace.

Your node is now live. Consumers can discover your bid, purchase a session, and your proxy-router handles the rest.

Supported model backends

The proxy-router is model-agnostic. You can route to anything with an API:

Backend	apiType	Notes
llama.cpp / vLLM	openai	Self-hosted, any GGUF model
OpenAI	openai	Forwarding to GPT models (you pay OpenAI API costs)
Anthropic Claude	claudeai	Forwarding to Claude (you pay Anthropic costs)
Prodia	prodia-v2	Image generation
Hyperbolic	hyperbolic-sd	Image generation

The self-hosted llama.cpp path is the most aligned with the sovereignty thesis. You control the model, the hardware, and the data. Forwarding to OpenAI or Anthropic works but adds centralised dependency and API costs.

The honest economics

Let me work the numbers at current prices for the budget single-GPU build.

Costs: hardware, electricity, staking

Hardware: ~A$2,200 for a single RTX 3090 build.

Electricity: A single 3090 under inference load draws roughly 200-280W. With the rest of the system, call it 330W sustained. Running 24/7 at about $0.32/kWh (roughly the Australian residential average), that is approximately $2.55/day or $77/month. At 60% average utilisation (mix of active inference and idle), expect $50-60/month.

Staking: 0.6 MOR. Negligible.

Earnings under the Yellowstone model

The entire compute pool currently accrues 2871 MOR/day. Under the Yellowstone model, rewards are not split equally. They go to providers who win bids and serve inference. But as a rough guide:

Providers sharing pool	Your monthly share
25	~3,470 MOR
50	~1,730 MOR
100	~870 MOR
250	~350 MOR
500	~170 MOR

These assume equal sharing, which the deployed contract doesn’t do. It pays each provider the seconds it served times its own bid price, capped by its stake, and routing leans hard towards the cheapest listed bid. In practice the split is lopsided: over the last 84 days one provider, mordiem.com, took 70.3% of what continuing providers earned. Convert at the live MOR price and subtract $50-60/month in electricity from each scenario.

The provider count is no longer the unknown it was at launch. The registry lists 49 active providers and 27 closed sessions in the last 30 days, but the concentration above matters more than the headcount.

MOR price scenarios and the thesis

What happens if MOR price moves: the pool accrues about 2,871 MOR a day, so every dollar on the MOR price adds roughly that many dollars a day to what the whole provider set shares, or about thirty times that a month. A recovery to several times today’s price would still leave MOR far below its ATHATHAll-Time High. The highest price a token has ever reached. ATH is usually quoted as a reference point for how far the current price has fallen (or risen) since the peak.Like the record lap time on a racetrack. It tells you what the car has been capable of at its absolute best, not what it will do today. Whether that record gets broken again depends on conditions that may or may not come back.ATH in the glossary →, and would make the compute pool attractive even with hundreds of providers.

The thesis: The asymmetry is interesting. Downside is A$2,200 in hardware that retains resale value (3090s hold their price) plus $50-60/month electricity. Upside is early entry to a compute pool with only a few dozen active providers, earning a token that is about 99% off its high. If you already have GPU hardware sitting idle, the marginal cost is just electricity and the 0.6 MOR stake.

Monitoring and maintenance

The proxy-router logs to stdout. For production, pipe to a log file or monitoring service.

Key things to watch:

• Session creation failures. v5.14.0 fixed an integer overflow that caused these. The on-chain tee tag now drives both Phase 1 (v6.0.0+ consumer verifies the provider binary) and Phase 2 (v7.0.0+ provider attests its own backend LLM on every prompt). If your enclaveEnclaveAn isolated region of CPU or GPU memory protected by hardware. Code and data inside the enclave are inaccessible to the operating system, the hypervisor, or even the machine's physical owner.Like a secure room inside a much larger office building. The building's caretakers have keys to every other room but not this one. What happens inside is invisible to them by design.Enclave in the glossary → attestation fails, sessions won’t open.
• Model server uptime. If llama.cpp crashes, your provider stops earning.
• Wallet balance. You need ETH on BASE for gasGasThe fee paid to a blockchain to process a transaction. Gas is denominated in the chain's native token and varies with network demand. Sending a transaction without enough gas means the transaction fails and the gas is still consumed.Like the petrol that powers a car. You need to put petrol in to make the engine run. The amount of petrol you need depends on how far you're driving and how much you're carrying. If you run out, the car stops.Gas in the glossary →. Keep a buffer.
• Software updates. The node is actively developed. Check releases regularly.

Common issues

1. “No provider accepting session”. Known issue under load. Ensure your endpoint is publicly accessible and your model server is running.
2. macOS quarantine. Run xattr -c proxy-router after downloading.
3. RPC rate limits. Set ETH_NODE_ADDRESS to your own endpoint. The maintainers say the built-in default was never meant for provider use, especially with many models on offer. Before v7.12.0, a single 429 on the startup balance read stopped the router; it now retries five times over about 30 seconds. A free Alchemy or Infura tier can still hit limits during heavy chain activity.
4. Port forwarding. If behind a home router, you need to forward ports 3333 and 8082 to your machine. UPnP may handle this, but manual configuration is more reliable.
5. Model too large for VRAM. If your model does not fit in GPU memory, llama.cpp will offload layers to CPU, destroying performance. Use a model that fits entirely in your GPU’s VRAM.

Testnet first

BASE Sepolia testnet (Chain ID 84532) is available. Use it. The setup is identical except you use testnet contract addresses and free testnet tokens. Get comfortable with the full flow (model hosting, proxy-router configuration, on-chain registration, bid creation) before committing live-network MOR.

The testnet environment variables are in the env.example file.

Resources

• Node docs (canonical): nodedocs.mor.org. The official Morpheus Lumerin Node documentation, covering both consumer and provider setup. Most up-to-date reference for node operators.
• Node releases: MorpheusAIs/Morpheus-Lumerin-Node
• Source code: MorpheusAIs/Morpheus-Lumerin-Node
• Lumerin docs: gitbook.mor.lumerin.io
• Morpheus compute page: mor.org/morpheus-compute
• Discord: #compute-providers channel for support
• Smart contracts on BASE: MOR token 0x7431...b8e3, Diamond 0x6aBE...030a

How other compute networks looked at this stage

Every successful compute network went through the same pattern. Akash, Render, and Flux all used emission subsidies to attract early providers before organic demand existed. Provider economics were negative without those subsidies in year one and two. The demand-supply paradox (needing providers to attract users, needing users to justify provider costs) took years to resolve.

Render had the advantage of existing demand from 3D artists. Akash found traction in 2023-2024 when AI workloads exploded. Flux maintained a large node network through the bear market on conviction.

Morpheus was approximately 16 months into its compute mainnet when this guide was first written in March 2026. That is early by comparison. Render took two-plus years from public launch to meaningful organic demand. The question is whether decentralised AI inference follows the same adoption curve or a faster one, given today’s AI demand environment.

My assessment

Morpheus is doing something different from the other compute networks I’ve reviewed. Akash, Render, and io.net are general-purpose compute marketplaces. Morpheus is specifically an AI inference routing network with P2P privacy by design. Prompts never touch a centralised server. That matters.

The 0.6 MOR entry cost is the lowest barrier of any node I’ve set up for this site. Proxy-router installation is straightforward and the on-chain registration via Swagger API is well-designed: no raw contract interaction needed. The Yellowstone reward model I like a lot: competitive bidding and demand-driven allocation, though the provider Power Factor it described is absent from the deployed contracts.

The gaps remain though. The verification system (Pretty Good Verification) is at proposal stage. Consumer demand is now visible on chain, but monthly tokens processed fell in August 2026 after six months of growth and recovered only partly in September, and whether that demand is paid or emissions-subsidised can’t be settled on chain. MOR is trading about 99% below its all-time high, which either means the market has given up, or the opportunity is priced at its most asymmetric.

For a budget build at A$2,200, the downside is capped (hardware retains resale value) and the upside scales with both MOR price recovery and early-mover advantage in a small provider pool. That is a better risk/reward profile than most node opportunities I have reviewed. The Aethir Edge’s two-decade break-even and Flux Cumulus earning cents per day do not compare.