Immutable Immutable Passport email sign-in, wallet access and recovery
Immutable Passport combines email or social sign-in with a non-custodial wallet for games that support its integration. Authentication identifies the account, while wallet connection gives an application access to its blockchain address and supported wallet functions. Returning users can reuse their Passport identity across participating applications. Access and recovery depend on control of the linked email or social account. Signing into a game, connecting a wallet and authorizing an asset transaction are related actions with different results.
Bottom line: A shared Passport wallet provides continuity across participating applications, while each game determines which assets and wallet actions its integration supports.
Return through the original sign-in account
With access to the linked email or social account, a returning user can authenticate again and connect the associated Passport wallet. Supported social options include Google and Apple. The standard Passport flow does not require a conventional browser wallet extension. The application determines which login options it presents and when it connects the wallet.
Losing a device and losing the login account create different recovery conditions. Another device can access Passport through the same retained identity. An inaccessible or compromised email account requires recovery through the email provider; a social account requires its provider's recovery process. Immutable cannot independently restore control of that identity. Support may restrict Passport access while credential recovery proceeds, where practicable. Such assistance does not reverse transactions that have already moved assets.
Identity, wallet address and game access
A Passport identity identifies a user to the application, while the wallet address identifies the associated blockchain wallet. Passport uses OpenID Connect for authentication. An application can request identity access without immediately connecting the wallet, so a successful login and a ready wallet are separate integration states. A game can retain its own account system and use Passport for wallet access.
Wallet connection supplies the provider that an application uses for blockchain requests. In the web integration, requesting accounts through
eth_requestAccounts
returns the Passport address. Native integrations connect their provider before requesting accounts. Some connection methods also prompt authentication when no session exists, so an interface can combine sign-in and wallet access. These related operations do not require separate player-facing screens.
Passport defines the wallet address at account creation; the user's first transaction from that wallet deploys the wallet contract.
A return visit with an inaccessible inbox
In this hypothetical example, a game integrates Passport and a returning player has an email-based account with a previously recorded wallet address.
Normal access would pair authentication through that email account with connection to its Passport wallet. Here, the player cannot access the inbox, so email sign-in remains unavailable. The recovery route runs through the email provider. Passport support cannot replace control of that account. In this case, the provider restores access and Passport subsequently returns the same wallet address that the player recorded. That match confirms access to the expected wallet. It does not establish that a missing item has returned or that a purchase settled; those outcomes require their own game or transaction records.
User signing and Guardian co-signing
Passport wallets on Immutable Chain use a 2-of-2 signing arrangement that requires user-key and Guardian-key signatures.
Two keys with different responsibilities
The user key
The user's device retrieves the user key from Magic's key-management infrastructure after authentication and signs the transaction locally. Immutable does not have access to this key. An application can request an action through Passport, and the user's device performs its side of authorization. A game requesting a transaction does not independently control the wallet.
The Guardian key
Immutable controls the Guardian key and uses it to enforce security policies, including spending limits and fraud checks. A user signature alone does not bypass these controls. Co-signing does not give Immutable unilateral control of the user's assets. It also creates a service dependency: a valid sign-in cannot force the Guardian to authorize a restricted action.
Link an existing wallet without transferring its assets
When assets remain in an external wallet, linking can associate that wallet with Passport for supported read-only use in a game. The linking process requires a signature from the external wallet to establish ownership. Linking an external wallet to Passport does not transfer its assets into the Passport wallet. Applications can use linked addresses to discover holdings that their integrations support. The external wallet retains its own signing control.
Importing supported assets into Passport changes where those assets reside and requires an on-chain transfer. A read-only link grants no authority to craft, burn or transfer assets in the external wallet through Passport. A game can separately support that external wallet's own connection and authorization. Linking supports recognition of existing holdings; importing places supported assets under the Passport wallet's control.
When does Passport omit a separate transaction popup?
In supported native game integrations, pre-approved transactions can omit the separate Passport confirmation popup for eligible actions involving linked contracts. These integrations require a native Passport client and prior user consent. Unity and Unreal native integrations support this flow.
Browser transactions use explicit confirmation popups. Native transfers of IMX also require confirmation, even when a game uses pre-approved contract calls.
Pre-approval changes the confirmation experience. Signing, submission and blockchain confirmation remain different states. A transaction hash identifies the transaction; a successful receipt establishes that the network executed it successfully. A game should credit the affected item or balance only after confirming the relevant transaction.
Gas sponsorship covers eligible network execution costs. An item's purchase price and any marketplace trading charges remain separate from those sponsored costs.
Passport access and a separately managed wallet
For a game that accepts Passport, the shared sign-in account can give access to an existing wallet across participating applications. That continuity does not make every collectible usable in every game. The game decides which collections and wallet operations it supports. Its account system also determines the gameplay permissions and progress that it grants.
Passport provides full wallet support on Immutable Chain mainnet and testnet. Ethereum mainnet support is limited to ejection of funds to Immutable Chain. Check the destination network before an asset transfer; matching address formats do not establish equivalent wallet capabilities. Assets sent to unsupported EVM chains remain inaccessible through Passport while those chains remain unsupported.
Passport's terms set wallet-value and transaction-value limits in Australian dollars. Immutable periodically reviews the US-dollar equivalent that it applies to the transaction cap. These limits can change, so read the current terms before transferring assets. A transaction above the cap does not proceed. Total holdings must stay below the wallet-value limit; keep any excess in another wallet that you control.
A separately managed wallet uses its own backup and connection method, which may involve hardware or a recovery phrase. Passport's standard access route centers on the linked sign-in account and Guardian policies. The game determines which connections it offers, so its supported wallet routes and the user's preferred recovery method guide the choice.
Practical questions about Immutable Passport
Does signing out erase the assets in my Passport wallet?
Signing out ends a login session; it does not delete the Passport account or erase its on-chain assets. Session cleanup varies by integration. Native software development kits distinguish clearing local credentials from clearing the browser session. Account deletion separately removes future wallet access, so signing out and closing the account have different consequences.
Can I create a separate Passport wallet for each game?
Passport's terms limit each person to one Passport wallet. Creating additional wallets can lead to suspension or termination of access to the extras. Supported games can use the existing Passport identity and wallet. Linking an external wallet associates that separate wallet with the identity; it does not create another Passport wallet.
What must I do before requesting Passport account deletion?
Transfer every asset that you wish to keep to a wallet that you control before requesting account deletion. Deleting Passport makes its associated wallet and remaining assets irrecoverable. Confirm that the transfers have completed before submitting the deletion request; an initiated transfer or transaction hash alone does not establish that the destination received the assets.
Are identity checks required only when creating a Passport account?
Passport may require identity verification after registration, including as a condition of transfers or reward withdrawals. Failing to comply can restrict access or functionality. Email authentication therefore does not establish that every later wallet action is available without additional eligibility checks. These requirements concern access to the service even though the wallet uses non-custodial signing.
Which account details can a game receive through Passport login?
A game can receive the unique Passport user identifier, and it can receive the email address when the email scope is granted. Wallet connection also exposes the associated blockchain address. These fields serve different purposes, so email sign-in does not make the account anonymous to the integrating application.
How does message signing differ between native Passport games and web integrations?
Native Passport integrations for Unity and Unreal support EIP-712 typed-data signing, while web wallet integrations also support ERC-191 personal signing. The native Passport interfaces do not expose that personal-signing method. An application must use the signing interface that its platform supports. Email sign-in does not establish that the native game and browser provide identical wallet methods.
Updated on