Immutable Review: Who Funds Gas-Free Gaming?

Immutable’s promise of gas-free play now sits beside a completed chain merger and a wider game-growth business. Its original Immutable X network stopped processing new transactions in February 2026, leaving today’s assessment focused on Immutable Chain rather than the retired StarkEx platform. For this Immutable Review, the central issue is who pays when players do not.

IMX pays for gas on the current network and connects to a published trading-fee and staking model. Players can use sponsored wallets without keeping personal gas balances, while studios can buy other Immutable services whose connection to IMX needs separate evidence. Security also depends on the deployed bridge and operator arrangements, beyond the technology suggested by the zkEVM name.

Quick Verdict

Immutable offers studios a practical combination of wallet onboarding, asset trading, payments and chain infrastructure. Gas sponsorship can remove an awkward step for players, and shared trading infrastructure can reduce the work involved in launching a marketplace. Those benefits address recognizable development and distribution problems.

IMX’s economic role depends on activity that reaches its gas and fee mechanisms. Gas spending, eligible trading fees and staking participation differ from company revenue, game sales or registered accounts. Current circulation figures also disagree sharply across major providers, making unqualified claims of complete market circulation unreliable.

Security deserves particular care. Immutable markets an Ethereum-based gaming chain, while L2BEAT currently describes the deployed system as a sidechain with a planned rollup transition. Its present bridge uses Axelar messaging. That combination calls for an assessment of current permissions and dependencies before assigning future proof-system guarantees to existing assets.

Key Takeaways

Immutable’s Current Operating Model

What Studios Get Beyond the Chain

Game teams need accounts, inventories, payment flows, marketplace access and ways to bring players back. Immutable packages several of these components around its chain. Passport handles authentication and embedded wallets, Checkout offers funding and transaction interfaces, and the Orderbook distributes eligible asset listings across integrated marketplaces. The commercial attraction is reduced integration work. A studio can spend less time connecting separate wallet and commerce systems. Players may encounter a familiar login and purchase journey rather than managing network settings before their first session. Whether that improves retention remains a question for each game’s actual users.

Immutable’s current website also promotes Audience, attribution, engagement and AI-assisted growth tools. Its documentation describes combining player data and measuring campaigns around wishlists, signups and game activity. That expands the commercial proposition beyond executing blockchain transactions. A studio could find those services useful even if its customers rarely trade onchain. The reviewed materials do not establish that every service payment requires IMX or enters its staking reward pool. Growth in studio customers therefore needs a demonstrable payment connection before it supports a token-demand conclusion. Researchers need to identify which actions consume gas, generate eligible fees or require token participation, and which remain ordinary software-service activity.

Blockchain ownership also has limits inside a game. Holding an asset record does not require a publisher to maintain servers, preserve item utility or support another developer’s interpretation of the item. Transferability can be useful without making a game independent of its operator. Studios still control substantial parts of the experience that give their assets practical value.

Legacy Balances After the 2026 Merger

Immutable’s migration repository records the legacy network’s sunset on February 11, 2026 and automated migration of remaining funds between March 5 and March 9. Current documentation says the old write interface no longer processes new transactions. New integrations need the current network’s endpoints and support policies.

Fungible assets and NFTs require different treatment. Documentation describes migration of ETH, IMX and other ERC-20 balances, while NFT outcomes depend on the game and collection. A general statement that every item moved identically would overlook custom migration logic and project-specific decisions.

Pending withdrawals form another category. The repository distinguishes withdrawals initiated before the sunset but never finalized on Ethereum from balances covered by automated migration. An unfinished withdrawal therefore does not, by itself, establish lost funds. Correct handling depends on the original action, asset and destination. Consolidation reduces the number of active environments without erasing every legacy recovery task.

Gas-Free Play Still Needs Funding

Current documentation makes gas sponsorship available to Passport users. Immutable describes covering transaction costs so players can interact without acquiring a gas asset first. It also presents sponsorship as an operating expense comparable to server infrastructure. Passport’s architecture documentation limits the description to approved operations.

That distinction matters economically. IMX remains the native gas currency even when the player does not maintain an IMX balance. A sponsoring service or another participant handles the required funding. More sponsored activity can create gas spending without requiring every new account to become a persistent token holder.

Studios need to evaluate that cost alongside customer acquisition and revenue. Sponsoring repeated interactions can make sense when players stay, purchase useful services or support an enduring game economy. Subsidized transactions alone cannot demonstrate those results. The relevant measurement concerns spending per retained customer and the revenue that supports it, rather than the size of a promotional transaction count.

Following the Charges on an Item Sale

Orderbook documentation specifies a 2% protocol fee on its trades. Marketplace fees and royalties can add separate charges. Applying that 2% to every transfer, crafting action or transaction across the chain would overstate the fee base. Integrators also need the final fulfillment breakdown because fee settings and promotions can change.

One Listing Can Reach Several Storefronts

Immutable’s Orderbook allows orders created through one integrated marketplace to appear and fill elsewhere in the ecosystem. That can reduce fragmentation between storefronts. A player does not necessarily need to find the original venue that listed an item before purchasing it through another supported interface.

Listings themselves are signed messages, while fulfillment executes onchain and consumes gas. This separates the cost of expressing an offer from completing a trade. It also explains why a large listing count cannot establish paid demand or trading revenue.

Liquidity still depends on buyers, prices, collection quality and willingness to transact. Multiple interfaces can display the same underlying order without creating multiple independent buyers. Researchers should distinguish completed sales from offers, repeated display from fresh liquidity, and organic purchases from incentive-driven turnover. Shared infrastructure improves access to a market, but it cannot make every game item desirable.

Where Trading Fees Can Reach IMX

Foundation materials describe a requirement for 20% of protocol fees to use IMX, with conversion through open-market purchases when the original payment uses another currency. They reserve that portion for rewards to active ecosystem participants. This describes a token-use route distinct from ordinary network gas.

The arithmetic needs care. If a qualifying sale has a 2% protocol charge and the published 20% conversion applies, the IMX-linked portion equals 0.4% of the sale value. That is a conditional calculation, not a 20% charge on the item and not a measurement of completed purchases.

Implementation and economic scale remain separate tests. Public descriptions explain the intended mechanism, while transaction records, conversion accounting and reward distributions would establish its operation over a particular period. Neither gross NFT volume nor company revenue can substitute for those records. Tokens acquired for rewards can also return to the market when recipients spend or sell them, so conversion demand does not establish permanent supply removal.

Reward Eligibility After the Migration

Current native-token documentation directs participants to the IMX Ecosystem Foundation for staking on Immutable Chain. The Foundation describes staking and pro-network activity as the basis for reward eligibility. Ordinary ownership alone does not establish an entitlement to protocol revenue.

Historical whitepaper requirements referred to governance participation and NFT ownership or trading activity on Immutable X. Those conditions belong to an earlier operating environment. This review did not verify a complete current eligibility schedule, withdrawal timetable or reward calculation from the migrated staking interface, so it does not present the old checklist as today’s universal rule.

Reward quality also needs accounting. Fee-funded distributions differ from allocations used to encourage participation, even when both arrive as IMX. Participants need the reward source, qualifying period and competing eligible stake to understand the mechanism. An advertised rate or a larger token balance cannot establish a sustainable reward stream without that context.

Tokenomics: Allocation, Supply and Distribution

Published token materials specify a maximum of two billion IMX. That ceiling describes token quantity under the stated model. It does not prevent existing balances from entering trading venues, moving between programs or changing ownership.

The Foundation’s allocation page reviewed for this article lists the following distribution. These categories describe designated uses, rather than independently verified present ownership or immediately available selling balances.

The page’s unlock rows reverse the private-sale and public-sale labels relative to its allocation overview. The figures above follow the overview, without claiming that those labels reconcile every historical schedule.

Ecosystem funding can support development and user acquisition. Its economic effect depends on what recipients build, whether activity persists and how they use the tokens. Grants that finance useful products can still create transfers or sales when recipients meet operating expenses.

Supply Providers Still Report Different Totals

During the October 19 check, CoinMarketCap reported two billion IMX circulating, matching its displayed total and maximum supply. CoinGecko instead reported approximately 904.472 million circulating, while also listing two billion total and maximum. This is a material classification disagreement, rather than a rounding difference.

The reviewed records did not reconcile that gap. This article retains both readings and avoids declaring either a universally verified measure of circulating supply. Market capitalization calculations will also differ when providers multiply a similar token price by different circulation figures.

