Cross-Chain Addresses Call #1

Transcript

uh well let's get started uh and thanks again everybody for joining for jumping into the chat I know it's been sort of a yeah a little bit of a last minute organizational effort but I really appreciate everybody jumping it's awesome to see so many people here I think excited about helping to solve cross ux at least I hope I hope there's some excitement here um uh yeah I I think you know of course it's it's one of the biggest problems affecting users this isn't new information to everybody here uh but the good news is there's a lot we can do here in this group there's a lot of collective knowledge and and brain power here so yeah thanks again for everybody being here I think you know as vitalic and and others have mentioned I think we

can really make a big dent in this in the next couple of months if we are you know sort of thoughtful and and can get enough Buy in of course assuming people are willing and able to work on this stuff assuming some amount of bandwidth uh I'd be curious what others think and and whether this is sort of overly optimistic but I I like having that as our sort of I don't know like North Star not to put sort of any hard timelines on things of course but just to help frame what we're hoping to achieve something like you know like what's realistic to have live by October perhaps um and you know we can talk more about that I shared the agenda in the telegram group uh if anyone has anything

they'd like to add or questions they want to make sure that we go over uh yeah please just add it to the bottom of the agenda there we don't have to make this an overly formal call it's maybe better that it's not and you know people can just jump in whenever they'd like um but yeah so I think that was all that I really had I don't have much else to add sort of um yeah by way of any intro um so yeah I guess uh velic I'll I'll hand it over to you then yeah sure no thank you uh very much for the introduction Josh um I think I mean as I think you've already summarized a lot of my motivation for starting this is basically

that like we there's been a lot of discussions um especially you like online and in various forums about layer 2 interoperability and like there's this uh recognition that ethereum has this big problem where one one simple way to summarize it is basically that using the ethereum L2 verse feels more like 34 different blockchains than it feels like using one coherent ecosystem and there's a lot of like specific ux screwups and both errors and like unneeded

centralization that ends up resulting from that and this there's a big opportunity to really start working together more to try to figure out and um agree on some some key standards to try to solve some of the biggest issues that we're facing in that regard and AD like adur formats seems like seems like as good a place to start as any uh just because it's something that's fundamentally so simple um and so this is something where like I've been you know like talking about

this for a while and then recently Justin made me aware that there's some also alter a couple of different alternative ideas for some of the details um so alternatives to things like ERC 3770 if we adopt to them would actually make them significantly better I and so I think I mean for me the ideal outcome from this would be to get to a point where like let's say maybe just uh you know keep the scope simple for now like get gets to an agreement for the you know the address for format of the future and

like at the same time there's definitely other standards that it makes sense to start like moving forward on as well but that like you know addresses as as a first step and hopefully just start getting all of those con conversations rolling and so I guess uh the way that I'd set up the uh the agenda at least just in terms of what I dumped in the Google dogr is basically trying to like goope out this uh address format question and kind of break it down into different pieces and basically see you know like can we like get agreement on specific pieces are

there particular pieces where it feels like there's like multiple options and uh an actual decision points to make um and then go from there um so I guess uh maybe before we get into details are there um any opening thoughts that anyone else Hower wants to share um yeah hi guys I'm Jeff munus um I think I'm really excited to join this call just because I think we've been thinking about this at ens for a long time at least the last 12 month or so I think the hard part for us is that we were always thinking about um what we were talking about in the chat probably

near the end talking about like multi-chain addresses and like you know how do we go from you know a landscape with 32 L2 with all these different addresses to like you know one name or one way of finding all of these addresses and we we've got somewhere down the line that with the with ens multi train addresses but I think the problem was always being like how do we get all the kind of wallets and uh all the different parties to kind of agree on a standard and I think yeah with I guess metallic poll on the community I think that's definitely something we can actually you know strive towards now um and that's something that we couldn't do by ourselves with just with justs so yeah I'm really excited to to get this

