Future of EOA and AA Breakout #3

Transcript

hey good morning everyone Welcome to our third AA breakout um we've had a bunch happen since the last one and uh hopefully we can take the time today to uh figure out how to move forward on the spec um so the two main things um basically uh that I think is worth like an upgrade on is one the pr that was made to 7702 u based on like some conversation between L1 client teams um and then there was a workshop in Berlin um last week um and uh yeah I think ongar has a

quick recap of that and then out of those things I think there's still a couple open questions on the spec which I think will naturally discussed um and hopefully yeah we can get to some next steps based on all of this but I guess uh maybe to kick us off uh light clients do you want to give just a bit of context on your PR um and how that sort of fled to the discussions in Berlin sure yeah um the the pr is kind of accumulated over the past few weeks of different many different conversations with some different stakeholders uh first we talked with some L1 client teams at the interop to sort of gauge what types of restrictions

they felt were going to be necessary and that sort of led to a lot of the restrictions from the original proposal adding the optional chain ID adding the optional nons into the signature scheme and then in Berlin we sort of talked about these restrictions again with some of the present uh wallet developers and it seemed like there was General agreement that the restrictions in place makes sense and we talked about some of the other open questions and it felt like the two things two good takeaways and ancar can confirm but two takeaways from the meeting in Berlin was that we probably

would not have a flag to persist to the code uh because we have open questions still on actual EA migration and the second big takeaway was we need to do more research into allowing storage for the eoas obviously it's something that people would like to see and it allows for us to use the smart contract wall implementations mostly out of the box as they are today but there are a handful of issues um the two notable ones are address uh or Storage storage key collisions

between wall implementations so concerns with the application layer and then there's some protocol concerns we recently added a retroactive EIP which was 7610 and that sort of disallows this behavior of having a an account in the state try that's empty other than its storage so those are two areas we're continuing to look into I'm happy to discuss further later in this call thank you um and yeah and do you want to give a quick recap of your Berlin notes yeah sure so basically in Berlin we also just talked about all the

different dimensions of like like the the open questions around the AP um we basically came down on exactly um the version of the of this open PR uh of meds of course not all of those are necessarily have full agreement by people yet but at least in terms of support so that was specifically um and so on the one hand the question was how how do how do you specify the the target um of of the of the code that that runs in your account and so the idea for now is that you um specify the address not the code um you also sign over the address not the code um and you don't run in a code uh as M was saying reper

protection chain ID non's optional um for now no storage restrictions um yeah and we we decided that for now we would not feel comfortable about launching with something something that looks like a permanent upgrade flag right from the beginning I mean obviously the detail to be figured out is whether we already um have this kind of flag um in the in the in the transaction we just for now enforce it to not reset so that it's easier to to upgrade in the future and we don't need a new transaction type or new signature type but that's a detail question so basically they idea what would at least not allow for for direct um permanent upgrading yet um and then other than the storage pattern which

indeed as met was saying was like a big open question I think the the one other thing that did come out of this meeting was that we realized that it would be really important to start also working on the like some sort of wallet guidance document because I think that that even just like we had some some someone from Ledger there for example and even just um talking about like in practice how would this be should this be supported by Ledger for example right like that clarified a lot of questions and concerns and so um learning from 1559 where I think we kind of underspecified how wallets should should should behave with this new functionality I think it would be really good to kind of start outlining very clear rules of like what how wallets are supposed to interact

with this yeah I think that that's kind of the the summary okay thank you um anyone else have anything to add I know there were a bunch of other people that the vered meet up okay so I guess in that case um yeah it might make sense to just go through basically the two um yeah uh maybe yeah going through like the the the different open questions so like uh on the replay protection it does seem like we we're set um on the restrictions storage uh still feels like the biggest question um so I guess yeah

maybe let's open the floor to this um how do people feel about storage uh you have you have comment uh yeah I just yeah I just finished writing about it so regarding storage the discussion was whe was whether there's a way to make it safe so that we don't have to uh ban aore and we agreed that if we if we had a stand out that prevents collisions if a stand out where each implementation uses its own storage base instead of starting from zero it could be made safe the problem was that it's hard and required assembly code and that's something that I've been asking

