DELEGATECALL is an Ethereum opcode that runs another contract’s code in the caller’s storage and execution context. The calling contract keeps its own state, address and sender context, which makes delegatecall the basis of proxy patterns but also a common source of storage collision and privilege confusion.
How delegatecall changes execution trust
delegatecall is powerful because it lets a contract reuse code without changing the caller’s storage, address, or sender context. That makes it central to proxy design, but it also means the caller is effectively trusting the callee to behave as if it were local code, which is a much stronger assumption than ordinary external calls.
In practical terms, the dangerous part is not the opcode itself, but the mismatch between code provenance and execution authority. A caller may appear to execute one contract while actually running logic that was deployed elsewhere, upgraded later, or reached through an unexpected routing path.
Storage Context and State Collision
Because delegatecall executes in the caller’s storage layout, both contracts must agree on variable ordering, slot usage, and upgrade compatibility. If they do not, the callee can overwrite the caller’s state in ways that are hard to spot during review and even harder to reverse after deployment.
This is why proxy patterns demand disciplined layout management. A safe proxy design treats storage slots as part of the contract interface, not an incidental implementation detail. When that discipline is missing, state corruption can look like a logic bug while actually being a trust-boundary failure.
Privilege Confusion and Control Flow Abuse
Delegatecall preserves the original sender context, which can create privilege confusion when the delegated code assumes it is operating with its own authority. An attacker who can influence the delegated implementation, the dispatch path, or the upgrade target may turn a convenience mechanism into an authorization bypass.
That risk is especially important in systems that mix governance, upgradeability, and funds control. A contract may believe it is validating actions against one identity or admin path, while the executed code inherits a different execution context and reaches privileged branches unexpectedly.
For broader identity and control-path implications, Crypto Exchange Identity and Key Security Guide is useful reading because it connects signing integrity, custody trust, and delegatecall abuse in operational crypto systems.
Why It Matters in Upgradeable Systems
Delegatecall is foundational to many upgradeable contract designs, so its safety depends on explicit governance over code changes, storage compatibility, and administrative routes. In that sense, the opcode is not just an implementation technique, it is a lifecycle and trust decision about who can change behavior after deployment.
Used carefully, it enables modularity and controlled upgrades. Used loosely, it can let a later implementation inherit the caller’s authority, preserve dangerous assumptions, and make a benign-looking upgrade path become a durable compromise path.
Risk and Threat Considerations
Delegatecall creates a high-impact failure mode because a trusted caller can end up executing untrusted or mismatched logic in its own state context. The result can be storage corruption, authorization bypass, or hidden takeover of upgradeable systems when the delegated implementation is altered or misrouted.
Failure mechanism: An attacker or faulty upgrade targets a delegatecall entry point, then exploits preserved sender context or storage overlap to change balances, ownership, or control flags without ever needing direct ownership of the caller contract.
Impact: The compromise can spread beyond a single function call, because the delegated code may write into persistent state, affect privileged execution paths, and undermine all contracts that rely on the same layout or dispatch pattern.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Delegatecall can expand effective authority beyond the expected code path. |
| Recommendation — Restrict delegated execution paths to the minimum authority needed for the contract's function. | ||
| OWASP ASVS | V8 — Authorization | Delegatecall can alter which logic decides access and privilege outcomes. |
| Recommendation — Verify that delegated logic cannot bypass the intended authorization checks. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Proxy-style delegatecall depends on controlled, consistent deployment configuration. |
| Recommendation — Harden deployment and upgrade configuration to prevent unsafe contract routing and state collisions. | ||
| MITRE ATT&CK | T1068 — Exploitation for Privilege Escalation | A delegated execution context can be abused to gain higher effective privileges. |
| Recommendation — Map suspicious delegatecall abuse to privilege-escalation detection and review affected execution paths. | ||
Practitioner Guidance
Why practitioners should care: Delegatecall is one of the few EVM mechanisms where code reuse and privilege reuse are tightly coupled. That makes it a design choice that should be reviewed with the same care as an authorization boundary, not just as a gas-saving optimization.
What to watch for: Pay close attention to storage layout drift, upgrade hooks, admin-controlled implementation pointers, and any delegated logic that assumes it owns the caller’s state or authority. Those are the conditions where confusion turns into exploitability.
Practitioner takeaway: Treat delegatecall paths as trust-sensitive execution boundaries, and verify both code provenance and storage compatibility before relying on them in production.
Related resources from NHI Mgmt Group
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 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org