get this going amazing thank you yes sorry uh maybe also just share a bit of uh context and and learnings from 3770 uh just as like for us the motivation where we put it out originally was because uh like if they followed like people had an address and they send it and then they got assets send on a chain where there was no safe smart account deployed um and uh like we we needed primarily like a solution for that like obviously you we were thinking of counterfactual addresses just have the same addresses everywhere but then you have two major problems one there

there are l2s that where this is not possible namely CK sync and the other one uh yeah the other one being that the the state of of the the contrafactual deployed account is the one from your original state so if you have a multi you do key rotations over the years and then hey there's like lens Network popping up two years later you can only deploy a save there with the state of the original uh safe smart account which might be that the keys that you had back then you don't have access anymore which was for us a clear sign that addresses uh or we cannot count that there's always the same user count at the same address with same state and therefore uh

like chain specific addresses are a must and there's like a like this chain agnostic IP 10 or 11 I think which was solving that already uh but it had like this prefix of like bp155 and then some chain ID and this was not uh in our view not like human readable enough uh because people would then just remove that and they still don't know kind what what was the intention uh so implemented that in in safe wallet and the learnings was that no other wallet adopted this the standard so far granted we didn't push too much because in the end the problem that we had had was so as uh yeah people were sending around

these erc's 3770 addresses and maybe they were the counterparty was annoyed that there was this prefix and they had to take it away because their wallet wouldn't uh wouldn't support it but because it was human readable it was already this like positive friction there that would then kind of make them think okay if there's a aaic before the address probably the the counterparty wants to receive the assets on on a different chain and so for us this was uh of solving that but especially because it's not widely adopted and because it relies on this offchain registry definitely we also think that there's some some need for a revision of that and and see like going forward

what's the best approach to chain specific addresses yeah thank you um anyone [Music] else okay maybe just to proceed with the kind of w with the structure um a little bit so we start moving things forward on some specific issues I guess uh I me I feel

like it's good it would be good to just see how much agreement do we have on the very basic thing and the uh the very basic thing I I have in mind is basically the uh the first part of the agenda as I describe which is the the underlying idea that it would be good if we up upgrade the ethereum ecosystem to using some kind of Standard address format which contains both the address within the chain and some kind of identifier that refers to the chain so I guess you know like first open question is that you know like is there full consensus

that we want to move to a world where addresses look like this and is there willingness to uh switch over to a standard like this if uh if there's broad agreement on it like lot of thumbs up anybody disagree dissenting opinions I wouldn't call it a dissenting opinion but um obviously we we solve it slight different at ens obviously so we have a name and it has the ability to to go to each individual um chain so you

can look up any specific address on any chain so it's it's a slightly different um way of doing things where it's up to who's looking at this address um or name um to decide which specific area to go to as opposed to this one is explicitly who's writing the address so I think I think it depends on the on the format right so if I'm putting something out there like op colon address I'm saying that this should be an address specifically on op op but as an ens name on its own I can say like no matter what um address you want to send to me you can just look at jeff. eth you don't have to go to I don't have to put op

colon Jeff e or something like that so sorry go on uh yeah as just wrapping up just like it might depend on the context itself of the address and I I was just GNA say sorry to jump in front of you y but um I was just going to say that in the context of Cape 10 those were not really meant to be enduser facing human readable addresses those were sort of canonical uh backend system log protocol level addresses so the trans uh to like

3770 when something goes user facing was a pattern we saw discussed in a couple places and makes total sense it was more like uh in in for lie of any other registries the ethereum lless one was used as canonical and the sort of numeric thing was canonical in case things get renamed over time or something I I think there was always this assumption that there was like uh an an analogy like IP addresses to DNS like the the more protocol leveled name was intended to be Cape 10 and it was always sort of hoped that there would be a better human readable one when people

are telling each other where to send assets uh which is maybe the same thing uh um Jeff just said fumble did you have a your hand up oh no that was me ah sorry yep perfect my zoom was not showing you speaking thanks oh I wanted to add that uh so since ens since ens already has already has a solution that is a bit different from what uh from what we're proposing now I wrote a message in the group and suggested that we need to side on like a

