Field guide 01 · Wallet permissions
Your wallet has an “upgrade” button. What are you agreeing to?
An Ethereum wallet upgrade can let code act through your existing account. That can make payments easier, but it is a lasting change in how the account works. Closing the app or disconnecting a website does not undo it.
Three permissions, three places to check
01
The address stays familiar; its behavior changes
Imagine opening the wallet you have used for years and seeing an offer to combine several steps into one. The address need not change. What changes is the code Ethereum uses when that account is called. The mechanism is called EIP-7702 delegation: the account points to a deployed program that supplies its behavior.
A well-designed program can support batched actions, fee sponsorship or limited permissions. Those features belong to the particular program and its configuration. An upgrade label alone does not tell you which protections it implements. Treat the request as a choice of account software, with consequences beyond the transaction on screen.
Source notes: Ethereum Improvement Proposals · 7702
02
Connection, token approval and delegation are different
Connecting a website lets it communicate with your wallet through the access you allow. A token approval is an on-chain allowance: a named spender can use a specified token up to the amount authorized under that token’s rules. Many Ethereum tokens use the common interface called ERC-20 for this. Delegation changes the code used by the account itself.
These permissions live in different places. Disconnecting a site does not clear an ERC-20 allowance. Clearing account delegation does not, by itself, erase allowances recorded in token contracts. A cleanup screen that reports one category as empty has answered only that category’s question.
This distinction is useful even when nothing has gone wrong. You may want to stop using one application while keeping a trusted account program, or remove an old token allowance without changing your wallet setup.
Source notes: Ethereum Improvement Proposals · erc20 / Ethereum Improvement Proposals · 7702
03
A failed transaction can still leave the upgrade in place
Delegation persists until it is replaced or cleared. The protocol processes the authorization before the transaction’s execution, and an execution failure does not roll back a delegation it already processed. A failed swap is therefore not enough evidence that the account change failed too.
After an unexpected result, inspect the account’s current delegation on the relevant network using a wallet or explorer that exposes it. Record the target address and compare it with the wallet provider’s official documentation. A familiar contract name is a label; the exact address and deployed code are what matter.
Source notes: Ethereum Improvement Proposals · 7702
04
Read the network scope and the program behind the promise
The authorization identifies a target program, a network scope and an account counter called a nonce. A chain ID of zero permits use across chains where the authorization otherwise remains valid; a specific chain ID narrows its scope. This does not mean the same program exists or behaves identically everywhere.
A spending cap shown in a wallet interface is not a cap imposed by EIP-7702 itself. It has to be enforced by the delegated account’s implementation. Likewise, a sponsor paying today’s fee is a service arrangement. It does not establish that the sponsor will fund your next transaction.
Before accepting, find the provider’s explanation of the target program, the permissions it supports and the supported way to return to an undelegated account. If the wallet cannot explain the change clearly, you can leave the request unsigned while you investigate.
Source notes: Ethereum Improvement Proposals · 7702 / Ethereum Improvement Proposals · 4337
05
Removing code is one step in understanding access
The protocol includes a way to clear delegation through a valid authorization to the zero address. Use the wallet’s documented flow and verify the resulting account state; do not interpret this as instructions to send money to the zero address.
Removing a delegation does not recover a disclosed signing key, cancel every separate signature, or reverse completed transfers. If another person has the key, they may be able to authorize a new change. That is a different problem from an unwanted program chosen while the key remained private.
Keep a small record of the account, network, old target, removal transaction and observed result. Then inspect token allowances and any remaining application permissions separately. You are building a clear picture of access, rather than relying on one reassuring status badge.
Source notes: Ethereum Improvement Proposals · 7702 / Ethereum Improvement Proposals · erc20
Worked example · fictional
The swap failed, but what happened to the account?
In this fictional example, Lena authorizes a wallet program and tries to swap 40 tokens in the same transaction. The authorization is valid, but the swap reverts because its price condition cannot be met.
She should check two results: whether the swap moved tokens, and whether the account now delegates to the program. The failed execution can leave the second result in place. If she later disconnects the swap website, that does not answer the delegation question either.
| Action | What it addresses | What still needs checking |
|---|---|---|
| Disconnect website | That website’s wallet connection | On-chain allowances and delegation |
| Revoke token allowance | A token’s permission for a spender | Other tokens and account code |
| Clear delegation | The account’s delegation indicator | Key security, token allowances and other signatures |
Try the idea
Remove one permission. See what remains.
Each button represents a different action. Start with all three permissions present.
Disconnecting the website would leave the token allowance and account delegation in place.
This is a fictional teaching example. It does not connect to a wallet, create a proof or send a payment.
Use what you learned
What to check
- Identify the account, network and exact delegation target.
- Read what the program can do and how its limits are enforced.
- Check the current account state after both successful and failed execution.
- Use the provider’s documented removal flow; review token allowances separately.
Why this may matter for years
As wallets bundle payments and offer sponsored fees, more people may encounter account upgrades without recognizing the permission involved. The lasting reader question is how to identify and remove each kind of access.
This is an editorial judgment about lasting usefulness, not measured search demand or a forecast of adoption.
Evidence and scope
These primary sources were retrieved and saved with content hashes. Specifications describe mechanisms; provider documentation describes a particular implementation. Neither is a certification of a product. The examples and checklists apply those mechanisms to fictional situations and practical questions.
Primary-source comparison completed by a separate automated reviewer on 2026-10-02. This is AI-authored content with automated verification; no human or expert approval is claimed.
- EIP-7702: Set Code for EOAs ↗
Ethereum Improvement Proposals · Behavior; Persistence of code delegation; Interaction with applications and wallets; Security Considerations
Protocol rules for delegation persistence, clearing and execution. It does not certify a wallet implementation.
Retrieval details
2026-10-02T21:37:35.905114+00:00 · HTTP 200
SHA-256 a63b7d68b0da3dc668dc99459c66b824a5ef4447a5ae4b1687faafe284f64a61
- ERC-20: Token Standard ↗
Ethereum Improvement Proposals · approve, allowance and transferFrom
The token allowance interface, separate from account delegation.
Retrieval details
2026-10-02T21:37:35.905459+00:00 · HTTP 200
SHA-256 98bda5e4707841a68684879878c4c165fdaa47d89ed69ebf232ab9be06ff050e
- ERC-4337: Account Abstraction Using Alt Mempool ↗
Ethereum Improvement Proposals · Definitions; EntryPoint; Paymasters; First-time account creation
Account operations and infrastructure roles. Support differs by deployed account and version.
Retrieval details
2026-10-02T21:37:35.905547+00:00 · HTTP 200
SHA-256 ba69db925f98b811c8b73915af67c25fa70fc8d5d8c8f2c4166ab376e0fcb115