Immutable
Immutable is a Web3 Gaming Platform for Verified Digital Asset Ownership
Immutable is a transaction workflow that connects the correct wallet on Immutable Chain, exposes the NFT and payment details, requests the required approval, settles the trade and records ownership on-chain. A sound purchase therefore moves through four checkpoints: network, asset identity, wallet confirmation and contract-level verification after settlement.
Wrong-network prompts break the purchase path
An Immutable purchase fails its network check when the connected wallet reports the wrong chain, because the prepared call targets contracts deployed on chain ID 13371.
Mainnet uses network ID 13371, while testnet uses 13473. Ethereum mainnet reports ID 1, where Immutable Passport support is limited to moving funds toward Immutable Chain rather than trading. MetaMask and other EIP-1193 wallets expose the connected chain to the app; WalletConnect carries the same provider request. If a prompt names Ethereum, testnet or another network, reject it, switch to Immutable Chain and reopen the order. The interface must prepare fresh call data after the switch because contract addresses, balances and nonces belong to one chain state.
Switching networks does not move tokens between chains. If the balance remains short afterward, fund the address on Immutable Chain or use the interface’s bridge flow from Ethereum.
The purchase-ready wallet checklist
A purchase-ready Immutable wallet has an active session, a visible address, the required payment balance and enough native IMX for any unsponsored gas.
- Use chain ID 13371 for an Immutable mainnet purchase.
- Match the full recipient address to the connected account.
- Match the payment symbol and, for ERC-20, its contract address.
- Cover the fee-inclusive total with the spendable token balance.
- Hold IMX for gas unless the review names sponsorship.
Immutable Passport supplies an embedded smart-contract wallet; MetaMask and WalletConnect connect external accounts through an EIP-1193 provider. Every EVM address contains 20 bytes, displayed as 0x followed by 40 hexadecimal characters, or 42 characters in total. Interfaces often shorten the middle, so expand or copy the full address before confirming it matches the intended recipient. A balance on another network does not satisfy the order. The payment token must exist at that address on Immutable Chain, and the gas line must show either a sufficient IMX estimate or explicit sponsorship.
Reconnect before changing funds if the account line is blank. An eth_requestAccounts request refreshes the selected wallet, while a network switch reloads chain-specific balances and prepares a new fulfillment call (more on this in Immutable intro to review ).
Asset identity before payment approval
Asset identity on Immutable requires the collection contract, token standard, token ID and quantity to match the item displayed before the wallet opens.
An ERC-721 Orderbook listing carries an amount of exactly 1 and uses the FULL_RESTRICTED order type, so a buyer receives the named token or nothing. An ERC-1155 listing uses PARTIAL_RESTRICTED and records a quantity, allowing fewer units to settle when partial fulfillment remains available. Both standards identify a collection by its 20-byte contract address. Their token IDs fit an unsigned 256-bit integer, although interfaces normally show a short decimal ID.
Metadata supplies the item name, image and traits, but those fields do not establish ownership. Before approval, read the contract address and token ID together; a repeated game-item name can refer to different tokens. For ERC-1155, also read the quantity beside the fee-inclusive total. That combination identifies the exact asset state the Seaport order will attempt to exchange.
What does the wallet confirmation authorize?
The Immutable confirmation authorizes either an ERC-20 allowance, a Seaport fulfillment call or both actions in sequence; each prompt deserves a separate review.
With native IMX, the Seaport fulfillment call carries payment and no ERC-20 spending approval is required. With an ERC-20 currency, an insufficient allowance produces one approval transaction before the fulfillment transaction, so a first purchase can create two wallet prompts. A later purchase uses the remaining allowance when it covers the new amount. An EIP-712 signature is different: it signs structured order data without mining a transaction or paying gas by itself.
One IMX equals 1 000 000 000 000 000 000 wei, and Immutable Chain records the native currency with 18 decimal places. Wallets convert those base units into the readable amount. Compare the transaction destination, payment token and maximum spend with the checkout review before confirming.
Fee and approval choices in the final review
The final Immutable review should separate sale consideration, creator royalty, marketplace fee and network gas because each amount reaches a different destination.
Seaport encodes the seller and fee recipients inside the fulfillment data. Creator royalties use EIP-2981 information with Immutable’s Operator Allowlist enforcing eligible transfers, while marketplace fees follow the order and fulfillment configuration. One percentage point equals 100 basis points, so the displayed percentage and token amount should reconcile. Network gas is separate. Immutable Chain uses EIP-1559, enforces a 10 gwei minimum priority fee and sets a 30 000 000 gas block limit; the wallet estimates the smaller gas amount this call is expected to consume.
Approval scope changes the next action. Native IMX moves with the fulfillment value, whereas an ERC-20 requires enough allowance for Seaport. Gas sponsorship removes the user-paid gas line only when the interface explicitly applies it. Confirm when the fee-inclusive payment, gas treatment and allowance action all match the intended purchase.
Settlement turns the order into ownership
Successful settlement on Immutable atomically transfers payment to the defined recipients and the purchased NFT to the buyer within the same EVM transaction.
During a Seaport fill, the contract checks order status, seller ownership, token approval and buyer consideration before committing state. An ERC-721 success changes the token’s owner mapping to the buyer. An ERC-1155 success increases the buyer’s balance by the filled unit count and reduces the seller’s balance accordingly. Payment moves to the seller, royalty recipient and configured fee recipients in that execution. If a required check fails, the trade state reverts together; only gas used by the failed call remains charged to its sender.
Typically, Immutable Chain publishes an approximately 2-second block time and approximately 2-second finality. Orderbook indexing follows the chain and exposes six lifecycle states: PENDING, ACTIVE, INACTIVE, FILLED, CANCELLED and EXPIRED. An ERC-1155 partial fill can remain active while units remain, so quantity becomes the next decision.
Receipt and contract checks prove completion
A transaction hash on Immutable proves submission only; a receipt with status 1 proves execution, while status 0 records a reverted call.
The transaction hash contains 32 bytes and appears as 0x plus 64 hexadecimal characters, making 66 characters in total. Open that exact value in Immutable Explorer, then confirm the network, sender, destination contract, block and receipt status. Transaction input and event logs show what the contract executed. A matching hash without a successful status never establishes the ownership change.
Next, query the NFT contract. For ERC-721, ownerOf(tokenId) must return the buyer’s 20-byte address. For ERC-1155, balanceOf(account, id) must show the purchased quantity added to the account. A Transfer or TransferSingle event supports the audit trail, yet the current contract read answers who owns the asset now.
At that point, Immutable Play and marketplace inventories depend on indexers, so their cards may update after the receipt. Preserve the full hash, contract address and token ID before leaving the confirmation screen.
Recovery for stale listings and delayed interfaces
Recovery on Immutable starts by separating wallet setup, order availability, transaction execution and indexer display because each layer produces a different symptom.
No transaction hash points back to the wallet or preparation step. EIP-1193 code 4001 means the request was rejected, while 4900 means the provider is disconnected. Reconnect the intended account, restore chain ID 13371 and request fresh fulfillment data. If the order has moved from ACTIVE to INACTIVE, FILLED, CANCELLED or EXPIRED, select an active listing or a remaining ERC-1155 quantity rather than reopening the old prompt.
A hash with status 0 shows the network executed and reverted the call. Inspect the receipt before retrying. An allowance may be short, the seller may no longer own the token or another fill may have consumed the order. Refreshing the Orderbook entry rebuilds the action against current balances, approvals and order status. The failed call does not transfer the sale consideration or NFT, although its gas remains spent.
A status 1 receipt shifts attention to display lag. Read ownerOf or balanceOf, then refresh the inventory in Immutable Play or the marketplace. If the contract already records the buyer, repeated fulfillment is unnecessary. Choose the next action from the receipt and owner read rather than the interface spinner.
What readers ask about Immutable
Does closing a marketplace tab cancel a submitted Immutable transaction?
Closing the tab does not cancel an Immutable transaction already accepted by the wallet. Once the wallet returns a transaction hash, the call has entered network processing and continues without the marketplace page. Reopen the app, reconnect the same address and inspect the hash in Immutable Explorer. If no hash was produced, no submission occurred; refresh the listing and prepare a new fulfillment instead of assuming the original click remains queued.
Is a failed Immutable transaction charged at the full NFT price?
A failed Immutable fulfillment does not transfer the listed NFT price to the seller. An EVM receipt with status 0 means the state-changing call reverted, so the NFT and trade consideration remain in their prior accounts. The sender still pays gas consumed while the network executed the reverted call. Check the receipt, refresh the listing state and obtain call data before another attempt. This sequence distinguishes execution cost from the sale amount and prevents an outdated order from driving the next confirmation.
What happens if an ERC-1155 listing is partly filled first?
When an ERC-1155 listing is partly filled first, the remaining quantity determines whether your requested amount still fits. Immutable Orderbook uses partial-restricted orders for ERC-1155 assets, so the order may remain active after a smaller fill. Refresh the quantity before approval. If fewer units remain than requested, prepare the purchase again with an available count; the old fulfillment data reflects an earlier recorded order state.
Do I need to keep an ERC-20 approval after buying on Immutable?
You do not need to keep an ERC-20 allowance after an Immutable purchase if you prefer tighter ongoing permissions. The allowance remains recorded until spending reduces it or the token holder changes it, while native IMX purchases create no buyer-side ERC-20 allowance. Reducing an allowance requires another on-chain transaction and gas. Before changing it, confirm no pending purchase still relies on the approved amount, then review the updated allowance on Immutable Chain. A low allowance triggers another ERC-20 approval later.
Will an ERC-721 token appear in every wallet view immediately?
An ERC-721 token may not appear in every wallet gallery immediately after settlement. Galleries rely on indexed collection metadata and cached inventory, while ownership exists in the NFT contract. Use Immutable Explorer or call ownerOf with the collection address and token ID; the returned address settles the ownership question. Then refresh the gallery or reconnect the account. A missing image or name does not reverse a successful contract transfer.
Where can I record Immutable purchase identifiers for later checks?
Keep four Immutable purchase identifiers: the chain ID, wallet address, NFT contract address and token ID. Add the transaction hash and final receipt status for the settlement record. Those fields let you distinguish the asset from a similarly named item and verify ownership without relying on a marketplace card. Store the full values rather than shortened display forms, because two addresses can share the same visible beginning and ending characters in a compact interface. Recording the payment token and purchased ERC-1155 quantity reconciles inventory changes.
Does reconnecting Immutable Passport create a different wallet address?
Reconnecting Immutable Passport with the same account returns the established wallet rather than creating a fresh address for each game session. Compare the full 42-character address after login before reviewing balances or approving a purchase. If a different address appears, stop the checkout and confirm which account completed authentication. Linked external wallets remain separate addresses even when associated with the same Passport identity, so the intended recipient must still match the transaction screen.
Are two buyers able to confirm the same active Immutable listing?
Two buyers can open confirmation screens for the same active Immutable listing, but only one valid fulfillment settles the unique ERC-721 token. Seaport checks ownership, approvals and order state during execution. After the first success, the later call reverts because its prerequisites no longer hold. ERC-1155 orders differ: separate buyers can fill remaining units while quantity lasts. Refreshing the listing immediately before approval reduces the chance of confirming data built from an earlier state. Always inspect an existing transaction receipt before selecting another listing.
