[CLS] Ethereum Magicians Infinite Endgames: UX

Hey everyone. Thank you for joining us so early in the morning. We appreciate it. We know it's been a rough night for some of you. So joining us today are Neha from Safe, Mark from Fuse Network, Derek from ZeroDev, Pedro from Wallet Connect, and Cody from Base.

So we're here to talk about Ethereum user experience. You know, account abstraction is beginning a lot of attention lately, and that's because we're trying to solve something that anybody who's been using Ethereum for a long time knows is a big challenge, which is user experience. There's always this tradeoff between user experience and security and trying to juggle the two in the right way. It feels like we're on the right path, but there's still a lot of things to tackle, especially as we start looking at cross-chain. Now we have this new kind of challenge.

We need L2s, we need roll-ups for scaling, but on the other hand, users need to start knowing which chain they're on and how to switch between networks and doing bridging and all kinds of things that, even as a technical user, it's sometimes daunting to do, so that's not really an option if we're talking about mainstream users. So we gather here a lot of people who are dealing with this on a daily basis to kind of talk about these topics and see where it leads us. So I'll start with kind of like an open-ended question. There are obviously many hurdles to user experience in the space. But in your eyes, what is currently either like the biggest or most important or like most pressing hurdle for mainstream adoption?

Sure. Is this working? Yeah. Hey. This may be like not entirely specific to AA, but I think funding is currently a big challenge for our users at least, getting users' wallets funded in the first place.

So you know, AA is great for onboarding users and it's a pretty seamless transaction experience, but I think we need to get to a space where native funding is a lot easier using things like debit cards or Apple Pay. Have it be simple to do just-in-time funding for transactions because especially as embedded wallets can fragment users' funds, I think we just need a better solution there. I'm a little biased. I think the funding isn't really necessarily a wallet problem. I think it's a blockchain problem.

I mean, I know it's not a wallet panel, but that's how my brain works. And I think on the wallet side, which actually influences the user experience the most, the account management is still the biggest problem. And we kind of have fragmented ourselves because obviously it's a decentralized network and there's no single product manager overseeing everything. There's like thousands. And we need to kind of coordinate that accounts now are very fragmented and reaching truly universal accounts is going to be a problem.

Mobile wallets have one version of it. MPC has one version of it. Browser wallets are the first type of wallets. And then embedded wallets come and then they do something completely different. And now accounts are just completely fragmented in different types.

And all of these wallet types should just be the same instance of the same account. There should be just one universal account. Sure, you can create multiple accounts because you want a DJ and a gaming one, a social one, or whatever. But the account design needs to be truly universal across all chains, across everything. Yeah, I think if we were talking about the obstacles to adoption, I think we can talk about the adoption of crypto in general, and then the adoption of AA, which are two different things.

So the adoption of crypto in general is actually, in my opinion, not primarily blocked by the lack of UX, which there is, but rather by the lack of super compelling on-chain use cases. So I think throughout the history of tech, whenever a tech is solving a great problem, it doesn't really matter how hard it is to use, people try to use it. So the fact that there are still so few people on-chain right now, I think it's primarily because there are still a very big lack of super compelling on-chain use cases. If you are talking about the obstacle of adopting AA, I think the single biggest obstacle is just the fact that today, it is impossible to use account objection on a wallet you already use such as MetaMask. So despite all the benefits of AA, no one wants to move all their assets from their ledger, from the MetaMask into a new wallet.

And that's why I think everyone here is super excited about 7.2, which will finally bring the benefits of AA to the average crypto user. Works. So I think that we don't have a technology problem. We have a business problem, and specifically trying to...

I think in this cycle relative to the last cycle, things became a little bit more product-led. In the last cycle, it was primarily developer-led, and I think now we see signs of actually trying to solve the business problem of getting users in growing the pie and I think the protocol is not like the main question for why should we adopt you know this technology or that technology trying to do like the perfect protocol is not necessarily a way to sell cut to customers I think we're at this technology or that technology. Trying to do the perfect protocol is not necessarily a way to sell to customers. I think we're at this point where things are complicated enough to hide them under the hood. So I think the best products out there make people's lives simpler.