the solidity team for a long time so the update is just is that I just got off a call with just the weekly call with the solidity team they understanding the issue and made it a priority to uh to find a way to um find a way to set find a way for contracts to control their storage layout before and they understand that it has to happen before Prague 47702 so we should get them feedback we should work with them now to agree on a on what it should look like in solidity but I think it will enable using it it will enable S sto in the EA thanks anyone

else yeah onar let's do onar phix yeah just very say that like part of the design philosophy behind 7702 was to try to be as compatible with the existing 437 smart account ecosystem as possible and so to the extent that storage collisions are a con concern that is already present in that world I think the idea would be to just to try to avoid ending up with two separate tax stacks and so to leave it up to that ecosystem to figure that out like with with approaches like the one just presented by you of course to the extent that concerns are Beyond this equivalence um Point um they are still valid and we

might have to address them but basically like if it's just the concern around STS I think would would really be best to try to leave it up to the 437 ecosystem yeah so from my end so we have been discussing last couple of days this this this topic quite quite heavily in in in G and um from what I heard also from that this seems to be the general consensus that um it is usually kind of unsafe for users to sign um like any kind of like conflicting authorizations for code that could run within their eoa so it's only really

ever going to be safe to sign like a specific and very well audited proxy and so it feels like maybe we should just only allow like that one proxy and that would also kind of remove the possibility to like have storage conflicts for the time being and we can like worry about storage conflicts later when we actually do allow more than one specific proxy to run within context of the account and I think that would also allow like way more time for for example the contract development ecosystem to like migrate to these ideas of like declaring the storage

slots and because it's kind of a topic that's very new now so yeah just maybe something to consider thanks um conr um following up from what Anar was saying um so we um I can I can send the pr kind of context afterwards but we have a modular account which is like a reference implementation and kind of um a few weeks back we just quickly kind of tried pting over to using an external storage contract and essentially it took like an hour and already like 50 lines of code of changed to to pull that over so like the effort there was pretty minimal like I understand that there

could be some security implications in terms of like for formal verification and stuff like that that that are of that we should also consider but like purely in terms of kind of pulling over an existing for 37 accounts um to use an external storage contract and in my opinion and based on this like PR is is pretty minimal effort um yeah thanks uh Amad um so like uh I just want to comment about uh uh specifying a proxy implementation uh and only allowing to sign a single authorization uh so like about this in

my opinion this same problem exists with like even if the proxy contract uh you have only a single proxy contract the proxy contract still calls delegate call and when you use Tor sales in the smart account implementation or smart wallet implementation then it would use the same storage sales of the eua so regardless if you use a single proy implementation or multiple proy implementation uh the same issue still exists and this also exists for smart contract accounts and I don't see why the Restriction should uh like any restriction should be applied in this uh manner of course I do agree that

auditing the proxy contract and uh from the wallet before approving them is is something that should be done but uh restricting the wallets to a single proxy implementation is not something that I would support uh Felix yeah I can just quickly uh react to this and just say that I think that it's more like the difference with this proposal of only allowing specific proxy for now is also that like for example changing the destination of the proxy or like migrating to a different wallet type or whatever would involve an onchain action which is very explicit and so it would for example also allow

you to if you wanted to switch from one from one kind of wallet type to another wallet type which can act on your behalf you could do that by for example first like initially you would you would point a proxy to one specific wallet implementation which would set up its storage slots the way it wants to do it and then when you want to switch to different wallet you'd have to deploy some kind of temporary migration contract that like switches the storage around and then you could go to what clears it or whatever and then you could with another transaction switch the proxy again to like the new wallet implementation you want to use or things like that whereas uh with this like authorizations approach it's like you

you would be free to accidentally for example sign multiple conflicting authorizations for different wallets to run within your account and if you're unlucky these since there can be basically these authoriz authorizations could potentially be used by anyone to um run code uh in the context of your account um it means they it's just like much more risky basically I think to to to to allow because it has this this danger of not just like it's not a it's not an explicit onchain action to change like which code is the designated code to run Ahad is your hands up again or yeah

