-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
Conversation
File
|
tx_origin
field to authoritytx_origin
field to authority
Co-authored-by: g11tech <[email protected]>
There was a problem hiding this 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. |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
No description provided.