Immutable's stated ambition is to bring digital ownership to players while helping studios build and grow games. The company now presents blockchain infrastructure alongside audience, engagement and marketing products. That wider business matters when interpreting announcements: a studio using an Immutable growth service is not necessarily deploying game assets on the chain. The official chain page explicitly makes onchain infrastructure optional for users of the broader growth platform.

The network retains chain ID 13371 and uses IMX for gas, while current documentation increasingly calls it Immutable Chain. Its EVM compatibility allows familiar Solidity development and Ethereum tooling. These identifiers describe a specific execution environment, not the old Immutable X system and not Ethereum mainnet itself. A wallet can display similar addresses across networks while balances, contracts and operational support differ. Correct network selection therefore remains relevant even when an application hides much of the blockchain interface.

Immutable X was a customized StarkEx deployment with a more specialized transaction environment. The deprecation notice now says its write interface no longer processes new transactions, its old marketplace has been removed and remaining read interfaces are deprecated. Fungible balances were migrated to the new chain, while NFT treatment depended on individual collections and game-specific migration logic. It would be misleading to describe both environments as equally active options for a new application today.

The 2023 roadmap helps explain why terminology became confusing. It proposed moving from Polygon Edge to Geth, opening mainnet in stages and introducing a prover later. That document explicitly distinguished an initial public-bridge arrangement from the eventual goal of a trustless proof-based bridge. Historical projections are valuable evidence of intent, but their target year cannot be silently converted into confirmation that the planned security milestone was delivered on schedule.

Current node instructions distinguish permissionless public nodes from private infrastructure peers requiring an Immutable relationship and allowlisting. Public nodes forward submitted transactions to the Immutable RPC endpoint instead of participating in transaction-pool gossip. The instructions and maintained client identify Clique authority consensus. Running a node can help a developer inspect and serve chain data; that permission does not automatically confer a right to become an independent block producer or bypass the transaction-submission infrastructure.

The maintained Geth changelog records network-specific behavior, including restrictions on transaction gossip and historical access controls. It also records removal of the deployer allowlist, so a launch-era restriction should not be repeated indefinitely as though nothing changed. These implementation details are more informative than treating Ethereum compatibility as equivalent governance. Shared execution semantics can coexist with different operators, transaction policies and upgrade processes, each of which affects what users must trust.

Current bridge documentation states that the canonical connection uses Axelar for cross-chain messaging and that ZK proofs are planned for the future. Deposits and withdrawals therefore depend on the documented messaging path, not solely on a general promise about zero-knowledge technology. The same guide describes withdrawal queues for large transfers or periods exceeding configured flow limits. A quick game transaction and completion of an Ethereum withdrawal are different events with different operational dependencies.

The bridge architecture specifies upgradeable proxies and privileged roles for pausing operations, adjusting limits and changing adapters. During an emergency pause, ordinary user actions can stop while authorized administrative actions remain available. These powers may help contain an incident, but they also create an explicit control surface. Reviewing an audit or the word canonical does not eliminate those powers; a useful security assessment asks which roles exist, how upgrades work and what an interrupted withdrawal would require.

The migration-contract repository describes disbursement against the final Immutable X vault root, with proofs preventing arbitrary reassignment of eligible balances. It also identifies trust assumptions: permissioned operators must advance migration, and account associations originate from offchain mappings published for verification. Those mappings are not presented as a complete independently derived onchain truth. The design therefore combines cryptographic ownership checks with operational and data-publication responsibilities rather than making every aspect of migration trustless.

A separate maintainer guide records automated migration completing during March 5 through March 9, 2026. It preserves a different path for users who had already initiated a normal Immutable X withdrawal by February 11 but had not finalized it on Ethereum. Those balances are not the same as automatically migrated funds. The distinction prevents a common troubleshooting error: looking only on the new chain when the relevant transaction is actually an unfinished withdrawal on the old Ethereum bridge.

IMX is native currency on Immutable Chain and an ERC-20 on Ethereum. Bridging the Ethereum token credits native IMX on the destination, while wIMX is a separate wrapped representation used by contracts that expect an ERC-20 interface. The native-token documentation also links to Foundation-provided staking. None of those facts establishes that every holder operates a validator or receives a guaranteed proportion of company revenue. Gas utility, wrapped-token interoperability and a staking program are distinct functions.

Passport sponsorship pays the gas for supported player actions, removing the need to acquire cryptocurrency before minting, trading or transferring an item. Eligibility is exclusive to Passport users; an ordinary external wallet does not receive the same promise. Studios treat this spending as an operational expense, much like server infrastructure. The guide links automatic minting sponsorship to the Minting API and directs teams to Immutable Hub to monitor gas costs.

That gives the convenience a concrete operating model: players encounter fewer payment steps while the application still accounts for computational expenses.

