
Paradigm's Latest Paper: The Unique Value and Open Challenges of Fully On-Chain Games
TechFlow Selected TechFlow Selected

Paradigm's Latest Paper: The Unique Value and Open Challenges of Fully On-Chain Games
Why put games on the blockchain?
Authors: Charlie Noyes, Doug
Translated by: CaptainZ
The intersection of games and cryptocurrency is full of possibilities. Vitalik was inspired to create Ethereum after Blizzard weakened his Warlock's abilities in World of Warcraft. World of Warcraft isn't "critical infrastructure," but we expect virtual worlds to become critical infrastructure—containing trillions in assets and millions of jobs. It’s hard to imagine such worlds existing under the control of centralized platforms.
Of course, decentralized applications sound appealing in theory. The most compelling ones in practice are those that can only exist through crypto—applications that can only emerge on-chain. Despite strong narrative momentum, it has proven difficult to clearly identify what unique features fully on-chain games actually offer.
Why put games on a blockchain?
This article reflects our current thinking on this question.
Designing for Emergence
Some games maintain long-term engagement by giving creative users tools to generate new content themselves ("UGC"). We see two main sources of UGC—mods and open economies—as potential breakthrough directions where fully on-chain games could excel.
Mods
Mods allow third-party developers to create experiences beyond what the original game developers envisioned. Many genre-defining games (e.g., DoTA, LoL, PUBG) originated as mods of other games. Others, like Roblox, have evolved from games into mod development platforms. While game studios typically focus on producing value, highly engaged mod communities bring diversity and novelty—akin to the contrast between Netflix and YouTube.
Minecraft is a strong concrete example. Simple game mechanics make it easy to modify. Mods that extend these mechanics can be recombined into functionally new experiences. Many popular Minecraft servers are entirely different from the original (e.g., prison escapes, battle royales).
However, even Minecraft has a limitation: players cannot contribute new mods to existing servers. They must launch a new server to introduce changes. As a result, Minecraft’s “universe” is fragmented across many parallel, mostly non-interacting private servers.
There are good reasons why modern games implement mods via instantiation (new servers) rather than scripting (modifying existing servers). Ensuring player-contributed code remains compatible with native rule sets is difficult (especially when exploited). Rule set updates may break mods built atop them. Limited computational resources require intelligent allocation.
Yet instantiation leads to fragmentation. Every mod spawning a new server competes with others for player attention. Mod developers must consider not only what addition makes a world interesting, but whether it’s worth launching an entirely new server.
Consider that many potential mods only make sense in context—i.e., added onto an already-existing world. For instance, suppose you run a restaurant on a Minecraft server and want to add a new menu item. Launching a new server for this is meaningless—you’d need to convince all your customers to migrate, which they likely won’t do because they have their own commitments and customers on the current server.
Fragmented game worlds lose the ability to incrementally expand.
Open Economies
In-game economies represent another dimension of near-infinite creativity. We’ll use EVE Online (the first game to hire a full-time economist) as a teaching example.
Through informal combinations of game systems and external infrastructure, EVE players produce and trade goods; declare, lease, and fight over territory; and organize everything from industrial collectives to militant pirate gangs. Even simple tasks like transporting resources are handled by fully player-run companies—with customer service, SLAs, and employee benefits.
Players have stayed in EVE for over two decades—not because of developer-generated content, but due to the rich social and economic world driven by other players.
Yet even EVE’s economy faces significant limitations:
1. Limited in-game primitives. Any transaction beyond the developer-defined set (e.g., loan agreements) must rely on informal, unenforceable trust networks. This trust constraint limits the complexity and scale of economic structures.
2. Regulatory constraints. Due to compliance issues, most games (including EVE) simply block players from transferring assets or exchanging in-game goods/services for fiat currency. Those that allow it require large compliance teams and operate under strict terms.
Fully On-Chain Games
There are many potential forms of blockchain games. Our focus is on the most crypto-native variant: fully on-chain games, whose state and logic exist entirely on open smart contract platforms.
Equally important, mods for fully on-chain games can be permissionlessly deployed as separate contracts alongside the base game logic. Users can then choose which mods to participate in simply by selecting their client (rather than having administrators decide for them).
So, why put games entirely on blockchains? We believe the strongest rationale rests on two points:
Composable modifications. Players can add mods to fully on-chain games without requesting permission or splitting state. On-chain infrastructure and smart contract developers have already prepared for the challenge of allowing permissionless code uploads: security audits, access control, resource metering, etc. Traditional games aren’t built for such environments and are unlikely to restructure around supporting composable mods.
Permissionless open economies. Players can use smart contracts to build a game’s economy instead of being limited to a fixed set of primitives defined by developers or relying on informal, unenforceable agreements. Additionally, player sovereignty over game assets eliminates compliance costs.
Composable mods aren’t uniquely enabled by fully on-chain games—they’re path-dependent innovation. While traditional games could theoretically support composable mods, they currently don’t and lack incentives to change. This model will only be explored out of necessity—that is, within crypto.
The combination of composable mods and permissionless economies could generate large-scale on-chain game worlds. Mod developers would build upon simple foundational rule sets, extending them with new content. They could use real money, access DeFi markets, and experiment freely. Resulting economies might grow extremely complex and recursively incentivize cumulative content creation. Once clear profit opportunities emerge, activity could explode—mirroring the speculation-experimentation cycles seen in other crypto ecosystems.
Most discussions about fully on-chain games dive deep into this detailed optimistic future. We’re more interested in understanding the obstacles preventing this future—the open problems that must be solved before massive game worlds can emerge.
Open Problems
Technical limitations constrain game design.
It’s widely believed that the main reason no fully on-chain game has stood out yet is that the technical infrastructure isn’t ready. Most games remain at the proof-of-concept stage: simple gameplay, buggy clients, and limited participation from players and mod developers.
Existing infrastructure and developer tools are limited. In particular, the EVM is slow and clunky, Solidity’s data model is ill-suited for complex game development, and no mainnet chain serves as a viable deployment target (due to high costs and low scalability).
Fortunately, we’re seeing paths forward. Rollup scalability and cost reductions are gaining broad acceptance across the crypto community. Many teams are building game-specific infrastructure. For example, Lattice is developing a system combining Solidity frameworks with compatible tooling (indexing, state sync, etc.) to simplify EVM game development. Teams like Dojo, Argus, and Curio are also building infrastructure platforms.
Other challenges stem more fundamentally from the nature of fully on-chain games. Specifically, certain properties of permissionless chains hinder support for mainstream game design mechanisms:
1. Imperfect Information: A key mechanism in many games. Existing solutions have unacceptable flaws (e.g., DarkForest’s cryptographic fog of war devolved into a hardware mining race).
2. Automation & Sybil Collusion: Fundamentally impossible to prevent. Cannot distinguish bots from real players or ensure players are unique. Developers must build games resilient to bot strategies and Sybil collusion.
3. Timing: Blockchains are driven by asynchronous transactions. Most traditional games are built around timed game loops independent of player interactions.
These constraints might inspire creativity and spawn game types we’ve never seen—just as MakerDAO and Uniswap emerged from DeFi without borrowing models from traditional finance. However, traditional games face fewer technological and legal constraints than traditional finance—they’ve already explored broader territories—so the likelihood of novel fully on-chain games emerging from unknown domains seems smaller. We believe improvements to these constraints are necessary to give fully on-chain games a fighting chance at success.
Research Directions
1. TEE. Though cumbersome, Trusted Execution Environments (TEEs) are currently the only practical option for private, permissioned computation on public blockchains.
2. MACI. Originally designed by Vitalik Buterin to enhance collusion resistance in on-chain voting systems, MACI could be adapted for on-chain games and further improved through tight integration with relevant game systems.
3. Custom Rollups. By modifying rollups to include global timing as part of their state transition function (without gas cost), it may be possible to achieve some form of traditional timed game loops on-chain. Other game-specific rollup modifications could also prove valuable.
Using ZKPs to enable private state is another active research direction. However, we’re skeptical whether their non-programmable privacy can unlock meaningful game mechanics. Current circuit-writing difficulties also limit their practicality.
Composability is Inherently Financialized
In a system open to the entire world, incentives aren't just suggestions—they're more like physical laws, such as gravity or entropy. If any aspect of a system is incompatible with incentives, it's only a matter of time before it gets exploited.
— Nikolai Mushegian
Smart contract blockchains are highly adversarial, financialized environments. This isn’t a path-dependent artifact of decentralized culture—it’s a mechanical consequence of permissionless composability. As applications primarily based on composability, fully on-chain games are exposed at a fundamental level to these incentives.
In isolation—before considering modularity’s effects—fully on-chain game developers must contend with the inevitability of real-money markets, MEV (front-running incentives), and economic exploitation. The bar for designing an incentive-compatible fully on-chain game may be quite high—perhaps equivalent to designing a secure DeFi product.
Second-order problems are trickier. Fully on-chain games are designed to be modifiable, and modularity brings its own emergent incentives. Even if developers skillfully manage core game incentives, they cannot predict what will be built atop them—or what new incentives will arise. (Indeed, enabling such unpredictable emergence is their goal.)
Drawing another analogy to DeFi, consider an oracle. In isolation, an oracle might be economically secure (resistant to manipulation). Yet the oracle cannot foresee which applications will integrate with it or how they’ll compose. If a lending protocol uses the oracle to trigger liquidations, the oracle inherits manipulation incentives—often fatally. Similarly, when a Minecraft mod introduces MEV incentives to mine a block first, it affects gameplay for all players—even those whose clients don’t interpret that mod.
This is a hard problem to solve. Attempting to permission or otherwise restrict who can develop mods for a fully on-chain game directly contradicts the goal of maximizing emergence—the very reason for building on-chain in the first place.
We suspect incentive compatibility will be a defining challenge in fully on-chain game design. Some traditional games avoid real-world money markets due to compliance headaches; many others simply find them unfun. Fully on-chain games need to figure out how to harness financialization pressures without being consumed by them.
Research Directions
1. Anti-Fragile Design. Core game mechanics can influence—but not determine—what kinds of mods emerge atop them. To what extent can fully on-chain games encourage social mods? Which game designs are least vulnerable to corruption by higher-order incentives? These remain open questions.
2. Permissioning. A direct approach to mitigating financialization is controlling who can play the game and who can deploy new code. This clearly trades off against emergence, but it may be necessary to test games in closed gardens before exposing them to strict permissionlessness. And permissioning can be done cleverly—not just via simple whitelists.
3. Order Flow Auctions. Instead of trying to prevent emergent incentives, we might harness them. For example, by routing all game transactions through an order flow auction and recycling proceeds back into the game’s economic faucet. Value created by mods gets reinjected into the game economy (e.g., via repurchasing scarce goods). A downside is that underlying behaviors may still harm gameplay (e.g., players mining coal to fund solar projects).
Metagames Tend Toward Stagnation
Fully on-chain games will inevitably have longer release cycles than traditional games. They aim to maximize novel experiences, and frequent disruptive updates discourage creators from investing in these worlds. Updates also require new audits. Many fully on-chain game developers view permissionless “autonomy”—no admin keys, no updates, infinite persistence—as a goal in itself.
Thus, for both technical and philosophical reasons, fully on-chain games will exist along a spectrum from “never updated” to “rarely updated” autonomy.
The best-case scenario for maximally autonomous fully on-chain games is that the right rule set sparks an active modding community and endless novelty—experiences that might only emerge after decades of undisturbed evolution.
Yet most games are actively managed to prevent metagame stagnation. Players are already highly skilled at finding optimal strategies in traditional games; now MEV adds explicit financial incentives. These strategies tend to be static and boring. A truly autonomous world loses the ability to control its metagame at any level—Vitalik may have worried about the wrong thing with his Warlock.
Rather than treating autonomy as an inherent design goal, we suspect the key question will be: How much autonomy can successful fully on-chain games afford?
Research Directions
1. Seasonality. Many traditional games deploy major upgrades on cycles ranging from months to years (e.g., WoW expansions). The main trade-off is discouraging players from building complex mods, since they may become obsolete in future seasons. We see this as one of the most promising paths for iterative experimentation.
2. Automated Feedback. Just as Bitcoin automatically adjusts difficulty in response to hash power, fully on-chain games could embed anti-stagnation mechanics directly into core game systems. This isn’t exclusive to fully on-chain games—centralized games have stronger capabilities here—but necessity may drive innovation.
3. New Governance Mechanisms. Though we’re usually governance minimalists, there may be interesting space to explore non-token-based systems. The ability to create new rules could even become part of the core gameplay loop (e.g., the card game Mao). Early attempts exist—for example, Topology tightly integrates custom governance systems into their fully on-chain game Isaac.
Should Games Be Fully On-Chain?
There may be accessible on-chain game designs that cleverly leverage permissionless composability. These worlds could thrive due to open economic incentives continuously driving new content, persisting indefinitely on censorship-resistant, impartial blockchains.
But simultaneously, there may not be enough uniqueness to justify navigating these open problems—which are far from trivial. Compared again to traditional finance, games have always been highly experimental. Thus, the bar for fully on-chain games should be higher than DeFi—which solved a previously closed market.
If fully on-chain games aren’t a viable path, the reasons to be excited about them might be expressed through less “on-chain” approaches. Viable games might minimally use smart contracts—or none at all. GameFi games with NFT assets (“Web2.5 games”) offering infrastructure and interoperability with DeFi might hit the right practical sweet spot. Especially if certain elements of non-fully-on-chain games (Web2.5 games) are controlled by on-chain assets, smart-contract-based coordination around assets alone could still be powerful.
Finally, regardless of whether games go fully on-chain, the patterns they explore—especially composable mods—might drive innovation in traditional game design. Traditional studios might recognize the potential and invest heavily in redesigning off-chain engines to support composable mods. These could coexist with, surpass, or spiritually succeed fully on-chain games.
Conclusion
We see many hard problems ahead, yet still intuitively believe fully on-chain games can leverage blockchains to create strange, novel outcomes.
We’re excited to explore all frontiers of crypto-native gaming alongside other builders. We’re more interested in building games than infrastructure—and games we ourselves would play.
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














