Immutable availability is wallet Support for Marketplace Access

Immutable availability is the wallet-and-network state that lets a buyer enter Checkout and execute a marketplace purchase on Immutable Mainnet. Access requires a connected address, chain ID 13371, a supported asset or active Orderbook listing and the correct token balance. Immutable Checkout supports Passport, MetaMask and WalletConnect, while each marketplace chooses the connectors and payment flows it presents. A visible item becomes purchasable only when the wallet, chain, contract, order and funding route agree.

Buying a listed game item begins with the correct chain

A buyer opening a listed ERC-721 game item reaches an executable purchase only after the connected wallet selects Immutable Mainnet. Chain mismatch stops execution.

Consider a buyer viewing an ERC-721 sword priced in USDC. The storefront can render metadata before a wallet connects because names and images come from indexed collection data. Purchase availability arrives later: Checkout reads the selected account, the collection contract, the listing currency and the network. USDC held at the same address on Ethereum does not fund an Immutable Mainnet order. The asset and payment must occupy the chain where Seaport settles the trade. That separation explains why a balance can look familiar in one wallet view yet remain unavailable to the marketplace.

An EVM address contains 20 bytes and is normally displayed as 0x followed by 40 hexadecimal characters, giving a 42-character string. The address may match across EVM networks, but each network maintains its own balances and approvals. For a worked version, see Immutable intro to review.

Wallet connection creates the marketplace session

Immutable Checkout establishes availability by asking a supported wallet provider for one account and an Immutable Mainnet connection.

Passport access

Said differently, Immutable Mainnet uses chain ID 13371, while Immutable Testnet uses 13473; Passport provides full support for both networks. Ethereum mainnet support in Passport is limited to ejections, so an Ethereum balance is not a general Checkout balance. Passport uses one embedded wallet across supported Immutable games and signs from that address after authentication. Gas sponsorship is available for Passport flows configured to use it, rather than every transaction.

MetaMask and WalletConnect access

MetaMask connects as an EIP-1193 wallet provider and switches to chain ID 13371 when requested. WalletConnect supplies a session between Checkout and a compatible external wallet. Checkout supports both routes plus other EIP-1193 providers, although a particular storefront controls which buttons it exposes. Connection proves control of one address; it does not move tokens from Ethereum or convert a testnet balance into mainnet funds.

Checkout funding routes determine whether payment can start

Checkout funding availability depends on the payment token existing on Immutable Mainnet in the connected address before authorization.

For primary sales, the default payment currencies are two real tokens: IMX and USDC. Custom ERC-20 payment tokens need allowlisting. Checkout uses QuickSwap for supported swaps on Immutable Mainnet, while its Bridge flow moves supported assets between Ethereum and Immutable Mainnet. The Fund flow combines swap, bridge or onramp routing when a storefront exposes it.

For one worked example, every changing input is hypothetical: unit price 3 USDC, quantity 4, starting balance 15 USDC and native IMX balance 0.10. The product principal is 3 × 4 = 12 USDC, leaving 3 USDC after payment. That calculation establishes sufficient purchase currency only. Checkout still checks product inventory, recipient limits, wallet authorization and whether gas sponsorship applies; otherwise the separate IMX balance must cover the network fee.

The canonical bridge uses Axelar messaging. A deposit from Ethereum to Immutable Mainnet has a stated 15–30 minute path, while an Immutable-to-Ethereum withdrawal can take up to 24 hours. Checkout availability begins after the destination balance is credited, rather than when the source transaction first appears.

Orderbook status separates visible listings from executable orders

Equally, Immutable Orderbook availability rests on order state, ownership and approval at the moment Seaport prepares settlement.

Active and terminal order states

