Summary: EIP-5003 is best understood as the missing revocation half of the older EIP-3074 account-delegation path, not as an isolated opcode curiosity. Its core move was to introduce AUTHUSURP, an opcode that could deploy code directly at a 3074-authorized EOA address so the account could become a contract account in place; when combined with EIP-3607, this would effectively revoke the original transaction-signing authority of the EOA key. The reusable mechanism insight is that EIP-5003 tried to turn delegation without migration into delegation plus one-way escape from ECDSA, which makes it a crucial comparison point for understanding why the ecosystem later chose EIP-7702 instead.
What it does:
Introduces an AUTHUSURP opcode that behaves like CREATE except it deploys code into an EIP-3074-authorized address
Lets an EOA transition into contract-style account logic at the same address instead of moving assets to a newly deployed smart account
Complements EIP-3074 by adding a way to revoke the lingering power of the original EOA key once code is installed
Avoids nonce checks on the target account so previously used EOAs can still be upgraded in place
Makes key rotation, social recovery, batching, sponsored transactions, and richer authorization policy available to legacy EOAs via contract-account behavior
Exposes edge cases around off-transaction ECDSA assumptions because contracts using ecrecover or permit-like flows may still treat the old private key as valid
Key claims:
The EIP abstract says AUTHUSURP deploys code at a 3074-authorized address and, together with EIP-3607, effectively revokes the original signing key’s authority, which is the clearest reason to catalog it as an EOA-exit primitive rather than generic account abstraction rhetoric
The motivation explicitly says 3074 adds delegated power but cannot revoke the original key, making 5003 analytically useful as the design that tried to close that security hole
The proposal is aimed at existing EOA holders who cannot cheaply migrate every asset or ownership reference to a fresh smart-account address, which makes it a direct response to Ethereum’s installed-base migration problem
The specification says AUTHUSURP does not check the target nonce and runs initcode at the authorized address, which shows how aggressively the proposal prioritized in-place upgradeability over traditional deployment safety assumptions
The rationale says zero-length deployment must fail because otherwise the account could be AUTHUSURPed repeatedly, making the one-way migration semantics more legible
The security section points out that contracts using ECDSA outside transaction validation would not automatically know the account had been usurped, with permit named as a concrete example; that caveat makes offchain-signature compatibility the real hidden control surface
The EIP is now marked withdrawn and superseded by EIP-7702, which is itself an important signal: Ethereum wanted an EOA-upgrade path, but not this exact opcode-and-revocation mechanism
Whitepaper: No standalone EIP-5003 whitepaper or litepaper surfaced in this pass. The clearest sources were the withdrawn EIP text and raw spec collected in ../../whitepapers/eip-5003-primary-sources-2026-05-14.md.