canonical resolution order in case there's a conflict so see my message there but basically the idea is that since uh in an ens an ens user I mean if it's a user. e at chain. then it's possible that the user already has an address for this chain as an address record in which case this should this should get a preference so we should decide on the order preference which I would assume is H that if the user has said something in the EMS record it should take residence and if not we should fall back to the uh if not then we should fall back to the default which is the e address so user at so user. e at chain. e would be the the etherium

address if it's not explicitly said otherwise right I mean I guess this uh this all depends on um like the details of how things are set up right because like conceivably you could imagine an ens thing that basically were where like the entire interface is basically it's a function where the uh input to the function is some kind of chain identifier and the output is an address and then any kind of fallback stuff would just be purely internal logic but okay I guess maybe just move things

a bit forward right I think I guess are we in agreements that uh like generally the know like you can think of human readable addresses as being like one interface form factor and ens is another interface for form factor and generally these two are like separate problems where we want Tove like move forward on solving both and like it feels like generally they don't interfere with each other except I guess would probably want to agree on a common way of identifying chance does that uh like does that sound

correct to people yeah that sounds correct to me I think they're like they can work pretty well together and they don't necessarily conflict with each other so if you did something like op colon Jeff la. eth then if I had an you know obviously if I know I want to send to something to Jeff L ethon op then I can just look up the op address but if you write op col on d e you're kind of specifying I want to only receive assets or this specific address I'm talking about is only for op and something like that so if the standard kind of works well with that I think they can operate quite well together M I got it okay um so sounds like uh that makes all makes sense so far maybe

yeah I guess we can uh move straight into the other probably somewhat meteor topic um so this is uh actually the place where my own phys you got changed you know like thanks to Justin Drake and the the the ZK snc folks a couple of weeks ago but basically so status quo ERC 3770 the uh the way that chains are identified right so the place that stores the mapping of like what even is I know eth Co and what even is op and so on and so forth that is an offchain centralized registry right and the there's an argument that uh that got

made that feels pretty persuasive which is basically that offchain centralized Registries are harder to scale right because they work fine when you have I know like 10 like five or maybe 15 different layer toos and people are generally friendly with each other but uh once you have layer two potentially thousands of layer 2s and ideally you want to be able to like you want creating new ler to to be as permissionless as possible so there isn't like a central gatekeeper of like which which US are like even allowed in the list even for in the first place um

okay yes s this secretly or to is good addition then like basically there's these Arguments for using ens um as a registry in um instead of this uh offchain list right um and so like basically instead in of having this centralized list that says like this is what op colon means this is what polygon colon means or whatever ler 2 is what actually be identified by a particular ens name and there would be like a type of ens record that you could set if you are a AER 2 contract that basically says like essentially this is this is my config um so yeah I

guess like one broad question is like how do people feel about this idea and like this is uh like this gets into deeper stuff right because I think there like starting to like there's actual trade-offs between the different designs as we started talking about in the chat over the past week H Julia H yes hi Julia was sing um so the way that I think about it is um similar

to how DNS routing work works in the rest of the world right if we were to register l2s like Zig syn era um. e or base. E on layer to ethereum ens um we can also deoy local contracts for ens on each L2 and then that L2 can uh create name services for their specific rollup um how do people feel about that so this is like basically the kind

of original ens scaling proposal right where you scale ens without like moving it to one single L2 by basically encouraging people to use subdomains where top level domains would be yeah like controlled by contracts that would then do like ccip read to verify right uh yes I suppose I think like a hierarchical way of structuring name service yeah yeah um right I mean that makes sense I mean I guess I mean the thing that I like I guess technically like you can you can do that while at the same while at the same time