The Orderbook defines six states: PENDING, ACTIVE, INACTIVE, FILLED, CANCELLED and EXPIRED. Only ACTIVE describes a live order ready to fill. PENDING and INACTIVE are non-terminal, while FILLED, CANCELLED and EXPIRED are three terminal outcomes. Status changes are asynchronous, so a marketplace index can briefly lag the execution path. A page showing an NFT does not override the latest ownership, expiry or order state returned during fulfillment.

Seller and buyer approvals

Sellers approve the Seaport transfer contract once for each NFT collection before the first listing, unless they later revoke that approval. Buyers using ERC-20 currency approve Seaport once per currency and renew the allowance when it is too small. A native IMX order needs zero ERC-20 buyer approvals. Listing creation uses a signed order and does not itself spend gas; filling the order produces the on-chain transaction and its fee.

Token contracts decide whether Seaport can transfer the asset

Collection-level availability depends on the token standard and the transfer policy embedded in the NFT contract itself.

ERC-721 assigns one owner to each token ID. ERC-1155 uses quantities under one token ID, so a buyer may fill part of a multi-unit listing. Immutable preset contracts add the Operator Allowlist; custom ERC-721 and ERC-1155 collections need the same enforcement for compliant ecosystem marketplaces. Approved operators include Seaport, while EIP-2981 supplies royalty information for secondary transfers. Metadata indexing determines whether artwork and traits render, whereas transfer approval determines whether the asset moves. Both paths must resolve before an integrated storefront exposes a dependable purchase route.

Primary-sale catalog rules create a separate availability gate

Primary Sales availability comes from catalog state, inventory and minting rules rather than the secondary Orderbook used for existing NFTs.

A Simplified-mode product must be active, hold remaining quantity and include at least one pricing entry. An ERC-721 sale lets the mint assign token IDs, while an ERC-1155 product specifies its token ID before sale. If per-recipient limits are enabled, the maximum must be an integer greater than zero. Advanced mode adds four backend decisions around quote, authorization, confirmation and expiration, so a product can pass the visible catalog gate yet stop when the merchant backend declines the purchase state.

Primary Sales accepts a maximum of 350 items in one transaction because larger batches exceed the supported gas envelope.

Orders above 350 items must be split. Payment completion precedes backend verification and mint delivery, separating catalog availability from final asset receipt.

Legacy Immutable X access no longer represents Mainnet support

Legacy Immutable X availability no longer identifies a working marketplace route because the service’s write path and marketplace have been retired.

For anyone starting out, Immutable X was the earlier StarkEx-based rollup and was merged into Immutable Chain in early 2026. Fungible assets such as ETH, IMX and supported ERC-20 balances were migrated through the bridge upgrade to the same wallet address. NFT handling followed each game or collection, so ownership on the old system does not establish the item’s present marketplace path. An old API order record also does not supply an executable Immutable Mainnet order. Use chain ID 13371, the migrated asset location and the current game marketplace as the three availability anchors.

Availability failures map to three transaction layers

A reliable Immutable availability diagnosis follows three layers in order: provider state, funding state and executable marketplace state.

Provider and network state

Provider state begins with the address returned by Passport, MetaMask or WalletConnect and chain ID 13371. Immutable Mainnet uses EIP-1559 fees, a 10 gwei minimum priority fee and a 30 000 000 block gas limit. The fee cap must also cover the live base fee. Blocks and finality target about 2 seconds, so network inclusion remains separate from slower index updates.

Funding and approval state

Funding state confirms the payment currency is on Immutable Mainnet, the balance covers principal and any ERC-20 allowance reaches Seaport. Native IMX handles gas when sponsorship is absent. A user holding only Ethereum-side USDC needs a bridge, while the wrong Immutable token needs an available QuickSwap route and adequate liquidity.

Order and settlement state

Marketplace state requires an ACTIVE order or an active Primary Sales product, remaining quantity and a transferable asset. Read the transaction hash after submission, then match its receipt to the connected address and collection. This sequence separates a connector issue from a funding route, an approval gap, an inactive listing or pending indexing.

The first failing layer identifies the action that restores marketplace access.