And unfortunately at the moment with blockchain or crypto, it's actually making people's lives harder. And I agree with Derek here. We need more solid, compelling use cases, which actually make, which actually wants, which actually people make want to use of the crypto network. And at the moment, like if somebody really wants to use crypto, they would go through the hurdles of getting the gas, they would go through the hurdles of setting up an account. And these are the people who maybe want to make a quick money, maybe, but we need more compelling use cases.

Okay, thank you for that. And so, yeah, there's also, I think, it could also be said that it's kind of like a chicken and an egg problem in some sense. Yes, I agree there's not a business case, but sometimes maybe someone did create a compelling business case, and the UX was just so terrible that nobody could use it. And personally, I think that maybe the one thing that, for what Derek said, that even if the UX is terrible, people will still do it if it provides them value. So I guess that's DeFi right now, right?

Because I mean, people were even trading like an Ether Delta back in 2017, even though it was really hard because they saw the value. But I want to expand a little bit on what Pedro said in terms of the account fragmentation, taking us a bit more to the UX. So that is something I'd love to hear your thoughts on because one of the things I've noticed in the space is around embedded wallets. So we made it thanks to account abstraction. Onboarding now, like Cody said, is super smooth, right?

It's like you use your fingerprint, you don't know about anything about private keys, you don't have gas with Paymasters, everything really great. We got to the promised land. But now we introduce a different problem, is this kind of like wallet fragmentation, right? We're fragmenting identity. We're fragmenting liquidity.

I'm just wondering what is your take on that in terms of like what do we do about that? If anything, it can be done. That bad, huh? Thank you for the mic. I'm going to go a little bit back to the compelling use cases before I talk about the counter-fragmentation.

Maybe I'm just being a little too pragmatic, but even if we just cancel everything in the roadmap and we just put DeFi, like Ethereum is going to be DeFi and nothing else, that for me is already a compelling use case. I'm obviously going to be biased by my background in fintech, but we do everything like 10x better. And you need to be 10x better to justify a user to switch. But we're thinking too much from like, oh, it is 10x better as an offering but the accessibility means that you have to climb the mountain with a backpack full of rocks and it's going to be good when you get to the peak and that kind of scares people away because the reason all of these banks actually own all of finance is because you can just go downstairs and like open bank account, even though they have a terrible experience at the end. So I don't think we need compelling use cases.

We already have compelling use cases, but we have to ask people to climb a mountain. And in the account of fragmentation, I think it plays a big role into that. If you're telling people that like oh your account is one thing here and another thing here and then i'm offering you the whole world of ethereum but actually it's fragmented at the wallet level then the whole composability offering of ethereum was gone and we might as well just go back to siloed apps. Because yes, we did not silo apps at the blockchain layer, but we did silo it at the wallet layer and the user lives in the wallet layer. So for them, it is siloed.

There's no composability. Like we broke the composability at the wallet. So we can scale and make interoperability between the chains, but the wallets are fragmented, period. Like the user doesn't feel the composability anymore. And you feel like that's...

Do you have any ideas on maybe how we can tackle this? I spend... I don't know if you guys see my Twitter account, but I write more tweets about ERCs than even about WalletConnect. Maybe I should write more about WalletConnect. But I think ERCs are the way to go like everything that you work in your job whether you're a designer or product or engineer maybe not in the other departments can be an erc like you can literally make an erc out of everything that's the beauty of it and the beauty of an erc is that as i mentioned to you like there's no product manager in the whole ethereum ecosystem everyone is their own product manager in a way.

But by writing an ERC, we can share the scope of the project together, and we can write the project scope, and we can project manage together. But if everyone is writing in their little Notion docs or Apple Notes, we're not going to get there. Everyone is just kind of siloing the information and have split roadmaps. I feel like this is something that we can talk for a long time about. So I know we're talking about UX, but since you mentioned ERCs.

So I think personally I feel like we also have like a ERC fragmentation problem, just like Wally fragmentation. Which is that I feel like I'm all for ERCs, I'm obviously part of some ERCs as well. But I do feel like sometimes we have the tendency to standardize too early. I think standardizing too early is just as dangerous and just as bad as standardizing too late. Because you are, what's the word, you're like ossifying a particular approach before the market, before a particular solution has even been proven on the market.