using ERC 3770 but I guess uh well okay like maybe yeah like one reason why right right like it definitely is like a little bit orthogonal right okay so one one of the ways to think about how it's orthogonal is that like at least with the ens approach like it's theoretically possible that someone could make multiple subdomains and put them both on zync and you could have or multiple domains and put them both on into these contracts where subdomains are in zync and then you could have like multiple um top level domains subdomains of which

could be registered inside of zync right so like that design by itself doesn't imply that there's like one like canonical ens sub registry for a layer two though I mean obviously if we want we could try to I'm encourage ler TW to do that sorry I couldn't see the right hand button but maybe just kind of building on at least some of the conversations we've had on The Zing side um so I work Clos with you um I think at least for us the en solution was cleaner for a few

different reasons but it did come largely down to I think something that you mentioned in the introduction which is you know in a world where we want to see uh you know a lot of l2s exist permissionless creation you know even things like ephemeral use cases having this offchain registry feels like it will be a bottleneck for people to be able to move quick L and will become a maintenance burden um and having you know moving more towards as much as we can a single source of Truth on one via something like looks like a good solution to this problem at least okay um maybe let's get to uh let's let's like jump into you know like some of the authority issues so let's say we

do adopt a version of 3770 that depends on ens that's uh that's rooted in L1 um let's how would we handle test Nets like would uh having an address on like the uh optim would resolving an address on the optimism test that would it require looking at the ethereum main net or would we have like basically you know like separate roots for or like basically like separate I mean like test um 's that have different prefixes for each of the different ethereum test Nets um so we do have supporting

Registries on some of the test Nets um I guess if we were going to depend on these these specific deployments then you know obviously we want to make sure that these are kept up to date um we do keep it mainly up to date I believe on sepolia and I think we deprecate gy so it's sepolia and heski right now um so definitely possible to use those as like the main net of all the other test Nets um but yeah um there are other options as well I'm sure right I guess um like do people Richard yeah um I hope you can hear me first of all but I would prefer if it's same as L1 like use the same as a normal main

net because we also don't want that like let's assume we want to extend this and also push additional information like train ID and so on also with this entry TOS which would allow to have a more holistic picture of the of this chain then we want even for test Nets that they should not like collide with the same information as any main right so it should testnet should also not have the same Shain IDE as the main and then utilizing one registry would make more sense for me than saying oh test Nets are on a testet registry and then right I mean I guess the the concern that I have with that design right is that like philosophically it it feels weird to say that resolving

addresses on a test net would requires running a main net node right because gener yes yeah go ahead um Anthony uh yeah thank you for telling oh so backg I think I agree with your position my intuition is the most simple thing for us to do in that case would actually be for the test net registry to be maintained but it to be uh independent of main net so that you would essentially have a testet where your s name's mapped to whatever the addresses are required for the test Nets to run correctly fully isolated from M

um mostly just from like you know simple philosophy like having a beer like clean design and having to make sure that the test mirror M it in a way where okay the specific address could be different but to First approximation everything is internally consistent rather than say relying on Main also this seems like it could introduce sort of like weird version mismatches particularly where protocols may be deploying different upgrades at different times making different assumptions and having it kind of move in a consistent fashion where the test Nets are internally consistent at least to me seems sensible and then Protocols are I think required slash incentivized to keep those system up to date and and make sure that the test are maintain correctly for their own testing as well as obviously the like ecosystem

correctness right okay um so like so like if you if you do the approach of test that'ss being separate that does mean that like there is a more limited use case for some kind of sort of offchain root registry right where in this case the role of the of chain Reg indry would be yet to not register l2s but to like in some sense register ecosystems right so the the example there yes so like you could have like East for minut andoo for the for the seia testet and like you might have a similar thing for other test

Nets so is uh is that a thing that people are um leaning toward are there even conceivably other options h seems like we are right

yeah yeah I'm I'm seeing some uh discussion that's uh in the that's in the chat that's been going both ways um I guess uh anyone else have any like particularly deep points or deep thoughts on this topic okay um

