EIP-3074 primary sources — 2026-05-07

Project status in this pass

• No standalone EIP-3074 whitepaper or litepaper surfaced.
• The clearest source of truth was the canonical EIP page plus the raw markdown in the Ethereum EIPs repository.
• The proposal is now withdrawn and explicitly marked as superseded by EIP-7702, but it remains analytically important as a predecessor to Ethereum’s current delegation path.

Primary-source snapshots

1) Canonical EIP page

• URL: https://eips.ethereum.org/EIPS/eip-3074
• Key excerpt/signals:
  • The page marks EIP-3074 as Withdrawn and gives the withdrawal reason as “Superseded by EIP-7702.”
  • The abstract says the proposal introduces AUTH and AUTHCALL, with the second sending a call as the authorized EOA.
  • The discussion link anchors the proposal in the long-running account-abstraction and sponsored-transaction debate rather than in a standalone wallet product context.
• Why it mattered:
  • This source establishes both the mechanism and the historical outcome: 3074 mattered enough to shape the path to 7702 even though it did not ship.

2) Raw EIP text / motivation

• URL: https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-3074.md
• Key excerpt/signals:
  • The motivation names batching, gas sponsoring, expirations, scripting, and smart-wallet-like behavior for EOAs as the problem space.
  • It says the approach is to let users delegate control of their EOA to a contract rather than enshrining all desired features as transaction-validity rules.
  • Sponsored transactions are named as the leading motivation.
• Why it mattered:
  • These passages show that 3074 is best understood as a minimal delegation substrate for EOA programmability, with sponsored transactions as the flagship use case.

3) Raw EIP text / mechanism details

• URL: https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-3074.md
• Key excerpt/signals:
  • AUTH verifies a signature over MAGIC || chainId || nonce || invokerAddress || commit and sets a frame-scoped authorized variable.
  • AUTHCALL then behaves like CALL except that the caller becomes the authorized EOA and value is spent from that account.
  • authorized is scoped to the execution frame and is not inherited through calls.
• Why it mattered:
  • This is the clearest evidence that 3074 is not just meta-transaction glue; it is an EVM-level authority-masquerading primitive whose trust model depends on the invoker contract.

4) Raw EIP text / trust boundary and replay protection

• URL: https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-3074.md
• Key excerpt/signals:
  • The rationale says replay protection was moved out of an earlier precompile-with-storage design and into invoker contracts.
  • The text explains that users sign for a specific invoker and commit value because they are expected to trust that invoker to validate committed conditions faithfully.
  • It explicitly frames AUTHCALL as the minimal change needed to enable sender abstraction while allowing more logic to live around it.
• Why it mattered:
  • This is the most important governance and centralization clue: the protocol would have provided the masquerading primitive, but practical safety and policy would have concentrated in trusted invokers.

5) Raw EIP text / transaction-type comparison

• URL: https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-3074.md
• Key excerpt/signals:
  • The rationale contrasts two broad approaches: introducing a new transaction type versus introducing a new EVM mechanism to masquerade as other accounts.
  • The text argues the opcode route is less intrusive and more compatible with account abstraction than sponsor-signed transaction types.
• Why it mattered:
  • This helps place 3074 in the account-abstraction design tree: it is a modular EVM primitive proposal, not merely a one-off sponsored-transaction scheme.

Working conclusion

EIP-3074 is best cataloged as a withdrawn but essential delegation precursor. It reveals an earlier Ethereum design choice: make EOAs programmable by authorizing trusted invoker contracts, then let later standards like EIP-7702 inherit the delegation intuition while changing where persistence, safety expectations, and wallet control ultimately sit.