So I feel like even in AA, you see things about modular smart accounts, where there's a bunch of different competing standards, because people try to standardize too early. And then the products who actually got traction later, after the first ERC was proposed, felt the need to then propose their own ERC, because they actually had a traction. So I feel like sometimes when you do ERCs ahead of traction, you might think you're solving the fragmentation problem, but you're actually creating a deeper fragmentation problem early because now you have different projects fighting between different ERCs. So personally, I actually think that we should try to find a balance between, obviously, trying to create interoperability between the solutions, but also not try to enshrine some approach too early before the solutions have actually been played out on the market. So that's on the ERCs.

Then back to your original question about- Fragmentation. The fragmentation between wallets, right? So personally, I'm not too concerned about the fragmentation between embedded wallets because of two reasons. So one is that I work very deep... Our company, ZeroDev, works very closely with the leading embedded wallets players, like Preview, Dynamic, blah, blah, blah.

So I know it as a fact that they are all exploring and trying to build global Wallis solutions. So by global Wallis, I mean Wallis you can take to other Devs, Wallis that will be the same across different Devs. So I think they are trying to solve the problem. That's possible by the way, thanks to a lot of the innovations in account abstraction, especially session keys. Because if you want to use the same wallets across different applications, but then still be able to provide security guarantees for the user, you need session keys to isolate the wallets between different applications.

So that's been helpful. Then the second reason why I'm not worried about it is because I think I always see embedded wallets as just a temporary solution. Not temporary solution in the sense that there won't be a runs in the future, but rather in the sense that I see them as just like the first step in a user journey. So I think people they get onboarded with embedded wallets, but they would then be, at some point, be onboarded to an actual standalone wallet. So I feel like once, again, Samsung O2 comes out, and once the standalone wallets actually become smart accounts, I think we won't be worrying about the fragmentation problem as much, just because people will actually have standalone AA wallets that they can use.

I also agree that... I think that there's no real fragmentation problem because the pie is not getting bigger. And also we're confusing our investors as our customers. So I think that when we talk about account abstraction, we talk about actual consumers. Right now, the way people use blockchains, they need to understand what is the opportunity cost.

They need to understand a lot of technical jargon. And I don't think those people necessarily that complain about fragmentation or complain about UX are necessarily the actual end user. They're the investors, they're people that are maybe more technical, and there's a big herd that is following the technical people and the investors. And the pie over the last year didn't grow that much. So if the pie grows and new customers will come, and actual consumers, consumers don't pay for gas, and they don't also want to learn, or we don't want to create new habits.

We want to give them the habits they know already. So it's a totally different type of customer that we don't have in crypto right now at a large scale yet. So I think there are like two parallels running here. One for the ERC fragmentation, one on the wallet UX, embedded wallets. So maybe if I touch on the embedded wallet side, I think the UX that it offers for Web 2 users or new users to crypto is pretty good.

Like you enter an app, you don't have to worry about downloading some browser extension or having some app on your phone. You're in the environment of an app, you sign up, you have a wallet. Boom. Pretty sweet, right? Maybe for crypto native users, this is not what we expect.

We want to be more in control of our funds. But people out there don't really think like that. They actually trust in the app that they use, unlike us, who are skeptical of everything. So I think I would put my bets on embedded wallets. I think they will get better, and probably one of the ways in which we can improve crypto UX.

On the other parallel that's running on fragmentation, standardization is pretty, pretty good. And I think there are several standards out there which point towards the same outcome, but different philosophies. And that also creates fragmentation. So it's like an inception of standardization and fragmentation. And how do you come out of it?

Like buy-ins, like you either work on these standards together or you lobby outside of these standards, which is also happening. But it kind of creates a toxic, almost a toxic or a very competitive environment in which you want your standard to win and that's quite a zero sum game in my opinion actually I want to just respond to that just one second I think that actually sometimes competition is good and it actually speaks to what Derek said about the kind of like pre-designing everything in advance sometimes this competition between two or three competing standards, I think, can breed good. I guess it's all about how it's done, right? It can be toxic. It can be positive.

