Immutable

Immutable is an EVM Gaming Chain for Minting and Trading Game Assets

Immutable is a gaming network where digital items become wallet-held tokens and trades settle through Ethereum-compatible smart contracts. Its active blockchain, Immutable Chain, uses IMX for gas and supports ERC-721 and ERC-1155 assets alongside wallet, minting, checkout and shared-orderbook tools. Players use Passport or another EVM wallet, while sponsored actions hide gas when a game funds the transaction. The earlier Immutable X rollup has merged into Immutable Chain and no longer accepts writes.

Do not confuse Immutable Chain with the retired Immutable X rollup

One active mainnet, chain ID 13371, now carries Immutable’s EVM game activity, so treating Immutable X as a separate live network sends users toward retired interfaces.

Immutable X was the original StarkEx-based rollup. It merged into Immutable Chain in early 2026, after which its write sequencer stopped new transactions and its marketplace was removed. ERC-20 balances moved through a non-custodial bridge upgrade into the same wallet address. NFT migration followed each game’s collection plan, so ownership should now be checked against the destination contract and token ID.

What does it cost to use Immutable Chain?

A 10 gwei minimum priority fee sets the floor for unsponsored Immutable Chain transactions, while games using Passport sponsorship pay gas on the player’s behalf, which is examined in Immutable intro to review.

Network gas

Typically, Immutable Chain exposes EIP-1559 gas, a 30 000 000 block gas limit and Solidity support through version 0.8.28. The paid network charge multiplies gas used by the effective gas price, combining the base fee and priority fee within the sender’s cap.

IMX has 18 decimal places on Immutable Chain, and unsponsored wallets must hold native IMX before they submit a state-changing call. Passport sponsorship shifts the charge to a studio policy for approved operations; it does not remove gas accounting from the chain. A transfer, approval and order fill each consumes a different amount because the contract executes different opcodes and writes different storage. Blocks and finality target roughly 2 seconds, so confirmation time stays separate from fee size. The wallet quote immediately before signing is the useful amount for that call at that moment.

Trading fees and royalties

Creating an Orderbook listing uses one signed message and no gas, while filling the order invokes an on-chain transaction.

A settled trade contains four possible economic components: the asset price, marketplace maker or taker fees, an optional creator royalty and IMX gas. The maker fee is fixed inside an order when it is created, while the taker fee is supplied at fulfilment. EIP-2981 reports royalty information from the collection contract, and Immutable’s Operator Allowlist enforces configured royalties within eligible venues. Compare sale-denominated charges with the separate native gas balance before confirmation.

From game inventory to a tradable token

Two Ethereum token standards, ERC-721 and ERC-1155, cover most tradable game assets on Immutable, with ERC-20 reserved for interchangeable currencies and resources.

Choose a token model

ERC-721 maps each uint256 token ID to exactly one owner, which suits distinct characters, land and serialised equipment. ERC-1155 records a balance for every owner and ID, so one ID represents many interchangeable copies. Immutable preset NFT contracts add EIP-2981 royalty reporting and the Operator Allowlist expected by ecosystem marketplaces.

Mint and index the asset

Studios deploy presets through Immutable Hub or use Solidity with Hardhat and Foundry. The presets target Solidity 0.8.19, while the chain supports compilers through 0.8.28. The Minting API accepts only preset contracts and batches up to 100 ERC-721 tokens in one request. Each mint assigns an owner, token ID and metadata; the Blockchain Data APIs then index the emitted state for inventories and search.

List and settle the order

Orderbook listing creation signs structured data off-chain. A seller first gives the Seaport contract one collection approval, then later listings for that collection reuse it. Native IMX purchases need no buyer-side ERC-20 allowance. Order records move through six defined states: PENDING, ACTIVE, INACTIVE, FILLED, CANCELLED and EXPIRED. A fill transfers payment and the asset on-chain, making the receipt the settlement record.

How do players get onto Immutable?

Two account routes bring players onto Immutable Chain: Passport creates an embedded smart-contract wallet, while MetaMask and WalletConnect connect conventional EVM accounts.

A companion page walks through Immutable in depth quick start. Passport offers email, Google or Apple sign-in and creates one smart-contract wallet across Immutable games. Full wallet support covers mainnet 13371 and testnet 13473; Ethereum mainnet, chain ID 1, has limited transfer support. MetaMask and WalletConnect suit users who already manage EVM accounts. Keep native IMX available unless the game explicitly sponsors the selected action, because owning the purchase currency alone does not pay unsponsored chain gas.

