# Morpheus Lumerin Node: How to Provide AI Compute for MOR > How to set up a Morpheus Lumerin node and earn MOR by serving AI inference. Proxy-router setup, model hosting, on-chain registration, hardware builds, and the honest economics of compute provision. - Published: 2026-03-10 ยท Updated: 2026-10-17 - Canonical: https://ownyourmind.ai/use/morpheus-lumerin-node-setup/ - Cite as: Own Your Mind (ownyourmind.ai), licence CC BY 4.0. Link the canonical URL. Charts and interactive widgets are omitted here; project data is at https://ownyourmind.ai/api/scores.json. --- ## What you are building A Morpheus Lumerin node turns your hardware into a decentralised AI inference provider. You host an AI model, 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 GPU and a model. For the full project assessment, see our [Morpheus review](https://ownyourmind.ai/projects/morpheus/). ## How the system works The architecture has four moving parts: 1. **Your AI model server.** llama.cpp, vLLM, or any OpenAI-compatible API 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 contract on BASE.** An on-chain marketplace where providers register, post bids, and consumers purchase sessions. 4. **MOR token.** Payment and staking 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 emissions 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 query 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. (figures as of 2026-10-23) ### 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 serving. ### Install llama.cpp with CUDA ```bash 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 ```bash ./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: ```bash ./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](https://github.com/MorpheusAIs/Morpheus-Lumerin-Node/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 TEE attestation: 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](https://github.com/MorpheusAIs/Morpheus-Lumerin-Node/blob/main/docs/providers/full/secretvm-quickstart.mdx). 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: ```bash xattr -c proxy-router ``` ### Option 2: Docker ```bash 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: ```bash # 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 wallet 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 ```bash ./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: (figures as of 2026-10-23) | 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. (figures as of 2026-10-23) 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. (figures as of 2026-10-23) ### 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 ATH, and would make the compute pool attractive even with hundreds of providers. (figures as of 2026-10-23) **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 enclave 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 gas. 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](https://github.com/MorpheusAIs/Morpheus-Lumerin-Node/issues/881#issuecomment-5619268310), 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](https://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](https://github.com/MorpheusAIs/Morpheus-Lumerin-Node/releases) - **Source code:** [MorpheusAIs/Morpheus-Lumerin-Node](https://github.com/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.