fluidkey
Attribute: Prevent or warn against dapp-specified 7702 delegation requests
Part of our work on EIP-7702.
7702 allows for EOAs to delegate their authority to a smart contract. Wallets that use EIP-7702 would typically ask the user to sign a transaction to set this delegation address as part of user onboarding.
~Dapps can also request transactions, including ones that update the delegation address of the EOA.~ EDIT: no they cannot, but they can initiate atomic batch transactions which can cause the wallet to initiate a delegation. Need to determine how to rate whether wallets correctly inform the user about what is going on in this case.
This discussion on X shows a user initiating a transaction batch on a not-yet-7702-delegated EOA, causing the wallet to create a delegation to the wallet's own delegator contract. This is arguably OK or not OK, not sure how to rate this case. Maybe it's a matter of how confusing the wallet UX is in this scenario.
Dapps can't request such a transaction from a wallet, there isn't an rpc method to do so.
I think it's worth noting if dapps can trigger a delegation (as in the metamask case) - that leverages the "atomic: ready" status in eip5792 which was included for this purpose (but it doesn't give the dapp a way to specify the delegation contract)
@azf20 Thanks, makes sense. I'm already adding tracking for whether wallet specify atomic as ready or supported in #229, but I hadn't made the distinction between the two values. I'll extend this to be able to indicate whether the wallet has a way to delegate + execute in a single UX flow (in which it would presumably use atomic: "ready").
Still not clear what the bar should be for such a UX flow though...
Nice sounds good.
When you say the bar for the UX, you mean in terms of how clear and legible the upgrade experience is for the user? Metamask has a specific "do you want to use a smart account" step, while I think Ambire just assumes you want to use their smart account (for example).
I think it's tricky because (I expect that) going forward for new users they'll probably be defaulted into a smart account (in the same way that smart account wallets work). But it's obviously potentially pretty confusing for existing wallet users.
When you say the bar for the UX, you mean in terms of how clear and legible the upgrade experience is for the user?
Yes.
I think it's tricky because (I expect that) going forward for new users they'll probably be defaulted into a smart account (in the same way that smart account wallets work). But it's obviously potentially pretty confusing for existing wallet users.
I think it depends whether the default for future users will be pure 4337 accounts, vs EOAs that are 7702-delegated on their first transaction. Different wallets may make different decisions on their approach here. If the latter, then there will technically always exist a delegation step that needs to be shown and approved by the user, even for new accounts.
The simplest thing would be for such accounts to have their 7702 delegation be done as part of onboarding, but I realize that forces the user to have money for gas right at account creation time, and they may feel like Ethereum is nickel-and-diming them just to create an account, which is not a great user experience either.
Maybe the criteria should be around the visual differences between a batch transaction that includes a delegation, vs the same batch transaction without a delegation involved. The delegation needs to be transparently disclosed on the UI, but should not reduce the legibility/understandability of the other transactions being approved alongside it, relative to their typical level of legibility when there is no delegation involved.
If the latter, then there will technically always exist a delegation step that needs to be shown and approved by the user, even for new accounts
I don't think this is true? If wallets have the private key, they can make the relevant signature without showing the user anything additional. I don't recall Ambire asking me anything specific about smart accounts, as they default to smart.
The simplest thing would be for such accounts to have their 7702 delegation be done as part of onboarding, but I realize that forces the user to have money for gas right at account creation time
This seems like a bad experience to me, vs. taking a "just in time" approach when you make your first transaction. An alternative would be for the wallet to sponsor the delegation transaction.
If wallets have the private key, they can make the relevant signature without showing the user anything additional. I don't recall Ambire asking me anything specific about smart accounts, as they default to smart.
I wonder how Ambire deals with the hardware wallet case; surely hardware wallets should be very loud about being asked to sign a 7702 delegation transaction. So the software wallet's transaction dialog would need to explain why it's sending such a request to the hardware wallet in order for that to all make sense to the user.
This seems like a bad experience to me, vs. taking a "just in time" approach when you make your first transaction. An alternative would be for the wallet to sponsor the delegation transaction.
Yeah, that would be good too
I wonder how Ambire deals with the hardware wallet case
I don't think it's live on the hardware wallet side yet, but it's in progress (see this tweet)