Sometimes people want their standard to win because they have monetary gain from it. Sometimes it's very ideological because they truly believe that this is the correct way. Doesn't mean they're right, by the way. But you're right. It the way.

It's still, but you're right. It depends on how it's done. But sorry, Cody or Derek, you want to go ahead? Yeah, I think I just want to clarify my stance in that I'm not against, I'm of course not against ERCs. And I also don't fault people for creating ERCs early.

I think their intentions are good. What I'm trying to say is that I feel like as a space, I feel like we should do a better job at not shaming companies who don't appear to be embracing ERCs immediately. Because sometimes I see a lot of finger-pointing whenever there's a company who's building something not on top of some open standards, and then people are like, oh, why are you not building on top of ERC, blah, blah, blah. But sometimes the reason is just because they are trying to iterate. They are trying to build the best solution for the customers first, for the users first, to try to prove out their solutions first before they make a Yasi.

So I just feel like sometimes it's not so much that, the problem is not just that people are creating Yasis early, it's that there's almost like this community pressure of just shaming projects who don't appear to be super enthusiastic about the existing Yasis and not embracing them immediately. So that's my point. Yeah. No, I think I agree with Derek here. I think there's a constant balance you have to strike between trying to meet these standards, but also ship value to your users immediately.

Like we only have so many resources to build things. So, yeah, we have concerns around, or I'm concerned a little bit around embracing these standards too early and instead of just building features that our users need right now. Sorry for shaming your cities. I'm super guilty. I literally do that all the time.

And I don't even do it privately. I do it very publicly. Like I really push really hard and aggressively to everyone to write a standard or to use a standard. Like, I hope that wasn't like very targeted, but literally it's really important that people understand that the process of ERCs is incredibly malleable. It's not something static.

It's not something that you can... And I think you touched something really interesting. Like, is an ERC an outcome or a philosophy? And I think people get too caught up that an ERC is a specific approach rather than a specific outcome. Like, some ERCs that I've worked with have changed, like, four or five versions.

Like, if you go through the GitHub history, it looks nothing like it, version after version. But at least it had one number that everyone said, I am part of this ERC. I am sharing this ERC with the community. And one of the ways that has successfully happened this is people don't get too caught up of who are the offers. Like the best ERCs out there have like 10 to 20 offers.

The problem is when an ERC has like two or three offers. And then these two or three offers are saying, this is my ERC. And that basically becomes like a philosophical and almost like an ego journey rather than saying, we share this outcome. And I don't think you need to force your product to use an ERC, but I think your product needs to think that it will use an ERC and needs to be part of the journey early of the ERC so that you can comment and say, I don't like how this ERC is going. Here's my feedback from my own product experience.

And then you participate. And if you do that, I would add you as an offer right away just because you made a comment. Like, because now this is our ERC. And I think the way people do ERCs is the problem. It's not the ERCs themselves.

There's stages, there's draft, there's review, there's final call. Like, there's a whole product management of the ERC, and some people kind of just take it a little too personally. This is my ERC. And I just want to add, don't feel shy about continuing this subject, because I feel it touches on something which is very relevant to the advancement of UX in Ethereum, which is coordination, which is something that I think we can all agree is a challenge right now. But Derek, it seems like you have something you want to say, or I can continue.

I thought you raised your hand. So let's take this opportunity about ERCs, just one last thing maybe. There are a lot of ERCs in this ecosystem which are very beneficial for UX. Some of the people here are, I think most of the people here are authors or involved in those ERCs on some levels. So I want to take this opportunity if each one of you can share one ERC that they think is really interesting and important in the UX standard.

I know some of you what your answers will be, but I don't know if everybody knows what your answers will be. So it's a good chance to kind of maybe tell people about them. Keep it short, right? This is not about getting on a soapbox and giving a 10-minute lecture on your ERC, but just share what you think is important right now. Yeah, I mean, I think I'll probably give a pretty obvious one, but 7702 is really important to us.

We, you know... Oh, is it not on ERC? Oh, man. EIP, shoot. No, it can be in EIP as well.

That's fine. All right. We're going to go with 7702. Yeah, you know, there are a lot of users right now using EOAs that obviously we want to give them the benefits of AA, so we need to get those users migrated over. I'll be the last one.

