Teams should search for logic that assumes an externally owned account can never behave like a contract, then test those paths under delegated execution. The highest risk patterns include tx.origin checks, contract detection with extcodesize or code.length, and signature or transfer logic that depends on the caller type. Review business rules, not just syntax, because valid delegation can change execution behavior without changing the visible address.
What EIP-7702 Code Review Needs to Catch Before Delegation Changes Execution
EIP-7702 changes the assumptions many smart contract systems rely on, because an account that looks externally owned can execute delegated code paths. That means review has to go beyond ordinary linting and style checks and focus on places where business logic, authorization, and contract detection depend on the caller’s type. For smart contract teams, the issue is not just correctness after upgrade, but whether old trust assumptions still hold when execution context becomes more flexible. Guidance from the NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces the need to verify control assumptions, not just code structure.
In practice, teams often miss the breakage because the visible address still appears familiar while the execution path changes underneath it.
How to Review Smart Contract Code for EIP-7702 Assumptions
The safest review approach is to trace every path that depends on who the caller is, what the caller can prove, and how the contract decides whether an address is trusted. Start with authentication and authorization gates, then move to transfer, signature, and proxy-style logic. Code that uses tx.origin is especially sensitive because it often encodes an outdated assumption about call provenance. Code that checks extcodesize or code.length can also fail, because the apparent account type is no longer a reliable indicator of how the call is executing.
Reviewers should ask whether each rule still behaves correctly if the same address can now trigger delegated execution. That includes permit-style flows, allowlists, blacklist bypass logic, ownership checks, and any branch that treats an externally owned account differently from a contract account. The question is not whether the code compiles, but whether the business rule still means what the author intended after the upgrade. Any logic that derives trust from caller type, rather than from explicit authorization state, deserves close manual inspection.
- Identify every place where caller classification affects permissions, asset movement, or sensitive state changes.
- Test those paths with delegated execution assumptions, not only with normal externally owned account calls.
- Check whether signature validation, replay protection, and sender checks still match the intended trust model.
- Confirm that proxy, meta-transaction, and account abstraction assumptions do not conflict with upgrade-era behavior.
External tooling can help surface suspicious patterns, but the final decision should come from business-rule review and scenario testing. This guidance breaks down when teams rely only on static pattern matching and never simulate the post-upgrade execution context.
Where EIP-7702 Review Gets Tricky in Real Projects
Tighter caller-assumption review often increases testing effort, requiring teams to balance confidence against release pressure. The biggest edge case is code that is technically valid but semantically brittle, especially when the protocol distinguishes between direct user action and delegated execution only implicitly. Consensus is still evolving on how much existing tooling should be updated versus how much teams should compensate with manual review, so organisations should treat automated findings as a starting point rather than a conclusion.
One common trap is assuming that only authentication code is affected. In reality, any feature that changes behaviour based on the caller’s apparent identity can be impacted, including fee logic, withdrawal rules, delegation controls, and admin-only operations. Another edge case is dependency on third-party integrations that themselves make caller-type assumptions, because the risk can move from your contract into the integration boundary. Teams should also be cautious about contracts that were safe under older wallet patterns but become ambiguous once delegation is introduced.
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 | 5 — Account Management | Caller-trust assumptions affect who can exercise sensitive account paths. |
| 16 — Application Software Security | Smart-contract logic needs secure design review before protocol behavior shifts. | |
| Recommendation — Review and remove logic that grants access based on brittle account-type assumptions. Perform manual secure-code review on authorization and transfer logic before deployment. | ||
| MITRE ATT&CK | T1588 — Obtain Capabilities | Attackers benefit when delegated execution expands what a visible account can do. |
| Recommendation — Model how upgraded execution paths can expand attacker capabilities and abuse potential. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity and Credential Management | Delegated execution can undermine assumptions about who is really invoking a function. |
| PR.IP-1 — Baseline Configuration | EIP-7702 creates a changed operating baseline for contract behavior and testing. | |
| Recommendation — Validate identity and authorization assumptions against post-upgrade execution behavior. Update secure coding and test baselines for delegated execution before go-live. | ||
Practitioner Guidance
What to prioritise: Review every branch that treats caller type as a trust signal, then rank the findings by whether they can move funds, bypass authorization, or alter privileged state. Those are the paths most likely to become security-relevant after delegation goes live.
What to verify: Confirm that each critical rule still works when the same visible account can execute delegated code. If a control only works because the account “looks like” an EOA, treat that as a design weakness rather than a minor implementation issue.
Common mistake: Teams often focus on pattern hunting alone and miss the more important question of whether the surrounding business rule still holds. A line of code can be syntactically fine and still become unsafe once execution context changes.
Practitioner takeaway: The right review standard is not “does this contract still run,” but “does it still mean the same thing when the account can delegate execution.”
Related resources from NHI Mgmt Group
- How should security teams govern smart contract code before deployment?
- How should security teams evaluate the risk of VS Code extensions that target developers in blockchain and smart contract environments?
- How should blockchain security teams reduce the risk of smart contract exploits before deployment?
- How should teams review AI-generated code before merging it into a legacy codebase?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
