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.
Expanded Definition
EIP-7702 is an Ethereum account-authorization proposal that lets an externally owned account temporarily point execution at smart-contract logic. The important boundary is that it changes how an address behaves without turning that address into a traditional smart contract, so older code that assumes a fixed account type can misread what the address can do.
That distinction matters because many on-chain checks are written around account classification, not just permissions. A contract may assume a sender is always an externally owned account, or may treat contract calls differently from account calls, and EIP-7702 can make those assumptions less reliable. Guidance on this kind of account delegation is still evolving, so implementations should treat it as a governance and compatibility change, not just a new transaction format.
For a standards-oriented overview of the proposal itself, the canonical reference is the Ethereum Improvement Proposal for EIP-7702, which captures the intended transaction semantics and delegation model.
Examples and Use Cases
- A wallet can delegate an account to a contract that batches actions, reducing friction for users who want one signed transaction to trigger several on-chain steps.
- A protocol may rely on account-level behavior for login, authorization, or nonce handling, and the delegated execution path can alter those assumptions.
- A dApp can support temporary feature upgrades without asking a user to migrate funds into a new smart-account structure.
- A security review may need to check whether contract logic still distinguishes between direct account control and delegated execution, especially where allowlists or signature checks exist.
- Teams that monitor transaction provenance may need to distinguish native account activity from delegated execution when tracing incident response or fraud patterns.
The tradeoff is familiar in smart-account design: more flexible account behavior can improve usability, but it also increases the number of paths that must be understood, tested, and monitored before deployment.
Security Implications
The main security implication is that code written for older account assumptions can fail open or fail closed when execution is delegated. If a contract or off-chain system infers trust from address type alone, it may miss that the same address can now express different behavior at different times.
That creates risks around authorization checks, replay expectations, wallet UX, and application-layer policy. A system that validates only the sender address may not notice that the effective behavior is coming from delegated contract logic, which can change how signatures are interpreted, how permissions are exercised, or how monitoring should attribute the action. If those checks are brittle, the result can be unexpected access, broken compatibility, or false confidence in review outcomes.
Practitioners should also expect a testing gap: legacy contracts, indexers, and analytics tools may not be built to model this delegation path, so they can produce misleading operational signals even when the chain itself is behaving as designed.
Domain and Governance Relevance
EIP-7702 sits in the Ethereum protocol and smart-account domain, but it has a direct governance effect for teams that depend on account behavior as a security boundary. The question is not only whether a transaction is valid, but whether the surrounding system still makes correct assumptions about who or what is executing.
That matters for custody platforms, wallets, protocol operators, auditors, and incident responders because account abstraction changes how control is expressed over time. For organisations that treat on-chain execution as part of a broader identity or authority model, the practical issue is lifecycle management: delegation can be enabled and later removed, so trust conditions may be dynamic rather than static.
NHIMG would treat this as a control-boundary change first and an identity issue only second. The relevant governance task is to decide where address type, delegated authority, and effective execution path must all be evaluated together instead of relying on older account-class assumptions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Covers preserving authorization checks when account behavior changes. |
| Recommendation — Review access decisions against effective delegated execution paths, not address type alone. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Applies to trust and access decisions affected by delegated account behavior. |
| DE.CM — Security Continuous Monitoring | Supports detecting unexpected delegated execution and broken assumptions in monitoring. | |
| Recommendation — Update identity and access controls so delegated account behavior is validated before trust is granted. Instrument monitoring to detect delegated execution paths that change expected transaction behavior. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Maps to changing account behavior or authority through delegation-like control shifts. |
| Recommendation — Monitor for account manipulation patterns that alter effective authority or execution behavior. | ||
