AllWalletDevs #22

Transcript

so we have two eips to go through today we have um EIP 5792 which is the wallet call Api all right so this is uh 5792 um it is a batched transaction uh RPC endpoint so uh this is probably relevant for anybody who builds a smart contract wallet or uh who's planning on using 3074 or 7702 at some point in the future um it allows you to create a batch of calls using wallet send calls um and you can also specify certain capabilities that you want so say you want like all of the calls to succeed or all of them to revert so at ATAC City you can do that through

something called capabilities um you can also get the status of calls and uh yeah so it's basically you know the batch transaction API that people have been asking for um and it's going into last call I believe or it's going to final next week so uh this is your last chance to comment on it um again if you're planning on supporting any kind of batch transactions you should definitely go and check this out and take a look at it um does anybody have any questions about the CIP hi uh I had a question Sam can you expand on what can be put in the capabilities field for the batch

calls sure um so I'm not an author of this EIP so I can't like I'm not the authoritative source of the information but the only capability that I know um right now is uh for atomicity and it is specified here so you can say um you want to ask for um Atomic batch and then where is it here yeah so it can execute them all in a single transac action so that that would be the um the only mode that this supports um and then you can add other capabilities later but this is the only one that's

defined uh and then Shane so uh Jason RPC does have batching but um EIP 1193 does not have batching so um this also supports that uh interface oh cool that's exciting so yeah I would definitely um leave a comment to that effect on on this um discussion thread because I think they're kind of Designing this to be both uh batching and uh atomicity and stuff so yeah

definitely let them know that you're working on it great okay so um let's move on to the SE second scheduled topic here um which would be uh erc20 payment reference extension and I'll turn the floor over to reic and um they can explain it hi thanks can you hear me yep you sound great awesome thanks um so I just disc a second

second this one okay can you still can you still hear me yep perfect because I needed to change the the mic as well sorry for that okay so for the ERC for this for this extension it's a generic extension to the ERC 20s and it just adds the um capability to to uh transfer the the payment reference or transfer reference as we can call um aside the regular transfer so uh basically it overrides the uh I don't know if you are still sharing the screen to show to show the uh the I can yes

please um there we go yeah thank you so uh the one of the issues is that that uh regarding the ERC 20s and specifically stable coins the people the people are not able to add any message for the beneficiary and this types of the messages is uh very often used to for the reconciliation of the whatever invoices uh um inquiries anything to towards the payments um so this is the reason why I actually submitted this it is uh upon a long-term discussion within the defi community over here in Europe um and it

should work for the I would say the new ERC 20s uh and and those which are upgradeable so they that they could actually add these there is the uh related discussion on the E2 magicians where we are trying to align a little bit on the on naming and and um uh and the types and so on so the current result or let's say one month old result is is is here in this BL request um which is um implementation wise uh on the contract level it's it's very limited and very easy but the reason uh for this minimalism is for the

to to get the broad consensus on this interface and um this has the impact on you as the bullets uh and as also the question to you uh as the wallet providers or the builders uh whether you are willing to create their that additional UI field that would enable the users to actually submit the message for the beneficiary so that's the that's the key question so just to provide some context from our users on this I think there's probably other folks that do have good use cases for this and in our UI we do let folks

put a reference but most of the time folks want that information private and it's likely not something they want onchain that's publicly visible so I think there might be mixed use cases of folks that want it publicly on Chain versus yeah um I can tell you the very common uh use case which is happening I would say uh on the almost regular basis and it is that the centralized exchanges they when they collect the ec2s they uh have to provide um a different account uh EDM account number for for their clients for each of the client actually to collect that um uh to

to P that payment or to pay the transfers whatever you know the client wants to do there then in in in or or actually uh submit that usc2 towards the towards the sex and then the consequence is that they has have to sweep it from thousands of accounts at a certain moment and and uh you could see it um on almost like regular basis that in general it was also like a a huge sweep by the binance for instance so once there would be the option to to provide this um this message for the beneficiary then uh the sis could just ask the the their clients to send the these erc20

