Standard / EIP·EVM
EIP-3074 — AUTH and AUTHCALL Opcodes (Withdrawn)
Withdrawn proposal that introduced two EVM opcodes (`AUTH` 0xf6 and `AUTHCALL` 0xf7) letting an EOA sign a commit that an 'invoker' contract could use to call other contracts on its behalf. Status: Withdrawn (Standards Track / Core) — superseded by ERC-7702, which was preferred by core devs because it does not require trusted invoker contracts and integrates with smart-account standards.
- 01historical reference / context for 7702
- 02understanding the invoker pattern
- 03research on EOA-delegation alternatives
- # No production tooling — proposal withdrawn. For EOA delegation use ERC-7702 (viem signAuthorization).
Do NOT build new systems on EIP-3074 — it was withdrawn in 2024 in favor of ERC-7702 and will not ship to mainnet. For historical context: 3074 added `AUTH` (which verified an ECDSA signature over `keccak256(MAGIC || chainId || nonce || invokerAddress || commit)` and set `authorized` in the call frame) and `AUTHCALL` (which made a call with `msg.sender == authorized`). Users had to trust an 'invoker' contract because a malicious invoker could drain the EOA. ERC-7702 replaces this model: the EOA itself sets a delegation pointer (transaction type 0x04) so the code IS the trusted contract — no separate invoker needed. If you encounter 3074 in a codebase, port to 7702 by replacing invoker calls with `signAuthorization` + a delegated implementation contract.
- ⚑WITHDRAWN — will not be activated on Ethereum mainnet. Any tutorial or library referencing AUTH/AUTHCALL is obsolete.
- ⚑The signed `commit` is a free-form 32-byte hash; invoker contracts that did not bind it tightly to (target, calldata, value, nonce) were trivially drainable. This is the design flaw that motivated 7702.
- ⚑Trusting an invoker is equivalent to a `setApprovalForAll`-style approval over the EOA's entire balance — a bug or upgrade in the invoker compromised every user.
- ⚑The MAGIC byte (0x04) and signature scheme differ from 7702 — do not copy-paste signing code between the two.