EIP-7702 Delegation Checker

A transaction type (0x04) that lets an EOA install code on itself by signing a small authorization tuple: [chain_id, address, nonce, y_parity, r, s]. Once processed, your account's code field is set to the 23-byte value 0xef0100 || delegate_address. When anyone calls your account after that, the EVM follows that pointer and runs the delegate's code inside your account — your storage, your balance, your nonce. This is what enables gas sponsorship, batched transactions, and passkey wallets, and it's also the mechanism behind a new class of phishing sweepers.

It's the delegation indicator — the fixed 3-byte prefix that identifies a code field as an EIP-7702 delegation rather than a normal deployed contract. 0xef is the specific opcode banned by EIP-3541 (contracts can't start with 0xef through normal deployment), so the presence of that first byte is an unambiguous signal that the code was installed via a set-code transaction. 0x0100 is a version identifier. The remaining 20 bytes after the prefix are the delegate contract's address.

The user signs a hash: keccak256(0x05 ++ rlp([chain_id, address, nonce])). The 0x05 byte is a domain separator — it guarantees this signature can't be replayed as any other kind of Ethereum message. A sponsor then submits a type-0x04 transaction containing that signature, and if it's valid the network writes 0xef0100 || delegate_address into the signer's code field. The delegation persists across transactions until the account owner signs a new authorization replacing it.

The chain_id field in an authorization tuple can be set to 0, which means 'valid on every EVM chain.' This is legitimately useful for wallets that want to upgrade across all chains with one signature. But it's the mechanism behind cross-chain replay attacks: a victim signs a chainId=0 tuple thinking it applies to one chain, and an attacker replays the same tuple on other chains where the signer has the same address (same nonce assumption), installing the malicious delegation everywhere at once. If a dApp asks you to sign a chainId=0 authorization, treat it with the same suspicion you'd give an unlimited token approval.

Sign a new authorization tuple with the delegate address set to the zero address (0x0000000000000000000000000000000000000000). When that transaction is included, the delegation indicator is cleared and your account returns to plain EOA state — code field back to empty. Some wallets expose this as a 'reset' or 'remove smart account' option. Verify it worked by pasting your address here again after the reset transaction confirms.

CrimeEnjoyor is the informal name given to a family of minimal sweeper contracts that early phishing operations delegated victim EOAs to. The pattern was simple and identical across variants: a tiny bytecode that, when called, forwards all ETH and token balances to an attacker-controlled address. Because delegation is persistent, once a victim signed the authorization, every subsequent transaction to their account — including automated retries from wallet software — routed funds to the attacker. Multiple security firms tracked these variants in the first months after Pectra shipped, and estimates at the time suggested a large majority of early delegations pointed at addresses in this family.

This is a subtle but important detail from the EIP. When another contract inspects your delegated account with EXTCODESIZE, it sees the size of the delegation indicator (23 bytes) — not the size of the delegate's actual code. But when your account's code runs (because someone called it), the CODESIZE opcode inside that execution returns the delegate's full code size. The asymmetry lets contracts detect that an address is a 7702-delegated EOA rather than a regular contract, without breaking the code-runs-with-the-account model. Some contracts use this to gate behavior on whether the caller is a plain EOA.

Yes. Delegation state is per-chain (unless the original signature used chainId=0). Your Ethereum mainnet EOA can be delegated to one contract, your same address on Base delegated to a different one, and your Arbitrum address undelegated. This tool currently checks Ethereum mainnet; multi-chain support is on the roadmap for a later phase.

Yes. The tool only does read operations — it calls getCode on an RPC endpoint, which is a public query that anyone can make against any address. No signature is ever requested, no wallet connection is needed, and no address is stored server-side. You're not authorizing anything by using this.

The known-delegates list is curated and finite. When your delegate isn't in either the whitelist or the blocklist, the tool tells you honestly that it can't classify it. That's a signal to look up the delegate address on Etherscan, check whether the contract is verified, whether it's been publicly audited, and whether the wallet vendor you use has published it as their implementation. False confidence would be more dangerous than 'unknown.'