status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-23 04:08:09 +00:00
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 3074 (#3413)

Browse Source 
Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft, Review, or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
lightclient 2021-03-18 14:07:05 -06:00 committed by GitHub
parent 07eb837030
commit b5a69c6233
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
EIPS/eip-3074.md
View File

@ -11,17 +11,17 @@ created: 2020-10-15
## Simple Summary
Creates two new EVM instructions that authorize (via an ECDSA signature) a contract to act on behalf of an externally owned account.
Allow externally owned accounts (EOAs) to delegate control of their account to a contract.
## Abstract
This EIP introduces two EVM instructions `AUTH` and `AUTHCALL`. The first sets a context variable `authorized` based on an ECDSA signature. The second sends a call as the `authorized`.
This EIP introduces two EVM instructions `AUTH` and `AUTHCALL`. The first sets a context variable `authorized` based on an ECDSA signature. The second sends a call as the `authorized`. This essentially delegates control of the EOA to smart contract.
## Motivation
Adding more functionlity to EOAs has been a long-standing feature request. The requests have spanned from implementing batching capabilities, allowing for gas sponsoring, expirations, scripting, and beyond. These changes often mean increased complexity and rigidity of the protocol. In some cases, it also means increased attack surfaces.
This EIP takes a different approach. Instead of enshrining these capabilities in the protocol as transaction validity requirements, it provides developers with a flexible framework for developing novel transaction schemes for EOAs. A good way to think about this is that this EIP allows any EOA to become a smart contract wallet *without* deploying a contract.
This EIP takes a different approach. Instead of enshrining these capabilities in the protocol as transaction validity requirements, it allows users to *delegate* control of their EOA to a contract. This gives developers a flexible framework for developing novel transaction schemes for EOAs. A good analogy for the benefit this EIP provides is that it's similar to allowing any EOA to become a smart contract wallet *without* deploying a contract.
Although this EIP provides great benefit to individual users, the leading motivation for this EIP is "sponsored transactions". This is where the fee for a transaction is provided by a different account than the one that originates the call.