AllWalletDevs #35

Transcript

[Music] What's up?

Thank you. Heat. Heat. Heat

up here. Super.

Heat. Oh, heat, heat.

This is uh all wallet devs call number 35. Um we're going to be talking about a few different things today. Uh ERC7920 uh MetaMask improvement propos proposal number six as well as uh two changes to um the 5792 capability set. So, um, yeah, I guess let's kick it off with, uh, a little bit of discussion about an MDN like wallet, uh, API page. So, uh, this is a project I've been kicking around for a while. Um, I haven't been able to spend any time on it. So, I'm just bringing it up here maybe to get some interest from other developers, wallets, uh, in the space. Um, I'd like to build, um, an MDN like resource that documents

all of the wallet APIs that are available. uh preferably with like a can I use style interface. Um if this is something that interests you, something you'd like to work on, give me a message on Discord. Um I'd be happy to, you know, give you a hand and get you started. Um yeah, so that's about it on that for now. Uh we can kick that off to later if we want to talk about it more. Uh because I think we actually have some technical discussions today. Um, do we have somebody from MetaMask here to talk about um MIP6?

>> Well, I don't know how this got I I'm from MetaMask. I don't know how this got on our uh on the agenda, but uh who who pushed this onto the agenda? I'm happy to talk about it. >> Oh, we um we talked about it last time and uh we just wanted to bring it back up and see if anybody had any thoughts on it after reading. >> I see. Okay, cool. I missed last time, so Uh, I see. Okay. So, >> I guess Yeah, >> sure. Um, yeah. I mean, so I I'd imagine some folks here are familiar with like Casa and uh the the capes. If if not though, that's the chain agnostic standards alliance. Um, so let me I can

drop um I can drop the github or if you bear with me for a second. Um, but basically, you know, uh, Juan Bubble Fudge maybe has dropped into this meeting before. He he he sort of runs it and um this is a uh you know effort to create some standards that you know uh bridge and and sort of go above any particular ecosystem and and can glue them together. And so we at MetaMask have been for a while adopting um the uh a few of these these capes the the sort of central ones being Cape 25

and Cape 27. um which uh describe here. Sorry, I'm just gonna drop this in there. Um and these describe sort of handshake and um uh sort of request protocols um that um theoretically and and actually at the moment um now we have a full implementation in MetaMask um as a sort of parallel API alongside our 1193 um API. um the injected Ethereum provider. Um and so happy to if anyone has any questions or wants to play around with it, I can I can drop some resources um for doing that. But um yeah uh this uh allows you to um you know

query and and provides pro standardization and protocols for um um yeah making requests uh to EVM chains to um you know Salana, Cosmos, you know you name your the ecosystem and these are all um standardized within the the sort of Casa framework. um they have name spacing and um and various standardization within if you explore within the cost the chain agnostic link that I uh I linked um and uh yeah that's that's the kind of overall purpose and uh we are yeah these these standards power our quote unquote

multi-chain API um which has a number of you know improvements UX improvements to, you know, the standard EIP193 um uh API interface that we're we're sort of used to um in the EVM world at least. And uh yeah, we think this is a great standard. We've been working on it and and helping shape it for some time um with Casa with wallet connect and um we would encourage others to do the same. um we've been kind of slow to to devril it as much and and sort of promote it as much as we'd like, but that's the kind of that's the rough idea. Um so yeah, happy to answer any questions um or concerns.

If you could ask uh like one action from wallet developers on the call, what would you like them to do? leave a comment on your discussion thread or or >> Yeah, I mean I would I would love um I I think the so myip 20 mip myip six is a decent place. MIP five is uh my five and my six six are kind of more or less the same thing. Would love for for folks to engage. There's a discussion thread um there. Um, I would also encourage you all to take a look at Cape 25, which I can link um, as like a, you know, I think it's the

