Skip to content
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.

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

Update EIP-7702: Add tx_origin field to authority #8763

Closed
wants to merge 2 commits into from

Conversation

jochem-brouwer
Copy link
Member

No description provided.

@eth-bot
Copy link
Collaborator

eth-bot commented Jul 26, 2024

File EIPS/eip-7702.md

Requires 1 more reviewers from @adietrichs, @lightclient, @SamWilsn, @vbuterin

@eth-bot eth-bot added the a-review Waiting on author to review label Jul 26, 2024
@eth-bot eth-bot changed the title EIP-7702: Add tx_origin field to authority Update EIP-7702: Add tx_origin field to authority Jul 26, 2024
EIPS/eip-7702.md Outdated Show resolved Hide resolved
Copy link
Contributor

@g11tech g11tech left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for this small but potentially very important security feature

@@ -121,6 +122,10 @@ An alternative to adding chain ID could be to sign over the code the address poi

Unlike previous versions of this EIP and EIPs similar, the delegation designation can be revoked at anytime signing and sending a EIP-7702 authorization to a new target with the account's current nonce. Without such action, a delegation will remain valid in perpetuity.

### Explicit `tx.origin` signing

A signer might desire that only a specific EOA account sends the EIP-7702 transaction. If this is the case, the signer should set the `tx_origin` field of the authority list to that address. If any EOA account is allowed to send the authority transaction, the `tx_origin` field should be set to `null` (empty bytes). Note that without `tx.origin`, once a EIP-7702 transaction enters the transaction pool, this delegation authority is now immediately available to all accounts, and could thus lead to undesired or unwanted results such as being frontrun by MEV.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This either requires a trusted party to relay or self-relay. I don't support protocol features that are only useful if you trust a third party. If you need to self-relay, just gate initialization of your contract with ORIGIN.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if i understand your comment correctly, this is not a security feature for the wallet provider (their gated contract), but for the user doing the delegation.

The basic security principal is keep the attack surface minimal, and this is what this does. it only allows trusted wallet provider/party to use the authorization to prevent timing/reuse attacks (of a tx that couldn't make to block but is in mempool or failed)

This anyway doesn't hinder someone to sign a public authorization by allowing origin to be null.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a-review Waiting on author to review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants