MUD
Lattice's open-source MIT-licensed framework that brought game-engine discipline (ECS, then an onchain relational store) to EVM development, becoming the de facto engine for fully onchain games and 'autonomous worlds.'
▶ Run interactive simulation animated mechanism with editable parameters
How it works onchain
Summary
MUD is an open-source (MIT) engine for building complex onchain applications — especially fully onchain games and "autonomous worlds" — created by Lattice. It grew out of the Dark Forest milieu: in 2020–21 Lattice's pseudonymous founder Ludens began collaborating with Dark Forest developers, and the team's attempt to build a fully onchain game (zkDungeon) collapsed under infrastructure toil — most engineering time went to state sync and indexing rather than game design. Their conclusion was that Ethereum needed a game engine, not another bespoke contract suite. MUD v1 was publicly announced in November 2022 (debuted at Devcon VI in Bogotá, October 2022) as an Entity-Component-System (ECS) framework for EVM state. MUD v2 — a deeper redesign around an onchain relational database ("Store") and a shared "World" kernel — was audited by OpenZeppelin (completed February 2024) and shipped as stable 2.0 ahead of the May 2024 launch of Redstone, Lattice's OP Stack L2 for MUD apps. It is widely regarded as the most-used framework for fully onchain games, adopted by 30+ projects including Sky Strife, Biomes, This Cursed Machine, and CCP Games' EVE Frontier.
Design (Mechanism)
- v1 — ECS on the EVM. Borrowing the dominant pattern from game engines: Entities are numeric IDs, Components are per-attribute data contracts keyed by entity, Systems are contracts holding logic that reads/writes components. New components and systems can be registered without modifying the core, so third-party developers extend a world on equal footing with its creators ("no first-party vs third-party distinction"). A standardized data layout means one generic indexer and client sync stack works for every MUD app, replacing per-project subgraphs.
- v2 — Store + World. Lessons from v1 (documented in Lattice's "zero to v2" retrospective) drove three changes: (1) tight bitpacking replaced wasteful
abi.encodestorage; (2) the single-key ECS model was generalized into a multi-key relational model — onchain "tables" with composite keys (e.g., Sky Strife needed match-ID + entity keys to segment parallel matches); (3) a central World contract became the entry point, routing calls to namespaced Systems and providing shared access control and account delegation (session wallets) instead of ad-hoc per-system permissions. - Tooling as mechanism. Automatic indexer, client sync libraries, optimistic execution via local EVM simulation (instant UI feedback before inclusion), hot contract reloading in a dev server, and frontend templates. The framework's bet: standardizing state layout unlocks the entire toolchain "for free."
- Distribution. Fully open source under MIT; monetization sits not in the framework but in the adjacent Redstone chain operated by Lattice.
Outcome
Ongoing and broadly successful as infrastructure. Proof-of-concept OPCraft (an onchain voxel Minecraft-like built in ~2–3 months on an OP Stack testnet, October 2022) drew 1,000+ players and ~3.5M transactions in a two-week playtest, producing emergent player politics (a player who amassed ~135,000 diamonds declared an "Autonomous People's Republic of OPCraft"). MUD v2 passed an OpenZeppelin audit (February 2024) and reached stable 2.0; Redstone mainnet launched May 2024 with eight onchain games at launch. MUD became the reference EVM framework in its category (its main rival, Dojo, is a Starknet/Cairo port of the idea), with adoption spanning solo devs to a AAA studio (CCP's EVE Frontier). GitHub shows 86+ contributors. Counterpoint: no MUD-based game has yet achieved sustained mainstream scale, and the fully-onchain-games category remains niche — MUD is technically dominant in a small market.
Why it worked
- Solved the real bottleneck. Lattice built MUD after directly suffering the problem (zkDungeon); the framework encodes hard-won pain, not speculation.
- Standardization compounds. One canonical state layout meant indexers, sync, explorers, and templates could be built once and shared by every project — the classic engine/OS network effect.
- Credible dogfooding. OPCraft and Sky Strife proved the engine on ambitious first-party games before asking others to adopt it, and v2's redesign was driven by those deployments' concrete failures (ABI-encoding waste, single-key limits).
- Open-source + neutral extension model. MIT license and permissionless System/table registration made MUD safe to build on and aligned with the "autonomous worlds" ideology Ludens articulated, which gave the project a motivated community, not just users.
Limitations and criticisms
- Market ceiling. Fully onchain games remain a small audience; the engine has outrun demand. Technical leadership in the category has not yet translated into a breakout consumer hit, and it's unclear how much of that gap engine design can close.
- Long pre-production. ~18 months between v1 and audited stable v2 meant early adopters built on shifting APIs and some churned; mainnet-grade readiness only arrived in 2024.
- EVM cost/latency constraints. Even with an engine, real-time gameplay requires a dedicated low-cost chain (hence Redstone), coupling MUD's flagship deployments to Lattice's own L2 and partially re-fragmenting the ecosystem across chains.
Lessons
- Infrastructure extracted from a failed app beats infrastructure designed in the abstract — zkDungeon's death was MUD's requirements document.
- Standardize the data layer and the toolchain follows: a canonical onchain state format turns indexers, clients, and explorers from per-project costs into shared public goods.
- Ship an opinionated v1, then be willing to break it: MUD's ECS-to-relational pivot shows early architectural bets should be treated as hypotheses, validated by flagship dogfood apps.
- An engine can't create its market: developer leverage is necessary but not sufficient; category demand (players) is the binding constraint for game infrastructure.
- Open-source frameworks monetize adjacently (Lattice via the Redstone chain), which funds development but creates gravitational pull toward the maintainer's platform.
Redesign (EDITORIAL — hypothesis, not fact)
This section is editorial speculation, not a description of anything Lattice has done or planned. A redesigned MUD might attack the demand side rather than add engine features: (1) treat interoperability between Worlds as a first-class protocol — standardized cross-World entity portability could make the "autonomous worlds" pitch concrete instead of ideological; (2) decouple flagship deployments from a single house L2 by shipping first-class multi-chain World bridging, reducing the perception that MUD's success is captive to Redstone; (3) formalize the emergent-governance behaviors OPCraft surfaced (land claims, player states) into reusable governance tables/Systems, turning MUD's most memorable demo phenomenon into a product primitive; and (4) fund the ecosystem's missing layer — live-ops and content tooling for non-Solidity game designers — since the engine has arguably already won the developers it can win with contracts-first ergonomics.
Sources
- MUD — Framework for onchain applications (official site) — primary (docs)
- latticexyz/mud (GitHub, MIT license) — primary (contract)
- MUD: An engine for Autonomous Worlds (v1 announcement by ludens & alvarius) — primary (docs)
- MUD from zero to v2 (Lattice retrospective) — primary (retrospective)
- MUD v2 is ready (Lattice) — primary (docs)
- Making of OPCraft Part 1: Building an on-chain voxel game (Lattice) — primary (retrospective)
- Lattice — About (team, history) — primary (docs)
- The Ultimate Guide to the MUD Ecosystem (WASD) (analysis)
- Dungeons and Dojos: Exploring Onchain Game Development with MUD and Dojo (BITKRAFT) (analysis)
- Redstone Network Launches to Power Fully On-Chain Ethereum Games (Decrypt) (news)
Related experiments
Last verified: 2026-07-26 · Spot an error? Suggest a correction