the probably the best entry point into sort of understanding what what's being um, uh, what we're what we're going for um, with this new API. Um and it will link you to some of the corollary and ancillary um PRs or or standards. Um and yeah, and so engage there. There's a Discord. Um there's the Casa Discord. Um I'll drop an invite in the uh the uh Zoom chat here as well. Um so if anyone's interested in uh you know we're yeah we're we're eager for other uh adopters um and we think that this is

like the path forward or you know it's it's there's obviously a lot of paths forward but we this is our chosen path forward for sort of bringing our wallet into a more uh agnostic world where we're not particular we were not no longer just an EVM only um wallet and uh this is kind of the the tip of the spear u for that effort. Um so I'll drop some links uh in the the Zoom chat, the Cape 25, MIP 5 uh and um uh the Casa Discord invite link. So looking for engagement thoughts on on any and all of those places.

>> Awesome. Thank you so much. Yeah, >> if there aren't any questions, I guess we can move on to the next topic which is E7920 which is by Solo who I think I saw on the call. Yeah. So, I'll turn it over to you. >> Hi. Yeah, thanks Sam. Um, yeah. Uh, just want to talk a little bit about 7920. um a read Mercy Graph PR I think uh three to four months ago and uh just uh haven't uh yet kind of brought it up to the wallet devs and I was hoping to do that on this call and see if I can get

some feedback and we'd like we'd also like to move it into review formal review so if anyone um would would love to be a part of that process just let me know. Um I'll start off by just explaining what it is. Um so 7920 um allows um basically batch signing of off-chain signatures. Um so EIP 712 signatures um 712 signatures um are becoming pretty um quite popular uh in the ecosystem um largely because they allow um the apps to interact with with EOAs um without relying on on state state changes and state modifications.

You can think of state changes as kind of like a slightly slower um costly process um to go back and forth between two parties and so both sides can kind of agree on or can kind of speak to each other without without that process. It kind of speeds things up and it doesn't require the EOA to hold any ETH. Um and so off-chain signatures are kind of picking up hyperlquid poly market wallet signin and um some some payment protocols are also kind of picking it up. Um but with that kind of popularity I think there's a need for um a workflow um sort of improvement to allow multiple offchain messages to be signed in one signature. Um and that's what 7920 does.

It basically um allows a user to kind of look at a bunch of messages and say, "Okay, I I I agree with all this." And then put one signature on the set of messages and then have those messages be verifiable um by apps and also on chain. Um and what's really cool about 7920 is that it allows um uh in order to verify that any single message was signed, you don't need to know about what else was in the was in the batch. you can just kind of only look for your message in the batch signature and verify that. And so it really lightens the load on on apps um in that regard. And some of the other benefits, I'll just kind of go through it. Um

yeah, single single signature uh isolated verification. You don't need to know everything that was signed. You just need to know about the thing that you care about being assigned. And then and then it's also human readable. And so EIP712 um kind of the major benefit of it is that you you have full visibility into what you're signing and 7920 kind of built on top of that and so all the benefits of 712 are preserved. Um and then it's also compatible with um 712 signatures. So, in a sense that you can write a verifier for 7920 that can also still verify 712 signatures that weren't um signed as 7920. And uh stepping back,

I'll explain uh what that means is you essentially um a you can think of a uh a regular EIP712 signature as a as a batch of one or Merkel tree with only one entry um where the root and the um leaf nodes are are the same. And so that that that sort of uh that primitive allows um 7920 aware apps to validate signatures that were signed by um older wallets. And so it's backwards compatible. Um and then it also allows for new verification modes. So um one of the cool things you can do with 7920 is you can say that um hey this message um and you can say that two messages can only be signed together

or you can say that hey these two messages can never be signed together. And so you can now um start to kind of you can have full visibility into the batch if you care um or not no visibility into the batch. And so that's kind of a cool cool feature. Um but yeah, uh the full spec for this is up on the uh on the uh uh we have a thread going on Ethereum Magicians and then we also we're also up on the Ethereum EIP website. Um and then I also set up a uh a website just for 7920. It's called ERC7920.org.

