Why does EIP-7702 increase risk for contracts that rely on tx.origin and caller type checks?

Why tx.origin and caller-type logic become fragile under delegated accounts

Contracts that use tx.origin or try to distinguish “contract caller” from “EOA caller” are depending on an execution-property shortcut, not a durable trust signal. EIP-7702 makes that shortcut less reliable because an account can present contract-like behaviour while still originating from an externally owned account context. The result is not just a theoretical edge case: authorization, onboarding, and branch logic can all be routed through assumptions that no longer describe the runtime path accurately.

That matters because these checks often sit in places where a small interpretation error becomes a real security decision. A contract may allow a path only for “wallet users,” reject automated callers, or assume a human-controlled origin for sensitive actions. When the caller model shifts, the contract can grant access, block legitimate use, or take the wrong branch entirely. For a broader control lens on avoiding brittle trust assumptions, the NIST Cybersecurity Framework 2.0 provides a useful governance baseline for resilience and access-control discipline.

In practice, many teams discover this class of flaw only after a new execution model or wallet feature changes how their existing assumptions behave.

How the failure shows up in real contracts

The core issue is that tx.origin reflects the original transaction originator, while caller checks are often used to infer the immediate execution context. Neither is a reliable substitute for explicit authorization. A contract that uses tx.origin for access control may accidentally bless a call chain it did not intend to trust. A contract that branches on whether the caller is a contract may also misclassify behaviour once delegated execution becomes possible.

Typical failure patterns include:

• access control that allows a call because the original origin looked trusted, even though the immediate execution path is not;
• registration or onboarding logic that rejects or misroutes users because it assumed only one account type could reach the function;
• feature gating that depends on whether the caller “looks like” a contract, even though delegated execution makes that distinction unstable;
• security workflows that implicitly trust an origin rather than checking the specific authority, signature, or role that should matter.

The practical fix is to treat caller classification as an implementation detail, not a policy foundation. Contracts should express intent directly, such as explicit permissions, validated signatures, and role-based checks that survive changes in account behaviour. It is also important to review any code that special-cases EOAs, because those branches are often where upgrade-risk hides. For engineering teams that need a control baseline around secure design and verification, the NIST SP 800-53 Rev. 5 control catalogue is a relevant reference for access enforcement and system integrity. This guidance breaks down when a contract’s core design is already built around legacy origin-based trust and cannot be changed without redesign.

When the old EOA-versus-contract distinction stops being dependable

Tighter account abstraction and delegation support often improve user experience, but they also reduce the security value of caller-type heuristics. That tradeoff is unavoidable: the more flexible the execution model becomes, the less meaningful it is to infer trust from whether an account appears to be a contract at a given moment.

Where consensus is still evolving, the safest interpretation is to avoid using caller-type checks for any decision that affects authorization, asset movement, or privileged workflow selection. If the business logic merely uses the distinction for logging or non-security telemetry, the risk is lower, but teams should still expect the label to become unstable over time.

One common edge case is a contract that seems safe because it only uses tx.origin indirectly, for example through a helper or guard library. The risk is the same if the resulting decision still hinges on origin identity rather than explicit authority. Another edge case is a protocol that tries to block automated callers by rejecting contract accounts. That approach can fail both ways: it can exclude legitimate delegated wallets and still miss abusive flows that arrive through a trusted origin.

Risk and Threat Considerations

The material risk is authorization drift. Once caller behaviour can be delegated, any control that equates “originated by an EOA” with “safe to trust” becomes easier to bypass or misapply. The threat is not a new exploit primitive so much as a broken assumption that can be converted into unauthorized access, policy bypass, or failed defensive branching.

Failure mechanism: An attacker or abusive user routes execution through a path that satisfies tx.origin or caller-type logic without satisfying the intended security condition. Because the contract relies on a heuristic about account form rather than explicit authority, the control can make the wrong decision under delegated execution.

Impact: Sensitive functions may open to the wrong caller, legitimate users may be blocked, and downstream controls that depend on accurate caller classification may fail. In protocols that manage value, that can translate into unauthorized state changes, asset movement, or trust-boundary collapse.

Practitioner Guidance

What to prioritise: Treat every tx.origin check and every EOA-versus-contract branch as a high-priority review item. The first question is not whether the code “works” today, but whether the policy still means the same thing once delegated execution is possible.

What to verify: Verify that any privileged path is tied to an explicit authorization condition, not to account form. Check whether the contract’s real security decision depends on origin identity, immediate caller identity, or a role that should be represented directly in the code.

Common mistake: Teams often replace one heuristic with another, such as swapping tx.origin for a simple caller-type test, without changing the underlying trust model. That preserves the bug in a different shape.

Practitioner takeaway: If a branch or permission rule cannot be defended without saying “because this caller looks like an EOA,” it is probably relying on the wrong security primitive.

Related resources from NHI Mgmt Group

• Why do supplier risk programmes fail when they rely on onboarding checks alone?
• Why do weak identity checks increase fraud risk in digital onboarding?
• Why do same-origin mock or preview features increase security risk?
• What breaks when security teams rely on package version checks alone for dependency risk decisions?