You go first. All right. I have a banal example, ERC-20. We tried to kind of innovate a few years ago and use ERC-667. And I think ERC-20 is a good example of simplicity and you add complexity, you add hacks, people steal money.

We had to revert back to your C20. And it also shows that not the perfect protocol wins or not maybe the nicest. It's also about simplicity and HTTP2 is trying to replace HTTP1 for like two decades already, and people settled for the good enough. So I think if Ethereum is like kind of the HTTP of money, there's some stuff that need to be bedrock, and some stuff that are a lot trial and error, and think this is like the advantage of permissionless innovation, but some things need to stay simple. So, well, lately I have a crush on 7702 because it's like migrating all EOS to smart accounts.

But I think it started, UX started with 4337 for me because it enabled gasless payments, it enabled paymasters, bundlers, batch transactions, basically putting smart in accounts. I'm not super nice at remembering random numbers, but there's an ERC that gets wallet capabilities. Thank you. I like that one. That's from Wallet Connect.

But I really like the concept. It makes developers' lives easier. So when we talk about UX, we should not only think about the users, but we should also think about developers, the product people. And that hits the nail on its head. So yeah.

What's the name of the ERC with the plug-ins? Six. Six. 7579. 7579.

Yeah, yeah. 7579 and 6900. Those are the two. 6900. Yeah, yeah.

I think, I don't remember the exact number, but I think there are starting to be attempts. I think actually also one of them is by Wally Connects to solve a very you know, I think actually also, like one of them is by WalletConnect to solve a very important problem, which is the fact that as chain abstracted wallets becomes a thing, it's hard for the debt to correctly read the balance of the wallet, right? So if my wallet has 100 USDC on base. Seven, eight, one, one. Okay.

Seven on base, okay, 7811 apparently, yeah. And then, you know, so if my wallet has 100 USDC on base, but then I'm connecting to a polygon DAP, today there's no way for the DAP to know the fact that my wallet can actually pay the money, even though it doesn't appear to have money on Polygon, right? So I think there are a number of different approaches to solving this problem. So I'm generally excited about ERCs in that they try to solve the problem. I'm glad that everyone said a bunch of ERCs that I was going to say, so I can say the last one in my list, which is 7715, which allows wallets to grant permissions for the app to actually act on the behalf of the wallets with certain policies that are enforced by the smart contract.

Yeah, so session, you mean like session keys in a sense? Yeah, yeah, yeah, but more like smart sessions sessions because it doesn't necessarily have to be keys. Yeah, okay. Smart sessions, sorry. So going back to what Derek said about the...

Yeah, there's a question, but let's not derail it necessarily. So going back to what Derek said about the fragmentation of asset, that's also a very interesting topic as we get to chain abstraction. I'm going to move us away a little bit from ERCs. So when we're talking about chain abstraction and this kind of like fragmentation of assets, so we've seen some interesting solutions come out of it, usually using the word magic. There's magic, there's magic spend, and that's an interesting approach.

What are your thoughts on, you know, in general, about how do we solve this problem? Like what you said, Eric, that you go on one chain and you want to know how much balance you have on another chain, stuff like that. Sorry, so the question is how do we solve which problem? So the fragmentation of assets. I'm starting to shift a little bit more to talk about cross-chain.

Yeah, I think it's a very active research area right now. I think a lot of teams, I think Zero Dev, one of them, is very actively exploring the approaches. But generally speaking, the idea of a chain abstracted smart account is basically combining two technologies. Smart accounts and intent. So smart accounts and intents, right?

So we are starting to have very fast intents-based slash liquidity-based bridges, such as across, relay, blah, blah, blah, that can... So it's like basically, fundamentally, what this chain abstracted, what is that doing? I mean, not often, but a lot of them, what they're doing is they're essentially just bridging your assets through a liquidity bridge and then making the transaction, right? And because the liquidity bridge is so fast, your transaction time goes from maybe two seconds if it was on the same chain, to maybe four seconds if it's cross-chain, but it's still very much within the realm of what users are comfortable with. So there's a really high level, I guess, intro to how chain abstraction smart accounts work.