well uh sorry I my my only question if though com coming back to the secret l2s um is what's the fallback for secret l2s or l2s that are for whatever reason ephemeral non-public do do they just uh use CH like is back unregistered simple I mean the simple thing that might be always available right is that like basically instead of using like whatever. e you would just like directly put the uh the like L1 address of the L2 contract and so you would just do address at address.

e right like it's uh it's clunky but it does work or you could just eper register some like totally random Sor can you explain better what you mean with the secret l2s sorry maybe I'm missing a bit of context um I guess the idea is to just like make a an L2 that's like used by some group of people that like almost everyone in the world never ends up hearing about so you mean like an L3 something that is hosted inside another system or so yeah I think it's a then it will

have a contract on the Y one so the world will know about them yeah I think it's a it's probably it's almost identical to the case of L3 L3 can also be Emeral and uh but all of these things are rooted to some canonical bridge that something that every Layer Two whether it's secret or whether it's layer three it's rooted there so I would assume that um it could be a it could be a hierarchy where uh you can use the bridge that defines any number of L of secret l2s or L3 is on top of a on that and then you can have a internal naming convention or

something yeah s Sor I was asking because we so I'm also at Z sync and we were thinking so in the elastic chain we have this problem we have the fact that we have nested uh uh well not a problem it's a feature we have this nested L2 l3s let's say and so that's why we wanted the recursive part because we don't want people to resolve a layer three name on the L1 because it's expensive and it's clunky so we want them to to jump to the uh to the ens record that says Ah by the way the the place to resolve stuff in in the zik sync ecosystem is this and then you do it off chain through whatever sequencer or service is going to resolve the the

contracts recursively the ens contracts that lives on the L2 so on on the L1 nobody would ever see the L3 name uh you will just look at it on the L2 MH right it's it becomes something a bit similar to the very old fonet protocol where sometimes you had to Define that the way to reach a certain node is via a certain other node so the address had to reflect that that the way to reach a certain Layer Three is through a certain layer

two and then the rest of the resolution can happen there e should we I guess move to a different

yeah yeah let's move on maybe uh yeah so the next question is this is uh I guess uh a somewhat uh you know like political and like not just technical question which is uh like what is our stance toward evm are ones that are not ethereum rooted right so this is things in the binance smart chain monad Tron type of category um so I mean I think you know it's it's perfectly fine for um our stance to basically be you know you go you go figure something um out for yourself or it's fine for our stance to be like

basically you know treat treat them the same way that we treat tests um or or or even doing our best to encourage them to get ens addresses but is this a a topic that people have thoughts on a sort of a tangential point to this um we we're thinking about uh using the standard for URLs or Uris for for addresses so having a prefix that says basically the protocol that you're you're using which could be evm column SL slash and then the address um so this

would be so from a ux point of view this was this could be useful to make sure that these things are treated as other URLs so it's not a A New Concept that you need to part and and maybe make mistakes but this could also be an occasion to sort of U be sure that the addresses are disjointed between the L1 between the different l1s so if youm compatible you should have a but you're using a different protocol a different one then you should use a different uh a different protocol graic at the beginning or something like that does it make sense to people right I mean this is um also one of those things where the you know the like address at

l2. kind of does implicitly right because the the E tag like basically implies like what the ecosystem is yeah I'm never sure if that if I should interpret that as the uh one specific ens contract or like uh or like go on ethereum so I'm not I'm not sure exactly how we want to add meaning to like the protocol part of the like the the suffixes because because we could have different uh reg top level register at the end so you could have like a at the end you could have aens a DOT something else if you want to use another register I don't know or

maybe we don't want that we want to impose that it will be one single point of route to start uh and so yeah you wouldn't want that to if that's if that's unique then you just need to know that you're going through ethereum and then then that's clear it doesn't have to be in the address I think for me there's two there's two different parts here like one is um you know non ethereum Affiliated evm chains like say binance chain or something or um and and Tron and I think I think it's okay for these these um these kind of services to maybe pick their own Doom name that they import to ens via dnsx um or decide to get their own e name if