I'll paste a link in the Zoom here. Um, and I would love for, you know, folks to just sort of engage with it and and like I said earlier, we're looking for kind of uh reviewers, former reviewers, um, for for the next phase of this. Um, and just anyone who has kind of thoughts and ideas on ways to improve this. Um, I'll also put my, uh, Discord and Twitter links on the on the website so you can reach out to me anytime. But yeah, that's it. >> That sounds super cool. What kind of use cases do you envision for this?

>> Uh, so I started working on this because I was working on a DEX that needed uh we were gas-free decks and um we had uh we had this two two this two signature problem that everyone has. It's like oh you need to approve a permit two or or three or 09 or whatever transfer with transfer with authorization. Basically, you had to do a token approval and then a swap approval right after each other. And uh that was super frictional. And so this, for example, would allow the user to just sign to sign one message that has kind of all of it, everything in in in that one batch. Um and also just kind of apps that are coming up. I see a lot

of um like Hyperlid has an offchain signature for you know setting leverage before you trade and there's a bunch of preconfigurations that need to happen before you trade. Um that all can be bashed into one um placing multiple orders on on their decks um without having to kind of post separate trans uh you know make separate calls. Uh that that would be huge. Um and also wallet signin. I noticed a lot of apps have um kind of a separate signature. No, they have one signature for the terms of service and the uh privacy policy saying, "Hey, I agree to both terms of service and privacy policy." Um, with 78920, you can split that up and have

the user uh um agree to privacy policy in one message and terms of service and then the in another message and then have the app kind of hold both signatures in isolation and verify them in com if verify them together if you want both both of them signed in one batch or verify them kind of separately if if you care about that. So just a lot of use cases for um workflows that require um sort of multi-me workflows and I think those are are kind of increasingly going to become more prominent.

>> Cool. Thanks. Um Oris, your hands up. >> Yeah, quick question. Like you said, this is the problem everyone has and has had for a while. Do you see like is there some predecessor work to this? >> Uh not really. Well, uh if you look at the full spec, there is a new JSON RPC method um that is needed um and it's I I called it sign type sign data V5 um but all it really does is that it computes um a um um a mer so it signs a it signs a batch signature computes the the batch signature but it also returns a Merkel route um that you can use to verify the the batch um offchain um and it does

require developers to have a new verifier for 7920. So, it's um there are there are things that need to be done, but I I don't think these are large things, particularly because of the UX improvements that we get here. Um I I think they're they're quite they're pretty achievable. >> Thank you, >> Adam. Yeah, the only other the the prior art which I was reminded of was the I don't know if you come across by economy super transactions idea which isn't sort of exactly equivalent but um they have an approach where they sort of like similarly I think it uses mur to um essentially sign with one signature a bunch of different

um onchain calls. So that could be on one chain or across chains and that's how they sort of like make their sort of I think it's their modular execution environment makes multiple calls with one with one user signature. So I don't know if you've seen that um but that but there might be some interesting folks to talk to talk to at least um check that works that's powering stuff in their stuff in production right now. >> I have not um I will check that out. Um thanks for pointing that out. So, how does this um interact with 7702 um and being able to do like multiple calls in the same um account, right? Um I guess you could probably mix that with uh what is it

1271 to do uh signatures onchain uh or offchain signatures rather? So, like have you thought about how it would interact with like rich accounts? Um, so what I I've I've kind of been thinking about this as almost like a a uh separate problem. So 7702 is really cool for um for allowing wallets to um kind of batch multiple transactions into into one call. Um, I've been thinking about this more as a way for uh developers to um talk to EOAs more efficiently um without relying on state change. Um so it's more of a it's more for off-chain

use cases. It's what I've been kind of thinking about whereas 7702 is I mean kind of a game changer for onchain batching. um 7 7920 is it kind of similar but for offchain >> I think you can do offchain with 7702 as well though you could sign a um a transaction that deploys your account and then implements 1271 to do like a batch verification and then you wouldn't actually have to play the transaction onchain to get the results you could just do it offchain and see if the signature validates >> that is cool I am I am just running into 1271 So, I will check that out. That is pretty cool.

