# Usability changes in a post-EOA world - Speakers: [GregTheGreek](https://streameth.org/speakers/gregthegreek), [Cindy](https://streameth.org/speakers/cindy) - Channel: [Devcon 7 SEA](https://streameth.org/devcon_7_sea) - Date: 2024-11-14 - Duration: 24:03 - Watch: https://streameth.org/watch/6735e3f49dbb7a90e171c913 ## Description The wallet world has evolved to embrace contract accounts (4337 and 7702), app-owned wallets, session keys (CAIP-25), and permissions controls (7715). How might we on the app layer design and build upon these new account types? In this talk, I will demonstrate the possibilities for novel user flows given these new account standards, compare how these new standards can introduce pitfalls, and provide best practices on how to design for app layer in a post-7702 world. ## About the speakers ### GregTheGreek CPO & Co-Founder @ ChainSafe Co-Founder @ Sygma Labs ### Cindy I'm a designer, coder, researcher. I like talking about what can be done to advance user and developer experience for blockchain applications. ## Transcript So today we're giving a talk about what evolving standards, different account models, and how that changes usability. This talk is basically going to be about endgame wallets and the connection between wallets and dApps. Okay, sorry. All right, so a little bit of background of what the UX looks like today is that dApp UX today is constrained by the concept of the account model. So what that usually means is that when you visit a dApp, the purpose in life of that dApp is constrained by the thing that you're trying to do on chain, and also the private key signatures and how you interact with that dApp. All right. There are a lot of account abstraction talks, I realize, at this conference. So I don't want to spend too much time. But these are some properties that you get when you're signing with a single signature. So your entire account gets connected, key management is all on you, no native batching, and you have to have native gas tokens. These are the common pitfalls that I think most of us are familiar with. So no recovery or upgrades, signing a message for virtually every action that you have to do, and also having blocked experiences on dApps where you need to connect your wallet to be able to see a quote or you need to be able to connect before you do anything. All right. So what's at stake here is something that I'd like to call the appification of dApps. So instead of the dApp experience being one thing and then using a legacy app and being another thing, it would be great if they're more blended. And the properties of that would be enhanced security, smooth onboarding, and what I want to say, convergent applications where you're blending on-chain, off-chain, and cross-chain components. Oh, I'm blocking the QR code. I'm so sorry. Maybe I'll come over here. All right. So what I want to do now is give a tiny glimpse into what greater programmability and security on smart contract wallets actually looks like on a UI. I don't want it to be too detailed or implementation specific. So these are just general examples of what can be done in the future. All right. So with smart contract wallets, they can run code. And with that, you can get conditional logic. One use case that I think would be pretty interesting is like, let's say that you are a DAB and you manage portfolios and you want to add a security service that says if there is an on-chain condition that is met and we are able to prove that there is an exploit or there's a vulnerability in this DAB, please remove my exposure and unwind my positions. So in order to do this, you have to presign it and then you would be waiting for the condition to be met and then you won't have to unwind it manually as you do today. Other things you get with smart contract wallets, you can do cross-chain calling and balance aggregation because you can query the state of other contracts as a smart contract wallet. So this means that let's say I want to buy an NFT on Zora, and I only have funds on Optimism and Mainnet, this doesn't have to be a problem because we can aggregate the balance and bridge it for the user on their behalf. So this means that the click path is getting much lower, so you're not clicking as much and approving everything, looking for which bridge has the liquidity that you want, and numerous other things that we have to do today. Okay. This use case, this example is the most important one to get right because user ops are not highly adopted right now. It's still pretty early. So the thing that we need to nail is the onboarding and the issuing of the smart wallet. I mean the smart account. So what I say here is modular authentication allows users to define the dApps level of access. So this is not unlike when you sign in with Google, and Google is telling you, oh, when you're going to Calendly, I'd like to see your contacts and your calendar and what you have set up there. We could do this on chain as well with smart accounts. So in this example, I want to show that it's looking for a specific domain that you have set, and then it wants to request access to a spend limit or maybe usage of modules that this dApp wants to use. Okay, so those are some very high-level examples of what can be done in the future, or even now. So the upshot of all of this is that you can get better blending of off-chain, on-chain, and cross-chain components. This is a nod to the convergent application thing that I was talking about, so that dApps don't feel as single-purpose. The thing is, though, like many complex systems, when you introduce new solutions, you can also risk introducing new frictions. And I'll gloss over this very quickly. Now that we want fewer approvals, currently right now with the standards that we have is that you do migrate to a new account and funds get fragmented. Even though there's fewer approvals, that is a user friction that we might have to deal with. Obviously the evolving standards and there's different ways in which that we can try to deal with this. So there's also enhanced programmability. This means like the contract can run code. It's like currently the EOA, they don't have, like it can't actually read state or anything like that. So EOA is still initial signer for it. So that's another user friction that is possible. Gas abstraction, paying gas and other tokens other than the native token of the network. This is not gas optimized yet because we're still prior to 7702 being on Pectra, I think. And then we have account recovery. These can introduce unfamiliar user patterns. So the one that I, again, like the one that I want to focus on is the onboarding aspect, which would be the modular authentication, because there's a plethora of solutions that you can choose from for implementing the onboarding of smart accounts. And so I want to hand it over to Greg so that he can show you some best practices on how to implement a helpful experience. Thank you, Sydney. Sorry. Okay, perfect. Sorry, I forgot where we were at. How many people here are familiar with, like, the CAPEs, Chain-Agnostic Improvement Proposals? This is good. We need to change that. How many of you are familiar with EIPs? Keep your hand up. How many of you actively check the EIPs or the ERCs? How many of you are wallet developers? How many of you are applications as opposed to smart contract accounts? Yeah, we have to change all this. Basically, in order to get any of this done, we need to start focusing on standards more. And so I'm going to verbally assault you all with some very important ERCs and show you exactly how we get to, frankly, what's probably the end game wallet to dap interaction where those pieces fit together and how we do it. It's going to take a couple of ERCs, capes to get there. Frankly though they're all available. They're live and there's other versions being iterated on. So we're not too far away. It's just going to take some work because we need more people actively working and looking at standards. These are the main ones we're going to be talking about. 275, 4337, which we should all be familiar with, 7702, 7755, 17715, 7679, and RIP7575, which I'm not going to cover. Let's start, though, with some, like, visual stuff. And then I'll kind of stitch it together at the end. When you first go, this is a website that's live, basement.fun. When you first go to the website, you get to experience the entire website without ever needing to get a wallet prompt prompt without needing to actually install anything without even needing your funds the way they do that is by embedding a embed they put an embedded wallet behind the scenes for you and there's a reason they go with the embedded wallet behind the scenes it's because you don't have to actually they don't want to force you into a smart contract account right at the beginning because that would just cause further fragmentation if you come to the app later with your own account that has a smart contract wallet enabled. Now we're already just fragmenting. We're splitting up your accounts where they don't know about each other. So now you're having to maintain effectively two separate bank accounts. I don't know if anyone's done banking with two bank accounts, but it's, like, unenjoyable. So I don't know why we'd force our users to do it. Similarly, which is 7555 and K275, we have this issue. Do we have any mobile app developers here? Maybe mobile game developers? Have you ever tried to actually connect to somebody else's smart account or even someone else's external wallet? It's borderline impossible. And that's because you can't discover. The ability to discover a wallet and then know where it's deployed is practically impossible. That's what Cape275 tries to do. It's the idea that you basically look up gregthegreek.eth and instantaneously I'll figure out where the address is, what type of account is it, EOA, smart account, safe account, is it someone else's es. And we can then use a wire protocol, which is the Oeth one, to basically go and connect to them. Because we do know everyone's familiar with pass keys. We know that that's probably the best way to remove seed phrases. But how many of you know that your pass key is scoped to the website you issued it from? Or the app you issued it from? Or the app you issued it from? That means if I generate a public key from the passkey, it's only going to be found there. If I go to chainsafe.io and I issue passkeys that way, if I go to then sprinter.tech and try to issue a passkey there, I'll never get the same pub address. And this is a fundamentally big problem because we're all issuing pass keys with our smart accounts. So we need to create a way to bridge that gap. And that's what 7-triple-5 aims to do. And I'll get into it a little bit. We're going to stitch this all together. Don't worry. It's going to be less confusing, I promise. 7-7-1-5. This is pretty ‑‑ this is also an interesting one because what we do is we start to say, hey, if I'm going to remote into somebody else's smart account and I'm going to ask to use that smart account with a passkey that I don't have, I don't want to constantly go back and forth. The UX breaks. You're constantly flipping out of a mobile game that's supposed to keep you in the game, and now you're going out to sign every single time you need to do something. So what 7715 tries to do is basically says, hey, we're going to let a random key, aka this is where we tie the embedded wallet back into the picture, the embedded wallet can now act as a signer to the wallet for a given period of time. And if you're thinking about the Web2 model, this is a JWT token. All we've done is brought back the JWT and said put some cryptographic properties to it. And that's how we can maintain it. So you can maintain your UX in the app and use an embedded wallet. Now you don't need to deploy them in a smart contract account. You can use what they already have in preexisting infrastructure. Finally 7579, this is an interesting one. You do want a smart account feature. There's stuff that the smart account doesn't actually provide you. It's simply a plug-in. Build it as a plug-in. You tell the wallet to register the plug-in. You get the full benefit of deploying a smart contract account for someone without fragmenting their balance. You remain the existing experience. And the big thing to discuss here is, which I'll get into and then is it the next slide? No. Oh, yeah, it is the next slide. Perfect. And so this is these are all the EIPs. ERCs. That stitch it together. And what we'll do is we'll go through an interactive game of actually stitching together to show you kind of like how the end game in one to two years' time will actually look like. Because we have a lot of teams that are doing really good infrastructure work at the application layer, but frankly, because we don't have all of these things plumbed in, we are frankly setting up the applications for a little bit of failure and there's going to be a period in time where we're going to see mass migration of self-deploying app infrastructure outwards. And my main argument I have for this is there exists two spectrums of UX that we need to maintain as an app developer. There's your local app UX, which we have full control over, and that's why we're suggesting you deploy with embedded wallets, because you can fully control it. You can make your perp decks that's fully on-chain look and feel exactly like Robinhood. You can make your perp decks that's fully on chain look and feel exactly like Robin Hood. You get all the benefits. So there's no reason to go anywhere else. The other thing is we have wallet land UX. And most app developers think we don't have control over this. And that's where we're hoping to tell you something else. Because you do. You have to control that you don't change it. The minute you go and change someone else's experience of how they bank effectively with your app, it's breaking it. And when you deploy a smart account into the application layer, we've gone back to the old principle of, you know, think about like Starbucks. You have to put money into the Starbucks app. Your bank now no longer knows how much money. If you moved $100 in there, you don't know that you have your bank account value plus $100 that you have unspent in Starbucks. You just have minus 100. We have the ability to not do that. We have the ability to not fragment and deposit funds but rather borrow funds directly from the bank with a scoped permission. And that's what we're going to achieve here. So what do we need to do to get this done? The whole pipeline is going to look like this. We want people and wallet info teams to deploy 4337. We want them to be the smart account issuer. If they're not the smart account issuer, if the app ends up being the smart account issuer, you need to be able to let the user rage quit. You need to be able to set permissions. Like, are you comfortable as an app developer saying, oh, yeah, I want to make sure when I get into a chain-abstracted multi-chain future that the user always has one eth and mainnet because they always want to make sure they have gas to pull out some Aave positions or compound positions that I don't know about. They might want that preference. But are you really ready to actually deploy all that info or do you just want to focus on your app? Let the wallet handle that part. We then always pass keys are the way to go. It's already like this today. And it's only going to get better. We have solutions to do like multi-account pass keys where the address persists. The app is where you're going to deploy the embedded wallet. Within that app, we see CAPE 275 come in. And I want to think about clicks, so keep your hand up thinking about the clicks we're going to do here. When the user first auths onto your website, they're going to type in their identifier, email, phone number, ENS name. They'll click enter once. I'll then go and look up in the registry, you figure out who issued it, who their provider is, the SmartCon account provider, and you go to that website directly. This is now going to look like an iframe. This is what 7755 does. Think about that iframe you're used to, you know, when Google says, hey, someone says can you log in with Google so I can get access to your calendar information. It's the exact same flow. That's going to pop up the destination where the smart account is. It might be the NOSA safe website. Once you get in there, along with that message, we're going to pass in 7715. That's now going to say, hey, I'm a perp desk. I want to trade 1,000 USDC every hour for the next 24 hours. That means your total bound is 24K worth of USDC that could be taken by this application but it's defined, strictly defined the same way Google strictly defines your log in process. 7579 I talked before. You want that extra smart contract functionality on the same wire protocol, the same 7555 wire protocol. That should be 7555. You'll be able to attach whatever else you need. You need that extra functionality as a plug-in. It's simple. You just add it in. The screen shows the exact same view. 7811, for anybody that follows standards, you probably haven't seen this yet. It came out a few days ago. But the simple thing is, you know, when you're an app, do you how many of you develop your app and then go, okay, cool, step one, hit the RPC for every available token balance that this user has? There's no need. It's already been done for you. The wallet knows what the user has available. And in a cross-chain, multi-chain world, the wallet also knows how much is available against other chains as well as what the spending power is. I have USDC. I need to use ETH to go buy an NFT. It knows that I can convert USDC. The app doesn't need to know about that. So this makes an extension for it. There's a plethora of other ones we can add on to here. But if you think about it, at the end of the day, what happens with this experience? Remember how I said to think about the number of clicks we did for the user here? There's two. We've reduced it to two. You go from looking up your account, automatically generating the pop-up iframe. If anybody's used Coinbase's wallet recently, there's that iframe that pops up. That's your OAuth window. The user clicks. One click, OAuth window is up. One more click to confirm. And now you have the full power of that smart account locally while only using an embedded wallet, and you can ensure the security remains constant because the permissions are there in place. And you now have the full flexibility. You never had to deploy account of any sort of wallet infra. You don't have to care about the wallet infra. You don't have to even care about what app, what type of implementation do they have because you can attach the plug-in you need. So you can ensure as long as they're 4.3.3.7 compatible, you can boot in anything else you want. You don't have to go and deploy them a custom implementation. Your onboarding experience, just 10x's right out of the gate. This is what the end game realistically will look like. How close are we? We started with 7.5.5. Realized we needed 7.1.5. 715. This one is almost done. There's a few last little things needed. Modules by rhinestones been done forever and frankly if you haven't looked at them, you should. This will be pretty quick. 275 is live. Lit's using it. And we already know we've got pass keys and 437. We just need the permissions module to finish. And we need to get the main wallet providers to start adopting the slugs so that we can have those pop-ups happen. And you have a full OAuth journey that when you go to onboard your grandmother, it just looks, or your mother, it looks exactly like how they do by logging with Google. And you can issue all the infra underneath blindly. And so that's, this is the endgame for wallets. This is how we envision it. And frankly, we need more people looking at standards and helping just see what's out there and realize what they can do with what's available. Because all this already exists. We can have this. We can have a two-click journey, and you get a smart account without ever having to deal with that info yourself. Oh, there's more slides. Ah. Yeah. Time for a... I don't know. Yeah. Time for ground zero good Dapp experience. Thank you, guys. Let's keep in touch. Okay. We have time for questions. So if you have questions, you still can ask them. We have two questions already. So first question is what is that we're missing or need to change on layer one in order to enable better experiences for everyone and not just a specific layer two? Native account abstraction that doesn't look like 7702. Something more closer to 3074 that actually achieved its goal. There's a lot of chains that actually have that at the base layer. And 7702 is good. It's a migration tool. It's a stopgap. We're going to have to release more account abstraction features down the road, natively. But unfortunately, that's the biggest one. Okay. So our next question is about passkeys. You said that the problem with them is being scoped to specific sites, but later you said they're actually good, that we should use them. So what is the solution here? Two separate problems. So the one problem is that when I issue a passkey, you get a public,. Like when you do a passkey authentication, you know, face ID, touch ID, whatever it may be, that issues you a public address. And it works the same way that a YubiKey works. What happens is they basically say, cool, what's like the DNS record? And they match that DNS record to a new public key generated on the passkey chain. So the problem is if I go to another website, it's going to either get a new one or create a new passkey. And so you can never have that same address persisted through. And so that's why you have to push outwards. If you want access to the signing key of the smart account, you actually need to go to whoever generated the passkey in the first place. And that's why we need that OAuth window. The same way Google doesn't let you just like OAuth inside of an API call inside some random website. It would just be very insecure. Okay. Next question is if we connect our wallets to apps in this way that you described and there's all our savings on these wallets, is it going to be safe enough? How many of you trust Gnosis Safe? Or safe? Lovely. Do you trust safe to provide you the UI you need to ensure you're signing the right message? This isn't rhetorical. Okay, good. In that case, if you trust them to provide you the correct UI when you sign a message, why would they not provide you the correct UI when they say, hey, by the way, this thing's going to drain your account? Instead, it's going to say, hey, it just wants to spend like a thousand USDC for the next like two hours. And then the token expires and they have to refresh that token. Same thing as a JWT with your bank. If you trust the people providing you the wallet, then you should have no problem actually using it in the system. It's the same problem with, it's exactly why I said, you as an app developer, are you actually comfortable deploying all this infra? Even the person giving you the smart account, are they giving you all the infra you need to ensure your users are safe? Push the barrier to the wallet. There's a last question, I think. Next question. In the endgame, are token ballots still held on external wallets or smart contract address? 4337. So, smart account. Okay. And banks often have the backup of support. Will the wallets provide the same backup? I mean, pick a good provider. MetaMask support is pretty good on Twitter. I think this question is really interesting. It's more like an insurance type of question. Because I think banks are like they have FDIC. It seems like this question is asking about support of user funds, which I think is external to wallets themselves. Or recovery mechanisms. Yeah, exactly. Okay, if there are no more questions, that's it. Please give it a round of applause for Greg and Cindy. Thank you.