One wallet confirmation can involve several kinds of permission. A token allowance, a wallet session key and EIP-7702 code delegation have different scopes and end conditions. This guide helps you identify which authority was granted and what can remain after an interaction finishes.
Start with the permissions behind one interaction
Suppose Alice wants to approve a token allowance and then swap. A compatible wallet can package those calls into a batch. A sponsor might cover the gas, or Alice might pay it herself. A wallet showing one confirmation does not, by itself, prove that every permission is temporary.
Use the wallet's own permission view and documentation to answer the following questions. These controls are separate; one interaction does not necessarily create all three.
| Permission | What to identify | What determines its end? |
|---|---|---|
| Token allowance | Which token, which spender and how much the spender is still allowed to use. | The token's allowance state and the supported way to change it. Closing a website does not itself change that on-chain state. |
| Wallet session key | Which actions the key can authorize, with what limits and time window. | The wallet's actual expiry and revocation rules. The word “session” alone does not establish a deadline. |
| EIP-7702 code delegation | Which code the account delegates to and who retains control of the account. | A valid authorization that changes or clears delegation. Finishing a swap or closing the app does not remove it. |
The allowance check comes from the ERC-20 token interface; session features depend on the wallet implementation. Disconnecting a website is not a substitute for checking on-chain permissions.
Why EIP-7702 delegation can remain after the swap
The account owner signs an authorization identifying deployed code. A type 0x04 transaction can write a delegation indicator into the EOA's code field. Calls to that account then execute the referenced code in the account's context.
The delegation remains until changed or cleared through a valid authorization. The protocol supports clearing it by authorizing the zero address. This is a wallet-level operation, not an instruction to send tokens to that address. A failed execution also does not automatically undo delegation that was already processed.
Source: EIP-7702 specification, including persistence and clearing.
Ethereum introduced EIP-7702 with Pectra on 7 May 2025. See the activation details for that protocol milestone.
Where ERC-4337 fits
ERC-4337 provides a route for smart-account requests through UserOperations, bundlers and an on-chain EntryPoint. EIP-7702 lets an existing EOA delegate code execution. They change different parts of the system and can work together in compatible implementations.
A separate smart-account deployment usually has its own address; an EIP-7702 account can retain the existing EOA address. Neither mechanism automatically supplies free fees or recovery. Sponsorship, recovery, spending limits and batching depend on the implementation, and the original EOA key retains control after EIP-7702 delegation.
Background guide: For the request's execution flow, fee funding and a recovery example, read ERC-4337 Explained: UserOperations, Fees and Wallet Recovery.
Check authority, code and the exit before enabling a feature
- Authority: Identify who controls the wallet and whether the original key can bypass a delegated policy. Delegating to multisig-style code does not by itself remove that key's authority.
- Code: Use a wallet-supported, reviewed implementation. A delegation authorization is not an ordinary website login.
- Exit: Locate the wallet's documented way to change or clear delegation before enabling it. Changing code can also create storage-compatibility problems.
- Fees and access: Ask what happens if sponsorship ends or a relayer is unavailable.
Source: Ethereum's EIP-7702 guidelines. These are protocol explanations, not an endorsement of a specific wallet.
Continue learning
For the underlying account and gas model, read How Ethereum works. New to the site? Use the Start Here guide.
Review and correction history
Last fact-checked: 12 October 2026 (KST) · Educational guide
Correction history — 12 October 2026 (KST): Replaced the outdated single-transaction delegation explanation and future-Pectra wording. Corrected the description of UserOperations, added EntryPoint's role, qualified address/recovery claims, and added primary-source links. The original publication date and URL are retained.
Editorial update — 20 October 2026: Moved the permission example to the start, organized allowance, session-key and delegation checks into a comparison, and shortened the repeated ERC-4337 introduction. The existing protocol review date and correction record are preserved above.