But there are many, many different approaches that I can dive into if we have time. So in this panel, I feel like there's a big focus on wallets, obviously, because of everyone who's involved. But chain abstraction actually comes with two problems. One is the authorization layer, which you just described on the intents. And I think there's been some good work in there.

But I think it's fundamentally blocked with the actual asset fragmentation. So the liquidity layer is really hard to optimize because even if you have the best intent structure in place and every wallet supports intents, tokens are completely fragmented. And that's another source of fragmentation that needs to be solved. But I would say that everyone in this panel actually is not default for that because it's out of scope of everyone else's project. Token fragmentation is something that needs to be solved at the bridge, blockchain, and token issuer layer, and that actually would make intents substantially much easier to design because every design with the tents is really really hard to do with like all of the token fragmentation and whether the token is bridge or is a native token and like if it's evm or non-evm it becomes really really hard and that's something that is completely blocking so when we think about the counter traction we really have to think single chain because the moment it becomes multi-chain there's multiple problems to solve one of them being intense and account management across chain but the token fragmentation is quite a heavy problem just to clarify like when we say token fragmentation you're talking about like you're talking about the fact that for for example forC there's like native USDC, USDC, is that what you're talking about?

There's actually two problems to it, right? So when you think about the token, what do you guys think? A ticker. Like ticker is the thing that defines a token. So let's say USDC.

How many USDCs are there? There should be only one, right? As a user, I only care about USDC. You don't go and think like how many types of euros or dollars or pounds exist. Like there's only one version of it.

That's not true in blockchain. Like USDC, even though they did this massive upgrade for USDC v2, where they tried to make it as native as possible across multiple chains, it's still not truly native. This is like probably the most interoperable token in this space, and it's still not native everywhere. So that means that in the tokens which is not native, there's like bridged versions of it. And for every bridged version of it, you could have multiple USDC versions in the same chain.

So you don't even know if it has the same address, if it has the same liquidity, if it has the same risk assumptions, because it's bridged through different issuers, and this issuer bridge fragmentation causes a token fragmentation. So I think that one of the things that we're ignoring is, like, the reason L2s exist right now is because people want cheaper gas. But I think different types of customers will use different L2s and there will be different types of transactions and different types of tokens. And I think some people want to move a million dollars across continents and they need the trust guarantees of an L1 and they need to be the most secure way to transfer value. And some other people want to pay $5 for a coffee and they want to be able to maybe reverse this transaction and they need instant clearing.

They don't want to put anything on chain because what's the point of announcing a global settlement network that they bought coffee and so I feel like there's like a maximalist approach in in crypto where everything needs to be like I think we we had this debate in 2017 with private blockchains you know it was this false dichotomy let's put everything on the blockchain let's put nothing they needs to be decentralized nothing needs to be decentralized, nothing needs to be decentralized. And right now we're trying to find the sweet spot in the middle, but really I don't see anyone talking about, I don't know, off-chain transactions, really. We're not even at this stage. I think we're at the layer two, and what I'm talking about is layer three, four, five, and finance is built by layers. So we're not even at the point where we actually need to address those issues yet.

So that's my take. Like fragmentation is not really like a big problem until we have all those use cases trying to work on the same L1, trying to settle to the same L1. I think you're right that the motivation for the fragmentation was like cheaper gas and more accessibility for these tokens. But the actual problem was caused early on when we're designing everything around the blockchain and not around the asset. Because if you designed assets to be like a primitive of the blockchain then they would actually be treated differently like for example with ethereum we have a very different use case it's the native currency in pretty much all evms so you do not have this problem with token fragmentation as much because it's treated as a special asset because tokens are treated just like any other smart contract.

They end up inheriting all the problems that smart contracts have in fragmenting across chains. So if tokens are treated as a special class in the blockchain, you can still benefit from all the cheap or private versions of the token, but still have one canonical version of the token. And that actually is what caused the problem, even though the motivation for fragmentation was cheaper gas, privacy, and all of that. I just want to add something else to the mix when we're talking about this fragmentation. There's also an additional fragmentation that comes about with smart contract wallets, which unfortunately, this wasn't a problem with EOAs due to their simplicity, which is the key fragmentation as well.