just just one comment about that is I would have the wallet let check the storage cells before having them approve a certain implementation and if they find that these storage cells have value they can do a transaction that clears them before authorizing the the different implementation or or something like that of course uh this is just theoretical I just don't want to restrict the design space for the uh the wallet implementers for whatever reason it it does not make sense to restrict the design space just for this reason that that's that's my my yeah so I also I also don't think we should

restrict the design space if we can standardized storage but regarding trans action that clears the storage that wouldn't be practical for wallets because they would need to trace since especially with verel you have no way to enumerate the storage so you would have to go through all the transactions and not just for E for this EA but every transaction because it can be a different EA using 7702 to change storage slots so you would need to trace every transaction that ever touch this EA and Trace the storage slots that were written so no so so you don't need to CLE All Storage you need to only clear the storage that your specific implementation uses so

like in that way with mapping with mapping it becomes impossible because it's catch up of something so for example it could be a sign like in the in the case that I like to point out with a with safe so safe has a mapping of owners and if you have if you have one written in some high slot you don't know whether it's a shadow or whether it's going to end up an additional owner in your account yep yep yep y you're right you're right okay um not quite sure where we've landed

here um is yeah I guess yeah sorry I'm trying to think through like do we think it makes sense to remove the store capability and yeah um yeah I guess so one way you know to think about this as well is if we think there's a risk around allowing it um this is slightly more work on the protocol side but we could also ship the EIP with the storage uh like s store not enabled and then potentially in a future

hard Fork activate it um one risk around this is just in the meantime the ecosystem sort of develops around this um yeah come on um so I would not prevent s store instead I would allow a store and then at the end of the transaction clear the storage slots that were written the reason is to keep compatibility as high as possible for all the smart contracts that are using is load is store possibly even for counters or something like that um and then like yeah so I would not prevent the whole up code and so basically sore would act kind of like T store does um yes okay

yeah so let uh I mean if I don't think we should it seems that we shouldn't ban the op code but I definitely wouldn't want to make it behave like T store because the developer of the contract was not aware that this storage actually becomes Emeral and could be it could have interesting uh unintended consequences where parts of the transaction modifi the storage in other contracts and part of them didn't for example suppose you are setting the threshold for your safe implementation but now the thresh goes back or you change sence happen so if it's if it's t store let's just use T store and ban ban s store but I don't

think we should change yeah change the semantics got it uh Anar yeah I I just wanted to say that um yeah not on this temporary point but if we basically were to decide to ban storage I think we have to to understand that this will likely set the standard around how how these these systems work including existing smart accounts so that I think that would push the ecosystem to like external storage contract patterns and that will be a very sticky default given that by the before we can unblock storage like a big portion of uas would already start using this and um then that migration of of a contract that already does use an external storage is kind of infeasible

because you'd have to copy over all the existing storage which is super expensive so we really basically set longlasting defaults here um and I mean I personally think that there might be even be a world where external storage contracts might be the safest pattern also for normal smart accounts because then you you never have to think about conflicting storage access but of course it's more expensive so I think either way it would be really important that whatever choice we make the smart account ecosystem feels confident that it is the right long-term solution otherwise I think we just really in a bad place got it y up ah no no I guess no it's I left it I

left my hand ra the sorry got it Anor uh yeah so this is just something which I kind of thought on the flight please let me know if this doesn't make sense but what if we allow the user to specify a additional contract which is which let's say we call the storage contract while signing so like assuming that like we sign the address or like the code apart apart from that we allow the user to also specify like a storage contract address at the time of signature and what would happen in the transaction is that whatever s stores or S loads are being done it happens in this particular storage contract and if the user for whatever Reon wants to switch to another implementation they just produce a new signature and