tokens towards one like collectible sorry not collectible like one um towards one account for the collection of those USC 20s and and they would just reconciled by by those messages honestly I cannot understand why this was omitted in the in the erc20 uh standard as such because originally we have the message in the even like on the on the evm level right uh which is used by the contct so but uh it is there and when I was doing the

research on on the metamask and I can see that there are a few metamask folks over here I know that you're like support reporting this sort of uh for the etherum native uh token uh but in like advanced settings sort of type where the user would need to switch it on and then it is more like that the user could like add their the the call data so it's a little bit different and of course it is not for the ERC 20s so I have um two questions so uh the first one is can you do something like this with a smart

contract account and an approve and transfer from flow so instead of just sending an erc20 to like an address the you call a function on the address and it it handles all of this as as opposed to modifying the token itself uh this is this is common uh right now they're like a rappers let's say that would uh enable or I would call them rppers so when I was researching some of those payment options um I found those um solutions that you have like a intermediary contract which you call with sending or with a specific like

transfer uh or just something specific and then you you have to give it the approval and so on and it it does then transfer from and and uh you know proceeds to where the the under Ling erc20 I would say and uh so the service or the merchant you know the beneficiary the other side has the option to use this intermediate contract to actually map those payments or these like transfer invocations with their whatever invoices so this is a little B some sort of strange work around when actually it would be much easier and much more like um

simplified way of the working when we had this originally in erc20 as such uh you know as part of the transfer function it is not there so this is like over overloading that uh with a new signature basically but as you can see on the detail it's purely overloading of the transfer and transer from adding the payment reference and as I mentioned before in the uh ethereum magicians we had discussion that the naming should be a little bit different but uh but the core stays the same uh have I answered your question yeah yeah I think so um so it's just extra overhead to have the contract

handle emitting the the events basically yeah okay and it's pulling up to the contract what the contract would do with that so the only thing which we concluded over here with you know a bunch of the people uh is that that there should be uh uh there there should be a lock emitted for this transfer and we also discuss and that's what you can see in the E magician discussion I don't know if some could open that uh that there were different options discussed and um the conclusion yeah this one yes uh one of the conclusion was whether we should also submit the uh the lock to emit the

lock in any case even if the regular transfer was invoked so so that the indexers or the wallets could fully depend if if the erc20 token has this extension then it could just follow purely this lock which is almost like duplicate one but it has that that uh message for the beneficiary or the payment reference in in included yeah that's that's interesting okay and um so I think that my my second question is can you achieve something very

similar by just appending the uh payment reference on the end of the call data or uh will solidity revert if you do that well this isn't specifically a question for you just for the for the room yeah I would answer on that because we also discussed that within the Bui group already PR and um the problem is that once you are like targeting for the regular users and and who are like just using the uh the wallets uh they fully they they fully depend on the user interface there so uh if the UI doesn't have that option uh to add this then they are not

they are not able to do that so Technic you know you and me we could do it right to add the call there as this with the I don't know the The Trusted forward for instance and so on uh but for the day-to-day use of the regular defi SL nft User it's basically impossible yeah that makes sense okay cool thank you so I would like to hear your opinion speciically you guys if you if you could go like around around the around the vet Representatives over here uh I see that there is a Shan from metamask and there

might be some others uh from the other wallets as well I discussed with the some of the wallets uh during the East Frack uh who were like supporting this uh but those were Min ones I would say uh so please if you could give your opinion on that [Music] um yeah like oh can you hear me okay we go yeah uh like I said in chat I think um to Sam's boy I think there's lots of protocols using something similar to this right and uh like you said this is for erc20

so it doesn't really help on nfts or anything like that but what people have been using to kind of they've just like stuffing the end of call data with their own kind of analytics um I I know it's not exactly what you're trying to do here but uh that's what I've seen in the wild what what people are using right now to do this uh same kind of thing on chain so how do how do they do it in metam mask this this if if if if they don't use any other like front end UI and they they would just use the extension yeah so they'll make a transaction like a