they want to um I think the more important question maybe is like how do we support I guess um like slightly non evm compatible things like I guess there are some l2s that don't have address format are exactly the same as as ethereum and that might be slightly different as well right and I think like one answer that we can have for there is like that's just out of scope right and like I think the reason why that's fine is like if you take for example Bitcoin addresses right then like if he wants to have a wallet that also supports Bitcoin like there's already zero risk of confusion uh even if we do absolutely nothing right because the address

formats are just like so completely compatible yeah that makes sense too just to be clear this isia um sorry I posted I posted a picture in the chat does this kind of makes sense to people I know we don't have to boil the ocean with solving the l1s but each of the ones can have their own name service but then also register their name that I don't know Solana that's all that um you

know binance on the L1 ens um if they wanted to um interrupt between the their chain and ethereum and for ethereum we will have those subdomains like the rollups registered on L1 and then local the deployments of enss for their own resolution within each chain and then tests we talked about having that the testet net name so that so that basically sounds like in a sense we are treating uh test Nets and like non ethereum rooted l1s in the same way yes except for it those would be

deployed or registered on the the ethereum testet yeah service right right but yes but the right so you just have like other so you'd have e which basically refers to the ethereum ecosystem like a registry of the etherum ecosystem that where the root is the registry and then like if Tron wallets wants to they would be they would just make TRX points to the equivalent for Tron and and then we would do like dooa Foria test that and so

on yes yeah yeah okay I mean I and I think this is like a fully coherent proposal that uh makes makes a lot of sense um no and no thank you for making the diagram by the way um okay um that makes sense um I guess that one um maybe just so that we can get through things uh in um in this call um do people

have like opinions or strong feelings on the Aesthetics question so this is the the the third section in the uh in the road map right so like this is basically holding um you know like format constant holding like what information goes into the address constant and holding all the other issues constant um like do people have uh like like basically I know like one option is like chain Colin address another option is like address at chain um and then I like we like if we're g to make a distinction between like eth and TRX where does that live and so

on um so I'll just reiterate my opinion from from the chat I think like having the identity of of uh the person be be first I think makes a lot more sense than how having the chain first um so I think just for ux reasons that makes a lot of sense that's kind of how things are with like emails and other IDs um it makes sense when you see it like op colon because that's kind of like how we do prefixes for like protocols but I don't think protocols is a very like userfriendly thing and I don't think we really really see it when someone like you know looks at.com you don't see you know https colon anymore um so I think that's that's more of like this was a

lowlevel protocol but if it's a bit more high level where you going to see something I think identity first makes a lot more sense to me okay um is there anyone who like significantly disagrees with uh what's um option two in the list so zerox d8 da blah blah blah at optimism dias uh hi this is zy from the okx I actually prefer the first option that we put the network name before the other D um since like when we first looking at the

address we are going to send the wallet the that receiving address I mean like when we first look at that address we read from the beginning to the end so it will be more specific that uh to finalize which time we are going to send the money into so I actually from the user side I prefer the we put the optimism first before the other Tri because the what address is kind of hard for user to read yes I would just um back up my point and just say that like from an ens point of view we view addresses as some that will

eventually go away and that we're not looking for a world where I think crypto doesn't go get to like you know a or ethereum doesn't come to a mainstream world where we have tons and tons of addresses the fact that we have the protocol as a ens name I think is already a lot more readable and So eventually I would like us to see transition to a no heex world where you know the first part is actually the identifier and the identifier could be an address as we fall back to that but it could be an inest name um that is more readable something like the e and that's why I think it looks better at the front I I feel a bit strongly about uh making this respect the URL format so

just use what has been standardized for like a long time so you have your identifier on your on the system at however I find that system which is for email or Mastodon or whatever other um I see Bumble fudge raised hand oh wait oh wait I'm I'm not formed I think maybe one point to add if the address is standardized let's say it is the the address name at uh the the

