EIP-5003 primary sources — 2026-05-14

Project status in this pass

  • EIP-5003 is marked Withdrawn.
  • The canonical withdrawal reason says it was superseded by EIP-7702.
  • No standalone whitepaper or litepaper surfaced during this pass.

Primary-source snapshots

1) Official EIP / abstract and withdrawal status

  • URL: https://eips.ethereum.org/EIPS/eip-5003
  • Key excerpt/signals:
    • The EIP introduces AUTHUSURP, which deploys code at an EIP-3074-authorized address.
    • The abstract says that for EOAs, together with EIP-3607, this effectively revokes the original signing key’s authority.
    • The canonical page marks the proposal as withdrawn and says it was superseded by EIP-7702.
  • Why it mattered:
    • This is the cleanest evidence that EIP-5003 belongs in the corpus as a historical EOA-migration primitive and a comparison point for the eventual 7702 design.

2) Official motivation / why 3074 was insufficient

  • URLs:
  • Key excerpt/signals:
    • The motivation lists the familiar smart-account benefits existing EOAs lack: key rotation, batching, sponsored transactions, social recovery, and delegated capabilities.
    • It explicitly says EIP-3074 can delegate authority to additional actors but cannot revoke the original key.
    • It frames the proposal as a migration path off EOAs for today’s installed user base rather than a way to preserve EOAs forever.
  • Why it mattered:
    • This makes EIP-5003 much more analytically useful than a bare opcode draft: it is the clearest expression of the final revocation problem in the 3074-era account-abstraction debate.

3) Raw spec / AUTHUSURP behavior

  • URL: https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-5003.md
  • Key excerpt/signals:
    • AUTHUSURP behaves like CREATE, but deploys code into the already-authorized address.
    • It deliberately does not check the nonce of the authorized account, so previously used EOAs can still be upgraded.
    • It reverts on zero-length returned code and checks for pre-existing code immediately before deployment.
  • Why it mattered:
    • These details reveal the real design tradeoff: in-place EOA upgradeability was prioritized over normal deployment assumptions, and the one-way nature of the migration had to be defended explicitly.

4) Security considerations / lingering ECDSA trust surface

  • URL: https://eips.ethereum.org/EIPS/eip-5003
  • Key excerpt/signals:
    • The security section warns that contracts using ECDSA signatures outside transaction validation will not automatically know the account has been usurped.
    • permit is named as a concrete example where the old private key could still retain power.
    • The text says this should be mitigated by changing the ecrecover precompile.
  • Why it mattered:
    • This is the strongest signal that EIP-5003’s hardest problem was not only deployment mechanics but compatibility with Ethereum’s broader offchain-signature ecosystem.

5) Discussion context

  • URL: https://ethereum-magicians.org/t/eip-5003-auth-usurp-publishing-code-at-an-eoa-address/8979
  • Key excerpt/signals:
    • The canonical EIP points to this thread as the main discussion venue.
    • Even though rich thread extraction was limited in this pass, the discussion link confirms the proposal’s place in the 3074-era account-upgrade debate rather than as a later 7702-specific artifact.
  • Why it mattered:
    • It anchors EIP-5003 in the historical argument over whether EOAs should be migrated by opcode-level delegation plus revocation or by another mechanism.

Working conclusion

EIP-5003 is best cataloged as the revocation-focused companion to EIP-3074 and a key withdrawn precursor to EIP-7702. The decisive evidence in this pass was its in-place code deployment at an authorized EOA, its explicit goal of revoking the original ECDSA key, its no-nonce-check migration semantics for already-used accounts, and its unresolved compatibility hazards for off-transaction ECDSA-based systems like permit.