Immutable review is a focused look at Passport’s gas-sponsored game actions

Immutable review is a focused assessment of Passport, the non-custodial smart-contract wallet built for gas-sponsored actions on Immutable Chain. Its strongest feature is friction removal: approved game calls settle without the player maintaining IMX for network fees, and native clients can reuse one consent for linked contracts. The trade-off is narrow network access. Full wallet support covers Immutable Mainnet and Immutable Testnet, while assets sent to other EVM chains become inaccessible through Passport.

From game login to a settled sponsored action

Passport turns a game action into a sponsored Immutable Chain transaction through login, wallet connection, contract checks, signing and settlement.

A player starts by signing in with email, Google or Apple inside a Passport-enabled game. Passport returns one wallet address, defined through CREATE2 before the smart-contract wallet is deployed on its first transaction. The game connects the wallet provider, confirms the active Immutable chain and loads the action contract. That sequence gives the game three anchors: the authenticated account, the selected network and the wallet address expected to own the resulting token or item. No extension installation or seed-word entry interrupts this path. The player remains inside the same game session throughout.

For a native Unity or Unreal Engine client, the player grants one-time consent before streamlined calls begin. The title then sends crafting, trading and transfer calls only to contracts linked in Immutable Hub. A browser build follows the same wallet and contract path, but every web transaction opens an explicit confirmation interface. Client type therefore changes the number of prompts, not the on-chain destination.

After submission, the user key signs on the device and Immutable’s guardian key co-signs under wallet policy. The relayer sends the call, sponsorship covers EIP-1559 gas and Immutable Chain returns a receipt. A successful receipt changes the relevant contract state, such as minting an ERC-721 item or updating an ERC-1155 balance. The game should tie its visual reward to that receipt rather than the button press.

What does gas sponsorship actually cover?

Gas sponsorship covers approved Passport transactions on Immutable Chain, including supported minting, trading, transferring and game-contract calls.

Passport users qualify for sponsorship, yet the sponsored unit is the approved operation rather than any arbitrary call from the address. Supported game paths include mints, trades, token transfers and contract interactions. Linked contracts become eligible through Immutable Hub, where studios also monitor operational gas spending. Sponsorship and pre-approval solve separate problems: sponsorship assigns the fee to a sponsor, while pre-approval removes repeated confirmation popups in eligible native clients.

Native IMX transfers still open a confirmation prompt, even when the surrounding game uses pre-approved token and NFT calls.

A worked fee example for one game action

A worked fee example shows the network cost a sponsor absorbs and the exact player debit after an approved action.

For this worked example, the only changing inputs are a hypothetical gas estimate of 100 000 units and a hypothetical maximum fee of 15 gwei per unit. Multiplying those values gives a maximum charge of 1 500 000 gwei. IMX uses 18 decimal places, while one gwei equals 1 000 000 000 of the smallest IMX units. The same ceiling is therefore 0.0015 IMX.

With approval and sponsorship established, the player’s gas debit is exactly 0 IMX and the sponsor carries the 0.0015 IMX ceiling. Actual execution consumes the gas used and settles at the effective fee, so the sponsor’s final cost can fall below that ceiling. The arithmetic exposes a useful distinction: gas-free describes the player experience, while the EVM transaction retains measurable network cost.

Pre-approved calls and one-time consent

Pre-approved transactions let a native Passport game reuse one grant of consent for calls to contracts linked in Immutable Hub.

The grant belongs to a native Passport client and its organisation’s linked contracts. Future eligible calls run without another popup, which suits repeated state changes during crafting or item upgrades. The wallet still applies the 2-of-2 signing flow behind the interface; consent changes presentation and authorization policy, not ownership of the user key.

Passport pre-approves calls to linked contracts using three token standards: ERC-20, ERC-721 and ERC-1155. Transfers, mints, burns and custom calls fit this path. Native IMX transfers retain user confirmation, and web clients keep confirmation for every transaction.

The 2-of-2 wallet security model

Passport uses a 2-of-2 smart-contract wallet requiring both a user-key signature and an Immutable guardian-key signature for every transaction. Every Passport transaction requires two signatures: one from the user key and one from Immutable’s guardian key.

Magic provides the infrastructure for the user key, which is delivered to the user’s device for signing. Immutable holds the guardian key and applies rate limits, spending caps and other policy checks before co-signing. Neither key satisfies the wallet alone. This arrangement supports login-based recovery after a lost device without presenting a seed phrase, while preserving the requirement for user-initiated signing.

