Skip to content

Update EIP-5003: Move to Stagnant #10567

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+1 −2
Open

Update EIP-5003: Move to Stagnant #10567

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 1 addition & 2 deletions EIPS/eip-5003.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,12 +4,11 @@
description: Allow migrating away from ECDSA by deploying code in place of an externally owned account.
author: Dan Finlay (@danfinlay), Sam Wilson (@SamWilsn)
discussions-to: https://ethereum-magicians.org/t/eip-5003-auth-usurp-publishing-code-at-an-eoa-address/8979
status: Withdrawn
status: Stagnant
type: Standards Track
category: Core
created: 2022-03-26
requires: 3074, 3607
withdrawal-reason: Superseded by EIP-7702.
---

## Abstract
Expand All @@ -20,7 +19,7 @@

EOAs currently hold a significant amount of user-controlled value on Ethereum blockchains, but are limited by the protocol in a variety of critical ways. These accounts do not support rotating keys for security, batching to save gas, or sponsored transactions to reduce the need to hold ether yourself. There are countless other benefits that come from having a contract account or account abstraction, like choosing one's own authentication algorithm, setting spending limits, enabling social recovery, allowing key rotation, arbitrarily and transitively delegating capabilities, and just about anything else we can imagine.

New users have access to these benefits using smart contract wallets, and new contracts can adopt recent standards to enable app-layer account abstraction (like [EIP-4337](./eip-4337.md)), but these would neglect the vast majority of existing Ethereum users' accounts. These users exist today, and they also need a path to achieving their security goals.

Check warning on line 22 in EIPS/eip-5003.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC` 

warning[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC`
  --> EIPS/eip-5003.md
   |
22 | New users have access to these benefits using smart contract wallets, and new contracts can adopt recent standards to enable app-lay...
   |
   = help: see https://ethereum.github.io/eipw/markdown-refs/

Check warning on line 22 in EIPS/eip-5003.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

references to proposals with a `category` of `ERC` must use a prefix of `ERC` 

warning[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC`
  --> EIPS/eip-5003.md
   |
22 | New users have access to these benefits using smart contract wallets, and new contracts can adopt recent standards to enable app-lay...
   |
   = help: see https://ethereum.github.io/eipw/markdown-refs/

Those added benefits would mostly come along with EIP-3074 itself, but with one significant shortcoming: the original signing key has ultimate authority for the account. While an EOA could delegate its authority to some _additional_ contract, the key itself would linger, continuing to provide an attack vector, and a constantly horrifying question lingering: have I been leaked? In other words, EIP-3074 can only grant authority to additional actors, but never revoke it.

Expand Down Expand Up @@ -85,5 +84,5 @@

Contracts using ECDSA signatures outside of transactions will not be aware that the usurped account is no longer controlled by a private key. This means that, for example, the private key will _always_ have access to the `permit` function on token contracts. This can—and should—be mitigated by modifying the `ecrecover` pre-compiled contract.

## Copyright

Check failure on line 87 in EIPS/eip-5003.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Copyright"] 

EIPS/eip-5003.md:87 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Copyright"]

Check failure on line 87 in EIPS/eip-5003.md

View workflow job for this annotation

GitHub Actions / Markdown Linter

Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Copyright"] 

EIPS/eip-5003.md:87 MD022/blanks-around-headings/blanks-around-headers Headings should be surrounded by blank lines [Expected: 1; Actual: 0; Below] [Context: "## Copyright"]
Copyright and related rights waived via [CC0](../LICENSE.md).
Loading