transfer and then they will stick you know whatever extra data they want they'll stick it at the end of the call data which is like sneaky but like it still works right yeah uh I I was trying to find it out and I didn't really realize how this could be done with the with the metamask only so uh I don't want to bother you guys over here with with the question on this this isn't like a metamask only thing you can submit a normal transaction that has extra call data at the end no yeah so

when when you build the uh like you use your library to encode it like your function call and then you just concatenate some bites on the end I'm I'm a smart contract developer so I do this sort of the you know adding the call data from the command line so uh my confusion is rather about the uh for the regular Forks who are using metamask UI for instance or rebe you know or something um that uh that we didn't find a way that this could be possible oh see you're talking about like like you're not on a Dap you're just in the metamask wallet and you want okay exactly exactly because that's very common we discuss here with the with the

centralized exchanges and this is very common actually that uh that they instruct the people like uh you you will just find whatever there is the instructions for the metamask how to install it how to use it and here you just click Send to send the erc20 so this is like a common instruction for the regular users you know and and obviously that's let's say payment reference field or whatever you would call it uh it's missing yes they don't know how to instruct them on this in the easy manner yeah it's it's not uh something

that a user can do yeah here's the question why don't centralized exchanges use uh what was that uh uh window that uh because that instruction towards the their clients is not from buin the front end that only it it goes via different channels and so on so it's almost uh it could be on the workshop you know they they are just telling the people in the in the same way as you send the erc20 to someone you just send it to us as the as the uh Exchange makes sense so it almost sounds like you're asking not necessarily for erc20

tokens to make any particular change although that is what the EIP is specifically asking for it's more that you're asking wallets to create a UI for adding a payment reference in some way yeah okay yes exactly well it it needs to be facilitated by both right uh so uh if we as the ecosystem if we agree on this sort of the interface then yeah the the erc20 is that would like to support it then they would need to implement the interface right and and and both the wallets would need to implement the UI so uh it's it's almost like a chicken and egg problem uh who does it

first I think I could see this more so being used lower level um where it's not actually like a user inputed thing but maybe like maybe a unique ID from like a centralized exchange or some sort of e-commerce platform because I think for a lot of users they probably don't there's oftentimes they don't want to have to put that information in it it just adds overhead a lot of the time um this is the part which we also discuss and it's a little bit elaborated in the ERC um uh because there is definitely the Privacy aspect uh if you because for some of the transactions speciically in

Europe uh you might need to put there uh almost like a sensitive identifier for instance like the birday number for example uh that's quite common actually um so there is a suggestion you know that there would be rather generated some hash of that or something but not by the vas that that would purely go on to the merchants when we could consider those centralized exis as mentions as well um and then they would just reconcile to as this number which would be sued so this this was the reason why we actually made it as the just the byes SC data so that anything could be

submitted there which would enable that reconciliation right and uh just to remark this is not only the issue of the Sexes it's the issues of of the Mars as well who would like uh like to receive the payments as the transfers and and the reason why we are or or I'm opening that because we are creating now the stable coin uh and and we s and we saw this as some missing piece of some traditional Finance functionality which is there as it's also mentioned here on the screen share when when you use the Swift sepa or even

like local uh National transfers it's always there the option for the payment reference or for the message message for the beneficiary to be like practically [Music] named um what if you just thund uh no extend L payment reference at the end of the call data is the question from [Music] Sam um yeah like we just come up with a standard format for encoding this we

stick it on the end of call data and wallet UI and that would be the standard uh no sold it so uh why would we do that in in in in the like a hecky way that we would like add the call data um toward where the TR because I think what what you're you don't have to do it again for for nfts right and again for smart contract accounts or something or whatever the new format is

right yeah um uh okay speciic so so what some wrote here is the idea that that we would use the regular transfer as it is now and uh there would be like extra like call it a piece edit at the end with no x9a and plus this um or general photo course um I'm not sure about the implications when you consider also The Trusted