invalidate the last one so this could potentially uh allow different implementations to use different storage slots while the contract code doesn't really change and if you really just want to switch to another implementation you also just like do a switch to another storage contract as well interesting um yeah I let you draw and then if anyone has thoughts on this h i I'm not sure about this external storage what I'm saying about using storage in account it is not how much it affect the smart accounts because smart account do use use their own storage the question that I don't

think we ask enough is how much it changes the implementation from existing EAS consider all the EA accounts that never intended to use these new features but through an upgrade to their wallet now have some feature very strong one imposing them that allows changing story changing behavior I'm not sure I think this is where the the storage recation came from how it will alter existing EAS not how it will help for those who opt in for that

because for an SEI you opt in you sign for an account and you know that it works like a contract or at least your wallet Nows okay so yeah and yeah there's a comment bance car saying that the storage contract defined in the transaction could be forward compatible um did you want to comment on this all uh yeah this is actually kind of related to the comment just now but uh kind of generally for me the the biggest problem with just allowing a store um right now in 7702 is like um kind of potential um kind of blocking the way towards like

permanent migration um so even if that's kind of like not included in 7702 right now like I think most most people would agree that eventually the goal would be to to upgrade existing EAS to Smart accounts but one problem is if you can in 772 Now set like storage um even if kind of most accounts adhere to like some sort of like names Space Storage if you just kind of like use a single account that doesn't um and set some some for example like storage. one or something like that then in the future if you want to permanently upgrade it might become like unsafe to use like your EA because it already has storage there might be unexpected Behavior if you upgrade to a specific contract like obviously like there are best practices we can kind of uh like do arant this but

I guess like my fear is that we we of I guess like miss something right now and and that kind of blocks the permanent upgrade path for EAS in the future got um okay and then y says he held the same opinion to he agreed uh to add Nam Space Storage and then a cent says that allowing storage isn't going to block migration um I guess

yeah it it's not clear to me how we make the call on this at this point like it does seem like um yeah if like solidity allows us to to deal with the name spaced storages you yeah and I guess yeah maybe like client do you want to explain how you think like even if we have storage we can still we can do migrations yeah I mean I just don't see these as as problems that are specific to 7702 you know we're kind of talking about the same thing in circles but this

is simply a problem that we have today with smart accounts and we have to come up with a solution solidity if they are able to support a better storage mapping scheme like this is a right the right step in that solution there are other possible solutions been discussed like Poss like having some sort of external storage account um but you know at the end of the day like if it's okay at the protocol level then I think it's um something that we can do nice um yeah I know this is just my opinion I know that some client teams other client teams other client

developers feel a bit differently but I don't see allowing storage today going to impact our ability to do an eement migration in the future okay so I guess yeah does anyone feel strongly we shouldn't move forward with uh no storage restrictions for now um so that we can actually get started on the implementations and then uh potentially continue discussing uh yeah the issue offline um it does feel like yeah there's probably like like yeah this on the wallet side like this is probably not

going to get resolved in the next five minutes of conversation so if we're going to S side step solving the storage issue for now do we have to decide the mechanism for clearing it I in protocol or by the the application in protocol only really possible in protocol yeah but even then with veral is not possible why would we clear in protocol or what would the mechanism be um so yeah so to elaborate on ansar's question I'm looking at two different

approaches one where we no op s store Ops that we encounter while processing this transaction as opposed to allowing and then reclearing it at the end of the transaction I'm not talking about either of those I'm just talking about allowing store to work as it would work under a regular contract account so updating the try okay okay um so okay a question by such if we

allow storage in the OA won this result in storage conflict when the OA uses different imputations with different transactions yeah I mean this is again the same thing that we've been discussing but it's also equivalent to the problem that we have today where if you're using NOS to safe and then you switch to another smart contract wallet you have a conflict a potential conflict of storage elements okay so that's yeah let's move forward with uh storage for now um and again yeah keep discussing um I

think and then like Cent you have the proxy pattern is this um basically this is independent of storage right like even if yeah I wouldn't say it's perfectly independent of storage because I think there is a distinction between the problem of allowing multiple implementations of code interacting with the storage of the same account uh um in 772 it's possible to like Felix said delegate to code offchain and this is something that it's kind of possible you could create a

