EIP-7702 Delegation

Overview

The EIP-7702 delegation detector identifies vulnerabilities in contracts designed to be delegation targets under EIP-7702. This EIP allows externally owned accounts (EOAs) to temporarily delegate their execution to a smart contract implementation within a single transaction. Delegation targets must handle the unique security constraints: the address(this) during delegation is the EOA, storage is the EOA’s storage, and the delegator can change targets at any time.

Why This Is an Issue

EIP-7702 delegation introduces risks absent from standard contracts:

• Storage conflicts: The delegation target’s storage layout must not conflict with previous delegations or direct EOA state.
• Re-delegation attacks: An attacker can delegate to a malicious contract after the victim has set up state under a legitimate delegation.
• Initialization race: Multiple delegation targets may compete to initialize the same storage slots.
• msg.sender confusion: During delegation, msg.sender and tx.origin behave differently than in standard EOA transactions.

How to Resolve

// Before: No delegation-specific protections
contract DelegationTarget {
    address public owner;

    function initialize(address _owner) external {
        require(owner == address(0), "Already initialized");
        owner = _owner;
    }
}

// After: EIP-7702 aware implementation
contract SafeDelegationTarget {
    // Use EIP-7201 namespaced storage to avoid conflicts
    bytes32 constant STORAGE_SLOT = keccak256("SafeDelegationTarget.storage");

    struct Storage {
        address owner;
        bool initialized;
    }

    function initialize() external {
        Storage storage s = _getStorage();
        require(!s.initialized, "Already initialized");
        require(msg.sender == address(this), "Only self-delegate");
        s.owner = msg.sender;
        s.initialized = true;
    }

    function _getStorage() private pure returns (Storage storage s) {
        bytes32 slot = STORAGE_SLOT;
        assembly { s.slot := slot }
    }
}

Examples

Sample Sigvex Output

{
  "detector_id": "eip7702-delegation",
  "severity": "high",
  "confidence": 0.65,
  "description": "Delegation target uses sequential storage layout (slots 0-3) without EIP-7201 namespacing. Re-delegation to a different target will corrupt stored owner and configuration values.",
  "location": { "function": "initialize(address)", "offset": 0 }
}

Detection Methodology

1. Delegation target identification: Detects contracts intended as EIP-7702 targets by analyzing initialization patterns and address(this) usage.
2. Storage layout analysis: Checks whether the contract uses namespaced storage (EIP-7201) or sequential slots vulnerable to collision.
3. Self-call validation: Verifies that privileged operations check msg.sender == address(this) for delegation context.
4. Re-delegation resilience: Checks whether state can survive re-delegation to a different target.

Limitations

• EIP-7702 is recent and implementation patterns are still evolving. Some legitimate designs may be flagged.
• Cross-delegation state analysis (what happens when target A’s state is interpreted by target B) requires knowledge of both targets.

Related Detectors

• Account Abstraction — ERC-4337 smart account issues
• ERC-6900 Modular Account — modular account vulnerabilities
• Storage Collision — storage slot collisions

References

• EIP-7702: Set EOA Account Code
• EIP-7201: Namespaced Storage Layout