forwarded which also has the edit to call data so whether there could be any issues on the on the contract level yeah that would definitely be a problem I think this would only be in the transaction call data you wouldn't want to forward it like through the forwarder but I'm not I'm not super familiar with 4337 so uh well the transer forward it actually just adds the the uh the 20 bytes uh at the end of the Cod data so um then you're using the assembly to read the to read that and

and and edit or adjust that sort of like a message cender uh by by this value uh and it has the I I don't like this sort of like hecky pattern because it has the implications on the security and there was the issue with the multi call and and this transfer forwarder uh when used get it's being patched Now by opens up but I understand your point or who said it whether Shane or someone that that it would be annoying to to uh have to to add it towards the nfts or the other things um this particular

ERC is purely focusing on ERC 20s um I mean also it'd be annoying for tokens that already exist that don't have this functionality right it's not like you can add this to a non- upgradable yeah that's that's that's correct with with the with the existing ones well the the point is that this this is actually optional so even even for the new ones and even if they have that uh this the filling out this this field would be optional and then it would be by it would it would be your call as the as

the as the wallet software whether in that case you would call the regular transfer or what you would call overloaded transfer with the um I don't know uh with by zero or something you know so um which function you would call it would be up to you not up to the user I guess um and for the for the existing ones which are non upgradable they would not be able to use that that's clear for those upgraded ones I can imagine that that that that circle is from time to time that they are upgrading

usdc I haven't seen any upgrades on usdt and I think everyone over here knows that that unfortunate thing regarding the usdt uh and and the return values and so on so I do not expect the usdt to add there anything but we would then be literally stuck on that b which was done there uh there was interesting question

or here by m whether metamask snaps would allow that and the UI well extra dat yeah it's I don't I think we we it sounds like our snaps do not we don't have per um endowments is what we call them like a sort of capability to um edit transaction information like that quite yet so it's still a little short of uh facilitating something like this mhm mhm so uh so anyway this would this would need to to have your support in

the UI is this correct um if there's something that you need support for in the metamask UI typically that is done through something like snaps um if uh there is a new endowment that would be necessary to enable the type of snap that you want to create then there I think there is something we have a snap Improvement proposal so you can propose addition of like a that kind of um endowment uh there I can post a link for that in case

you're you're interested in going down that route H I just wonder how many people over here are from Europe where it is common to use this approach with the with the transfers or whether most of you guys are here from the states um where I guess the it is not that common for the vir transfers to to use at all and and to use this [Music] um so is here anyone who actually experience this with the traditional Finance to use the payment reference or sometimes gold as they um I'm pretty old I remember writing

memos on paper checks in America oh yeah uh I I think the um I I've also heard about uh someone from I think it was the Maya protocol was explaining to me that they do cross chain transactions with this memo field which is standard or not standard common in a lot of Bitcoin wallets like you can append some sort of arbitrary data and if you they they have some sort of bridge where you have to the end user has to copy paste like an arbitrary token into the memo of a transaction into the void and then it

just pops up on another chain um so I know I mean I do Wonder it's an interesting ux thing but it's kind of a chicken egg problem until enough wallets do it that daps can say come with one of these wallets because you'll need to append some arbitrary data yeah yeah it's uh that's very much correct yes it's chicken and neck and uh the you you have the case over here as I mentioned we are building the stable coin uh uh fat back so we will have to have it there anyway in some way

um so you have that one part on on the chicken partially solved uh got half a chicken yeah we are we are half the chicken because we are not circle of course so so or or we are not tet uh I can imagine if Circle or tet would would did that then then um then you would like follow right so that will be the full chicken um and as I mentioned I do not expect that to to add it because even if you think about the offchain signatures for instance uh it's not there by there so the

um so what would be the best way to actually I'll proceed further with this um just to give you more idea that there were like two consequences on one one thing was the invocation which means

that it would be that col the bytes reference and the other thing was the emitting of the of the event where the event will be extended also by that so there by those two things uh guys I don't want to further keep you over here uh on this topic so if you just give the conclusion

and and uh I will then try to talk also to to the uh indexers oh wait did uh I think Sam stepped out was he running the meeting yeah yeah he left okay well uh okay so I guess there's no other agenda is okay um well I mean I think the yeah I I did I did find interesting

