{ "slug": "smart-wallet-portability-provider-shutdown", "title": "Could you still use your wallet if its app disappeared?", "searchTitle": "Smart wallet portability: access if your provider shuts down", "category": "Access and recovery", "accent": "#94d6bf", "diagram": "portability", "summary": "A backup can preserve a signing credential while leaving you without a practical way to use the account. For a smart wallet, portability means being able to identify the account, meet its authorization rules and submit a transaction through another supported route.", "why": "Wallets increasingly combine passkeys, account contracts and hosted services. If these designs spread, people will need to judge whether access survives a provider outage or a product being discontinued.", "overlap": "Existing recovery articles focus on lost access and credentials. This guide evaluates provider-independent operation while access still works, including contract configuration and transaction submission.", "related": [ "smart-account-recovery", "smart-account-bundlers", "smart-account-paymasters" ], "sections": [ { "id": "parts", "heading": "Start by separating the app from the account", "sourceIds": [ "4337", "safe" ], "paragraphs": [ "Your wallet app is the screen you use. The account is the object the network recognizes. A signer provides the authorization, and additional services may read balances, prepare requests or submit them. One company can supply several of these parts, which makes them feel like one thing.", "A smart account is governed by code. An exported key might be one authorized signer, one part of a threshold, or no longer authorized at all. Restoring that key in another app does not automatically recreate the original contract’s transaction format or recovery features.", "Start with a small account record: network, account address, account implementation or version, authorized signers and the rules for approval. Keep secret credentials out of that record. A map of the setup is valuable, but it is not a substitute for the protected material required to authorize transactions." ] }, { "id": "credential", "heading": "“I have my passkey” answers only part of the question", "sourceIds": [ "passkeys", "4337" ], "paragraphs": [ "Some passkeys synchronize through a credential provider; others remain bound to a device. That difference matters if you lose a phone. It does not by itself establish whether another wallet app can use the credential to authorize the same blockchain account.", "Ask the wallet provider for a documented alternative access path. Which supported tool can locate the account? Can it use your signer? Does the account require a provider-controlled cosigner or recovery service? If a dependency cannot be replaced, write it down as an unresolved dependency rather than assuming the word self-custody settles the matter.", "An extra device may help with device loss while doing little for a provider outage. Those are separate failure scenarios, so they deserve separate checks." ] }, { "id": "configuration", "heading": "The rules can matter as much as the keys", "sourceIds": [ "safe" ], "paragraphs": [ "Safe provides a concrete example: its accounts have owners and an approval threshold. A two-of-three owner arrangement requires two qualifying owner signatures for its ordinary transaction path. Optional code extensions, called modules, can introduce additional ways to execute transactions. Guards are checks that can block a transaction.", "This is why an inventory should include configuration, not only an owner list. A guard that blocks a transaction or a module with its own authority can change the practical answer to “can I move these funds?” Other account designs use different structures; use the documentation for the account actually deployed.", "Avoid changing signers or disabling protections merely to test portability. First learn what the current setup requires and which supported alternative can reproduce it." ] }, { "id": "submission", "heading": "Someone still has to get the request onto the network", "sourceIds": [ "4337" ], "paragraphs": [ "One common design for submitting smart-account requests is specified in ERC-4337. In that flow, software called a bundler submits account operations through a coordinating contract called EntryPoint. A separate service contract called a paymaster can sponsor fees. These are distinct jobs: having a usable signer does not make a bundler available, and having a bundler does not guarantee sponsorship.", "A portability plan should explain the fallback for each service. Can the account use another compatible bundler? Can it pay its own fees under its implementation? Which EntryPoint version does the alternative support? Do not assume every smart account offers a direct transaction path or that every provider can process its operations.", "Ask for a worked recovery procedure for the specific account version. An architecture diagram is helpful; a supported procedure you can actually rehearse is stronger evidence." ] }, { "id": "rehearsal", "heading": "Rehearse with a separate, low-value setup", "sourceIds": [ "safe", "4337", "passkeys" ], "paragraphs": [ "Create a separate test account with the same account design, where the provider supports that. Practice identifying it from your account record and using the documented alternative interface. If a test network is available, it can help you learn the steps, though it does not prove production services will behave the same way.", "A meaningful rehearsal reaches a verified result: the intended account authorized the request, the network processed it and the destination received the expected test asset. Seeing the right balance on another screen proves much less.", "Record which services were still involved. If the alternative interface silently used the original provider’s server, you have tested an interface change rather than provider independence. That is still useful information; it tells you which question remains open." ] } ], "example": { "title": "Two backups, one hidden dependency", "paragraphs": [ "A fictional club uses an account with three owners and a two-signature threshold. Two members keep usable credentials on separate devices. They assume that is enough for an outage.", "Their rehearsal finds that the alternative tool cannot construct the transaction format used by their account version. The credentials are intact, but the club has not demonstrated an exit route. Its next task is to identify compatible submission software while the original service is still available.", "A second club uses a compatible tool and successfully submits a small test transaction without the original service. That supports a narrower, useful conclusion: this configuration and procedure worked at the time of the rehearsal. It is worth repeating after a material account upgrade." ] }, "table": { "headers": [ "What you retain", "What it helps with", "What it does not establish" ], "rows": [ [ "Credential backup", "Restoring a signer", "That the signer alone controls the account" ], [ "Account configuration", "Finding the correct authorization rules", "That compatible software remains available" ], [ "Alternative submission route", "Reaching the network", "That fees will be sponsored" ], [ "Recorded rehearsal", "Evidence of a working procedure", "A permanent guarantee after upgrades" ] ] }, "checklist": [ "Record the account address, network, version and authorization rules.", "Identify dependencies on cosigners, recovery services, bundlers and fee sponsors.", "Use a separate test account to rehearse the documented alternative route.", "Retest after material changes and keep the result with your account record." ], "figure": { "title": "What has to survive an app shutdown?", "caption": "Each layer needs a usable path. A credential backup covers only one layer of this conceptual stack.", "description": "Four layers show the credential, account rules, compatible transaction software and network submission. A side path shows an alternative interface reaching the same account." }, "scopeDate": "2026-10-02", "authorship": "AI-authored for Degrees of Satoshi", "contentSha256": "80a977e7685f927eb6493b365b2d361601dcc518466baf153a105b93588b9500", "status": "verified by separate automated source review", "sources": [ { "id": "4337", "title": "ERC-4337: Account Abstraction Using Alt Mempool", "publisher": "Ethereum Improvement Proposals", "url": "https://eips.ethereum.org/EIPS/eip-4337", "locator": "Definitions; EntryPoint; Paymasters; First-time account creation", "scope": "Account operations and infrastructure roles. Support differs by deployed account and version.", "retrieval": { "id": "4337", "url": "https://eips.ethereum.org/EIPS/eip-4337", "finalUrl": "https://eips.ethereum.org/EIPS/eip-4337", "retrievedAt": "2026-10-02T21:37:35.905547+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/4337.source", "sha256": "ba69db925f98b811c8b73915af67c25fa70fc8d5d8c8f2c4166ab376e0fcb115", "text": "evidence/4337.txt", "textSha256": "af464789bffb51a4c451b1ec5053a2e58a90f33f1c38f06bf8a0d6a2963e62eb" } }, { "id": "safe", "title": "Smart Account Concepts", "publisher": "Safe", "url": "https://docs.safe.global/advanced/smart-account-concepts", "locator": "Owners; Threshold; Signature verification; Module Transaction; Safe Guards", "scope": "Safe-specific architecture, used as an example rather than a universal wallet design.", "retrieval": { "id": "safe", "url": "https://docs.safe.global/advanced/smart-account-concepts", "finalUrl": "https://docs.safe.global/advanced/smart-account-concepts", "retrievedAt": "2026-10-02T21:37:35.905627+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/safe.source", "sha256": "f3ee1776f5200e68212ffb41f51761405cea7e2ceb920113bfc54bab3adc085e", "text": "evidence/safe.txt", "textSha256": "d5b42f9f7d323dc8ac2688dea4eb16bd8a677c2c93ca6f84949042280f41235b" } }, { "id": "passkeys", "title": "Passkeys", "publisher": "FIDO Alliance", "url": "https://fidoalliance.org/passkeys/", "locator": "Synced passkeys and device-bound passkeys", "scope": "Authentication credentials and their recovery models; not a guarantee of blockchain account portability.", "retrieval": { "id": "passkeys", "url": "https://fidoalliance.org/passkeys/", "finalUrl": "https://fidoalliance.org/passkeys/", "retrievedAt": "2026-10-02T21:37:35.905709+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/passkeys.source", "sha256": "781fff7c38fe5800800d7a49d9bec452bd6ae4a2533936759492f98a0cde7004", "text": "evidence/passkeys.txt", "textSha256": "11b5e15c9f2a728f41dd9fae8b440050f0c97ed3cfd0d3d1d9818c0de01bcec3" } } ], "canonical": "https://degreesofsatoshi.com/guides/smart-wallet-portability-provider-shutdown/", "dates": { "published": "2026-10-02", "modified": "2026-10-02", "sourceScope": "2026-10-02", "verified": "2026-10-02T22:35:07.201Z" }, "review": { "method": "Independent automated review of complete article prose, headings, summaries, examples, tables, checklists, source notes, both diagram variants and interactive messages against 16 freshly retrieved primary-source documents. Relevant source passages were read and interpreted, not only matched by locator. Full rendered passages were checked at desktop and mobile widths; 12 rendered diagrams were visually inspected and 39 interactive states were exercised. No human review, expert approval, product certification or traffic forecast is claimed.", "reviewer": "Separate automated AI source-review agent /root/review_six_guides", "checkedAt": "2026-10-02T22:35:07.201Z", "contentSha256": "80a977e7685f927eb6493b365b2d361601dcc518466baf153a105b93588b9500" } }