A familiar address can execute new account logic
A smart-account upgrade deserves a different question from a token approval: what code will the account itself use? MetaMask explains that its smart-account flow points an existing account to a contract without moving the funds or changing the address. Seeing the same address afterward therefore does not answer the security question. The relevant change is the account's execution behavior.
MetaMask describes batching and sponsored fees among the capabilities smart accounts can enable. Its documentation also distinguishes general smart-account possibilities from features actually available in its wallet. Treat a feature list as a starting point for checking your particular account and network, rather than evidence that every listed protection is active.
Failure does not necessarily undo delegation
EIP-7702 processes authorizations before the main execution. A valid authorization can install a pointer to delegated code; if execution later fails, processed delegation indicators are not rolled back. A failed transaction is therefore insufficient evidence that the account stayed unchanged. Check the account's resulting delegation on the relevant network. This is a protocol rule, not a report of a particular theft.
The specification also treats changing delegated code as security critical. Delegate implementations need appropriate authorization and replay protection; changing implementations can introduce storage-compatibility problems. A wallet label cannot substitute for reviewing the implementation chosen by the wallet. This guide does not audit any delegate contract.
Look for account-state evidence
OpenZeppelin's account API reference documents `fetchDelegate`: it returns the delegate address for an account with EIP-7702 delegation, or the zero address otherwise. This is an account-state query, separate from a transaction's success status. It illustrates the evidence a wallet or inspection tool can expose; Jepeta did not run that function against a reader's account. A returned address identifies a delegation, not a security certification of its code.
Keep the signing key in the threat model
Ethereum.org's implementation guidelines state that the original private key retains control after delegation. Pointing an account at a multisignature implementation does not, on its own, remove that key's authority. In other words, do not assume that a smart-account upgrade has neutralized an exposed recovery phrase.
The guidelines recommend wallet-mediated interfaces instead of applications directly requesting arbitrary authorizations. For readers, the practical implication is to examine the wallet's supported flow and the implementation it permits. A request presented as an upgrade still needs a clear explanation of which account, network and behavior will change.
A review checklist before and after the switch
This is an editorial checklist derived from the documentation, not a tested recovery procedure:
| Check | Record | Stop when |
|---|---|---|
| Account context | The account address and selected network | The request concerns a different account or network |
| Execution logic | The wallet's documented implementation and purpose | The delegate is unexplained or the request contradicts the wallet's documentation |
| Requested behavior | What the wallet says the action will enable | The requested authority is unclear |
| Confirmed state | The resulting delegation, including after a failed call | The interface reports failure but account state is unresolved |
| Exit route | The wallet's documented way to disable the feature | You cannot identify a supported way back |
Keep the observations separate. Understanding a requested feature does not establish that its implementation is correct.
Use the wallet’s documented exit route
MetaMask's switching guide describes disabling smart-account functionality from the account's settings, per network, followed by transaction confirmation and a network fee. Follow the current instructions inside the official wallet rather than an unsolicited upgrade or recovery link. MetaMask says its account upgrades are managed in the wallet and that it will not email you to perform one.
Disabling a feature is not proof that every other permission or account risk has been resolved. Review token allowances separately, and keep the selected network explicit with the chain-context checklist. This article is a comparison of published specifications and product documentation. No wallet was connected, no recovery transaction was attempted, and no hardware device or contract was security tested.
Evidence and source-review method
- structured comparison — Compared protocol delegation/failure behavior, OpenZeppelin account-state inspection, Ethereum.org key authority and MetaMask account controls; derived a context/implementation/result/exit checklist distinct from token-allowance guides. No incident investigation or wallet test is claimed. · evidence · observed Oct 21, 2026
Editorial transparency
This article was prepared with AI-assisted tools and an evidence-oriented source review. Citations and limitations are provided below. Documentation comparison is not a hands-on test; historical content is not automatically certified under the later independent editorial review process. Editorial standards and corrections.
Sources
- EIP-7702: Set Code for EOAs · primary · verified Oct 21, 2026
- MetaMask: switch to or revert from a smart account · primary · verified Oct 21, 2026
- MetaMask: smart-account capabilities and limits · primary · verified Oct 21, 2026
- Ethereum.org: EIP-7702 implementation guidelines · primary · verified Oct 21, 2026
- OpenZeppelin Contracts: EIP7702Utils account-state reference · primary · verified Oct 21, 2026
