
What is the "AMM moment" for on-chain games?
TechFlow Selected TechFlow Selected

What is the "AMM moment" for on-chain games?
TickChain is the AMM moment for fully on-chain games.
When describing the revolutionary impact of a product, technology, or innovation within a specific industry, we often refer to it as that industry’s “iPhone moment.” This is based on the profound influence Apple's iPhone had on the mobile phone and computing industries after its release in 2007.
In the DeFi space, we call it the “AMM moment.” The Automated Market Maker (AMM) model played a pivotal role in DeFi, especially in enhancing market liquidity, directly catalyzing the bull run of 2021. So, what would be the “AMM moment” for fully on-chain games? Let’s explore this in detail.
I. The Crucial Role of AMMs in DeFi
DeFi combines blockchain technology with finance—essentially encoding financial rules into smart contracts to achieve decentralization, privacy, and automation. In any financial system, what matters most? Clearly, it's "liquidity." For example, the three core business models—lending, trading, and payments (stablecoins)—cannot operate sustainably without sufficient liquidity.
Lending: Liquidity is the foundation of lending. Banks and financial institutions rely on short-term deposits and funding sources to issue long-term loans. Without adequate liquidity, they may fail to meet loan demands or face crises when repaying short-term debts. Liquidity risk is a key factor in financial crises—when banks can't secure enough funds to honor their lending commitments, they risk collapse.
Trading: In capital markets, liquidity is essential for trading. High liquidity means assets can be bought or sold quickly without significant price slippage. If a market or asset lacks liquidity, investors may face wider bid-ask spreads or struggle to find buyers when selling, potentially causing sharp price swings and market instability.
Payments (Stablecoins): Liquidity in payment systems (e.g., stablecoins) is critical. When individuals or businesses transfer funds, they depend on efficient and reliable payment infrastructure. Insufficient liquidity could lead to delayed or failed transactions, disrupting broader economic activity.
In Web3, trading is the core financial function, as both lending and payments serve trading (leveraging and acting as mediums of exchange). So why did the “AMM moment” happen? It was fundamentally driven by the performance limitations of blockchains.
We know that traditional financial institutions run their systems on high-performance private servers, enabling extremely efficient order matching. In contrast, DeFi encodes financial logic into smart contracts—sacrificing matching efficiency for decentralization and privacy.
Smart contracts, as simulations running on a “world computer,” are inherently low-performing. Early DeFi projects—whether lending platforms or exchanges—used traditional order book models. Under this model, DeFi stood no chance against CeFi—until the arrival of AMMs.
How can an ultra-low-performance “world computer” significantly improve liquidity matching efficiency? The AMM model solves this by using liquidity pools and algorithms to automate matching. While many articles have explained the mechanics, here we focus on the known advantages:
No need for traditional market makers: In traditional finance, market makers provide bid/ask quotes to maintain liquidity. AMMs allow liquidity providers to deposit funds into a smart contract, which automatically adjusts prices and executes trades via predefined algorithms—eliminating the need for intermediaries.
Liquidity Pools: These pools act as always-available counterparties for traders. Providers earn transaction fees in return, incentivizing participation and boosting overall market liquidity.
Reduced transaction friction: Thanks to automation, traders can execute trades instantly without waiting for order matching—greatly reducing friction.
Driving DeFi innovation: The AMM model enabled new innovations such as yield farming and dual-token liquidity pools, accelerating DeFi adoption and development.
Remarkably, the AMM mechanism brought DeFi’s liquidity-matching efficiency on par with CeFi—ultimately sparking the DeFi Summer.
II. The Fundamental Conflict Between Games and Blockchains
Now, fully on-chain games are at a similar crossroads: How do you run a game on an extremely low-performance “world computer”? To answer this, we must first understand the fundamental conflict between games and blockchains.
I once wrote an article titled What Is the Difference Between ARC and ECS in Fully On-Chain Game Engine Architecture?, where I introduced the concept of the game loop and pointed out that traditional games are loop-based.
Traditional games are loop-based because their core operation relies on a game loop—a continuously repeating cycle typically involving input processing, game state updates, and rendering. This loop runs dozens to hundreds of times per second during gameplay to maintain smoothness. Within this architecture, game systems (like physics engines or AI) check and process relevant entities and components during each iteration.
In contrast, blockchain architecture is push-based. A blockchain is a distributed database shared and stored across network nodes. When a node generates a new transaction (e.g., a transfer or contract call), it broadcasts ("pushes") it to the network. Other nodes receive, validate, and add it to the chain. This is a passive process—nodes don’t actively seek new transactions but wait for them to arrive. Hence, blockchain is described as push-based.
This already answers our earlier question. The core conflict lies in architectural mismatch: games are typically loop-based, while blockchains are push-based. Resolving this contradiction would mark the “AMM moment” for fully on-chain games.
To go deeper, let’s examine how game loops are implemented.
Every game involves a sequence of operations: capturing user input, updating game state, handling AI, playing audio, and rendering visuals. These are managed through the game loop. Without delving into each task, we can simplify the loop to just two functions: update and display. Here’s a minimal example of a game loop:
bool game_is_running = true;
while( game_is_running ) { update_game(); display_game(); }
Let’s define three key terms:
Tick
"Tick" is synonymous with "game loop"—1 tick = 1 game loop.
FPS
FPS stands for Frames Per Second—the number of times display_game() is called per second.
Game Speed
Game speed refers to how frequently the game state is updated per second—in other words, how many times update_game() is called each second.
To summarize: Tick/Game Loop is the basic cycle of a game, determining how game logic progresses. FPS measures visual smoothness through render frequency. Game speed defines the pace of gameplay and usually matches the tick rate. Ideally, tick rate, FPS, and game speed are aligned—each logic update followed by a render. But in practice, especially under performance constraints, these values may diverge.
III. Core Challenges in Fully On-Chain Games
With this understanding, we can now identify the core challenges in building fully on-chain games:
-
Mismatch Between Game Loops and Blockchain: Traditional games rely on continuous game loops, updating state every tick. Blockchains, however, are event-driven—state only changes when new transactions occur. This fundamental mismatch makes implementing traditional game loops on-chain highly complex.
-
Latency and Real-Time Responsiveness: Blockchain transaction confirmation delays can impair game responsiveness—an issue for fast-paced genres like action or competitive games. An effective ticking mechanism must minimize this latency’s impact on gameplay.
-
Resource Limits and Computation Costs: Every blockchain state update consumes computational resources and incurs costs. Frequent updates in on-chain games could become prohibitively expensive. Thus, an efficient ticking mechanism must balance smooth gameplay with cost-effectiveness.
Developing a new ticking mechanism or game loop model tailored to blockchain characteristics could indeed be the “AMM moment” for on-chain gaming. This may require merging traditional game development techniques with blockchain-specific innovations to create an entirely new framework.
Are all game types loop-based? While most are, some games are naturally “push-based,” requiring no continuous real-time updates. Examples include turn-based strategy games, board games, or certain card games. In these, state only changes when players take actions—aligning well with blockchain’s event-driven nature. Therefore, for fully on-chain games, it may be strategic to start with genres that fit the push-based model, allowing a more natural integration with blockchain.
IV. Ticking Chains Are the AMM Moment for On-Chain Games
Scott, founder of Argus, shares a similar view:
Games operate on a loop-driven runtime. Even without user input, state transitions continue—fire burns, water flows, crops grow, day turns to night.
So how can we design a ticking mechanism suitable for blockchains? @therealbytes provided the answer. I previously translated his seminal article, How to Build a Clock Cycle for Fully On-Chain Games Using OPStack, which details how to construct a ticking system using smart contracts and precompiles. Unfortunately, due to its technical depth, it received the lowest traffic among all my translations—much like Vitalik’s early post “Let’s Run On-Chain Decentralized Exchanges the Way We Run Prediction Markets,” which first introduced the famous constant product formula “A * B = k.”
(An interesting note: back then, there was no term “DeFi”—it was simply called “on-chain decentralized exchange,” just as we now say “on-chain game.”)
In that article, @therealbytes was likely the first to propose leveraging blockchain-level precompiles to implement ticking: Ticking-Optimism modifies rollup nodes to generate a “tick transaction” that works similarly to a deposit transaction—not setting L1 attributes, but invoking a tick() function in a predeployed contract at address 0x42000000000000000000000000000000000000A0. This contract can be configured to trigger another contract.
Embedding the ticking function directly into the chain node represents a massive leap in loop efficiency—directly comparable to how AMMs revolutionized matching efficiency over order books in DeFi. Just how significant is this improvement? Data from another article I translated, “[Timing the ‘Digital God’](),” provides insight:
To test the chain’s limits, he implemented the game in two ways: one as a Solidity smart contract on-chain, and the other as a custom precompiled engine within the chain itself. The Solidity version maxed out CPU usage (1 block/sec, ~10k cells/sec) on a 70x70 grid with two updates per block. In contrast, the precompiled engine achieved the same update rate on a 256x256 grid while using only ~6% CPU (~130k cells/sec).
V. Conclusion
If the AMM model ensured financial systems could achieve high matching efficiency and liquidity even on low-performance blockchains, then the ticking chain ensures game systems can achieve high loop efficiency and smoothness under the same constraints.
The above describes only @therealbytes’ proof of concept. In practice, several fully on-chain game engines have already adopted this ticking chain approach. The first open-source ticking chain engine is @0xcurio, which uses OPStack with precompiled ticking functions to build its Layer 2. The second is @ArgusLabs_, which uses Polaris to build a Layer 2 with precompiled ticking. I believe many more ticking chains will emerge in the future.

The table above compares blockchain applications in finance and gaming, revealing striking similarities. Initially, DeFi used the order book model—an active, manual matching system. With AMM, it transitioned to a passive, automated system. Similarly, early on-chain games relied on conventional “lazy updates” and “manual ticking”—active loop management. With precompiled ticking chains, they shift to passive, automatic loops. AMMs enhanced financial liquidity; ticking chains enhance game fluidity.
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