Might & Magic Fates trading card game artwork
Might & Magic Fates trading card game artwork

Where does Immutable fit in a game economy?

Three asset patterns cover most Immutable game economies: unique collectibles, stackable items and fungible currencies, each mapped to a standard smart-contract representation. ERC-721 suits singular characters, land and serialised collectibles; ERC-1155 suits cards, crafting materials and consumables; ERC-20 suits currencies. Gods Unchained, Guild of Guardians and Illuvium show how cards, role-playing equipment and collection systems lead into marketplaces or in-game transfers. Studios also use the same contracts for primary sales, rewards, crafting burns and secondary trades through Orderbook.

Immutable game growth metrics dashboard

Shared liquidity and developer tooling

Four shared components reduce integration work on Immutable for studios: EVM contract support, the Minting API, Blockchain Data APIs and the cross-marketplace Orderbook.

Solidity teams keep familiar contract workflows with Hardhat, Foundry and viem. Mainnet uses chain ID 13371, while the Sepolia-backed testnet uses 13473. Public JSON-RPC access is capped at 25 requests per second, which suits development and light reads rather than a production game backend. Dedicated providers serve sustained traffic. Above the node layer, preset contracts, wallet components and indexing APIs reduce the custom services a studio operates through a single ecosystem stack.

Shared liquidity and developer tooling
Interface or tier Primary task Hard limit or threshold
Public JSON-RPC Chain reads and broadcasts 25 requests per second
Standard Minting API Small and test mints 200 distinct token IDs per minute; 2 000 burst
Partner Minting API Production mint throughput 2 000 distinct token IDs per minute; 20 000 burst
ERC-721 mint request One batch payload 100 tokens per request

The Standard Minting API processes 200 distinct token IDs per minute with a 2 000-ID burst. The Partner tier raises those limits to 2 000 per minute and 20 000 per burst. An ERC-721 mint request carries at most 100 tokens. For ERC-1155, minting 1 000 copies of the same token ID counts as one distinct ID, which favours stackable inventory releases.

Orderbook supplies the distribution layer: a listing posted through one connected marketplace becomes visible and fillable across other compatible marketplace interfaces. Studios choose between a shared order surface and a fully custom venue, then budget indexing and RPC capacity around expected traffic.

Boundaries imposed by wallets, bridges and metadata

Three operational boundaries shape Immutable deployments: Passport chain support, bridge settlement windows and the availability rules chosen for each token’s metadata over time.

Passport fully supports Immutable mainnet and testnet, while Ethereum mainnet access is limited to moving assets into Immutable Chain. The same address on an unsupported EVM network does not create accessible Passport balances. The canonical bridge uses Axelar messaging: Ethereum-to-chain deposits target 15–30 minutes, while withdrawals take up to 24 hours. A large withdrawal or a 4-hour flow-rate limit queues settlement for review. These timings concern cross-chain movement, not the roughly 2-second chain confirmation shown for ordinary Immutable transactions. Bridge capacity changes with its token buckets, so the source receipt and destination balance mark separate stages of completion.

Metadata availability follows the collection’s storage choice. Immutable-hosted metadata becomes fixed after minting, IPFS records are content-addressed and self-hosted records remain mutable only while the studio’s servers respond. Images still need hosting even when metadata enters the Minting API. The Operator Allowlist also limits which contracts transfer preset assets, so marketplace compatibility belongs in the collection design rather than an after-launch assumption.

Ronin, Polygon PoS, Arbitrum One and Base as alternatives

Four established EVM networks frame the alternative set: Ronin emphasises games, Polygon PoS serves broad applications and Arbitrum One and Base use ETH for gas.

Ronin provides a game-focused EVM environment with RON as gas and a wallet, market and developer console shaped by Sky Mavis. Polygon PoS uses POL for gas and offers a broader application ecosystem. Both give studios direct EVM deployment, but their distribution stacks and player account models differ from Passport and Orderbook.

Arbitrum One runs the Nitro optimistic-rollup stack and charges ETH, while Base uses the OP Stack and also charges ETH. Their general-purpose ecosystems offer wider DeFi composability and liquidity connections. Immutable concentrates wallet onboarding, asset presets, minting and shared trading around games. The decisive criterion is whether the project values that integrated game stack above a larger general-purpose network surface.