Reconciliation would need identifiable excluded balances, custody and bridge treatment, treasury classifications and dated methodology. Adding Ethereum escrow balances to their corresponding native representations would double-count economically linked units. Neither the provider discrepancy nor a wallet transfer alone proves new issuance, a burn or coordinated selling. The gap remains unresolved in the reviewed evidence.

After Vesting: Where Existing Tokens Can Move

The Foundation website displays a vesting schedule running from November 2021 through October 2025. That historical endpoint does not establish that every allocated token now sits with an independent market participant. Contractual release, treasury distribution, staking and exchange availability describe different states.

Existing token supply can continue moving through grants, rewards, liquidity programs and recipient decisions after a vesting calendar ends. These flows can affect available balances without increasing the published maximum. Their significance depends on timing and actual demand for those tokens.

Ownership concentration also requires labels. An exchange wallet may represent many customers, while several addresses can belong to one entity. Without a reconciled ownership analysis, address rankings cannot establish that a small group controls every outcome or that ordinary users stopped accumulating on a particular date.

Passport Access Depends on Keys and the Right Network

Passport creates a smart contract wallet and supports familiar authentication instead of a conventional seed-phrase onboarding process. Its architecture documentation describes a two-of-two signing arrangement: a user key supplied through Magic’s infrastructure and a Guardian key controlled by Immutable. The Guardian applies security policies. Immutable states that it cannot move funds without user action. That limits unilateral access, while the required second signature also introduces an availability and policy dependency. Account access, device security, identity-provider recovery and Guardian operation all matter to the user experience.

IMX exists as an ERC-20 on Ethereum and as the native gas asset on Immutable Chain. The canonical bridge connects those representations. Wrapped IMX is a separate ERC-20 representation on Immutable Chain for applications that require a token contract interface. Users need to distinguish these asset forms when choosing a withdrawal network. An exchange listing the ticker IMX does not establish that it accepts deposits from every chain or wallet. The deposit interface must support the actual source network and asset representation.

Supported-chain boundaries deserve attention as well. Documentation describes Ethereum recovery through an ejection flow and warns that assets sent to other unsupported chains can remain stuck indefinitely. Those are specific compatibility limitations. They do not establish that every Passport balance is vulnerable to theft or that every mistaken transfer has the same outcome. An unsupported transfer can require provider intervention or remain inaccessible. Recovery depends on contract deployment, key control and the receiving service’s procedures. Matching address formats alone do not establish network compatibility.

Invisible Approvals Still Need Boundaries

Pre-approved transactions can reduce repeated confirmation prompts in supported native Unity and Unreal clients. Current documentation distinguishes that behavior from web transactions, which still require explicit confirmation. Native IMX transfers also require user confirmation under the documented feature limits.

Convenience shifts attention toward the contracts a game links, the consent players grant and the actions that consent permits. A wallet prompt appearing less often does not reduce the importance of authorization design. Studios need to make those permissions understandable without interrupting every ordinary game action.

These controls operate at a different layer from chain security. A correctly functioning network can execute a transaction that a user authorized too broadly. Conversely, a carefully designed game wallet cannot remove the bridge’s messaging assumptions. Assessing those layers separately produces a more useful security judgment than assigning one safety label to the whole ecosystem.

Security Follows the Deployed Bridge

L2BEAT currently describes Immutable zkEVM as a gaming sidechain powered by the Polygon stack, with a planned transition to a ZK rollup. It places the project in its Other category and identifies an incompletely functional proof system and absent data-availability bridge. These are observations about the deployed configuration at review time. Immutable’s own bridge documentation says its canonical route currently uses Axelar messaging, with ZK proofs planned for the future. The sources therefore do not support presenting present transfers as if Ethereum already verifies every state transition through a functioning rollup proof system.

Fast local confirmation remains useful for gameplay, but it answers a different question from Ethereum-backed settlement guarantees. Product names, anticipated upgrades and the legacy chain’s StarkEx design cannot replace an examination of the current system. Current bridge documentation describes flow-rate limits and a 24-hour queue for sufficiently large withdrawals. Exceeding aggregate capacity can trigger additional review. These controls aim to limit rapid outflows, while also creating operational dependencies for users expecting immediate access.