Now we have additional issues with the fact that you have to deploy the smart contract on each network, and if a network you haven't deployed it on, your key is in a sense could be still valid for it without your knowledge. If you replace your key now, you have to replace it even on networks that haven't been created yet and it's kind of like a funky situation. I'd love to hear your thoughts also on that in addition. Do you think that's also something that we'll solve with additional layers or actually we have to go back to layer one and put everything there or a different L2 or what do you think about the key identity fragmentation as well alongside everything else we've been talking about. Yeah, I'll go real quick.

Yeah, I think this is a big issue that we're seeing because users, the way a lot of smart wallets are built right now is just through a passkey that is inherent across all chains because when the account's deployed, it's the owner on the account. But as you want to add new signers and whatever risk profile the user may have, they want to secure their account. We need to make sure that these signers are valid across all chains, which is a hard problem to solve. One thing that I'm excited about is minimal keystore rollups that Vitalik has talked about too, where we can sync these changes across chains. I don't think we're there yet implementation-wise, but I think there's a pathway to get there.

Yeah, I think keystores are generally recognized to be the end game to solving their problem. So I think, actually, been chatting with a few teams at DEF CON who are working on key stores. My impression is that I think people are optimistic that by Q2 next year, we'll have production-ready key stores. So I think the one that BASE is working on is actually one of the most promising solutions right now. So once you have a key store, there won't be a problem anymore.

Yeah, I think key store roll-ups is definitely the answer. But each day, a new L2 is announced, and somewhere out there, somebody's day a new L2 is announced and somewhere out there somebody is still announcing an L2. And I think the one that brings it all together or converges everything will probably be a key store rollup. Hopefully we don't mess it up again by changing the philosophy or something like that with key store rollups. But divided identity, I'm not sure if it's still 100% going to be solved with key store rollupsups but divided identity I'm not sure if it's still 100% going to be solved with key store roll-ups but definitely an effort in that direction and something I'd say fear very actively looking into one thing that I can add is that trying to imagine how a billion people using blockchains will look like, and trying to kind of reverse from that, like reverse engineer from that, it's really a difficult exercise.

And I do think that L2s in the future would be sort of the equivalent of spinning up a server. You know, you can buy or you can rent. So if you don't want to have your own dedicated infrastructure, then you can just use a public cloud. And for open banking, it's a real big challenge to build public banking clouds. So I think that, you know, a billion people using blockchains probably means there's going to be a lot more.

You know, all the jobs we see today is Web2. Product is a Web2 concept. SEO promoters didn't exist before Web2. Community managers didn't exist before Web2. Community managers didn't exist before Web2.

Web2 created a lot of new jobs that we didn't really imagine even 20 years ago. So I think that the problems that we think are the problems are not necessarily what we need to solve to get to to billion people. So that's my take. It's a bit abstract. Yeah, I just want to maybe add a few words about key stores.

I think there are actually two problems with key stores that are relatively unsolved. So one is the economics of key stores. Someone needs to be running the key store operator, and since the key store rollup is gonna be a ZK rollup, the cost of running it is not gonna be trivial. So I think, I still haven't met a team that is building key store rollup, but also has a good answer as to how they're going to make that, to make keeping that key store rollup running economically sustainable. You know, so I'm just curious if like anyone, even in the audience, you know, who has some thoughts about it.

I mean, it's very hard to spin up a new blockchain and even an L2. So we're basically kind of just bootstrapping as EVMs, but let's be honest. Do we really need an EVM for a keystore rollup? We don't. Like, we could make, like, the whole cost of a keystore rollup, like, 10 times or 100 times cheaper if it's, like, a specialized machine that, like, virtual machine that literally just does keystore mappings and management.

Like, that is the solution. But as you said, like, we have to work with what we have, and we'll use EVMs, and we'll cost 100 times more than it's necessary. But then one day we'll realize, oh, we have this roll-up that runs three smart contracts. Just encode the three smart contracts into the actual machine code. Go as close to the machine as possible and don't do Turing-complete smart contracts.

It's all unnecessary. So you're saying basically hopefully like 10 years from now this is just like an inherent cost when anyone is paying for a transaction they're in a way subsidizing the key management of everybody or something like that? Which I tend to agree by the way because that is something I tried to tackle back in like 2018 2019 with Porus and it just didn't make sense. Who's going to pay for this? The user won't pay for managing their keys, the dApps won't.

