EIP-7702-Delegierungs-Decoder

What an EIP-7702 authorization does

EIP-7702, activated on Ethereum mainnet with the Pectra upgrade, lets an ordinary account — one controlled by a private key — run a contract's code. The account's owner signs an authorization: the tuple [chain_id, address, nonce], prefixed with the byte 0x05, hashed with Keccak-256 and signed with the account's secp256k1 key. Anyone can then include that signed tuple in a type-4 "set code" transaction. When it is processed, the account's code becomes the delegation designator 0xef0100 ‖ address, and from then on every call to the account runs the delegate contract's code with the account's balance and storage.

That is what makes smart-wallet features — batched calls, sponsored gas, session keys — possible without moving funds to a new address. It is also why a single signature can empty a wallet: the delegate has full control of the account, and wallet drainers ask for exactly this signature.

What you can paste

The decoder recognises its input by shape:

• a type-4 transaction, raw (0x04…) or as an eth_getTransactionByHash object — every authorization in its list is analysed, with the transaction's sender and chain;
• authorization tuples on their own, as JSON (the way viem, ethers and RPC nodes write them) or RLP;
• the authorization message a wallet asks you to sign, 0x05 ‖ rlp([chain_id, address, nonce]), with the hash that would be signed;
• an account's code as eth_getCode returns it: empty (not delegated), a designator (delegated, and to whom) or ordinary contract code (a contract account, which cannot delegate).

Whether clients apply an authorization

A client processes the authorization list in order and skips — without failing the transaction — every tuple that breaks a rule. The decoder applies the rules that need no chain state: the chain id must be 0 or the chain's own id; the nonce must be below 2⁶⁴ − 1; the signature must recover a signer, with s in the lower half of the curve order and a parity of 0 or 1. Encodings outside the bounds the EIP lists (an address that is not 20 bytes, an integer wider than its field or with leading zeros) are worse: they invalidate the whole transaction.

Two rules depend on the signer's account: its nonce must equal the tuple's, and its code must be empty or already a delegation. When the transaction's sender signs its own authorization, the sender's nonce is incremented before the list is processed, so the tuple needs the transaction nonce plus one — a classic mistake the decoder points out. When several tuples come from one signer, the last valid one wins; earlier ones are marked as overridden. A tuple whose address is the zero address removes the delegation and clears the account's code.

Known, verified and malicious delegates

Each delegate address is compared with a list of contracts seen on mainnet, checked on the date shown in the list: documented deployments that the vendor lists in its own documentation (MetaMask's Delegation Framework, Coinbase's EIP-7702 proxy, Uniswap's Calibur, Biconomy's Nexus), contracts verified on a block explorer under a wallet's name but not documented by a vendor, and malicious ones whose verified source states their purpose — sweepers such as CrimeEnjoyor, which forward every incoming coin to an attacker. An account delegated to a sweeper has a leaked private key; sending funds to it gives them away.

A delegate that is not in the list is reported as unknown, not as malicious: make sure your wallet itself proposed it. Loading a delegate's code compares the Keccak-256 hash of its runtime code with the known contracts, which recognises a copy of a known contract deployed at another address. The EIP-155-style replay protection does not apply to a tuple with chain id 0: it is valid on every EVM chain where the account's nonce matches, so the decoder flags it.

What runs locally, and what is sent

Decoding, signer recovery and every offline rule run in your browser. Three optional lookups use a public JSON-RPC node of the network you choose, or your own RPC URL, and only when you press their button: the nonce and code of the signers and the sender (eth_getTransactionCount, eth_getCode), which decide whether each authorization applies; a delegate's code, for clone detection; and an account's current delegation. Only those addresses are sent, never the input you pasted; your own RPC URL stays on the page and is never put into share links.

The decoder does not run the delegate's code, so it cannot tell whether a documented wallet contract is initialised safely after delegation. To read the whole set-code transaction — fees, calldata, risks — open it in the Ethereum transaction decoder. Signatures a delegated account makes are checked with ERC-1271 by the Ethereum signature verifier.