L2BEAT identifies a four-of-six owner multisig controlling the ProxyAdmin and describes bridge upgrades without a delay. Its assessment also identifies limited recourse during operator failure. These permissions matter because changing bridge logic or interrupting its operation can affect access to deposited assets. The retired Immutable X migration used a different upgrade framework, including a legacy timelock that does not describe the current bridge’s controls. Security conclusions must identify the contract and version they concern. Administrative authority represents a trust assumption, while a hypothetical misuse remains distinct from evidence that an exploit actually occurred.

What the Migration Audit Actually Covers

Nethermind finalized its migration security review on February 9, 2026 after examining 865 lines of Solidity across named contracts. It recorded two informational findings and one best-practice finding, marking all three fixed at its final reviewed commit. The assessment concerns the asset-migration implementation.

That is useful evidence of a scoped review. It does not certify every current bridge upgrade, Passport dependency, game contract or offchain service. Deployment matching and changes after the reviewed revision require their own verification.

Solidity Compatibility Does Not Settle Game Design

Immutable Chain supports familiar Solidity tooling, but current documentation lists differences from Ethereum. One particularly relevant example for games is the PREVRANDAO operation, which returns zero on the documented configuration. Developers should not treat it as a source of unpredictable game outcomes.

Randomness can affect item allocation, matches and other valuable game actions. A team that assumes Ethereum-like behavior without checking network differences can create a predictable mechanism even when its contract compiles and transactions succeed.

The broader lesson concerns integration discipline. Compatibility reduces development friction but does not eliminate chain-specific assumptions. Compiler support, wallet behavior, permissions and external dependencies still need review. This is an engineering consideration, rather than evidence that any particular game has implemented randomness incorrectly.

Measuring Game Activity Beyond Address Counts

During the October 19 check, DefiLlama displayed approximately $11.13 million in Immutable zkEVM DeFi TVL, $19 in chain fees over 24 hours and $8,540 in application fees. It also reported 46,658 transactions and 1,615 active addresses for that daily window.

Those figures describe different things. DeFi TVL does not capture every game item or every player payment. Application fees are not automatically chain income or staking distributions. Active addresses can include automated accounts and repeated activity by the same people.

Gas sponsorship can make frequent interaction affordable while keeping direct gas spending small. To assess the token connection, researchers need paid trading volume, actual fee conversion, sponsor funding and reward distributions across comparable periods. To assess games, they need returning players, payer retention and spending after incentives. One successful measurement cannot stand in for all the others, and a single day cannot establish a durable trend.

Retention and Fee Records Would Strengthen the Case

The favorable case combines retained players with repeated asset commerce and transparent IMX-linked fee flows. Sponsorship could help by removing onboarding friction, while shared listings and integrated payments could make useful transactions easier to complete. Evidence should connect those improvements to customers who continue using the services after incentives.

Weakness would appear if growth depended mainly on rewards, if commercial services expanded without a measurable token connection, or if fee conversion remained difficult to reconcile. Foundation-sponsored player rewards represent an acquisition or engagement program, not proof that customers supplied the distributed value.

Operational confidence would also improve with reconciled supply classifications, clear current staking terms and verifiable progress on the security roadmap. Those records would answer specific uncertainties without relying on token-price performance as a substitute for operating evidence.

Final Assessment: Convenience Must Connect to Paid Activity

Immutable addresses practical friction in accounts, asset trading and game distribution. Its chain merger simplifies the active platform, while sponsorship can keep gas management away from the player. These are recognizable product advantages.

The economic assessment remains narrower. IMX demand depends on funded gas use, eligible trading charges, implemented conversion and participation rules. Security follows the present operator and bridge configuration, while circulation still needs provider reconciliation. This Immutable Review treats gas-free gameplay as a service-design choice and asks whether the business supporting it produces transparent, recurring token-linked activity.

Why Trust This Review

CryptosMedia compared current product documentation with Foundation token materials, the migration repository, the primary Nethermind report and independent network and market analytics. Historical whitepaper terms remain separate from verified current functionality.

Provider disagreement and incomplete staking-interface verification remain visible limitations. This review does not claim first-hand gameplay testing, a production security audit or complete deployment matching. Its conclusions concern the public evidence checked on the stated date.