Passport's architecture describes a two-of-two wallet: a user key handled through Magic and signed on the user's device, plus an Immutable guardian key enforcing policies. Immutable says it cannot move funds using its guardian key alone. That is a meaningful protection, but it does not make the service identical to an isolated seed-phrase wallet. Identity-provider access, key delivery and guardian cooperation are part of the documented operating model and deserve to remain visible beneath the simple login screen.

Pre-approved transactions are another bounded convenience. Current documentation limits the feature to native Unity and Unreal clients, with one-time consent and linked contracts; web transactions still require explicit confirmation. Native IMX transfers also remain outside that automatic approval behavior. A game can consequently reduce repetitive prompts without establishing a universal permission to transfer everything in a wallet. Readers should distinguish the supported contract scope from a broad assertion that all future actions happen invisibly.

The operator allowlist is designed to preserve royalties and protocol fees by restricting contract-mediated approvals and transfers to accepted operators. Immutable manages the registry and describes a manual mainnet review process for additions. Current documentation treats compliance as mandatory for supported collections and lists ecosystem consequences for noncompliance. This is a deliberate tradeoff between creator monetization and unrestricted composability, not an accidental detail that disappears because the asset follows an NFT standard.

Royalty documentation separately explains that a collection owner chooses whether to configure a royalty and can direct receipts through a fee splitter. Administrators can change the splitter's allocation, affecting unreleased fees. Owning an item is therefore different from controlling the creator's revenue settings. The economic rights of a player, marketplace, studio and royalty recipient should be read from the actual contracts and collection terms instead of being inferred from the general phrase digital ownership.

The shared orderbook makes an order visible and fillable through multiple participating marketplaces. Listings, bids and collection bids have different conditions, and an order can become inactive when balances or approvals no longer support it. This is useful market infrastructure, but publishing a listing does not create a buyer or establish an item's realizable value. The distinction between a signed offer, an executable order and a completed onchain sale remains important when discussing game-economy activity.

QuickSwap's March 2024 launch announcement supplies a concrete example of a third-party protocol deploying on the chain. It described swaps and liquidity provision, along with then-current incentives. Those incentives belong to that historical campaign, not a perpetual yield available to every reader today. A decentralized exchange can provide routes between game assets and settlement currencies while adding its own contract, liquidity and pricing risks; it does not turn every game's economy into a stable financial market.

Gods Unchained's migration announcement described plans for asset movement, crafting and trading improvements. The studio emphasized potential cross-game use and more programmable mechanics, which are understandable reasons to move beyond a specialized legacy system. They remain product plans until supported by implementation and actual gameplay. A shared chain can make transactions between contracts possible without obliging two game designers to give the same item compatible rules, artwork or economic significance.

The current Ethereum-differences guide says the chain aligns with Cancun but does not support blob transactions, and that PREVRANDAO returns zero. That last difference matters to game designers: treating the opcode as useful randomness would be an implementation mistake. Compiler support is also bounded rather than automatically tracking every newest Solidity release. The practical benefit of Ethereum tooling therefore comes with a responsibility to check the target chain's actual behavior before moving an application unchanged.

In January 2026 the maintainers published client v1.0.0-beta.17, addressing CVE-2026-22868 alongside changes that add build attestations to the image and publish them through GitHub. The release also directs operators to the official node setup instructions. These changes address different maintenance concerns: a software vulnerability, the provenance of distributed artifacts and installation guidance. The announcement does not report stolen player assets.

Its version and linked changes give operators a specific artifact to inspect, rather than leaving security maintenance as an undated claim about having been audited.

In the Gods Unchained migration discussion, protoaddict saw value in holding assets for different games in one place, while ChocolateBlaine anticipated a troublesome transition. Their disagreement is about an experienced player workflow, not a theorem about scaling. The original comments show why migration can be both attractive and unwelcome: existing users may appreciate consolidation while having little desire to learn another wallet or bridge process merely to continue playing a familiar game.

Other original discussions reveal different priorities. pablo-pon asked how new chains would connect to IMX token economics rather than assuming usage automatically benefits holders. ShitsGotSerious later asked for information beyond company promotion, while Icy_Interaction5874 imagined major gaming platforms adopting invisible ownership infrastructure. The latter is an expansive community aspiration, not verified evidence of those companies integrating Passport.

Keeping these voices separate avoids presenting technical adoption, investor optimism and skepticism as a single community consensus.

A June 2026 post by kcaazar questioned a lower staking payout than previously experienced. The post is a self-reported result without enough information to reconstruct the account's return or establish a network-wide rate. It is still useful evidence of what some holders care about: actual distributions rather than partnership announcements. The responsible comparison would use the program's period, eligible balance and reward calculation, rather than promoting the participant's earlier percentage as a return someone else can expect.