>> Yeah, just just a thought like like I have no idea if that's practical, but maybe something worth looking at. >> Sounds good. >> Cool. So, uh any other questions on 7920? If not, uh thank you so much for for presenting that. That's a really interesting proposal. Um, and then we can move on to uh the gas limit override capability if uh Adam is here. I think I saw you.

>> Yep. >> Yeah. >> Um, hey everyone. I'm Adam. I work on Coinbase Smart Wallet. Um, and we um have been pushing EIP5792 uh pretty hard, which is the wallet sync calls method. Um and and one of the the feedback that we get from our developers is um you know uh they have no way to communicate a gas limit for the calls that they're making to the wallet. Um and so um like like we use a a 4337 accounted wallet and right now we're delegating gas call gas limit estimation to the bundler and the bundler doesn't

always have context on the calls that are being made. So for example like a DEX swap that's going through a swap router um has pretty non nondeterministic gas usage. it might get routed to any number of dexes and the bundler might hit one path that doesn't get flexed um and when it's actually submitted on chain which can cause the user up to revert if it runs out of gas. Um so uh all that to say um with the old ETH send transaction RPC there was a parameter called gas where the apps could just specify the gas limit and I think most uh wallets respected that gas limit when constructing the transaction.

Um there is no similar functionality in wallet send calls um which is it's it's one of the considerations um in the um in the bottom of the ERC it's discussed I mean it's it's tricky right because like um an app can't give an account abstracted wallet a call gas limit because it doesn't know about the smart contracts that are actually being used by the wallet doesn't have that context and similarly the wallet doesn't really know that much context about the calls that being made. So, um my proposal here is to add a capability to 5792 to allow the the apps to per call that they're making uh specify a gas limit for each call and

then the the wallet will be responsible for calculating any overhead that's associated with batching that those calls on chain. Um and so I I've drafted up uh kind of like a a rough draft of an ERC. Um, I was hoping to get some uh feedback just kind of gauge interest from folks on the call. If anyone else has run into similar things with 5792 or thinks this could be useful. Um, would appreciate um some discussion in the thread or if anyone has any feedback here, but I imagine people take some time to read it, but it's hopefully pretty straightforward. Um, yeah, pause there.

Awesome. Thanks so much. I mean, it makes sense. I think this is a proposal that we probably need. Um, looking for feedback, same as uh everybody else. Do you have any do you have a prototype implementation already or? >> Um, not not really. No, I I mean uh the next thing I'm going to be talking about is the server wallet API and I've implemented on that API and it's um but it's not really something that's exposed to developers currently. So um don't have a demo up today but maybe that's something I work on.

>> Cool. Any any questions on this one or seems like we have some support in the chat? I think one thing I um was the example at the moment is all um at the level of the call rather than like there's not a way to provide a top level um top level guess and like like maybe that's intentional and I don't know if you thought about thought about that. >> Yeah, it's intentional and at least my rationale is that like uh an app doesn't really know if or how the calls are going to be batched. Um like like take for example like an EOA wallet that's implemented 5792 um like what does it mean when you're giving an EOA wallet

one gas limit for like three transactions and and how does it interpret that divide it by three or like Yeah. So I think it really has to be like per call. >> Yeah, that makes sense. >> I might um instead of calling it an override, I might call it a hint just as a suggestion. Um >> Sure.

Because in in like uh the the current uh APIs it sets the gas limit whereas this one I think would just be hinting to the wallet to increase it or maybe decrease it but probably only increase. >> Yeah. I mean I guess it's uh well so in in my current implementation at least and I don't know that every wall would implement it this way. Okay. Um, I take the the limit that's passed in for each call and I don't change that limit, but I do add the batching overhead on top of that to account for like our like execute batch function. Um, >> so be like an override for that call and that makes sense. Okay. Yeah.

