What Will Dojo and Mud Bring to the Autonomous World and On-Chain Game Engine Narrative?
TechFlow Selected TechFlow Selected
What Will Dojo and Mud Bring to the Autonomous World and On-Chain Game Engine Narrative?
On-chain gaming promises to bring to gaming what DeFi brought to traditional finance: decentralization and permissionless composability.
Navigating Web3 tides with focused insightsAuthors: Simon from IOSG Ventures, Sylve from Dojo & Kooshaba from Lattice
From PC to mobile internet, and even artificial intelligence, games have driven the adoption of new technologies by educating a new generation of consumers and creating use cases that didn't previously exist.
Through playing and making fun games, people experiment with new technologies and come up with ideas for how to leverage them. One simple conclusion gamers can draw is this—there are some of the most brilliant designers and developers in the gaming industry!
#Devconnect Istanbul's #AutonomousWorld Assembly# may be the most insightful and innovative crypto event in recent times. At AW, we saw people using crypto to do entirely new things—not just doing old things better—and this is precisely why IOSG sees AW/FOCG as one of many pathways toward mass adoption. (The following content is based on presentations by Sylve from Dojo and Kooshaba from Lattice at IOSG OFR Istanbul.)
Why AW - Dojo:
"Why would anyone put games on blockchain?" I'd like to try answering this question.
So far, blockchain games have focused on one thing: putting as little of the game as possible on-chain—only the assets—because it makes sense: they're decentralized and interoperable. But what happens if we also move gameplay and utility on-chain?
On-chain games promise a lot of things—I want to summarize them. I’d say they promise to bring to gaming what DeFi brought to traditional finance: decentralization and permissionless composability. But we want to go further—we introduce another concept called Autonomous Worlds.
This is still a very fuzzy definition. But our idea is this: beyond any single game’s control, you have a persistent world where anyone can continuously participate. Imagine a world built on blockchain, open for contributions from anyone. That’s our starting point. If you look at Twitter, everyone has their own idea about what an autonomous world should or shouldn’t be. We have many ideas too. So a large group of people spends enormous time and energy trying—even conceptually—to understand what this means. We even have companies building game engines to help more people join and build on-chain games: we have Mud, Dojo, Argus, and Curio. We’re highly confident this is exciting, and we hope even more people join and build.
Why? Why spend so much time and energy on this? My answer is negative: Why *shouldn’t* we do this? It really is a bad idea not to.
First, games are hard to build on blockchains. Blockchains aren’t fast enough and are too expensive for games. We’ve heard this before. I love this Antonopoulos quote: “Most networks simply cannot scale gracefully, but these are ultimately the networks we need.” He was talking about the internet. Using the internet for certain applications wasn’t originally intended; every time we push its limits, people say, “You shouldn’t do this on the internet—it wasn’t made for that.”
For blockchain, we’re at a similar starting line. Various initiatives said: “No, don’t put money on blockchain, please—you’ll break it.” Looking at blockchain history, most network collapses were caused by games. Now we hear, “Please don’t put game tokens on chain—you’ll ruin the fun.” Fortunately, now we have Layer 2s and Layer 3s offering these as services—a huge improvement over the past.
I think there are three main reasons to put games on blockchain.
We’re building something powered by your effort and capital. Blockchain is a legitimate machine. You don’t need to trust me or my reputation—you only need to trust the code. This legitimacy benefits many new independent developers and creators, enabling them to build multiplayer worlds without needing to be Valorant or Fortnite. You can just build your own game and benefit from the legitimacy blockchain provides. People will trust the code, not you.
To me, “permissionless possibility” is the most interesting part. Building games on blockchain allows mixing and matching. This doesn’t mean it’s impossible off-chain—just that blockchain makes it extremely convenient. You could use APIs or other methods, but direct access is easier.
For example, here we have two worlds, A and B. They share the same map, but maybe you have another game with different applications showing identical game logic. Going further, you could even enable contributions to this shared world. The value isn’t always provided by a single company. For instance, some games today run on MUD—people never get tired of them. What happens if you find ways to incentivize contributors?
Finally, I think it all comes down to George Mallory’s spirit. When asked why climb Everest, he said: “Because it’s there.” I believe people today enjoy challenges, communities, and great collaborations. “You shouldn’t do this on blockchain”—well then, why *not* do it?
Lattice, the team behind the fully on-chain game engine Mud, launched last week a Layer 2 built on the OP Stack, significantly reducing L1 submission costs to support fully on-chain games or autonomous world dApps. Starting from developing Mud, Lattice has aimed to provide an open-source, modular framework for fully on-chain games or autonomous worlds, hoping to establish a universal standard and lower barriers for developers. Redstone takes it further by solving the problem of which chain to deploy on, strengthening the moat even more—the full-stack development path of Mud + Redstone. This could greatly influence decisions by fully on-chain games or apps to use RaaS for launching chains.
What AW - Lattice
“Why are on-chain games so hard, and how can we make them better?” Today I want to talk about how to build good on-chain games.
We’ve been working on on-chain games for a while, and I’ve been thinking deeply about this. To me, this is the dream—this is why we’re here.
I work at Lattice, where we’ve been developing on-chain games—specifically, a core game engine called Mud and an on-chain framework. At Lattice, I focus on Sky Strife and game development.
Here’s a screenshot of Runescape. Runescape is a browser-based 3D online game launched in 2001. It’s insane—still played by millions today. Personally, I’ve spent thousands of hours in Runescape. If you haven’t played Runescape, we can never be friends. It’s a fascinating game—I’ll briefly describe it. You start at level one, extremely weak, aiming to gain skills, money, influence, and power. It’s like a second life for kids and immature adults. It features a player-driven thriving economy where money is central, along with PVP actions and permanent death—losing everything on your character.
Throughout Runescape’s development, players have protested against the developers—mostly about the economy. Now my question is: How can we make Runescape unstoppable? If you asked any regular Runescape player, “Hey, would you like to kill everyone who made this game?” I think they’d say, “Yes, I wish they disappeared. No one should control it. We want a game that exists independently, unmonopolized.” That’s why I add many constraints to this discussion. An “autonomous world” is our dream—we want a Runescape-like game on-chain that can never be stopped, controlled by no one, with no admin keys, no upgrade privileges. The game logic is 100% on-chain, permissionless, client-agnostic. Ideally, you could play it in a terminal window—no graphics needed.
Technically speaking, no precompiles, no application-specific genes—not that I’m criticizing them, but if we truly want an autonomous world as a dream, such technical choices sacrifice decentralization for gameplay. Today we’ll focus on EVM, the most common execution environment. Let’s keep it simple.
Runescape runs at 1.66 Hz gametick, which is very slow by traditional standards—I believe Valorant and CS:GO run at 120 or 140 Hz. So, seems achievable on-chain, right? Still faster than most blockchains we’ve seen. With a simple game loop, we should definitely achieve this on-chain. What could go wrong?
Here’s the starting area. Next to it is a small goblin village where players begin at level one. Typically, players walk here and start fighting goblins—many around. You can spend hours killing goblins, looting, etc. First task: get these goblins moving. Should be fine. In traditional architecture, you need a server with a “√” deciding where each goblin goes. The server moves them step by step, players chase and defeat them. Our first problem is pathfinding—we need to compute pathfinding on-chain. This is the first hurdle: running navigation on-chain is completely unbounded. For example, if a player being chased runs far outside the goblin spawn zone, the goblin must calculate surrounding objects—possibly exceeding block gas limits.
The first limitation: goblins act stupidly. You must stand very close for them to notice you—they don’t have five satellites orbiting stars. Another issue: who sends these transactions? There’s no background server ticking away. Someone must manually send a transaction saying, “Hey goblin, attack that player.” If players send these themselves, they never will.
Why would I voluntarily trigger a goblin attack? Traditionally, the on-chain solution is: only when the player interacts with the goblin first—counterattack when attacked. But this fails late-game—you can’t attack goblins anymore. You can just run away, risk-free.
Thus, we must somehow incentivize players to send transactions to run goblins—while also paying gas. All this just to simulate goblins walking around in a game server, feeling alive, making you afraid. For traditional games, it’s just appearance. But here, we need strange economic incentives—telling players: “Hey, we’ll give you a tiny token reward for letting goblins capture you.”
We continue. We need to navigate terrain—avoid goblins. Now we must run coordinates on-chain. Players compute paths locally and submit them to our contract. The contract only verifies validity. Verification is still computation, but much simpler than full pathfinding. Technically, players can submit any valid path—they calculated it. We can proceed.
Great—players and goblins run around, collide. Besides them, the game world mostly has terrain—like trees, common in traditional games.
How do we know this tree exists on-chain? We won’t debate optimal on-chain storage now. Eventually, the tree must enter storage—that’s “gas.” Who pays to store the world? As a developer, you bear the cost. This is just Runescape’s starting area—the full world might be 1,000–2,000x larger. And this is just a relatively simple browser-run MMO. Due to various constraints, anything on-chain faces massive scalability limits. It’s technically feasible—if you spend millions moving the entire Runescape map on-chain, you can. Even on mainnet.
In Runescape, hitting a goblin shows a number from 0 to 15. At level one, damage has randomness. Randomness is another thing hard to implement cleanly on-chain. How do we do it? Each player action commits a past block hash. On next attack, reveal that hash to determine randomness. A small technical detail, but it permeates on-chain game design.
With this commit-reveal scheme, you always know your next action’s outcome—you never wonder, “How much damage will I deal?” You only consider post-attack damage. It’s a weird thing players must adapt to. Actually, you’re just hiding information across the stack. Anyway, our combat uses this odd randomness, goblins move, we have a world map—players enjoy it.
Great—what do goblins drop? In traditional Runescape, they drop coins. You see I have a few. Say, 3–5 coins. In game design terms, this is a faucet. Even small amounts cause infinite exploitation—someone sits forever abusing the faucet, farming infinite coins from the goblin spawn. Inflation? Fine in traditional games. But in on-chain games, it’s a problem—any token tied to rewards quickly drops to zero. So we need sinks. We need fundamental wealth destruction—methods to remove value from the ecosystem. I believe this will become a core design decision for all on-chain games. Unlike traditional MMOs, you must now worry about inflation. Here, I think we need extreme permanent death—characters must be fragile, gold must leave the system faster. Not great for new players—if every corner brings fear of death, maybe it’s just an education problem. In our on-chain games, you should constantly feel fear—basically like real life.
Alright, I don’t have a fully satisfying answer on how to make this better, but everything I described is technically feasible on mainnet. Only cost—not technology—stops you. But it *is* an educational challenge, a shared foundational problem.
Currently, every on-chain game developer reinvents the wheel—writing their own libraries or using proprietary tech. We need consensus. We need a shared game engine, a shared framework. Trust my napkin math: I quickly prototyped—if five players and five goblins, ~2.3 million gas per second. Crazy. Compared to current chains: Ethereum mainnet theoretical max is ~2.5M gas/s. Arbitrum Nova, touted fastest, does ~7M gas/s. Uh, Base hits ~15M gas/s.
If I missed your favorite chain, sorry—I spoke fast. But fact is, we’re not there yet. Running Runescape’s unstoppable goblin spawn would consume all Ethereum mainnet resources. Let that sink in. So yes—just to clarify: our games aren’t physically impressive yet—we have a tiny village. Running this on Ethereum mainnet already demands chains capable of supporting large worlds.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
IOSG Ventures