l2. e wallets can then create a very good user experience by parsing this address and displaying it in a way that makes sense to the user the most if that was the concern right so like a a wallet that has like limited space in a text box would just like literally listed as 0x da d8 da dot dot dot dot 04 at optimism. that's right you create a separate field for it so it's very clear to see yeah I like that a lot I think like at the end of the day this is for users

and not for you know machines okay um let uh it's it's it's good to get the different uh P different perspectives um by the way um actually uh since uh I saw um who was it um Andy from okx here did you happen to have any thoughts on the things in the in the previous parts of uh of the doc so like basically the uh the general concept of addresses that include the uh some kind of chain ID um

and the and the in chain address um and then using ens as the the registry for l2s within the mucos system actually um really agree with that since you know we also have the AET as well and it always happen that user send the money to the uh Network that they haven't deployed the smart Contra on hand that means if they want to use this money they have to pay some actual Network fee to uh register and to deploy the Smart Country and TR and we also get some

complaint from the users that oh I I accidentally transfer money to a different CH could you help me do something or like give me free gu something like that but we cannot so is really useful that if we can use the this uh we put network name before other try that the user could really clearly to specify which CH they are going to send money to so we are really total G agree with this um prop and the thing is I think we we can start from overate and uh to uh give user a promote and to tell tell them like this is CH you're going

to send like using this way but the future the is we we should also push the those the apps to also adapt to this kind of this kind of format of other D but yes sure we really glad to support this kind of format it can really help us to reduce a lot of complaints from the uh our users okay thank you um by the way does I forget does Oka wallet support or do any of the okx like ecosystem things support chain like evm chains that are not uh rooted in ethereum L1 so like

things in me Byer Tron or like mo mo out Avalanche category I think currently no let me okay okay and okay um maybe yeah in the time just to move forward with the items this is one small one but how do people feel about putting it explicitly into um ERC 3770 that uh checking for check summing should just be mandatory in new style

addresses like basically just use this as an opportunity to make finally make non- check sumed addresses just invalid uh yes EAP 55 Jack In this case okay um I mean I uh I am seeing lots of

uh lots of Silent uh smiles and uh and raised hands so that feels like a yes um okay then uh another small one is uh if if we want to get into some myia um how do we how do we support uh addresses that are simultaneously valid on multiple chains um and the two methods that I have here are are basic basically one is the uh the listing method so this is something that I noticed the uh that is so wallet just independently decided to go and support uh which is basically

that if you want to have if you have an address that's accessible on some list of uh l2s then you can basically provide the uh the list of l2s and just merge that into a single address and then the other method is the uh the category method which where we could basically Define a larger set of categories so like for example this could be at evm for any chain that supports like some particular standard of the evm or like something potentially at ERC 4337 for any chain that supports subset of eips that includes some the evm features that you need for let's say

enshrine 4337 for example um so is and I mean I know I was talking to Wilson from about this um and there was a desire to be able to like for those wallets that are not or that that are not able that are able to offer users the same address on every chain that they support like basically like why like why not add a a type of universal um or or at least like category wide address is how how do people feel about ideas in any of these

categories what is the use case do you know that that Wilson yeah yeah I mean I think the uh the use case is basically that uh if you are a uh and uh like if you are a wallet I mean like one simple example is like if you just are um an eoa wallet then uh like the functionality that you offer your users today is that you just give them one address and that one um address gets usable everywhere and like users don't have to think about the or idea of like are they currently getting their Optimus of address or are they currently

getting their main net address or whatever um right right yeah in the chat can be solved with a user owned ens name right okay um that's uh that that sounds like the yeah the general Vibe is uh like not too much enthusiasm from uh most people um and uh I mean I guess one argument is

like for at least some period of time well it's that want to be chain independent could just uh continue to use old style addresses I suppose uh Bumble fudge I I was just going to say this actually makes me think back to yoo's point about um fallbacks or sort of anarchical resolution because if if the only two options are uh something that ends in e or a bare address um the fallbacks kind of clear but then if there's this third category like future EIP could Define a category or some other way of

