Summary: EIP-3074 is the important dead-end on Ethereum’s delegation path. It let an EOA authorize an invoker with AUTH, then let that invoker act as the EOA with AUTHCALL. The point now is not revival odds; it is understanding why Ethereum kept the delegated-execution ambition but moved away from this trust shape in eip-7702.
What it does:
Introduces an AUTH opcode that validates an ECDSA signature and sets a frame-scoped authorized context variable
Introduces an AUTHCALL opcode that makes downstream calls with CALLER set to the authorized EOA
Lets EOAs delegate execution authority to invoker contracts for batching, sponsorship, and other higher-level wallet logic
Makes sponsored transactions a first-class motivating use case by separating fee payer from action originator without introducing a whole new signed transaction type
Leaves replay protection and many higher-order safety properties to invoker-contract logic rather than fully baking them into protocol validity rules
Was ultimately withdrawn and marked as superseded by EIP-7702, which is itself a useful signal about the design tradeoffs the ecosystem rejected
Key claims:
The EIP abstract says AUTH and AUTHCALL together let a smart contract send calls as an EOA, which is the clearest evidence that 3074 belongs in the corpus as a delegation-semantics primitive rather than a wallet product
The motivation explicitly frames the proposal around adding batching, sponsorship, scripting, and smart-wallet-like behavior to EOAs without deploying a contract per user
The specification says the signed message binds authority to an invoker contract and commit value, showing that invokers — not the protocol alone — would become the practical trust boundary for delegated behavior
The rationale says replay protection was moved out of protocol storage and into invoker contracts, which is a crucial centralization and trust clue: users must trust invokers to enforce the safety properties they care about
AUTHCALL changes CALLER while spending value from the authorized account, meaning the design was not just a meta-transaction wrapper but an EVM-level authority-masquerading primitive
The rationale emphasizes compatibility with account abstraction and argues this opcode approach is less intrusive than introducing a new transaction type, which helps explain why 3074 mattered so much in account-abstraction debates even though it was later withdrawn
The canonical EIP page now marks the proposal as withdrawn and says it was superseded by EIP-7702, making 3074 especially useful as a comparison point for what 7702 inherited and what it deliberately changed
Whitepaper: No standalone EIP-3074 whitepaper or litepaper surfaced in this pass. The clearest sources were the canonical EIP page and raw spec text collected in ../../whitepapers/eip-3074-primary-sources-2026-05-07.md.