system that allows you to do this offchain delegation thing in a smart contract wall but no one does it because it's very roundabout and feels weird but under 7702 it's a lot more natural to have your seed phrase in multiple EA wallets and have them have their own proxies or their own wallet implementations that they sign over and so I think that in in the 772 case it's a bit more it's more likely that we will end up in a situation where the user has signed or the user has delegated to multiple pieces of code interacting with the storage whereas for smart contract walls today it's a bit less likely because we don't we don't

have this offchain delegation mechanism typically you change the proxy Target in your account this is a very clear process this is something you're interacting with on chain and then you just have to send a transaction so that leads into this proxy discussion there are numerous things to discuss about it but one way to bring 77 A2 in line with how EA wallets are sorry yeah bring 772 in line with how the smart contract wallets are working with delegation is to have one proxy contract that is allowed in protocol and I think that Felix was the

first to propose this but suppose in this hypothetical world we come up with a proxy smart contract I've come up with some sort of example to give you a rough idea of what what I would be thinking about but suppose we have this one proxy contract it's deployed on chain and in 772 we say that you can only delegate to the address of this proxy contract that we have decided upon and this is future compatible if we want to later allow people to delegate to other pieces of code but in the beginning we start with this more fixed restriction saying you can only delegate to this proxy code now you don't really have the situation that we could have today with 7702 where I

have my EA seed in multiple wallets those wallets are using different proxies are different wallet implementations in this world they would have all signed the exact same 7702 message and it's really just the onchain storage that affects what code implementation is running so I think this addresses that that issue of having offchain delegation 7702 as well as Trying to minimize uh the number of like floating around authorizations that a user might have you can always look on chain to see what delegate Target of the proxy is and then you can understand

what uh code will be executing in that account so that's just the idea I think onar is saying he doesn't like the one the enshrined in protocol version I'm curious what other people think I'm also generally very hesitant to enshrine a specific smart contract in the protocol but it is an option and I do think that IT addresses some of the concerns that we have around D um hey yeah so I was saying Anar saying he doesn't like a one proxy

contract because um you'd rather let uh wallet to the white listing on that and you know I've I've been a big proponent of like Trust the wallets to be safe but I think that this could actually be a bit of a foot gun because a user could have srps in multiple wallet implementations they might not be aware of 7702 signatures that other wallets had signed um and so you could have conflicting 7702 messages floating around which would expose that user to this kind of bundler griefing attack that we're talking about there'd be very little a wallet developer could do about it um so this isn't about ensuring that wallets are making safe decisions uh this is about making sure that it's even possible to have uh safety for the user

and the user Ops St sign H there's a question what's in srps oh my gosh uh secret recovery phrase it's uh we started adopting it instead of a seed phrase because uh seed phrase was not communicating the need to hide and keep secret the uh the private keys to normal users is a a user research thing obviously I don't need to use that term in this group but it is a force of habit thanks um ongard yeah I would just say I'm open to this idea of of this kind of try proxy but I think if we actually lean this way then there's at least a case to we made to like look into a bit more whether we

can just more fundamentally change 7702 to to basically account for this because it seems overkilled to have this general purpose delegation mechanism and then restricted to a single delegation Target um I mean of course if we very clearly expect in the future to completely remove this restriction that would be a different thing but to me it's not obvious that we would it seems like we would probably stick with this F and then at that point it might be better to to just directly have that behavior in shined at a more fundamental level at the EAP with the only countown agreement that I can see is that this way basically it kind of maybe most closely matches the pattern of existing smart accounts but but it still seems like because also for example there extra cost involved because now you have to

like first load that proxy contract a new in every transaction and then you have to basically load Lo load the target so it's it makes everything more expensive as well yeah I think maybe zooming out a little bit to understand why is this even proposed what exactly is the solving like what is the fundamental problem that we're trying to address uh with the the enshrine proxy proposal and to me it's about putting on chain in a standardized way what code is executing in the context of the account and so if we think about it more from this direction