The contract address is counterfactually defined at account creation and deployed through CREATE2 on the first transaction. Passport’s wallet contracts are open source, making the custody and co-signing roles inspectable. These properties explain why Passport is a smart-contract wallet rather than a plain externally owned account.

Which chains fully support Passport?

Passport fully supports Immutable Mainnet and Immutable Testnet, while Ethereum Mainnet receives only a limited asset-ejection path.

Immutable Mainnet uses chain ID 13371 and Immutable Testnet uses 13473; both carry full Passport support, which is examined in Immutable in depth quick start.

Ethereum Mainnet, chain ID 1, has limited support for ejecting funds through Immutable Play. It is not a normal Passport game-action network. Polygon PoS uses chain ID 137, Arbitrum One uses 42161 and Base uses 8453, but all sit in the unsupported EVM category for Passport wallet operations.

Sending assets to a familiar 0x address does not establish wallet access on the receiving chain. Passport cannot expose or move assets sent to an unsupported EVM network until that network becomes supported, so those balances remain stranded from the product interface. Check the chain name and chain ID before funding a game account, especially when a bridge, exchange or another wallet remembers a previous network. Ethereum Mainnet is the sole documented exception because Immutable Play provides an ejection route to Immutable Chain. That route does not extend to Polygon PoS, Arbitrum One or Base.

Performance and transaction visibility

Sponsored Passport transactions retain normal on-chain timing, fee accounting and receipts even though the player does not fund gas.

In day-to-day use, Immutable Chain reports a block time of about 2 seconds and finality of about 2 seconds for Immutable Mainnet and Immutable Testnet. Its EIP-1559 configuration sets a 10 gwei minimum priority fee and a 30 000 000 gas block limit. The native IMX unit has 18 decimals. Sponsorship leaves all of that accounting intact; it changes the paying account. A quick receipt suits frequent game actions, although contract execution, indexing and the game’s own state refresh remain separate stages. Immutable Play then presents wallet balances and transaction history to the user.

Games still need clear pending and failure states around the on-chain receipt.

Passport against MetaMask, Privy and Magic

Passport differs from MetaMask, Privy and standalone Magic most clearly in address continuity and built-in sponsorship for Immutable games. MetaMask offers broad EVM connectivity and explicit wallet approvals, with gas funding supplied by the account or a separate application system. Privy emphasises embedded onboarding, while standalone Magic commonly creates an application-specific wallet. Passport itself uses Magic infrastructure for its user key yet preserves one address across participating Immutable games. On this narrow decision, Passport favours integrated fee sponsorship and cross-game identity; MetaMask favours network reach.

Operational limits across clients and accounts

Passport’s operational limits come from client type, signing method, chain support and the lifecycle of the user’s account.

Web and TypeScript integrations support ERC-191 personal signing and EIP-712 typed-data signing. Unity and Unreal Engine SDKs expose EIP-712 for structured messages but not ERC-191 personal signing. Those two client families therefore need different message designs for off-chain authentication or order data. Pre-approved transactions narrow the gap for native game calls, yet they do not add the missing personal-sign method.

Account lifecycle matters because wallet recovery follows the original identity. Signing in again with the same provider restores access without a seed phrase. A deletion request can take up to 30 days, and completing deletion makes the associated wallet and remaining assets irrecoverable. Moving desired assets before the request is part of the exit workflow, not a cosmetic housekeeping step. Linked external addresses do not merge balances into Passport. The association helps a game recognise identity across wallets, while each address retains its own assets, permissions and transaction history. That separation matters when deciding which address receives an NFT or ERC-20 reward.

Immutable X context and the present-day verdict

Crucially, Immutable’s present-day Passport belongs to Immutable Chain, not the retired Immutable X marketplace and StarkEx transaction path.

Under normal conditions, Immutable X was Immutable’s earlier StarkEx-based rollup, built with StarkWare. It merged into Immutable Chain in early 2026; write processing ended and its marketplace was removed. Older Immutable X marketplace behavior therefore should not be used to judge today’s Passport transaction path. The relevant system now is the EVM-compatible Immutable Chain, its Passport smart-contract wallet and its sponsor-backed game calls.

This Immutable review finds a sharp product fit rather than a universal wallet. Passport combines social login, non-custodial user control, one cross-game address and zero player gas for approved actions. The 2-of-2 policy model and receipt-based settlement preserve visible blockchain mechanics. Limited chain support remains the deciding constraint. Passport fits games committed to Immutable Chain and players who value uninterrupted on-chain crafting, trading and asset management.

Immutable review questions, answered