Usability changes in a post-EOA world | Devcon SEA
Devcon·Thu, Oct 9, 2025, 12:00 AM
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, we 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. Speaker(s): Cindy, GregTheGreek Skill level: Intermediate Track: Usability Keywords: ux, wallet, Account Abstraction, Design, Key Management, UI/UX Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon Learn more about devcon: https://www.devcon.org/ Learn more about ethereum: https://ethereum.org/ Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more. Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024. Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/
Transcript
[Music] So today we're giving a talk about what evolving standards um different account models and how that changes usability okay this talk is basically going to be about endgame wallets and the connection between wallets and deps am I okay sorry all right so a little bit of background of what the ux looks like today is that dap ux today is constrained by the concept of the account model so what that usually means is that when you visit a Dap the purpose in life of that dab is constrained by the thing that you're trying to do on chain and also um the private key signatures and like how you interact with that dab all right there are a lot of account abstraction talk 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 um signing with a single signature so you know your entire account gets connected Key Management is all on you no native batching and yeah 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 message for virtually every action that you have to do and also having blocked experiences on daps 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 app ification of daps so instead of like the DAP experience being one thing and then using like a legacy app and being another thing it would be great if they're more Blended and the properties of that would would be enhanced security smooth onboarding and what I want to say say convergent applications where you're blending onchain offchain 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 while it's actually looks like on a UI I don't want it to be too um 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 onchain condition that is met and we are able to prove that there's an exploit or there's a vulnerability in this tab please remove my exposure and unwind my positions so in order to do this you have to pre-sign 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 does 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 is this example is the most important one to get right because user Ops are not like highly adopted right now it's still pretty early so the thing that we need to ma 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 daps level of access so this is not unlike when you sign in with Google and Google's 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 um it's looking for a specific domain that you have set and then it wants to request access to um a spend limit or maybe usage of modules that this dap wants to use okay so those are some very highlevel 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 offchain onchain and cross-chain components this is the a nod to the convergent application thing that I was talking about so that DBS don't feel a 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 is that 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 then that is a user friction that we might have to deal with obviously the evolving standard and there's different ways in which that we can try to deal with this so there's also enhanced programmability this means like uh they the contract can run code it's like currently the EA they don't have um like it can't actually read state or anything like that so uh EA is still initial signning for it so that's another user fiction that is possible gas abstraction paying gas in other tokens other than the native token of the network this is not gas optimized yet because we are uh we're still prior to 7702 being on Petra 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 um 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 of how to implement a helpful experience thank you Sydney sorry okay perfect sorry I forgot where to WRA um how many uh 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 of the erc's how many of you are wallet developers how many of you applications as boy 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 erc's and show you exactly how we get to frankly what's probably the endgame wallet to DAP interaction where those pieces fit together and how we do it it's going to take a couple erc's capes um 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 um these are the main ones we're going to be talking about uh I 275 4337 which we should all be familiar with 7702 77 that's supposed to be triple 5 one 7715 7679 and rip 7575 which I'm not going to cover let's start though with some like visual stuff um 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 um launched by B3 team when you first go to the website you get to experience the entire website without ever needing to get a log wallet prompt without needing to actually install anything without even needing your funds the way they do that is by embedding a uh embed uh 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 kind 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 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 75 and Cape 275 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 cuz you can't discover the ability to discover a wallet and then know where it's deployed is is practically impossible that's what Cape 275 tries to do it's the idea that you basically look up Greg theeg greek. eth and 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 isoteric implementation and we can then use a wire protocol which is the o 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 that means if I generate a public key from the pass key it's only going to be found there if I go to chainsa doio and I issue pass keys that way if I go to then Sprinter dotech and try to issue a pass key 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 cre a way to bridge that Gap and that's what 75 aims to do and I'll get into it a little about we're going to stitch this all together don't worry it's going to be less confusing I promise 7715 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 pass key that I don't have I don't want to constantly go back and forth the ux breaks you're constantly flipping out of like a mobile game that's supposed to be pretty like non 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 it 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 web 2 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 Main maintain your ux in the app and use an embedded wallet now you don't need to deploy them a smart contract account you can use what they already have in pre-existing infrastructure finally 7579 this is an interesting one you do want a smart account features there's stuff that the smart account doesn't actually provide you it's simply a plugin build it as a plugin you tell the wallet to register the plugin you get the full benefit of deploying a smart contract account for someone without fragmenting their balance you get you remain the the existing experience and the and the big thing to discuss here is which I'll get into and then is it the next slide no uh oh yeah it is the next slide perfect and so this is these are all the eips erc's um that Stitch it together what we'll do is we'll go through a little interactive game of actually stitching together to show you kind of like how the endgame 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're 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 like 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 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 per 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 after 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 you know 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 uh 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 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 be looked like this we want people and wallet INF for 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 rage 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 Ethan main net because they always want to make sure they have gas to pull out some a 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 infra or do you just want to focus on your app let the wallet handle that part we then always Pas keys are the way to go it's going to it's already like this today and it's only going to get better we have solutions to do like multiac account pass keys where the address persists the wallet 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 offs 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 you then 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 77 75 does think about that iframe you're used to you know when Google says hey can you 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 you know the destination where the smart account is it might be the NOA safe website once you get in there along with that message we're going to pass in 771 five that's now going to say hey I'm a per desk I want to trade a th000 usdc every hour for the next 24 hours that means your total bound is 24K worth of usdc that could be you know taken by this application but definely strictly defined the same way Google strictly defines your login process 7579 I talked before you know you want that extra smart contract functionality on the same wire protocol the same 75 wire protocol that should be 75 you'll be able to attach whatever else you need you need that extra functionality as a plugin it's it's simple you just add it in the O off screen shows the exact same you know same view 7811 for anybody that follows standards you probably haven't seen this yet it came out like a few days ago but like 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 R hit the RPC for like 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 know 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 uscc the app doesn't need to know about that so this makes an extension for it there's a pleural 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 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 popup iframe if anybody's used coinbase which is bases wallet recently there's that if frame that pops up that's your ooth window the user clicks one click ooth windows 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 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 plugin you need so you can ensure even as long as they're 4337 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 10 X's right out of the gate this is what the end game realistically will look like how close are we we started with 7 tri5 realized we needed 715 this one's almost done there's a few last little things needed modules by rhinestone has been done forever and frankly if you haven't looked at them you should this will be pretty quick 275 is live lits using it and we already know we've got pass keys in 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 popups happen and you have a full ooth Journey that when you go to on board 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 end game for wallets this is how we envision it um and frankly you know we need more people looking at standards and helping just like see what's out there and realize like what they can do with what's available cuz 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 in for yourself um oh there's more slides ah yeah time for you want to do that I don't know yeah like yeah time for Ground Zero good dab experience thank you guys let's keep in touch okay we have uh time for questions so if you have questions you still uh can ask them we have two questions already uh so first question is what is that we missing or need to change on layer one in order to enable better experiences for every and not just a specific Layer Two native account abstraction that doesn't look like 7702 something like more closer to 3074 that actually achieved its goal there's a lot of uh chains that actually have that at the base layer and uh 772 is good it's a migration tool it's a stop Gap we're going to have to release more account abstraction features down the road natively um but unfortunately that's like the biggest one okay so uh next question is about pys you said that the problem with them is being scoped to specific sites uh 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 prom is that when I issue a pass key you get a public key like when you do a pass key authentication you know face ID Touch ID whatever it may be that issues you a public address and it it works the same way that a UB key works and what happens is they basically say cool what's like the DNS record and they match that DNS record to a new publicly generated on the pass keychain so the problem is if I go to another website it's going to make either get a new one or create a new Pass Key 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 pass key in the first place and that's why we need that ooth Windows the same way Google doesn't let you just like ooth inside of like an API call inside some random website it would just be very insecure okay uh next question is um if we connect our wallets to apps in this way that you describe and there's all our savings on these wallets is it going to be safe enough how many of you trust NOS is 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 th000 usdc for the next like two hours and then it 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 like it's exactly why I said you you as an app developer are you actually comfortable deploying all this infra even the per the person giving you smart account are they giving you all the infa you need to Ure your users are safe push the barrier to the wallet there's the last question I think um next question uh in the end game are token ballan is still held on external wallet or smart contract address 4337 so smart account okay and uh Banks often have the backup of support uh will the wallets provide the same backup I mean pick a good provider metam Mass support's pretty good on Twitter I don't know 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 is the question it seems like this question is asking about like support of user funds which I think is external to wallets themselves or recovery mechanisms yeah exactly okay if there are no more questions uh that's it please give it with a round of applause for Greg and Cindy thank you
Automatic transcript — names and jargon may be misspelled.