resolving then it gets into like how uh how to what's what's the fallback if that fails or something I don't know I think I I I like everyone wanting to punt this but I'm also tempted to uh to say that if it were specified in a loose enough way future eips could add more options rather than having to hard code them now um okay I don't think 4337 was written to be to to be one of these categories so it's it's a little weird to to use that as the example but like I'd imagine there could

be a 4337 update or extension that would make you know add AI to a 4337 wallet that makes it work this way um but like I think maybe it's it's in how the how the spec defines that second segment as a right as a syntax or as or as you have meant like a you know like almost like a decision tree or something um yeah I mean like like my goal in suggesting that is that I think there's like if you think of it from a like V diagram kind of perspective like I mean in this case it's not really a van diagram because it's pretty concentric right but there's like a big set of

chains that's support addresses that are the catak 160 of an ecdsa key and then there's a somewhat smaller set of chains that like that support the evm up to a particular version with a particular set of exact standards that lets you have the exact same smart contract wallet address um across all of those chain and then that would get even more restrictive if people wanted that address to be eof uh for example so that was the motivation specifically specifically for a 437 I wasn't sure what there because the 437 addresses are determined by the

factory so they're actually uh they're just normal normal addresses that exist wherever you have this factor with the factor in the same address so what does it mean to have something at 437 sure if someone was trying to speak but we are also at time yeah I regarding what you have I actually say

that we are defining a standard for addresses not standard for accounts so fourth res7 is not relevant in this case because account addresses are just addresses like any contract likea like whatever right it is part of the network regardless of the account type yeah okay but I think this is in any case a pretty small point though I think although one thing that I do want to just like flag to everyone right is that the concept of an an address being not necessar the same thing as an account one other place where that becomes very relevant is things like stealth addresses like basically other

forms of addresses that don't that that map accounts in more indirect sense to go from here like uh you know would there be value in there being a group that creates a uh an updated version of uh ERC 3770 that uh takes or I guess like it could even be a

new a new ERC at this point that takes into account the things that we talked about today and flushes out some of the details and talks and talks about usage like does that sound like a useful thing to do or like otherwise what's the the next step for people I think that makes sense we can continue the discussion in telegram I don't know if there's any volunteers from uh 377 zero that would like to take on but yeah maybe we can continue this conversation in in the

group V do you mind summarizing what you just said because I I definitely lost you for like 30 seconds um I think someone El did as well we may have lost you theic are you still there yeah okay just said in the chat make a group to work on an updated ERC that implements the ideas um are there strong feelings on a new ERC versus updating the existing ERC I mean we have many authors of the

original here uh it seems pretty different to me I would I can't speak for them obviously but I would assume an a superseding EIP or an extension EIP would make sense to people who only need the current functionality I mean I think the motivation is is the same and I think with anyways like 370 uh7 would be deprecated or like we would like from safe perspective we would use the new format so in any way become redundant I personally don't have any strong feelings or I don't know what it

would if it would help having a new ERC because it's something new people were likely to adopt or I don't care too much so maybe the next steps and we can take it here z s we can write up what we just talked about uh with the questions in the doc share it within the group and then you know start iterating on the dock itself and then I guess convert it into an ERC at some point when we happy with it yeah to me yeah yeah yeah I mean it probably just it probably makes sense to start in like for for the first step to even just be Aver get into an ERC right

because it feels like you know we are at that stage where if uh the best way to try to like surface you know like any very like small and specific disagreements is to try to just like put the thing into the sort of like formal format that actually yeah flushes out the details exactly awesome I'll summarize the notes and then we'll uh yeah we'll get this going into a new ERC cool thanks all to you yeah thank you guys thank you thanks telegram for updates I think so yep yep okay awesome

thanks thank you thanks see yeah bye bye