AllWalletDevs #32

Transcript

I guess now that you're here, we can uh get started with uh all wallet devs number 32. Um today's mostly going to be dedicated to an update on EIP5792. Um and with that, I will turn it over to Lucas. Um cool. Yeah. So, uh I'm not sure how, uh how up to date people are, so I'll just kind of give an overall update from the last two weeks. Um so if you don't know uh 5792 is the um the EIP which introduces a few new RPC methods. Uh the main one is wallet send calls and it's kind of like you can think of it as a replacement for ETH

send transaction for wallets. Um, it allows for things like uh batching calls together natively and then also exposes these things called capabilities which are just um kind of like open-ended additional features that some wallets may support. So for example like 4337 pay masters uh so apps can sponsor their users transactions. Um and we've been at this uh like kind of trying to define this back and get adoption for like over a year now I think. Um and yeah, we started running these like calls over the last three weeks to just run down open discussions. Um and with 7702 uh starting to come onto uh mainets and

uh you know we we'll kind of be uh on most chains in the next couple months. uh we figured like other wallets started to feel that it was really time to drive down these open questions and uh start building more support and adoption. Um so we started doing these calls on Fridays uh to run down the open questions. The big ones being one uh how do wallets express the types of atomicity guarantees that they support? Um so for example some wallets uh might already be um like smart contract accounts. Uh so they can support like native um native

atomic batching where you submit multiple calls and you can have guarantees that uh all calls will land on chain uh versus other wallets like EOAs that want to support wallet send calls uh but cannot offer the same atomicity guarantees. Um that open question kind of has implications on how one would build an app using the RPC, right? Because uh you know this the example that we always use is like an approve and swap um if you have the atmosity guarantee either the improve and either the approve and swap are both going to go through or neither are going to go through. But if uh you submit the the batch of calls to an EOA

um maybe the approved goes through uh and then like what should your app do right? Um so that was the first kind of big question that we needed to align on and we landed on uh supporting uh a capability. So wallets will uh another part of 5792 is this wallet get capabilities RPC where you can see the kind of features that wallets support. And the way we've resolved the um the atomicity discussion is there's going to be an atomic capability and there's three values. There's supported ready and unsupported.

Supported means that the wallet is currently able to um execute multiple calls atomically. So this would be like a 4337 account. Um ready means that the wallet is able to suggest an upgrade to the user via 7702 or some other mechanism uh but the user has not yet gone through that uh that upgrade. And in this case um if a wallet if an app sends a batch of calls and an app can now specify that they the calls must be at uh executed atomically or they can say that they're okay with them being executed sequentially so that you know the app can support EOAs for example. So

if the um wallet is ready to upgrade and the app specifies that the calls must be executed atomically, the wallet must uh take the user through the upgrade process that it's able to before executing the the batch of calls. And then unsupported is just like your your typical EOA that is not yet um upgrading users via 7702 or some other mechanism. Um so in this case um you know there's like a specific error code if an app specifies calls have to be submitted atomically uh but the wallet does not support atomic execution in any way. Um so yeah that that's kind of how we've

resolved uh the atomicity discussion. I know I kind of just said a lot and you if you haven't been up to date on 5792 that might be a lot of information. So I would encourage you to to go through the updated spec. And um the other big thing was error codes. I think in general we just wanted to make sure we did a good job on documenting the types of errors uh that would arise from uh using the new RPCs. Uh so last week we merged APR um with error codes uh specific to 5792 and reusing some uh from like 1193 for example.

Um so yeah know that now that those two discussions have been resolved uh we are looking to move the spec to uh last call. The last call date is going to be May 5th and I'm going to put up the PR actually today um to change the status and um yeah it's been a a long a long journey but yeah super excited that uh we were able to kind of get I think a a good amount of alignment here and yeah excited that um a lot of people in the industry a lot of wallets apps and dev tools are like looking to support the the updated spec.

Great. Thanks for the update. Um, are there any events defined in 5792 like um the 1193's like account changed or um uh No, there are not no events. Okay. Should should there be like one for when an upgrade happens or I don't really think it's necessary. I I I guess I I couldn't have I couldn't think of any when you brought that up. The only thing that maybe could be an event is like the upgrade. Um but yeah, I I don't think an app really needs to like listen for that because the upgrade only really matters in the context of the the wallet send calls request.

