Skip to content

Add authorization status to EIP7702 authorizations in transaction receipt #640

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

yongqjn
Copy link

@yongqjn yongqjn commented Mar 21, 2025

Currently, to determine the results of both the transaction and delegation requires multiple RPC calls, which is a suboptimal experience.

We propose a change to the current getTransactionReceipt, to add a list of authorization statuses, so that we are able to determine both results in 1 RPC call.

@ChanHongMing
Copy link

Supporting this PR!! Able to determine which authorization succeed helps both developer and wallet user learn about their transaction status. Deducing authorization result through state changes of the transaction are less intuitive.

Copy link
Member

@lightclient lightclient left a comment

Choose a reason for hiding this comment

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

Generally onboard with this. I think it can be computed on-the-fly by clients relatively easily. Felix made a good point on ACD that it requires the authorizer's nonce at the time of the transaction so not possible to compute on the fly without an archive node.

Comment on lines +122 to +127
authorizationStatus:
title: list of authorizations' status
description: Ordered list of authorizations' status. List contains either 1 (success) or 0 (failure) for each authorization in the transaction
type: array
items:
$ref: '#/components/schemas/uint'
Copy link
Member

Choose a reason for hiding this comment

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

what do you think about returning the list of addresses that were set on behalf of the delegation (null for failure maybe?)

Copy link
Author

Choose a reason for hiding this comment

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

just to ensure we are on the same page, you are suggesting to return the list of signing accounts in the authorization list, and not the delegation right?

we are agreeable on the former, this would also work for us

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

Successfully merging this pull request may close these issues.

4 participants