we can think what is the right what what are other what are alternatives what would the right way to to do this would be because we're sort of constrained in many ways with what we can do in the protocol today uh and that's like especially when it comes to modifying the account structure in the state try because I think the right way a better way to do this would to have the off Tuple update uh field in the users account that could say this uh this contract has delegated to this code and it would only hydrate the code in that account in certain scenarios like uh

7702 uh transaction ction and that way if you have your seed your SRP in multiple different wallets that wallet can see on chain that you've already delegated to some different code and it will minimize the chances of you having many sign uh any of these signed delegate messages there would need to be some replay protection in there so that you can't um just keep updating the code you delegated to but I think that that's like the nice thing and we've sort of circumvented that a bit with this enshrined proxy by instead of having it on chain what code you're going to execute we just decide for everybody this is the proxy code that your

accounts will execute so you can't sign multiple 7702 messages from different wallets um you can only sign one and then the target is in the account storage with that said I don't know if anyone has other ideas about how we could address the problem of many wallets with your seed phrase not seeing what you've delegated Andre um yeah I'm just thinking if we need to um extend the um account scheme to include this new field authorized code or what not we can do it with v how

so well verle has a number of storage elements ments that's loaded with the account header oh right right I think that it's going to be much easier to put stuff into those storage slots and give meaning to them not storage slots they're like protocol slots um yeah so vco will be a big revamp of everything so it's probably rather easy to to change that bit as well add this new feature uh thard has a question about a

partially enshrined contract I'm not sure what partially enshrined is just a a very Bare Bones implementation um a proxy that's like barely even a proxy um but that still allows like arbitrarily customizable uh code to be added in in the transaction type so you would first hit the enshrined contract and then the enshrined contract would just do a handful of you know safety checks uh but then it would call into the EA's authorized code AS defined in the

transaction just just an idea um and there's two ideas by italic one is having the code at address plus one being the EOS backup code um and then having 7 to Temporary flip on the backup code um and then add an eof version for this account 7702 code is at address X and both of which are I guess bigger design changes thep um yeah I don't know any thoughts

comments like it does seem I guess like are um still like some quite significant uh design questions to discuss and I guess I'm trying to figure out what's the right way to square this with actually wanting this to ship in the next Fork so that users get the benefit from it um for I guess the wallet folks on the call who aren't as familiar with the uh L1 development process like if we want to actually ship this the next hard Fork we probably need to get started working on it in the next couple weeks um yeah so I guess I'm trying to balance

like how much do we want to explore this design space and um what's the best way to do that with is there like a minimal version of the CIP we can start working on um so that there's at least a chance it gets into the next hard forkin uh that we don't basically end up with a design when um we're we're ready to to start shipping things so yeah I don't know if maybe anyone on the L1 teams has a an idea for like what's the right Next Step from here to yeah keep this moving forward but also make sure we get to explore the yeah potential change just to the spec I think my very biased thought is

to pretty much merge the pr as it is so that's without dist storage restrictions it's without an enshrine proxy and it has the optional revocation mechanisms and and we go from there because I think ultimately the client teams are probably going to implement this and have comments and questions and in general you know wallet the wallet teams probably want the most permissive system as possible and the client teams are going to want less permissive systems so it's just we need to spend some time working on it and seeing what we can what kind of compromise we can get to

okay uh Andrew uh yeah one um I am in favor of merging PR 8561 just one uh small technical comment um we need probably to distinguish between null nons and zero nons and I suggest well one way to do it is just to encode n nns as an empty rlp list because um because zero nons will be encoded as an m to string that's the technicality okay yeah I assume we can make that

change um okay so yeah let's move forward with the pr we can discuss that on awward devs next week but it seems extremely likely that um team will just want to implement that and add it to Dev one um and then is it worth basically scheduling another one of these breakouts either two or four weeks from now um so that uh once teams have started uh working on it uh we can potentially um yeah have another deeper conversation and also have all the conversations on like the storage and the potential spec change happen in parallel um yeah my sense is like