Either the upgrade's going to happen and the the user is going to execute the calls or not or the upgrade doesn't happen and you know they get an error code back for that. up. Cool. Yeah, that makes a lot of sense. Um, so I think we have a couple wallets here. I'm not sure if y'all are part of the 5792 Telegram chat. Um, but, uh, who here has actually looked at 5792 and is planning on supporting it or not planning on supporting it?

Either way, So I mean I can speak um we're no longer like actively maintaining candidate wallet but we did support the standard uh uh when it very first like launched uh two years ago I think in candidate wallet mobile app. Um we could upate update it to have it as a reference implementation uh for others since our wallet is open source and also like helping out wallets to um from our side like helping other wallets to add the standard um we have been having good feedback because now since metam mask is is um is implementing it and then there's others

who are also encouraged uh to also implement it. Cool. Thank you. On the 4337 side, um does this look like an acceptable API? Um yes, I um so just recently like the the error messages like I saw that it's a big list. I'm just worried a bit that it would be too much uh for wallet developers to implement but if it's um but just a concern uh yeah just a small

concern. Great. Well, that sounds like um all the discussion on 5792. Um is there anything else anybody would like to talk about today? Have a little free form discussion. Um since we mentioned the capabilities the pay master capabilities um so there's this other standard it's 7 um let me check the number 7677 um so it's around the pay master web service capabilities which is an extension of 5792 it's only missing it's um it missing like the the way uh apps communicate if they want to use a token

pay master because there's no differentiation today between a completely gas sponsorship and um using a token to pay to pay gas if the app wants to communicate its own let's say suggested token um and the wallet in that sense like don't know which one is which even if it includes like token in in the capability like section uh so they don't know what what to display in the UI because they cannot differentiate between uh both. So I think there's missing uh standardization around that part. Um I believe it was part of the discussion initially but I wanted to maybe

uh reinitiate it again and then um I'll propose it like maybe in the discussion of the forum. Yeah. Um, so that's uh we uh we kind of put that capability out at the at the same time that we started updating 5792. And um just as kind of some context like my goal has been driving down the unknowns on 5792. So all the like other capabilities that we've proposed um have kind of been put on the back burner, 767 included. Um but now as soon as like 5792 is finalized

uh the the plan is to like revisit all these other capabilities that we proposed um when we initially started working on 5792 and make sure that they're also updated um and get them finalized uh correctly. So 7677 is going to be probably the first one that we come back to. And um from from more context, I work at Coinbase. I work on our smart wallet. Um and we like in we have some like undocumented pay master uh RPC methods for handling like token payments. Uh I think the plan is we're going to like ex either extend 7677 to document those

methods um or create like an extension ERC for 7677 to document those methods. Uh but anyways main point is like heard on the the token payment. It's like kind of an issue that we uh recognized a few months after we started supporting 6 7677 and uh yeah, we'll definitely be like documenting something around it uh to correct for this. Okay, sounds good. Since we run also a token pay master, I would love to join the conversation and um and then align on the on how it's going to the proposal how it's going to you how are you going to propose it. Uh Marth I want to

mention that you differentiated between verifying pay master and token pay master. But first of all neither the wallet nor the app can at this level differentiate between them. And secondly even if it is a verifying pay master it can be it can still use the users balance like think of an offchain pay master that uses its offchain balance to pay for the transaction. So you can say the there's a technical difference in how they are implemented but functional whether they are sponsoring payments that just pay for you or whether they take some of your balance through other mechanism. There's

no way you can tell it's a contract you user has to trust it. It's it's not something you can add to the API to say this is a pay master that I I don't know takes out of my balance. um you can express like so since we're speaking about app to wallet communication so you can express to the as an app to the wallet there's this like in the capability section like let's say token and then its address uh and then that way the the wallet knows it can so when I when I said token pay master and I actually said like um I was mentioning

like a verifying pay master that supports token payments. I didn't I didn't take into account the permissionless token pay master which is only an offchain cont onchain contract. Uh I think that point should be considered as well but I didn't think about it. Right now there are two ways you either specify explicitly what the token what the pay master and the pay master data will be. We can pass it as parameters. It's I don't remember the ERC. There is an ERC for adding all 37 specific fields and the other way and the other thing is that it is a complex pay master that needs a service and then you can specify the URL

