EIP-7702 is an Ethereum proposal that adds a transaction type allowing an externally owned account to delegate, and later remove, its behavior to a smart contract. It changes how some addresses execute on-chain, which can invalidate older assumptions embedded in deployed contract logic and security checks.
What EIP-7702 Changes in Ethereum Execution
EIP-7702 is a proposal that changes the execution model for an externally owned account by letting it temporarily behave like a smart contract. That matters because security assumptions built around “this address can only sign transactions” no longer always hold, especially in systems that treat address type as a stable trust signal.
Why This Matters for Contract Logic and On-Chain Security
The core security issue is assumption breakage. Contracts, wallets, relayers, and monitoring systems may infer behaviour from whether an address is externally owned or contract-based, but delegation blurs that line and can change how calls, permissions, and validation logic behave at runtime.
This can affect allowlists, signature handling, authorization checks, and any code that relies on a static mental model of the caller. If a protocol assumes “EOA means direct human control” or “contract code at an address is permanent,” EIP-7702 creates room for logic errors rather than a simple patchable bug.
Because the proposal allows behaviour to be delegated and later removed, security reviews need to consider both the delegated state and the post-revocation state. That lifecycle makes the address’s effective capabilities time-dependent, which is harder to reason about than a conventional static account model.
Security Implications for Wallets, Apps, and Protocol Integrations
Applications that interact with accounts should treat execution capability as dynamic, not inferred solely from address type. A transaction flow that is safe for one account state may become unsafe if the account delegates behaviour to a contract with broader call paths, different permission checks, or logic that can redirect value transfer.
For wallet and dApp integrations, the practical consequence is that simulation, policy enforcement, and transaction review become more important than simple heuristics. Security controls need to understand what code will actually execute, what permissions it may exercise, and whether downstream contracts are resilient to delegation-based behaviour.
For teams building smart account or wallet-adjacent tooling, the safest design pattern is to validate the active execution path rather than trust the historical identity of the address. That is especially important when a contract assumes a stable signer model or when a user interface presents the address as if it were a normal externally owned account throughout the interaction.
How Organisations Should Think About Exposure and Review
Exposure checks should start with inventory: identify any contracts, wallets, relayers, routers, simulators, and monitoring systems that assume a fixed EOA versus contract distinction. Then review whether those systems make authorization, spend-limit, or call-routing decisions from that assumption alone.
Operational review should also cover revocation handling, because delegation can be removed and the address can revert to a different behavioural state. Any stateful control that caches prior assumptions about the account may become stale and should be revalidated after delegation changes.
For teams designing user-facing controls, the key question is not only whether delegation is allowed, but whether the user can clearly see the active behaviour and safely remove it. The proposal makes governance over account behaviour a live security concern, not just a protocol design detail.
Risk and Threat Considerations
EIP-7702 increases the risk of security controls failing because they rely on outdated assumptions about what an address can do. That can create authorization errors, unexpected execution paths, or opportunities for malicious or simply misunderstood delegated logic to trigger value movement or policy bypass.
Failure mechanism: Defenders or contract authors treat address type as static, while delegated contract behaviour changes the effective trust boundary and execution path.
Impact: The result can be broken assumptions in validation, unsafe transaction approval, stale monitoring logic, and in the worst case unauthorised on-chain actions or loss of funds.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | EIP-7702 changes how authorization decisions map to runtime execution paths. |
| Recommendation — Validate authorization against the active execution path, not address category assumptions. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Delegated account behaviour can widen effective permissions beyond the static account model. |
| IA-5 — Authenticator Management | Delegation and revocation affect control over credential-like account authority and its lifecycle. | |
| Recommendation — Constrain delegated account capabilities to the minimum required for each interaction. Review lifecycle controls for account authority changes and revoke obsolete delegation paths promptly. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Protocols and apps must manage changing access paths introduced by delegated account execution. |
| Recommendation — Inventory and control account-based access paths that can change through delegation. | ||
Practitioner Guidance
Why practitioners should care: The main operational task is to stop treating “EOA versus contract” as a complete security model. Review tooling, smart contracts, and wallet policies for any decision that depends on that distinction, then re-test those paths under delegation-enabled behaviour.
Common misunderstanding: Many teams assume delegation is only a UX change for the account holder. In practice, it is also a security-model change for every downstream system that reasons about caller identity, call origin, or account capabilities.
Practitioner takeaway: Build your controls around the code that is actually authorised to execute, not around the address category you expect to see most of the time.
Related resources from NHI Mgmt Group
- Guide: AI Agents with Crypto Wallets Security Guide
- How should smart contract teams review code before the EIP-7702 upgrade goes live?
- Why does EIP-7702 increase risk for contracts that rely on tx.origin and caller type checks?
- What are the signs that a codebase may fail after EIP-7702 is enabled?
- EIP-712
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org