there'll probably be more to discuss than like you know what we can do in like 5 10 minutes on awkward devs so yeah did people feel like two weeks four weeks from now makees sense for a breakout um andar asking for weekly does anyone want to do weekly so one okay yeah I guess one small challenge with weekly it's a huge deal but there is like the roll call uh at this time every uh few weeks but um would yeah I guess okay so maybe let's

do this let's do bi-weekly and then we also have Aqua devs uh for yeah yeah L1 El teams that like discuss this so um yeah let's start with bi-weekly and see if if we need more I'll just do this time two weeks from now so June 12th um I think by then um by then what we can do is um figure out the um yeah figure out oh sorry the protocol calendar is wrong um okay so roll call is two weeks from now so then okay because there's like a lot of spec changes now let's do another call before next Thursday's alord Dev so like a week

from now see uh how things go on award devs and um yeah take it from there to potentially have like another call two weeks or a week after that if there's more changes but the people feel like a week from now um yeah we'll have more stuff to discuss if not we can also lose three weeks so yeah any strong preference it's not okay I'll just pull on the okay next week then bi-weekly seems

reasonable okay let's do that onar we still have like 10 minutes here so is there anything else that people wanted to discuss that we didn't get to today yeah elas yes yeah uh thanks I I had one question that I asked on the on the EIP which was about using kak as a way to I don't know there was a kak magic on the transction type and I suggested that using KCK was detrimental to Z kvms and I was wondering why we need a KCK in there which Usef cat do you have in mind

um let me get it but I think in the transaction it's for computing the Sig hash I see I mean I feel like that's like a broader issue right because right now basically all of the transaction types to use catak for computing the Sig has and so if we want to move past that then it feels like it makes the most sense to do that as part of the broader move toward ssing the transa the transaction list okay yeah I I agree with that MH yeah I mean I guess like one Fair critique

would be that like if someone wants to pull ahead the SSC features in their like DK family or two because that like reduces their vulnerability to catch ectos then they'll have like incompatible 7702 formats and so 7702 on every chain would not would not be something that exists but I mean I feel like that sort of thing is uh inevitable and like eventually we're going to get to a world where like if he wants to do things unquote Every Chain then uh like not every chain is even going to be a chain that supports SEI um

Aman yeah my uh comment here is about something else um it was uh I just wanted to propose that um the wallet uh developers uh gather and agree on an arc format for the proxy that they want to whitelist on the wallet side um instead of enshrining that in protocol um I I'm still leaning towards maximum flexibility when it comes to the implementation of the contract thanks um

onar yeah so um I mentioned in my summary in the beginning the kind of the desire to also start work on basically like a document with best practices and recommendations and possibly even things we kind of want to enforce on the social layer and wallet behavior and I'm just wondering what would be the best format to start making progress on this I know that we have these all wallet devs calls is that would that be a good place is that a different place like I just I just I just worry that basically if we start too late it might it might just take time to figure these things out can we have this as an ERC as well it's kind of weird though I don't know

if there's any wallet specific erc's um yeah I guess it's maybe like we can start working on the best practices and then we can figure out where we store it uh long term so I guess that for okay so for next week's call um the three things that would be nice is one um if we want to explore these different spec uh changes that metalic proposed um to having the uh ERC proxy that uh people sort of uh yeah can can can agree on and

then three uh getting some progress on the best practices document anything else people feel we need to get done before next week okay and anything else uh anyone wants to discuss before we wrap up okay sweet well yeah thanks everyone uh I'll post the recording oh who will be working on the best practice stock um and I guess same question for the ERC like I think if people okay ongar will be working on the best practice docs and

on the ERC Matt had a draft um does anyone from the wallet side wants okay uh want to help okay uh Richard uh wants to help okay and then I guess the best Channel at to so we have like each magicians for the EIP but we also have the uh do we we have an a channel yeah we have the future eoa channel in the R&D Discord um so we can use that as well to coordinate um yeah right anything else

okay thanks everyone talk to you soon thank you see you