and then you're using the pay master service to do the do a two-phase transaction to collect this information. Yeah, these are the two options because technically how you fill it whether it's one off to begin with or whether you need uh two RPC calls but what the actual functionality this pay master does whether it's simply a nice service that pays for your gas or takes out of your balance this is something we cannot But what if you

uh even if you express it in the capabilities I'm not sure what exactly you want to specify in the capabilities right now right now you have you either say either it's fix or it is a web service that you need to connect. Yes, these are the current capabilities. But what else do you need? Yeah, that's exactly it. But I'm not sure I understand your point. Like um like you cannot differentiate between uh are you saying you cannot differentiate between um yeah I'm not sure I understand your

point. What I'm saying is that there are two kind of pay masters. One of one of them is a benevolent pay master. He's very nice. is paying for you because he's nice, whatever you do. And the other one is a capitalist one that it pays for your gas and it charge you elsewhere either offchain or is a token or credit card or whatever. I don't care about the technicality but you for the first one you can cheat him by specifying a high guys values and you will pay because he's nice and the otherwise if you do the same you will happen pay yourself more so you cannot cheat

anyone you'll charge for it in any case yeah it's the technicalities of how this pay master works is different but one of them I said one of them is using an off-chain verification and the other can be completely onchain and for this the API supports these two modes. One of them is one of you specify the fields and the other requires a a web service and to RPC calls to field and this is already exist in the spec like the specs and the verifying pay master service uh is defined in one and there is the 437 capabilities that

lets you fill any specific field to a specific value and This is something you can use if the application want a specific I don't know token pay master a pay master that is fully onchain and doesn't need this web service. Uh okay. Okay. I see the ERC now. User operation builder ERC 7679. Maybe a little bit. I think that that one is different. That one is that that gives the contracts for how to build the uh um the user ops across different account implementations. This one's kind of been people are not using this as much anymore. They're using a different one.

Uh, like they're using RPCs for this as well now. Um, oh no, this is uh I haven't seen this one. Sorry. Ignore me. I'm clicking I'm seeing Alex's uh comment. Oh, okay. Okay. Okay. I just saw this. I didn't see know about it, Alex. Okay. Uh, thank you. I didn't know about this RC. I'll take a look at it. Very helpful.

You may be on mute. Oh, I'm still here. I was just waiting to see if anybody was going to continue talking. Um, yeah. So, um, are there any other matters people want to discuss? Speak up. Otherwise, we can end early and you can have half an hour back. I think I have a few things that I want to share in this group today. Yeah, go for it. Uh number one, uh I messaged in the wallet discord a few days ago that we are going to have Dan Finlay talking about EIP7710 and EIP7715. The meeting could not take place the other day, but it is scheduled for tomorrow at 18:30 UTC. I'm happy to share the zoom link right before the

meeting. So if anyone uh interested may join the meeting and going through the proposal 7715. It seems like that has a required section and in the required section there is a proposal 4337. Currently proposal 4337 is in draft status and it will make difficult for any other proposal having it in a required section to move beyond draft. For example, EIP7677. I think that also has EIP 4337 in request section. So if I may request from either the group of EIP 4337 to uh like promote the proposal in review status or maybe share if there are any

blocker and how we can help move the proposal to go to the final status as soon as possible but at least move from draft to review so other proposals can be promoted as well. Uh yes, we are on it. We will move it into a last call very soon. Now we're spending the audit which was finished. So hopefully uh it will be done this next week. Okay. So uh the proposal can not be allowed to jump from draft to last call directly.

There has to be a status for review in in between. So it would be a good idea to just make a simple PR to move the proposal to the review status and from there you can move it to last call whenever ready. Okay, great. We'll move it to review. Perfect. Thank you so much. And while uh this group discussed EIP5792, I would love to invite anyone from the author's list or implementers who may be interested in giving a talk on Penip so we can have a like resource created for EIP 5792 as well. Um please let me know right here or maybe later on I'm happy to schedule a meeting to talk about EIP5792 as well. That's all from

my end. Thank you Sam. No, thank you. Um, yeah, that's it for me. Nothing else on the agenda. Um, thanks everybody for coming out and we'll see you on May 21st if I'm not mistaken. That's it for the th third third Wednesday of the month. Yes. Great. Thanks everybody for coming out. See you then.