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.
- The EIP introduces
- 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 revocationproblem in the 3074-era account-abstraction debate.
- This makes EIP-5003 much more analytically useful than a bare opcode draft: it is the clearest expression of the
3) Raw spec / AUTHUSURP behavior
- URL: https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-5003.md
- Key excerpt/signals:
AUTHUSURPbehaves likeCREATE, 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.
permitis named as a concrete example where the old private key could still retain power.- The text says this should be mitigated by changing the
ecrecoverprecompile.
- 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.