The Paradox
You lose access to your smart account. The usual recovery flow activates: guardians sign off, the account checks the signatures, and executes the recovery. Except on one chain, the recovery doesn't work. Not because of a bug. Not because guardians flaked. The account doesn't exist on that chain, so there's nothing to recover.
This is where account abstraction meets multichain reality.
Smart accounts aren't inherent to a blockchain like EOAs are. An EOA's address derives from keccak256(public_key) — the same public key produces the same address everywhere. But a smart account address depends on where and when it was deployed. Even with the same creator address and bytecode, different chains mean different deployment conditions. CREATE2 can give you the same address across chains, but the same address doesn't mean the same state. On Ethereum, your account is deployed with five guardians configured. On Polygon, it hasn't been deployed yet.
When you try to recover, you're asking a contract that doesn't exist to execute code. It fails silently or reverts depending on the implementation.
Why the Address Is the Same But the Account Isn't
Here's the mechanics. Using CREATE2, you can predict an account's address before it exists: keccak256(0xff, creator, salt, init_code_hash). The same creator, salt, and bytecode produce the same result on Ethereum, Polygon, Arbitrum, and Optimism. You can even fund that address with tokens before deployment.
The wallet or protocol then deploys the account to each chain using the same salt and constructor parameters. On paper, unified multichain addresses. In practice, each deployment is independent. Funds sitting on the predicted address of an EOA will appear in the account once it exists on that chain — that's just how EOAs work. But a smart account's state is empty until the contract bytecode lives there. The account doesn't know about guardians configured on another chain. It doesn't have access to the vault of funds in the smart account address on Ethereum.
Add timing into the equation. Users might deploy their account on mainnet first, then only gradually to other chains. Or protocols deploy in phases: Ethereum and Arbitrum day one, Polygon and Optimism six months later. By the time recovery becomes necessary, the deployment map is fragmented.
The Failure Mode in Practice
A user's private key is compromised. Their recovery flow would normally work: three guardians sign a recovery request, the account verifies their signatures, and replaces the old signing key. But they're on Polygon, and the account was only ever deployed on Ethereum.
The recovery transaction goes to the Polygon RPC. It calls the predicted address. The address is empty — no bytecode. The call either reverts or does nothing, depending on the client and how the recovery contract is written. The user sees the transaction fail. Their funds on Polygon are now locked behind an account that doesn't exist.
They could deploy the account to Polygon now, but the recovery signer has already been compromised. If they deploy with the old signer, the attacker can drain it immediately. If they try to use the recovery flow first, they're back to square one: calling code that isn't there.
This isn't a problem if you're only on one chain. It's a real production issue the moment you operate across multiple networks.
Four Approaches We Tried (And Why They Didn't Work)
Pre-deployment to all chains: deploy the account to every chain before the user even knows they need multichain support. This removes the empty-address problem, but it's expensive and assumes your supported chains are fixed. If a new chain launches or you add support later, users who migrated before your expansion still have accounts on old chains but not new ones. Plus you're paying gas to deploy contracts that might never be used.
Merkle tree signatures: store a Merkle root of valid guardians on-chain, allowing recovery without the full guardian list. The idea was to propagate this root across chains. But it still requires the account contract to exist and be callable on each chain. You're just solving information availability, not the fundamental problem.
Registry contracts: deploy a central registry that tracks which chains have an account deployed, and which chains have pending recovery. The registry itself becomes a point of failure and adds latency — cross-chain messaging is slow and expensive. A user might initiate recovery on one chain while being unaware that the account doesn't exist on another. The registry approach also doesn't prevent the underlying issue: the account can't execute recovery code on a chain where it isn't deployed.
Scoping down: stop pretending recovery works across all chains. Only allow recovery on chains where the account was deployed. Direct users to migrate funds to a deployed chain if they lose access on an undeployed one.
Each approach had fatal flaws. Pre-deployment wastes gas. Merkle trees and registries add complexity without solving the core problem. Scoping down is honest, but it's a bad user experience.
Where We Landed
Guardians are only configurable on chains where the account is deployed. Recovery works only on those chains. Full stop.
This means:
- If your account exists on Ethereum and Arbitrum, guardians must be configured identically on both. The account on each chain has its own guardian storage. There's no synchronization mechanism.
- If you later deploy to Polygon, you must manually configure new guardians on that chain. They won't inherit the configuration from Ethereum.
- Private key backup becomes non-optional. If you lose access before your account is deployed to a new chain, you have no recovery path on that chain except to restore your private key.
This is less elegant than a unified recovery model, but it's sound.
We added clear warnings to the UI and onboarding. Users see which chains their account is deployed on and which chains have recovery configured. Before deploying to a new chain, they get a warning: recovery will require a separate guardian setup. If they move funds to a new chain before deploying the account there, they're told explicitly: recovery is unavailable on undeployed chains.
The private key backup is no longer an emergency-only option. It's the baseline recovery path. Guardians exist to protect against the specific case where the private key is compromised but funds haven't yet been moved to an undeployed chain. This is more constrained than selling recovery as a catch-all, but it's what actually works.
Why EIP-7702 and Cross-Chain Messaging Don't Solve This (Yet)
EIP-7702, part of the Pectra upgrade, lets an EOA temporarily delegate to a smart contract via a delegation designator. The proposal is interesting for multichain unification — an EOA can delegate to the same contract address across chains, even if the contract hasn't been deployed everywhere yet.
But adoption is inconsistent. Pectra hasn't rolled out uniformly across all chains. Ethereum moves on its own timeline. Layer 2s follow weeks or months later. Testnets adopt faster than mainnets. A user relying on EIP-7702 recovery today might find that their recovery chain doesn't support the opcode yet. You'd need fallback recovery paths for every unsupported chain, which immediately reintroduces the complexity problem.
Cross-chain messaging is the other proposed solution. Initiate recovery on Ethereum, have the message propagate to Polygon and Arbitrum, and execute the recovery atomically across all chains. In theory, this is sound. In practice, it's slow, expensive, and adds another failure mode: what if the bridge is down when recovery is needed? Bridge security is a distinct concern from account security. Bundling them together is risky.
Each blockchain is sovereign. Consensus rules, upgrade timelines, and opcode support are independent. Any multichain solution that assumes unified behavior across chains will eventually break.
What This Means for Builders
If you're building multichain account abstraction, stop trying to make recovery look the same everywhere. It won't work until there's true cross-chain atomic execution, and that's not a solved problem.
Instead: Make deployment explicit. Show users which chains have accounts and which don't. Make recovery configuration per-chain, not global. Use a modular account architecture (ERC-7579) so adding recovery logic later doesn't require a redeployment.
Invest in the private key backup. It's not glamorous, and it doesn't look like social recovery on a slide deck. But it's reliable. A user who has their private key backed up securely can restore access to any chain, deployed or not. That's worth more than a broken multichain recovery fantasy.
Don't ship recovery as a feature until you can actually guarantee it works everywhere. Start with deployed chains only. Document the limitations. Let users make informed choices about whether to deploy on new chains and how to handle recovery there.
The recovery paradox isn't a temporary problem waiting for the next upgrade. It's a structural constraint of blockchain architecture. The sooner you accept it, the sooner you can build something that actually works.