Delegatecall

How delegatecall works in the EVM

Delegatecall is a low-level execution primitive, not a normal function call. It loads another contract’s code, but the caller’s storage, balance, and execution context remain in place, which means the calling contract keeps control of state changes and access checks.

This makes delegatecall powerful for proxy patterns, modular upgrades, and shared libraries. It also makes the boundary between “who owns the code” and “whose state is modified” easy to blur, especially when contract addresses, calldata, or upgrade targets are not tightly controlled.

Why delegatecall is security-sensitive

The security importance of delegatecall comes from context confusion. If the wrong code is executed, the callee can write to the caller’s storage layout, alter ownership or role flags, and redirect privileged logic without ever becoming the direct owner of the contract.

That is why delegatecall sits at the center of many smart-contract trust failures: the code may be externally supplied, but the consequences land inside the caller. In practice, the risk is not just “bad code,” but incorrect assumptions about where authority, storage, and upgrade control actually reside.

Common failure modes and abuse paths

Delegatecall fails when a contract points to an unexpected implementation, when storage layouts do not match, or when upgrade hooks can be redirected to malicious code. A mistake in target selection can convert a routine upgrade into a full state compromise.

Attackers and exploit developers often look for paths where delegatecall is combined with weak input validation, unsafe upgrade authority, or poorly constrained plugin-style execution. Even without direct control of the callee, they may still gain influence by steering the caller toward dangerous logic.

For readers looking at broader control and authorization implications in crypto systems, NHIMG’s Crypto Exchange Identity and Key Security Guide covers the signing and verification discipline that helps prevent unsafe state-changing actions.

How to assess and contain delegatecall risk

Safe use of delegatecall depends on strict target governance: the implementation address should be controlled, reviewable, and hard to swap without explicit authorization. The callee’s expected storage layout must stay aligned with the caller’s layout across every upgrade path.

Organisations reviewing contracts should trace where delegatecall is used, verify who can change the target, and inspect whether privileged functions can be reached through delegated execution. That review should include upgradeability mechanisms, fallback paths, and any code path that treats external addresses as trusted execution destinations.

Security teams should also treat delegatecall as a state-integrity control point. When it is present, the contract design should assume that code execution and data ownership are separable, and that both need independent protection.

Risk and Threat Considerations

Delegatecall creates a high-impact trust boundary because the caller executes foreign code inside its own state context. A single bad implementation pointer, compromised upgrade path, or storage mismatch can turn an otherwise valid contract into an access-control and state-integrity failure.

Failure mechanism: An attacker or faulty upgrade path causes delegated code to run with the caller’s storage and authority assumptions, enabling unauthorized writes, privilege changes, or irreversible state corruption.

Impact: Funds, ownership, and privileged contract behaviour can be redirected without changing the caller’s apparent identity or external interface, making detection and recovery harder after the fact.