>> Yeah. But I mean, yeah, terminology I don't know what is idiomatic here. >> It's bite shedding. Call it whatever. Go ahead. >> I still think that um hint makes way more sense than override because um even if you support the capability in some cases you might opt to ignore the value while in other cases you might opt to use it. Uh I'm talking from the context of a wallet that let's say supports EOA pure EOS 7702 smart accounts everything. So in some cases depending on your implementation and

your design decisions you might simply decide not to use it like uh if you are uh estimating like a bunch of calls uh and you have the capability to estimate all of them together but some of them have the gas the gas hint and others don't. For example, one one is a badge that comes from one app and the other one is a badge that comes from another app that doesn't use uh this capability. So in this case, you'll have mixed calls that some of them have the have the gas hints, others don't and you would be able to estimate all of them together.

So in this case, you have nothing to do with the you you cannot do anything with the hints for certain calls per se. So I still think that hint makes a lot more sense than um than any other language like override or gas limit. Something like gas limit hint I think makes the most sense. >> Okay. Um I will say that like in in my current proposal I explicitly if if the capability is included on one call it must be included on all calls. But I I'm curious to know more about the use case where you like partial um >> yeah uh for example in umpire you can we

can receive um batches from multiple apps and you can you can batch them together. So like you can get a request from unis swap and right after this go on a for example uh without signing and then sign them together. So you would have 5792 batches from multiple dabs. So like two batches that would get batched together into one transaction. >> That's neat. Yeah, I'll have to look into that. But I agree the gas limit hint makes more sense here. Um and if you think it should be uh remove the restriction um for for making required on every call then uh can certainly make that change as well.

>> No, I I actually think this restriction makes sense. uh but you can still have multiple requests from different apps and then they cannot like they don't talk to each other so they cannot enforce this restriction across different batches but in one batch I think it makes perfect sense like in one particular batch I don't personally I don't see a use case of having some codes that are hinted and some not maybe someone can bring out such a use case um but I don't think so >> I mean the the simple one would be like in a proven swap right like unis swap wouldn't know how >> the how much gas the approved for a random token is going to cost but they would know how much the swap would >> roughly

>> yes actually I was going to say the same thing uh they can know but it adds extra overhead for them to implement this uh ERC and it will be much easier for app developers if if actually you allow some codes to be unintented because they care about the gas of of the call to their app they don't care about the approval to use for example, >> makes sense that you know DAP developers would would feel that way as a wallet developer. It's kind of also similarly hard to know the approval gas limit for any given token. But um yeah, may maybe we move this into this discussion side

and I'll think think more about it as well. Yeah, this should definitely be discussed separately because from a world developer perspective, if you have a mixed batch, uh then it kind of becomes pointless. >> Awesome. Yeah, thanks again for bringing that up. That's great. I think that's a super useful proposal. Um I don't know if that covered or didn't cover 7836, but if you want to talk about that one too, um please do.

>> Yeah, that's another one. Um so this ERC is in in draft. Um it probably still needs some love and I just wanted to bring it up um to to urge people to um review it and and give feedback. Um I guess I can introduce it. It's a um it's a basically it's a server API for um a wallet server API for um signing transactions kind of similar to 5792 but without the signing step. So, um it's kind of split up into uh wallet prepare calls and wallet send prepared calls and and kind of the usage pattern would be um think of like a um a session key kind of uh that's been given to an app. And

so the app still doesn't really know how to prepare a transaction and submit a transaction. That should still be the wallet's responsibility, but it does have a signer. Um and so it can sign without any wallet UI. Uh and so um the idea is the app gives the calls and prepare calls which would generate I don't know in our case like a 4337 user op and return that to the to be signed by the client. The client would would sign it and then submit it through send prepared calls which would go through the bundler. Um uh this is this is something that we found um pretty pretty useful for shielding our clients from the complexities of creating user ops

