# The End Game Wallet: When Does Abstraction Go Too Far?

- Speakers: [GregTheGreek](https://streameth.org/speakers/gregthegreek)
- Channel: [Devcon 7 SEA](https://streameth.org/devcon_7_sea)
- Date: 2024-11-16
- Duration: 09:57
- Watch: https://streameth.org/watch/67385f911b0f83434d0e265a
- Download: https://vod-cdn.lp-playback.studio/raw/jxf4iblf6wlsyor6526t4tcmtmqa/catalyst-vod-com/hls/7b976wspisiatj3s/1080p0.mp4

## Description

The End Game Wallet: When Does Abstraction Go Too Far?

## About the speakers

### GregTheGreek

CPO & Co-Founder @ ChainSafe
Co-Founder @ Sygma Labs


## Transcript

Hey everybody. My name is Greg, or Greg the Greek if you know me online. I'm one of the co-founders of ChainSafe and as well as Sprinter. We recently rebranded a few days ago from Sigma. Today I'm going to be talking about the end game wallet. This is coming from about a year, well over one to two years worth of standards work. That's something I do a lot in my spare time. And it's something that we focus a lot at Sprinter is driving how we can look at like multi-chain and getting the UX there right. We don't have a wallet. We don't really do wallet infra. We work in solving, as well as we've been doing multi-building bridges since 2018, and we're protocol engineers at ChainSafe, and I was one myself for ETH 2.0. So I'm trying to remove as much bias as possible. I'm objectively looking at the standards when we go through here. So let's do a little, I want to do a little memory lane. I want to bring out a little pain. I don't know if many of you remember the world before EIP-1193, but this was when you'd download a new fancy wallet, and then all of a sudden no app would ever be able to work with it or communicate with it. If you were an app developer, you had to manually code in, communicate with MetaMask or communicate with fancy new wallet. There was a time when you couldn't even have multiple browser extensions and that was pre-multi-injector provider. There was also, I mean, this is still a problem. Let's be honest. We're still getting, we're getting close to aggregate balances that look nicer. So your UCC is better. Or how about network switching? Or even, you know, you go to adapt, immediate wallet pop-up. We've been iterating and fixing a lot of the UX challenges we see, and we see that the improvements have been happening over the last couple of years. These iterations have all come from ERCs, EIPs, and CAPEs. And that's why they're really important that we start adopting them. But frankly, where are we going right now? We're actually like, right now, the chain abstraction space has kind of fucked us. We are right now selling application developers that they need to deploy a smart contract wallet for their app to get the best features and the guest users. If you hear that statement, frankly, from my opinion, you're going down a road where you're going to have to do a very ugly migration path within six to 18 months, and it's just the wrong way to be dealing with smart contract wallets. Unless you, as the app developer, are willing to deploy wallet infra, and when I say wallet infra, I'm saying like a MyCrypto website, like a full rage quit mechanism so they can migrate to something different, to someone better. You're just vendor locking them inside your own system. Maybe inside the wider system of the deployer who gave you that. Because frankly, are you well equipped enough as an app developer to deploy preferences for the user's smart contract wallet? If they want to say, because we're going down an intense system, are you willing to express a preference for them to ensure that if they say, I want one ETH always to exist on mainnet, never take away that one ETH? You know, if I have two, it can go down to one. Are you ready to deploy that type of preferences and those type of feature sets to them? Because if you're not, you should never be giving them a smart contract wallet. You're setting them up for failure and you're setting your users up for an awful UX experience down the road. And frankly, it just creates fragmented balances and it doesn't get us anywhere. And the biggest problem we still have today is that, do we have any mobile app developers here? Have you ever tried to communicate with a smart contract wallet that was deployed by another team? Yeah, it doesn't work. It's impossible. We work with game developers. They can't connect to remote accounts. It's literally impossible. And that's because we've moved into a world of passkeys. Passkeys are domain separated. If ChainSafe issues you a passkey, only the ChainSafe.io domain can ever access that same passkey. So you need a way to talk to them. And that's where I'm going to be going with this. A quick note, and I'm going to be very, you know, this might be a bit of a lie, but like I think we're getting there. Within one to two years, we're probably going to see 90% of transactions will be solved. There's no doubt about that. We are going down that path and that's going to happen. So with that in mind, we have to think there's this big debate of smart wallet versus like dumb app and so on and so forth. Frankly, if the app is going multi-chain and you're interacting with different contracts on different chains, you are smart. You have to be smart. You have to know how to actually make and bridge those connections. Otherwise, the wallet's always smart. Let's be real. They need to be the one to ensure that the user is there because they need to be pulling that wallet in for what I was describing earlier. Now let's do this end game. I'm going to verbally abuse you with ERCs and that's totally fine. There's other sessions today that will help you learn about these ERCs more in deep. I'm going to go over them as quickly as I can, as effectively as I can and use Web2 examples so you can understand why they're important. These EIPs and ERCs and CAPEs are written by well over 20 plus people. So when I say there's like no bias in here, I'm just stitching this stuff together that we're talking about in the wallet meetups at every conference. Okay, here's your general interaction, right? DAP, wallet, very simple. We know we want to deploy 4337 everywhere. That's a given. It's the best UX we can get because we can't get native account abstraction. We know pass keys are the easiest way to onboard a user because seed phrases are too complicated, private keys are difficult, and frankly, the whole experience that we've been doing before is just because we in this room, frankly, are ahead of the curve. It's not gonna work for most people. Pass keys are a must, and they live at the wallet level. The next way to actually broker this system is to realize that your dApp's never gonna actually have a wallet, like a smart account. Your dApp's going to use an embedded wallet. Why? You can blind sign in the background as long as you have permission. That means you can actually maintain the same Web 2 experience you thought you needed. This means that you don't need to go and make a job posting that says, hey, I need a Web 3 designer. No, no, no, you just need a designer. No, no, no. You just need a designer. You need a really good designer that knows what they're doing. And that's it. You can build Web2 experiences. You can get a perp desk that looks like Robin Hood. There's no reason you can't do that. The embedded wall allows us to have that control. We need to know how to register people. Now, this is one that a lot of people don't realize. The CAPEs, Chain Agnostic Improvement Proposals, Greenfield playing field for not just EVM, but the whole spectrum of blockchain standards. CAPE 275 basically says, how can we get to a one-click onboarding? I type in gregthegreek.eth. It looks up to see who deployed my smart contract wallet for me. And from there, we generate a slug for an HTTP request or an iframe or whatever. And this is where the magic happens. ERC 755. 755 is the same thing as OAuth. It's the idea that it links you, when you click sign in with Google, it links you out to Google, right? Because I looked up in the registry who deployed this wallet, I can actually go in directly to that user, so I can use that pass key to get access to that 4337 account. And now I can use it with the embedded wallet on my app. But permissions. 7715. We stack a permission across the wire protocol. By stacking a permission across the wire protocol, what you end up getting now is you can be expressive. Hey, my perp desk wants to spend 1,000 USDC per hour and make it expire in 24 hours. What does that resemble? A JDBT token, something we're used to. We're making the app development cycle easier here. Finally, 7579, rhinestone team, big shout out. The idea here, your app wants to be a little bit more expressive. The smart account isn't what you want it to be. So you can develop a plugin, directly link it onto the smart account that you don't really know about. Finally, 7811, if anybody keeps up in standards here, you probably haven't kept up with this one. It got announced last week, and there's gonna be a lot built up on top of it. The simple gist, I want to know from the wallet, what are the assets? I don't want to use an indexer anymore. I'm tired of having to go and query, you know, an RPC node on a for loop over the assets I want to know about. Just tell me, what do you have? What's the balance of it? It's single chain. We're going to take a multi-chain. There's a lot of other ERCs that go on this. But the interesting thing, the one thing to keep in mind, 7555, it's super ambitious, very ambitious. We're not there yet. We're really close. We need all these other EIPs to get standardized on top. But once we do, the one thing we get is we get this communication channel that we've never had to a remote account the same way we do with OAuth. So when a Web2 user comes into the Web3 space, it looks like an app asking Google, hey, can I borrow your calendar information? But in this way, it's going to register plugins. It's going to ask for permission on how to spend wallets from your funds. This way, we're not depositing funds into, you know, Polymarket. Instead, you're just, they're borrowing them. And I think I'm running out of time. There's a timeline here. I'll skip to one end. I don't know. I got quoted two years from now the other day. I'm not going to lie. I think we can be a bit more ambitious. Frankly, we're not protocol developers. I was one previously. We don't need to go slow. We can go fast. We can break a bunch of shit along the way, and we can get to what we need. Thank you so much.