While the whole industry is fawning over Pixels' "release flywheel," viewing it as the ultimate solution to break through in Web3 gaming, few have noticed: the white paper only depicts the flywheel's perfect forward cycle while deliberately omitting the three hidden prerequisites for its operation and the three fatal flaws currently being exposed.
This so-called "decentralized AppsFlyer" growth engine isn't born to self-operate in a perpetual cycle. Every part of it has a fragile balance point; once there's an issue in any segment, the whole flywheel could not only stop spinning but might even reverse, dragging the entire ecosystem into a death spiral.
The white paper summarizes the launch flywheel in three sentences: Better games generate richer data, richer data achieves more precise targeting, and lower UA costs attract more high-quality games. But this is just a highly abstract result; the real flow process is far more complex.
The complete launch flywheel is actually a four-layer nested closed loop, with each layer having clear inputs and outputs:
First layer: Data Collection Layer.
Input: Player behavior data across all ecosystem games (retention, spending, social, staking), voting data from stakers, and operational data from developers.
Output: Standardized user profile tags, game quality scores, RORS benchmark values.
Key node: Smart Reward Targeting System (SRT), which is the "brain" of the entire flywheel, responsible for converting raw data into actionable decisions.
Second layer: Reward Targeting Layer.
Input: User profiles and game ratings output by the data collection layer.
Output: Accurate reward distribution schemes, user recommendation lists, game traffic quotas.
Key node: RORS algorithm model, which determines the deployment efficiency of each reward token, directly impacting the rotation speed of the flywheel.
Third layer: UA Cost Optimization Layer.
Input: High-conversion users brought by precise targeting and the trust relationship established within the ecosystem.
Output: Significantly reduced user acquisition costs, higher user retention rates, and longer user lifecycles.
Key node: $vPIXEL seamless transfer mechanism, which eliminates conversion friction across games, making the cost of users flowing from one game to another almost zero.
Fourth layer: Game Onboarding Layer.
Input: Lower UA costs, more precise user pools, more transparent traffic allocation rules.
Output: More high-quality game developers onboard, richer game content supply, and more comprehensive player behavior data.
Key node: The "Game as Validator" staking mechanism, which uses market mechanisms to filter high-quality games, replacing traditional centralized audits.
These four stages are interconnected, and none can be missing. Any decline in the efficiency of one stage will slow the rotation of the entire flywheel. What the white paper does not mention is that for this flywheel to start and operate, it must meet three extremely harsh prerequisites.
@Pixels 's launch flywheel succeeded in 2025 not because the model itself was perfect, but because it just happened to meet three prerequisites that are nearly impossible for other projects to possess simultaneously.
Prerequisite One: A sufficiently large pool of initial real users.
Launching the flywheel requires a minimum critical quality user base. According to #pixel internal data, this critical value is about 500,000 daily active real users. Below this number, the volume of collected data is insufficient to train an effective machine learning model, greatly reducing the accuracy of reward targeting, making it impossible to lower UA costs, thus failing to attract high-quality games.
This is why 99% of Web3 game platforms have failed. They attempted to launch the flywheel with only a few thousand daily active users, resulting in inaccurate data models, rewards being exploited by opportunists, and UA costs being higher than traditional platforms, ultimately falling into a vicious cycle of "no games → no users → even fewer games."
Pixels' fortune lies in its initial accumulation of over 1 million real daily active users through farming games, providing sufficient initial momentum for the launch of the flywheel. This is a first-mover advantage that no other project attempting to directly establish a platform can replicate.
Prerequisite Two: An adequately precise RORS data model.
The core of the launch flywheel is the RORS metric, but the precision of RORS is not innate. It requires millions of users and billions of behavioral data points for continuous feeding to gradually approach the true user value.
The white paper states that the current RORS is about 0.8, but it does not mention that in early 2024, this number dropped to as low as 0.3. At that time, the model could only recognize basic online duration and task completion, failing to differentiate between real players and bots, leading to massive reward wastage.
It wasn't until the second half of 2024, with the launch of the Stacked AI system and the accumulation of over 1 billion behavioral data points, that the precision of the RORS model improved to its current level. Even so, it still has an error rate of about 15%, misjudging the behavior of some high-value users.
Prerequisite Three: A sufficiently diverse supply of high-quality games.
The ultimate goal of launching the flywheel is to attract more high-quality games, but it also requires a sufficiently diverse game supply to enrich the data dimensions. If the ecosystem consists only of farming games, then the data collected will always be limited to "farming, harvesting, trading," and the model will struggle to recognize user behaviors from other game types, encountering a ceiling in targeting accuracy.
In Pixels' current ecosystem, farming games still account for over 70% of user engagement and spending. This means that when it attempts to introduce competitive, puzzle, or RPG games, the existing data model can hardly provide effective targeting support, and the UA costs for new games will not be significantly lower than those on traditional platforms.
These three prerequisites are the cornerstone of $PIXEL for the flywheel to operate. However, even if these conditions are met, the current flywheel still has three fatal vulnerabilities that could lead to the collapse of the entire system at any time.
The white paper only showcases the beautiful side of launching the flywheel, without mentioning the three structural issues that have already emerged in its actual operation. If these problems are not resolved promptly, they will fundamentally shake the foundation of the entire ecosystem.
Vulnerability One: Data islands between sub-games.
Although Pixels possesses user data across the entire ecosystem, this data is completely isolated between sub-games. Player data from Game A cannot be directly used for user targeting in Game B, and consumption data from Game B cannot be used to enhance recommendation accuracy for Game C.
This has led to a very absurd phenomenon: a high-value user who spent $1,000 in a core farming game is still treated as a new user when entering a newly launched competitive game, receiving beginner rewards instead of being directly recommended potentially interesting paid content.
The existence of data islands significantly reduces the operational efficiency of the flywheel. According to estimates, due to data being non-interoperable, the current UA costs for new games in the ecosystem are approximately 40% higher than the theoretical value.
Vulnerability Two: The homogenization trap of sub-games.
Due to the "Game as Validator" mechanism focusing only on short-term RORS data, developers are flocking to already validated farming-style gameplay. Currently, over 80% of new games in the ecosystem are essentially reskins of core farming games, merely swapping "farming" for "mining," "fishing," or "tree planting."
Homogeneous games not only fail to attract new users but also divert the time and spending of existing users. More seriously, it leads to a singularity in data dimensions, causing the RORS model to increasingly only recognize user behaviors from farming games, further exacerbating homogenization and forming a vicious cycle.
Vulnerability Three: Short-term speculative behavior of stakers.
The design assumption of the launch flywheel is that stakers will vote based on the long-term quality of games. But in reality, over 70% of stakers only look at short-term APY; whichever game offers the highest rewards, they invest in that game.
This has given low-quality games the opportunity to thrive. They attract staking by offering extremely high initial rewards, quickly take the ecological incentives, and then run away, leaving a mess for players and stakers. Meanwhile, those projects that genuinely focus on quality and long-term development struggle to secure enough staking and incentives due to low short-term APY.
This phenomenon of "bad money driving out good" is seriously harming the health of the launch flywheel. If the short-term speculation problem of stakers cannot be resolved, the ecosystem will ultimately be left with a bunch of Ponzi games attracting users with high rewards.
Although the white paper does not explicitly mention these vulnerabilities, some optimization directions mentioned indicate that the Pixels team is already aware of these issues and is formulating corresponding repair plans.
Fix Proposal One: Build a unified data platform across games.
To address the data island problem, the white paper mentions "enhancing the flywheel effect through cross-game data interoperability." Specifically, Pixels is building a unified ecological data platform to connect user data from all sub-games, forming a complete user lifecycle profile.
In the future, when a user enters any new game, the system will provide personalized recommendations and rewards based on their historical behavior across the entire ecosystem. This will reduce the UA costs for new games by another 30%-50%, doubling the rotation speed of the launch flywheel.
Fix Proposal Two: Establish a multi-dimensional game quality assessment system.
To address the homogenization issue among sub-games, Pixels is upgrading the "Game as Validator" mechanism. In the future, the incentive quota for games will no longer only consider the RORS indicator but will also introduce multiple dimensions of evaluation, such as gameplay innovation, user satisfaction, and social activity.
At the same time, the official will establish an "innovation game fund" specifically to support those projects with novel gameplay but low short-term RORS. This will fundamentally change the incentive direction for developers, encouraging them to pursue genuine innovation rather than mere reskinning.
Fix Proposal Three: Introduce a long-term staking incentive mechanism.
To address the short-term speculation problem of stakers, Pixels is designing a tiered staking reward system. The longer the staking time, the higher the weight of rewards received, along with additional dividends from game earnings.
Additionally, the official will introduce a "locked voting" mechanism, allowing only stakers who lock their tokens for over 6 months to participate in the voting for game incentive distribution. This will effectively filter out short-term speculators and empower true holders who care about the long-term development of the ecosystem.
Pixels' launch flywheel is not a perfect, one-time solution. It is a dynamic system that continually exposes problems and is refined in practice. The white paper only depicts its ideal form, while the real evolutionary process is filled with trial and error and adjustments.
But this is precisely what makes Pixels so formidable. Unlike other projects that cling to a perfect white paper, Pixels dares to confront its problems and continually iterate its model. From abandoning DAU supremacy to launching a dual-token model and upgrading the launch flywheel, every transformation by Pixels has precisely targeted the industry's pain points.
Once the three vulnerabilities of the launch flywheel are fixed, it will truly become a "traffic black hole" in the Web3 gaming space. At that point, not only will all Web3 games want to integrate into this ecosystem, but even traditional Web2 games will be drawn by its low-cost user acquisition capabilities.
By then, Pixels' ambition will no longer be to create a decentralized AppsFlyer but to become the underlying traffic infrastructure for the entire gaming industry. And all this began with that often overlooked, imperfect launch flywheel.