Web3 wallet operations: recovery, provider exit and access dependencies

Wallet recovery and exit evidence map

A login recovery demonstration is not proof of provider-independent recovery or legal custody classification. Record untested scenarios as untested.

Draw the transaction path before the vendor comparison

For the exact wallet design being proposed, list the identity provider, key or signing-share holders, policy service, contract wallet, network access and application permissions. Mark which participant can initiate, approve, reject, pause or recover an action. Separate technical capability from contractual authority. Ask the supplier to demonstrate this diagram with a synthetic transaction and the deployed component versions. A short label such as embedded wallet or self-custody does not tell a support lead which dependency is preventing a player from acting.

Read a recovery promise in its product context

Immutable describes Passport as a smart contract wallet with a two-of-two signing arrangement: a user key associated with Magic and a guardian key held by Immutable. Its documented lost-device flow uses the same identity provider to regain access. This is a specific architecture description, not evidence that login recovery works when every provider is unavailable. Ask which failure the offered recovery procedure addresses and which services it still needs. Obtain current documentation for the exact product and network before extending this example to another wallet.

Immutable Passport — Architecture

Rehearse two different recovery cases

First test a player who has lost a device but still controls the authorised identity account. Record the access checks, support steps and transaction that demonstrates restored use. Then test the documented contingency for an unavailable identity, signing or policy service. If no supported path is documented, record that dependency as unresolved instead of improvising a key-handling procedure. Use test assets and a controlled environment. Never ask a player to expose private keys or recovery secrets in a support ticket, shared spreadsheet or procurement demonstration.

Treat administrative access as an operating dependency

OpenZeppelin explains ownership and role-based access patterns, including the need to maintain appropriate administrative access. Its timelock discussion describes the delay before eligible operations and the availability implications of its roles. These building blocks do not prove the permissions of a deployed wallet. Request a current role inventory, change procedure and evidence of who can administer the actual contracts. Our proposed acceptance test exercises an authorised role change and confirms that the former permission can no longer perform the protected action.

OpenZeppelin Contracts 5.x — Access control

Define exit by the actions a player can still complete

Ask what exit means in the proposed design: continuing with the same address, moving supported assets to another address, changing a signer, exporting permitted records or simply switching the game login. These are different outcomes. Identify restrictions from contracts, asset standards, network support and game entitlements before promising portability. Require a documented, supported procedure for the intended outcome and a test demonstrating it with representative assets. If the provider has supplied only a data export, record that evidence without calling it a working replacement wallet.

Carry permissions and pending work through a change

A provider transition needs an inventory of authorised contracts, session permissions, pending transactions and support cases. Record how old sessions are revoked, how a new application proves authority and how a player learns which actions remain pending. Include a transaction submitted just before the transition and a failed attempt after old permissions have been removed. The acceptance evidence should show the intended outcome once, with a traceable reference. Avoid publishing wallet addresses, identity details or transaction histories from real users in a demonstration pack.

Make the support and exit evidence reusable

Maintain a runbook that names the symptom, affected dependency, permitted support action and escalation owner. Include a verified provider contact route, the current procedure version and the conditions that require work to stop. Rehearse changes after material architecture or permission updates. Record unanswered exit questions in the buyer worksheet with an owner and requested evidence. A documented limitation can be weighed in a buying decision; a missing answer disguised as an affirmative portability claim cannot.