Verification and maintenance after launch

Two confirmations should close every Immutable asset operation: a successful transaction receipt proves execution, while an indexed owner and metadata record proves application visibility.

Confirm on-chain state

An EVM address occupies 20 bytes and a transaction hash occupies 32 bytes, displayed as 40 and 64 hexadecimal characters after the prefix. Record chain ID, contract address, token ID and transaction hash together. For ERC-721, query the owner of the ID; for ERC-1155, query the address balance for both ID and quantity. A marketplace card alone is an indexed view, not the ownership record.

Maintain indexed data

Blockchain Data APIs and marketplace caches update after the chain receipt, so a newly minted or transferred item passes through two verification stages. First confirm the successful receipt and emitted transfer event. Then confirm the indexed owner, balance and metadata. Dynamic items need a metadata refresh after crafting or progression changes, with the full metadata object resubmitted rather than only the changed trait. Track PENDING and INACTIVE orders until they reach a usable or terminal state, and keep base-URI content available for partners reading directly from the collection.

Maintenance also covers RPC capacity, sponsorship budgets and contract permissions. Retire stale approvals when a collection changes venues, watch rate-limit responses before bursts and test updates on chain ID 13473 before mainnet deployment. This cycle keeps the wallet record, contract state and marketplace view aligned as the game evolves.

Quick answers about Immutable

Is IMX on Ethereum the same token used for Immutable Chain gas?

IMX represents the same ecosystem token across the two networks, but its form changes by chain. On Ethereum, IMX is an ERC-20 token; on Immutable Chain, native IMX pays gas. Bridging maps the Ethereum token into the native chain balance, while wrapped IMX is an ERC-20 representation on Immutable Chain. A wallet therefore needs the correct chain balance, not merely an IMX balance displayed on another network.

Are ERC-1155 orders on Immutable partially fillable?

ERC-1155 listings on Immutable support partial fills when the order’s quantities preserve the configured payment ratio. The seller specifies a token ID and amount, while the total buy amount must be a multiple of the sell amount. A buyer then fills one or more units without consuming the whole listing. ERC-721 orders behave differently: each token ID represents one non-fungible item, so the Orderbook uses a full-fill order for that asset. The remaining quantity stays active until filled, cancelled or expired.

What happens when an Immutable listing expires?

An expired Immutable listing enters the terminal EXPIRED state and is no longer fillable. The signed order included an expiration time, so the Orderbook rejects settlement after that boundary. The asset remains in the seller’s wallet unless another transaction moved it. To offer it again, the seller creates a new listing with an expiration. Expiry does not transfer the token because no custody changed at listing time.

Does Immutable Orderbook support collection bids and trait bids?

Immutable Orderbook supports token bids, collection bids, trait bids and metadata bids as separate order types. A token bid targets one token ID, while a collection bid accepts any eligible asset in a collection. Trait bids filter indexed attributes, and metadata bids match a metadata identifier or defined fields. The seller still selects the concrete token during fulfilment, and its indexed data must satisfy the bid. Each successful fill settles the chosen asset and payment on-chain through the same Orderbook contracts.

How long can Immutable Passport account deletion take?

Immutable Passport account deletion can take up to 30 days to complete. Deletion makes the associated wallet and assets irrecoverable, so transferable balances and game assets must move to another supported wallet first. The process starts through Immutable Play support rather than a blockchain transaction. Moving assets does not delete collection records or past transaction history; it only changes the wallet holding transferable tokens before the identity account closes.

Could one wallet hold both ERC-721 and ERC-1155 assets on Immutable?

One EVM wallet address holds ERC-721 and ERC-1155 assets on Immutable Chain at the same time. Each collection contract maintains its own ownership or balance mapping, so the wallet does not need a separate address for each standard. Interfaces query the contracts and indexed data to assemble a combined inventory. ERC-721 entries show a single token owner, while ERC-1155 entries show a quantity for each token ID. Display support still depends on the selected interface’s indexing and metadata coverage within that application.

Will an Immutable NFT work inside every game?

An Immutable NFT works only in games and applications programmed to recognise its contract, token ID and metadata. ERC-721 or ERC-1155 compliance makes the ownership record readable by EVM software, but it does not give every game a matching character model, balance rule or gameplay function. A studio must integrate the collection and define what the asset does. Marketplace transferability and in-game utility are therefore separate properties.