A friend wires you USDC on Polygon. You send him the address you've been using on Ethereum for a year — same hex string, same wallet, same vendor. The transfer confirms. The funds are gone, in the protocol-level sense that they reached the destination, and stuck, in the practical sense that nothing on Polygon answers to that address yet. Same string, different chain, different reality.
This is the kind of problem smart accounts quietly create. They solve real ergonomic and security problems — that's what the first four parts of this series argued — but they replace one mental model (an address is a public key) with a richer one (an address is a contract, a delegation, or a counterfactual promise) that does not always travel cleanly between chains. This capstone is about the gotchas you only meet after you adopt one.
The Same Address — Until It Isn't
ERC-4337 accounts derive their address deterministically from CREATE2: the factory contract's address, a salt, and the init code hash. Plug the same three inputs in on any EVM chain and you get the same address. That is why "counterfactual deployment" works — your wallet can give you an address before any contract is deployed there, because the address is a math fact, not a piece of state.
The trap is that every wallet vendor ships a different factory contract. Safe, Coinbase Smart Wallet, Kernel, Biconomy, Alchemy's LightAccount — different factories, different addresses, even if you sign with the same key. An account you created with vendor A on Base does not exist as the same address with vendor B on Arbitrum. It will collide on hex but not on logic.
EIP-7702 is a different shape of the same hazard. The authorization tuple a user signs to delegate their EOA to a contract is scoped per chain_id. The same EOA can be a Safe-flavoured smart account on Mainnet, a plain EOA on Optimism, and a Coinbase Smart Wallet on Base — simultaneously. Per-chain code, one address, no chain-level coordination required. See the EIP-7702 phishing class for why that flexibility is also an attack surface.
The practical consequence: "send to my wallet address on Polygon" is no longer a safe assumption. Always verify the destination chain has either the same deployed account, an equivalent delegation, or a plain EOA fallback. Bridges and centralised exchange withdrawals to a counterfactual smart account on a chain where its factory has not been deployed will succeed at the protocol level — and the funds will only be recoverable if that exact factory and salt can later be deployed at the same address. That is not a guarantee; it is a vendor commitment, and vendor commitments expire.
Recovery Models That Fail Closed
Programmable accounts mean programmable failure modes, and the failure modes worth fearing are the ones that fail closed: locked out, no path back.
Passkeys are the canonical example. WebAuthn credentials live inside Apple's, Google's, or 1Password's sync ring. Lose the iCloud account, lose the Google account, lose the device-bound credential without a backup, and the smart account is bricked unless a secondary path exists. The credential is not the user; the user has no recourse against the cloud provider.
Argent-style social recovery shifts the trust to guardians. Guardians can collude. Guardians can be phished. Guardians, in practice, often share the same email provider and live one social-graph hop away from each other, which is exactly the threat model social recovery was meant to defeat. Modern designs add time delays and on-chain veto windows; older deployments do not.
Safe in an N-of-M multisig is recoverable up to losing M − N owners. Lose one more and the funds are gone. Most users never test the threshold before they need it, so they never discover that the dead phone, the wiped laptop, and the burner Ledger they cannot find together cross that line.
Coinbase Smart Wallet is convenient because recovery routes through your Coinbase account. That is also exactly its weakness: a suspended, geo-blocked, or KYC-locked Coinbase account effectively freezes the wallet. The wallet is non-custodial in the cryptographic sense and custodial-by-recovery in the practical sense.
The rule, regardless of vendor: test recovery before you need it. Move five dollars in. Simulate loss. Run the full recovery on a different device, on a different network, while sober, while not in a hurry. If you have not done it, assume it does not work.
When Your Signing Scheme Doesn't Speak Hardware
Passkeys sign with secp256r1, the P-256 curve. Almost every consumer hardware wallet — Ledger, Trezor, Keystone, GridPlus — signs with secp256k1. They cannot natively co-sign a passkey-gated smart account, and that is not a bug; it is two different mathematical primitives.
There are two clean workarounds in 2026. First: a multi-owner Safe with a passkey owner and a secp256k1 hardware-wallet owner, so the threshold logic happens on-chain and either signer alone is insufficient. Second: rely on RIP-7212, the on-chain P-256 verification precompile that drops passkey verification from roughly 330,000 gas to about 3,500. RIP-7212 is live on Base, Optimism, and Polygon PoS, and not yet on every EVM chain — which means a passkey-gated account is cheap on some networks and prohibitively expensive on others. Your wallet vendor's silence about which chains they support is a clue.
The most defensible 2026 setup for a serious self-custody user is hardware-wallet-as-Safe-owner: the device signs an EIP-712 typed-data hash, the Safe contract enforces threshold logic on-chain, and the keypair never touches the browser. This is also where what hardware wallets actually protect against becomes load-bearing — the device only protects you against a compromised host if you are not blind-signing what it shows you.
Session keys, common in modular 4337 accounts and in Argent, trade convenience for blast radius. A leaked session key with a generous policy can drain everything inside its scope. Treat them like API tokens: short TTLs, narrow scopes, monthly audits, automatic revocation if a device is lost.
Gas Abstraction's Quiet Corner Cases
Most of the time, gas abstraction is invisible — which is the point. The corner cases are where it bites.
ERC-4337 paymasters must post and maintain a stake at the EntryPoint contract. If the dApp's paymaster runs out of stake, gets slashed, or its sponsorship policy expires mid-session, your UserOp simply reverts with a FailedOp. The UX looks like "the app is broken" — and it is, but at a layer the user cannot see. The ERC-4337 architecture walks through where exactly this fails.
ERC-20 paymasters need an ERC-20 approval before they can pull the gas-token payment. On a brand-new account that approval is itself a gas-paid transaction — chicken and egg, unless the wallet bundles approval and the user op into the same UserOp. Some do; some do not. Read the network tab.
A candid disclaimer on tax: in some jurisdictions, including the United States, sponsored gas may plausibly be a taxable event — receipt of value at the moment of inclusion. The IRS has not ruled cleanly on it as of 2026, and the literature is split. This is unsettled, jurisdiction-dependent, and not tax advice. If sponsored transactions are a meaningful share of your activity, ask a professional. The article you are reading is not one.
EIP-7702 introduces no new gas model: the delegated EOA still pays gas in ETH unless the delegated implementation routes through a paymaster, which most current 7702 designs do not. And bundler censorship is real — a single bundler that drops your UserOp leaves you waiting indefinitely. Healthy stacks fall back to a second bundler or to direct EntryPoint submission via your own RPC.
Migrating From an EOA Without Losing Yourself
Most 2026 wallets — MetaMask, Rabby, Coinbase Wallet, Zelcore-paired stacks — default to keeping your existing BIP-39 seed and either deploying a 4337 smart account next to your EOA or applying a 7702 delegation in place. The address you have been using does not have to change. That is good.
What is bad is migrating without deciding which path you took. Three options, three different downstream consequences:
- Keep the EOA, add a Safe alongside. Move funds gradually. Two addresses now, two recovery models, but the old EOA stays as an escape hatch.
- Deploy a 4337 account at a new address. Cleanest mental model, worst transition cost: every approval, every whitelist, every ENS reverse record has to be redone.
- Apply a 7702 delegation to the existing EOA. Same address, new behaviour, per-chain. Easiest to live with, hardest to reason about across chains. This is exactly the multi-chain custody problem under a new name.
Before migrating, revoke all token approvals on the old EOA — revoke.cash, or the in-wallet equivalent. Inventory NFTs, ENS records, attestations, and tokenbound accounts. After migrating, re-test ENS reverse resolution, exchange withdrawal whitelists, and any subscription or streaming-payment authorisations that key off the original address. They often break silently.
The 2026 Smart-Account Operational Checklist
- Verify your smart-account address on every chain you plan to receive on, before anyone sends you anything. Counterfactual is not the same as deployed.
- Choose at least two independent recovery paths. Different device class, different cloud provider, different physical location.
- Test recovery end-to-end with a small balance. Untested recovery is a story you tell yourself.
- Pair a hardware wallet as one of the smart-account owners or signers. Do not let a hot key be the sole authority.
- Keep an EOA escape hatch funded with enough gas to extract you if the smart-account contract is ever paused, upgraded badly, or front-run by a malicious owner change.
- Audit and revoke session keys monthly. Treat them like short-lived API tokens.
- For EIP-7702: pin to a specific, audited delegate contract and re-check
chain_idon every signing prompt. Per-chain delegation is the new replay surface. - Document your setup in plain English for whoever inherits it. A recovery model is only useful if a second human can execute it.
Closing the Series
Five parts in, the picture should resolve. Part 1 — the smart account vs EOA primer — established why programmable accounts exist at all, and why programmable means "with new failure modes." Part 2 unpacked the 4337 architecture: EntryPoint, bundlers, paymasters — the very components behind the gas-abstraction and bundler-censorship corner cases above. Part 3 introduced 7702 and the new phishing class that arrives with per-chain delegation. Part 4 was the wallet menu — Coinbase, Safe, Argent, Ambire — from which your recovery model and signing scheme are actually chosen, whether you noticed choosing or not.
Smart accounts are the right direction. They are also, in 2026, still a power-user tool: an abstraction layer on top of self-custody, not a replacement for it. The discipline that mattered when you held an EOA — verifying addresses, testing backups, revoking approvals, refusing to blind-sign — matters more now, not less, because the surface area is larger. Pick deliberately. Write it down. Test the failure case before reality does.