and and submitting them and um and stuff like that. So um I think it also has a lot of use cases around like uh app wallets and and um session keys and stuff like that. So um any anyone who's worked on anything similar to that uh we we'd love some feedback on on the draft. Um, and yeah, uh, there's a there's a telegram chat chat as well. If you'd like an invite to that, I can figure out how to do that. >> Yeah, I'm sure. I mean, I'd be interested in that. Um, if you want to shoot that over.

>> Yeah, if I can figure out how to use Telegram. Yeah. >> That's all I got. >> Awesome. I appreciate it. Um >> I think I think the one there was one question on the spec of 7836 which was why their response is like a list of a list of calls. That was the only dangling question I think in the telegram as well as there was also some questions about send folks wanting to use it for slightly different purposes. Um and I think keeping it focused makes sense but the list of calls thing was an open question.

>> Yeah, I don't I I saw that question. I don't have the answer for that. It probably might be just cruff from our initial draft um where we weren't really sure what this was going to look like, but I think in practice um we we return a a single um call. So I think I think we could revise the the ERC. >> Nice. And I think there are there are a few actually a few implementations of this in the world already as in like um in different apps and libraries. Um most of which are aligned couplers like slightly different but um this one yeah

would feels like it would be worth trying to get this over the line so we can align those things and because it seems to be already useful. Well, thanks everybody. That's the end of scheduled discussion for today. If we want to chat a little bit, we can. Um, if anybody has anything random they want to talk about, otherwise we can call it for today.

>> Yeah, go for it. >> Actually, what I brought up in the chat is quite interesting. So uh you know the ERC for sign in with Ethereum and uh a while back they decided that um they will use plain text rather than 712 for good reasons. Um there is a specific article there's a blog article explaining it. I think it's linked in the year as well. Uh anyway, at this point things are a bit different and uh maybe it's worth revisiting >> like making sign in with Ethereum V2 pretty much. Yeah. Over 712. I'm not sure how people feel about this. This is

why I'm bringing it up. Otherwise, I would have simply went on to draft it or something. But I I personally am not sure whether this is a good idea. So, what does 712 support bring for sign in with Ethereum? It's pretty much only offchain, right? >> Yeah. Well, structured data is always better than plain text, right? So, if we're moving towards a more structured data point of view, um, then this can allow words to be more localized at one point. it can also allow better better accessibility and um yeah basically that's the argument structured data

should be better in theory I mean it is still structured data it's just a different kind of structure um but I do see your point it would be nice I don't like could you ever get rid of the plain text parser or would that always continue to exist as like a legacy thing >> well I'm not sure um if everyone migrates to the new EAP and it's easy to get rid of it. I mean, it's a matter of ducks moving to the new year. If there is a new year, >> yeah, I mean, as a non-wallet developer who has to do zero work for this, yeah, go for it. It's always

>> Actually, I'm not I'm not sure. It doesn't seem to be that many strong points for it. >> Yeah, if you >> actually uh the strong point was brought up earlier in the conversation and I totally forgot about it. It can be the it can be part of the batch signing. So that's one cool thing and you can get rid of stuff like requiring people to sign privacy policy, terms of use and login separately. Uh and without this you cannot put it as part of the Merco batch.

So yeah that's one thing I meant to follow up on on that on that actually. Why is it valuable to split the terms and conditions and the privacy policy policy signatures? Why is this a legal requirement or why would this be valuable? I don't know about terms of use and privacy policy but you certainly have to split login from terms of use specifically because of how the sign in with the proposal is written because it bounds you to certain to a certain message and you cannot add any additional things to that message.

So this is one potential argument. If you require uh a few separate signatures uh to log into your DAP then uh with the budging proposal that was proposed that was uh discussed earlier in in the call uh then this can happen. But that's only if it all uses 712. Gotcha. Cool. Yeah, I think it's a good idea to look

into. Um, thanks for bringing it up. Yeah, that's a great idea. Awesome. So, I think with that I'm going to call it here. Thanks everybody for coming out. A lot of good discussion today. We'll see you all in a month. See you. Thank you guys. >> Thanks guys. Hallelujah.

Heat up here.