The Proposal of making a more General um convention like you know even just retro specifying it if it's already convention being used but I do think that um getting wallets to adopt it using it for the nft you know the erc2 case and generalizing it or building it into um 4337 wallets are like three totally different strategies and like you you probably have to do all three eventually for for the stable coin so like just thinking of it as an order of operations problem like like where can you get traction first or where where

does where does someone have a business case to build this tomorrow is just my int intuition my intuitive answer I don't know if that helps though yeah true uh what do you mean provide ref friend implementations to solve chicken NE problem um I think about red was that

you speaking Yeah uh so um I am basically uh initiating and also like advocating for this approach where uh if we have this certain practice uh and we want to made them a standard um being a standard means they can be adopted by smart contract they can be adopted by wallets so they can interoperate right and order the apps um there's always a chicken an a problem because if no adopts it in from from one of the sides it it doesn't create a lot of incentive for the other side to adopt it because no one would use them so um anyone who want to propose such standard or such practice

can provide reference implantation first and go around advocating adopting them but make it as easy as possible um so in in real life uh we have this represent we have this um repository that I can share uh if you want you can kind of uh look at it but it's it's small Contra level thing I don't know if it's particularly relevant to all W death to everyone in all wall death but the general con general practice I would Advocate is to provide implementations and make it easier for people to adopt half the chicken yeah basically

and these are implementations on the uh like client level or it is on the smart contract level so this particular one I Shar was about smart contract the contact was that back then we were proposing erc's and were trying to say hey open zeppin can you include them open zeppin was saying like hey if no one is adopting then we don't want it to be on library and I said if no one is adopting is including in them in in the library uh then no one would be EAS will easily use them and it just uh impede the adoption so I go ahead to create this repository to allow people to adopt yeah uh thank you thank you for this comment because that resonated well

that it best besides that reference implementation the very minimalistic one which is within the URC proposal that it be ideal to create a pool request towards the opens up and then ask them whether to include it and once it is there then it's it's one step further for the chicken egg right that's true yeah but um you know one of the reasons why I actually am on this call is that we are actually implementing this into the stable coin into the stable coin SM contract and uh

in in basically this minimalistic manner because the only thing which we want is that it's visible on the on the Explorer on the indexers and it's visible for uh for the UI of the of the wallets and um the thing is that what I would like to avoid is that we implemented somehow and then there would be a con then there would be a conclusion that it would have a different form or the structure or something one year later so this is something which I would like to avoid um what would be the best steps to do this sort of the avoidance

and to right like get the mutually Mutual consensus at least on the form even if you do not proceed with the with your implementation on your SES that's a very very important question and then I personally experiencing or our team personally experienced the same problem that you have already uh for example I'm happy that thatan is here because I one of the contact in last all wallet death I raised is that we were here to present that with happily implemented uh EIP uh 747 uh only to realize that and then we're very happy to present to our

wallet group and says hey everyone uh this is great we should let while it easily add assets right that user want uh and then only to know that the original proposer which is metamask shift to a different standard they the metamask team says well we realize there's some problems we we we don't really like how the EIP was drafted um and then so we shift it over to use mip1 and so that happens uh to us so the the whole point of having a standard is that people have a way to discuss to agree and to commit to a consensus um yeah I share the pain with you we should

discuss how we can solve them I don't have a good answer I'm advocating for people to share the reference implementation test them out have adoption and finalize the implementation uh finalize the standard yeah okay um any anyone else to have any feedback or conclusion on this okay everyone else is

already uh on their own business so thank you all for listening to that and that you at least know about about this URC I will do a minor adjustments uh if any of you guys would uh give or put any comments into the E magici discussion uh I would really appreciate that even like directions where to go with whom to discuss it where to make the some agreement or consensus with and so on I'm really willing to push this forward because as I mentioned at the beginning um this is common in the in when transferring the value that there

is the option to pass the message towards to the beneficiary somehow it was omited for the irc2 so this is to fix it thanks SW