EIP-7702 lets an Ethereum account controlled by a private key delegate execution to a contract. This can support transaction batching, sponsored gas and more flexible application permissions. The security consequence matters just as much: you are not merely approving a token spender. You are choosing code that will execute in the context of your account.
Delegation does not automatically expire at the end of one transaction. It can remain in place until properly replaced or removed. A signature request should therefore not be accepted simply because it promises free gas, an airdrop or convenient activation. This guide explains the mechanism, distinguishes authorisation types and sets out checks without pretending there is a universal recovery procedure.
EIP-7702: account, private key and delegated code
An externally owned account, or EOA, is traditionally controlled through a private key. This mechanism allows it to point to a contract whose code runs in that account’s context. The address remains the same and the original key still plays a fundamental role. You do not automatically obtain a new wallet with stronger security.
What changes is the account’s behaviour. A carefully designed implementation can add useful capabilities, but their quality depends on the selected code and its checks. Delegation is the underlying mechanism. Spending limits, session keys and recovery features belong to the implementation; the protocol does not guarantee that every delegated account provides them safely.
For the distinction between key control and a custody service, see our crypto wallet guide. A simpler interface does not remove the need to understand who can sign and what each authorisation actually permits.
What can improve in everyday use?
Batching can combine multiple operations into a single execution. An application might arrange a token approval and a subsequent swap in a less fragmented workflow. However, you still need to check that the implementation delivers the expected behaviour. Combining operations does not make each operation secure or economically sensible.
Sponsorship allows another party to pay transaction costs. It can remove the need to acquire ETH immediately before an operation, but gas has not vanished. Someone pays for it. A service may recover that expense through fees, commercial conditions or another asset. Look at the full price instead of treating a “gasless” label as proof of a free service.
A wallet may also build narrower permissions above delegated code. A session key might be restricted to an application or a spending threshold. Those restrictions must be genuinely implemented and enforceable. A website’s description is not enough: ask which code enforces the rules and who can change that code or its configuration.
Delegation is not a normal token approval
An ERC-20 approval lets a spender use a specified amount of a particular token. Permit and Permit2 signatures use different authorisation paths, with powers defined by the relevant contracts. Delegation instead changes which code executes in the account’s context. These are different security layers, even if their interfaces all ask you to sign.
| Action | What to inspect | Key question |
|---|---|---|
| Token approval | Spender and authorised amount | Who can spend this token? |
| Permit or Permit2 | Signature and contract-defined permissions | Which assets and limits are involved? |
| Delegation | Code associated with the account | Which implementation will govern execution? |
Our guide to Permit2 signatures and revocation helps separate these layers. Revoking a token approval does not automatically remove delegation. Removing delegation does not automatically clear all existing token approvals either. A safety check must identify the actual permission rather than assume every signature creates the same risk.
Persistence is the detail to remember
The final mechanism uses persistent delegation. Thinking of it as a permission that lasts only for the current click understates the consequences. A signature can authorise a change that is submitted through a transaction, and the delegated implementation may remain associated with the account after that execution finishes.
Processing an authorisation and completing the subsequent operation are also different steps. A failed execution does not necessarily undo delegation already processed. Do not infer the account’s complete state from a “failed” label alone. Check what the wallet and the chain report about the account itself.
Consider a site offering a sponsored swap. The swap fails and the user closes the page. It is unsafe to assume everything returned to its previous state. The relevant follow-up includes checking any installed delegation, not just the token balance or the swap receipt. A failure message can be accurate about one operation while incomplete about the wider account change.
Contract address, network and nonce
An authorisation includes information about the selected implementation, its network scope and the account nonce. These are material details. A contract can be reviewed on one network but absent, different or unverified on another. An address resembling an official deployment is not sufficient evidence.
The protocol also permits a chain ID of zero, which does not bind the authorisation to one particular chain. This does not mean every signature works everywhere: nonce requirements and network support still matter. It does mean a wallet should explain the scope rather than hide it behind a generic request.
Users should not have to reconstruct signature encoding manually. The sensible approach is to use implementations documented and supported by the wallet, verify the network and reject arbitrary delegation addresses suggested by applications. The wallet’s official documentation is a stronger starting point than a connected site’s promotional screen.
The main risk is untrusted delegated code
Code running in an account’s context can have consequences far beyond reading a balance. A malicious or defective implementation can endanger assets and permissions. Verified source code on an explorer helps identify what was deployed, but verification is not the same thing as a security audit.
Ask what independent reviews exist, which parts are upgradeable and who controls changes. An audit covers a particular version and scope; it does not guarantee every future configuration. Even a familiar wallet should explain the proposed implementation and the supported response if something goes wrong.
Do not sign an arbitrary delegation to “verify your wallet”, collect a reward or fix an alleged problem. Attackers can present a substantial account change as routine maintenance. If an interface fails to distinguish website access from account control, stopping is safer than approving requests experimentally.
Understanding removal without assuming a reset
The mechanism allows a new authorisation pointing to the zero address to clear delegation code. Use trusted, compatible tools and verify the resulting state on the correct network. Do not follow instructions from strangers or import recovery words into a supposed wallet-cleaning service.
Removal is not a universal reset. It does not automatically erase account storage, token approvals or every permission granted through unrelated applications. Those layers may need separate checks. If the private key was compromised, removing delegation does not make the key secret again or prevent an attacker from using it.
Signed authorisations that have not yet been used also deserve attention. Disconnecting a site should not be treated as destroying signatures already handed over. Appropriate handling depends on supported wallet tools and the account state. For significant funds or an active incident, obtain qualified technical assistance instead of chaining together unfamiliar actions.
Hardware wallets need real compatibility
A hardware device helps protect key custody, but does not automatically make an authorised signature harmless. If its screen does not explain the authorisation or shows incomprehensible data, practical safety can suffer. Check support from both the manufacturer and the software communicating with the device.
Our hardware wallet guide explains the distinction: separating a key from a computer is valuable, but you still need to understand what you approve. Do not work around missing compatibility by disabling warnings or accepting a configuration supplied by an unfamiliar website.
Distinguish what an interface displays from what the code enforces. A daily limit is a security boundary only if the implementation correctly applies it. Closing a browser tab does not remove permissions already granted. If the authorisation type does not match the official documentation, stop rather than assuming that a small visible amount means a small account-level risk.
A checklist before activation
- Does your wallet document support for the relevant network?
- Is the implementation wallet-reviewed rather than an arbitrary address?
- Who pays for gas, and what other costs remain?
- Are advertised limits enforced, and who can alter them?
- Do you know the supported way to inspect and remove delegation?
- Have you separated delegation, token approvals and outstanding signatures?
For a first test, keep the scope small and avoid treating a successful operation as proof of comprehensive safety. A swap can work while an account retains broader permissions than expected. Record which network and implementation you used, read the wallet’s description of the resulting account state and check whether future actions require different signing flows. Do not use experimentation as a substitute for understanding an unfamiliar authorisation.
EIP-7702 can make an existing account more flexible. The right decision is not to activate every new feature, but to understand the code you are authorising and the checks constraining it. Better usability is valuable only when it does not conceal a security decision broader than the one you intended to make.
Primary sources checked on 30 September 2026: EIP-7702 specification; Ethereum’s Pectra and delegation explainer; Ethereum documentation. This is a risk explainer, not a universal recovery procedure or financial recommendation.