Who should? So you're saying the network should? No, like I'm saying that the keyster rollup, first of all, we're kind of like exaggerating the cost of a keyster rollup. You only need to touch it every time you need to update it. Like if you add the new device or if you add the new chain, that's when you actually need to touch the Keystore rollup.

It's not like you need to touch it at every transaction. But the point is exactly that since there are so few actual key updates operations, the sequencer, the operator of the rollup is not gonna make enough revenue to offset the cost of running the- But we just said we're going to do 1 billion users. That's a lot of Keystore updates. That's like a business in itself. But even if it's not updates, just maintaining the data, keeping it high availability for everybody.

And there's even the security element around that. You don't want to just... It needs to be on the network, which is... There's a financial motivation to keep it secure because that's the best way to secure right now. Fireblocks was a blockchain.

Fireblocks was a blockchain? You got to... Look at him, so happy. He's so happy now. I love that question.

I hope Fireblocks likes it. Yeah, for the audience back home, he said he loves that question. Okay, so do you guys want to keep talking? I think that guy wants to say something. Oh, sorry, yes.

You want to... Oh, okay. I actually wanted to make a weird plug pitch announcement thing. You were speaking earlier about EIPs and standards, and I always like to emphasize belligerently that EIPs are not standards even if they're final and implemented. Only node level EIPs become standards because they get hard-forked in.

Anything above is opt-in. It's never standardized. EIPs are just specifications that went through a process and got published. So UX ideas, user stories, mock-ups, flows can be EIPs. They can go through the document process.

ERCs. Sorry, they can be ERCs. Well, can be EIPs. They can go through the document process. ERCs.

Sorry, they could be ER... Well, ERCs is sunset. Anyways, they could be published as documents by the process. So you can use Ethereum Magicians to put out user stories, multiple solutions to one problem, definitions of a problem. These are all things that you can do in the open to design in the open or to rally developers around an idea.

Something becomes a standard when there are multiple competing companies or even entire ecosystems using the same design. But it being a final ERC doesn't make it a standard. It just makes it a design that was published. So as the guy on ETH Magicians who reads every single thread about UX, just put UX in the title. I will see it.

I will give feedback to anything about UX. Like, please design in public, everyone. Zero sub-economics isn't the best way to do design. So you're actually raising an interesting point. The person controlling the question from the audience can scroll down, please.

I saw a question before that was actually relevant. It's kind of like a counter-argument to what you're saying. I want to hear your thoughts on that. Can you scroll down, please? So can someone actually vote on that question so it goes to the top?

Can you? Oh, yeah. Here it is. scroll a little bit up just a little bit up too much uh no go go back up you had the question it was just like you scroll too much down a little bit more oh there it is so um i guess it starts there so you're someone asked like what's your thought on product like product-led protocol development is erC's convention the reason we have not so many apps? Why no ERC equivalents in Web 2?

Product market fit is already so hard. Why focus on standardizing pre-product market fit? I will say that the equivalent in Web 2, I guess, is RFCs. Yeah, but RFCs are also usually something. You don't just spin out an RFC for every little thought that people have, right?

It's like usually... Yeah, but it's like, no, but I'm saying it's an interesting question because you might even say, you know, in a way, maybe it dilutes the meaning of an ERC or an EAP. If every random thought in one person's head, is this the way we want to truly collaborate right from every little thought that a person has? I think that's an interesting question. It's a really good question.

It's actually three questions. But I think that one of the interesting things about RFPs is that they were monetized by big corporations. There was a lot of HTTP standards. And nobody's doing that with ERCs. No, that's the whole idea.

So basically what happened with OAuth, for instance, is that it was created by this public standards body and then Facebook monetized it. And it's literally how it came to be used. OIDC. I think it means OIDC more. Facebook totally conquered OIDC.

Yeah, yeah. OAuth or OATC. I think it means OIDC more like Facebook totally conquered OIDC yeah, yeah, OAuth or OATC yeah, yeah I think that Web3 has a lot more rapid a lot more open a lot more democratic approach