Simplifying Smart Wallets: ERC 1271 and ERC 6492 Explained

Itai Turbahn, CEO of Dynamic, delves into the significance of ERC 1271 and ERC 6492 in the smart wallet revolution and account abstraction on ETHGLobal online. Dynamic actively engages with ERC 1271, aiming to simplify account abstraction complexities for users. In this session, Itai explains regular signatures, and the challenges of smart contract wallets, and introduces ERC 1271 as a solution. He also touches on ERC 6492, which verifies signatures for yet-to-be-deployed contracts. Itai advises against DIY implementation, suggesting the use of existing tools. He concludes by stressing the importance of these ERCs for DApps, with a focus on user experience.

Watch it in full here or read full transcription below.

Read the transcript:

We will talk today about two ERCs actually. ERC 1271, which is the topic is about, but also ERC 6492, which is important, especially within an account abstraction world and we'll get to it, but it deals with contracts that have not yet been deployed.

We'll start with a couple of things on the agenda. Let's see if this works. We'll talk about Dynamic, which is the company I'm the co-founder of just in 60 seconds so you guys have context as to why I'm here and actually talking to you. We'll talk about the smart wallet revolution and why these are important EIP's and essentially RC's. We'll talk about some of the challenges with signing with smart contracts. We'll talk about the two solutions and we will leave you with hopefully an optimistic note about the future. But with that, real quick about Dynamics, I'm Itai Turbahn, the co-founder. Dynamic has been around for about two years. We're backed by a16z, and First Round Capital, and Solana, and Circle, and a bunch of other amazing folks. And really what we do is an all-in-one authentication platform. If you go on sound, or token proof, or Anomoca, or Alongside, or Parcell, or Doodles and you click log in, that's powered by Dynamic.

You can either create embedded wallets or you can log in with third-party wallets. In the context of why I'm telling you this is because we deal with ERC 1271 on a day-to-day basis. We have to deal as a provider to DAPs. We have to ensure that if someone comes in with a smart contract wallet, they can sign into that DAP. That's the context for why I'm here and why I'm talking about this. Just so folks know the Dynamic product I do not mean this as a sales pitch at all though. I wouldn't be a founder if I didn't at least mention the company that I work for. This is what Dynamic looks like. It's essentially a multi-chain wallet adapter on steroids. You can do a bunch of really cool things with it and if anyone ever wants to talk about it, let me know.

But this is the last, I'll talk about us until the very end and we'll actually talk about the topic at hand. If anyone has been in Web3 for the last year and has been living under a rock, then you might not know. But besides that, the smart contract wallets are coming and really what we think will happen over the next couple of years, and the reason these ERCs are important is that the web is moving to account- abstraction-based world. It's essentially a combination of a couple of really cool things. The ability for you to spin up a private public key type system for users, a wallet per user, but also make that wallet super smart. Make that wallet something that can do a bunch of really great things. In our vision and the way we see the world is that if you fast forward a couple of years, every app on your phone has some smart contract wallet tap to it. It might be hidden, you might not know it exists, but it will be there and it will allow you to interact with other apps. It'll allow you to transfer money, it'll allow you to interact with games, and so on. Sometimes behind the scenes, sometimes in center stage, but that's the world we're living and moving to.

And that creates a bunch of really cool opportunities, but a lot of really challenging problems. And if we think about account abstraction, we at Dynamic are divided into two types of wallets. We think about branded wallets. Wallets like Sequence, or Argent, or Embriar and others and some multiple up and coming ones that essentially are a wallet that you have on your phone. You pull it up, but it is a smart contract wallet. It is not just an EOA, just a single private public key and some basic stuff on top of it, but it's a contract that has been deployed or is about to be deployed.

They'll let you interact with other contracts on chain. And that's one category. The second category that we think about is a fascinating category where we spend more of our time is the embedded wallet category. How can you log in with an email or social to an account and spin up as part of it, a smart contract wallet that lets you sponsor gas for your users, lets you create session keys, social login and so on. And there you have really interesting players like Xeradev, like Alkabe that just announced some cool stuff over the last couple of days there. And that's where we're going to focus a little bit more.

Now if anyone's interested in the account abstraction side, and again, these are all just context for why ERC 1271 is important. You have this massive ecosystem that's spinning up. You have wallet SDKs, you have smart wallet apps, you have gaming focus SDKs, infra. It's a pretty healthy ecosystem that's growing in order to make everything an account abstraction wallet.

Now, by the way, this is an extremely long monologue. It sounds like we'll take questions at the end, but please note them down and ask me anything. As you can tell by now, I can talk for a very long time. In the end, please stop me and ask me actual questions about all this stuff. Let's continue.

The last thing before I dive into the details is, as developers, we should be focused on creating flows that people want. And if you take nothing else away from this conversation, take a single thing which is no one besides us cares about account abstraction. And no one besides us, developers cares about EIP or ERC 1271. And that inherently means everything we're going to talk about is about how you abstract that away from end users. No one cares, no one should care, no one should care that you log in with your Google and you're using OAS, no one should care. And that is one key takeaway I want to make sure everyone gets as we dive into the details. Let's talk about the actual details.

The very basic premise is the following. When you want to sign a message, as in for instance, sign in with Ethereum, you generate Anon's and we'll go through it and you have an EOA or a regular wallet sign, and return it, you verify it and you're good to go. The problem is in a smart contract wallet, the signer is the contract, not the private public key that is the signer for the contract. The second challenge there is because smart contract wallets have all this cool functionality around signers, there's no standardization for what can be used as a signer. There isn't a standard validation method. Unlike an EOA, an externally owned account, a basic account that can use ECDSA and keep it to the very basics, there's no standardization around smart contract wallets and how signing works.

Now, I'll say one more thing here, which I'm not going to go into details in this deck, but there are some interesting blog posts out there about it, which is this is doubly true for things like safes where it's not just an account abstraction wallet, but it has multiple signers. There is an async nature to it. When you deal with smart contract wallets as compared to externally owned accounts, you inherently deal with an order of magnitude more complexity as to what can be accepted as a signature. And that is what inherently ERC 1271 tries to solve. At the very basic level, it tries to create some method that allows you the DAP developer to verify a signature from a smart contract.

Let's talk through what that means. How regular signatures work, and we alluded to this, but let's dive in. The server requests a unique message with anons to sign. There's a hashing component and then the end user using their private key signs the message in Anon's, signs the hash essentially, and then the server using the EC recover method can actually just validate that and they're done. That inherently means what that means to an end user is they go into a website, they click log in with MetaMask, they have sign in with Ethereum popup, they sign a message and they are good to go. They finish the process.

Now again, with smart contract wallets, it doesn't work that way. This is where ERC 1271 comes in. Who needs it? What is it used for? It's implemented by DAPs, it's implemented by OpenSea, by sound.xyz by Fair.xyz. Any company that is big enough and supports wallets usually has an implementation of ERC 1271. They either have done it on their own or they use a service like Dynamic or other services similar to that. What this EIP does and proposal does is the following, it introduces into the smart contract and is a valid signature function, which the DAP can call and get a standard response as to sign and verify ownership of the contract. And we'll see the function here in a second. But the basic idea is that it introduces the ability to adjust and is valid signature type function and check the signature using that versus using EC Recover.

At the very, very basic level, what you're doing is you're introducing an if statement where you check, "Hey, does this signature match a regular EOA wallet or it's a smart contract wallet signature." If it's EOA, use this method to verify it. If it's a smart contract wallet, use this method to verify it. At the very basic level, you're introducing a fork in the road for how you verify signature. The actual function here, and we will talk about it briefly, is on the left is the way in which the validation is done. Checking inherently whether the signature complies with is valid signature, and apologies for everyone for presenting code on screen and hoping everyone reads through it. I can send links at the end for where to actually dive into this.

But on the right you can inherently see that really what we're talking about, and hopefully you can see my mouse, is a function to validate signature that breaks and moves from just a single way to verify to an "if statement" that says, "Look, if you detect it's a smart contract wallet, verify using this method, otherwise verifying using this method." At the very basic level, you've introduced one fork in the road for how to verify things.

I've talked for a very long time. I'm going to pause for 10 seconds as people ingest this. Then we're going to continue to one more level of complexity. Now that we've done this, we have one more level of complexity, just to keep this interesting. What that inherently means is the following: With 4337, which is smart contract account abstraction, coming in what you see is this really, really cool method and bear with me for a second as I just let my dog in, otherwise you will hear barking for a very long time.

But what's really interesting is the following: With account abstraction coming in, you have this really cool feature that was introduced, which is counterfactual deployment. What that inherently says is the following: It says that I can actually get a contract wallet address, a public address for a smart contract wallet, before that is deployed on chain, before the contract is actually deployed. And that's really, really cool because it means that if I... Apologies, I am going to kick my dog out as we do this presentation.

Apologies again, but at the very basic level, and sorry about that everyone, at the very basic level, what that means is that if you log in with an email account or social account and generate a smart contract wallet, you delay deploying it on chain, you delay actually putting it on chain until later on in the life cycle, until you actually have to run your first transaction. And that saves significant gas costs. That essentially means that you don't have to actually take gas costs into account until very late in the process. That's really, really cool. But it creates a problem, which is how do you verify a signature of something that has not yet been deployed. How do you actually validate that a contract that has not been deployed can sign? And that's where ERC 6492 comes in. A second iteration of 1271 is 6492, which essentially gives you another method, an additional if to verify contracts that have not yet been deployed.

And that's really, really cool. And the way that works, and I'm taking here in full credit to the ZeroDev team for writing about this and Ambire team for coming up with a lot of this solution, and this is from the ZeroDev blog. At the very, very basic level, what you do is you introduce some contract that validates a signature or checks whether the contract is deployed on chain, checks the address type to see whether its sequence is an address that has not yet been deployed, a counterfactual address, and then essentially simulate running it and using an e-call to simulate running the contract and get the signature based on that. And then use his valid signature. Inherently what that means is a dapp looks at a smart contract while it has not yet been deployed, simulates it and then gets his valid signature in order to sign and validate the signature of that contract. It's a little bit of ninja tricks, but what it inherently does is it allows you to validate signatures for contracts that have not yet been deployed, which is really, really cool. It's not just about ERC 1271, but inherently what folks have to do is implement ERC 1271, followed by ERC 6492, in order to really cover the universe of verifying smart contract wallets.

Now I've been talking for a very long time. In a minute I'll pause and talk and take questions if anyone has those. And again, we can send resources at the end. But I will say one thing here, which is I would strongly, strongly, strongly recommend against doing any of this on your own. The idea is that you have Ethers and Veeam and you have libraries on top of that like Dynamic. And you have other options that do this for you. Unless you are Open C, or unless you're maybe Foundation, maybe one or two others, you should not need to implement this stuff on your own. You should be able to use tools that exist that already support this stuff out of the box. It is not a good use of your time to write, validate things and ensure they're validated correctly. There are additional complexities specifically with account abstraction here, which is a contract is deployed on specific chains so validating across multiple chains is extremely difficult.

And if you leave with nothing else here, hopefully you leave with the takeaway that when in doubt, don't implement this stuff on your own, but rather use providers, or use open source libraries to do that for you. And with that, a quick note about the future, and this is again a shameless plug for Dynamic just for a second, which is we fundamentally believe that what you're going to start seeing in the world is this combination of passkey-based login and account abstraction on top of it. You're going to start seeing a lot of these types of products that let a user log in with an email address, log in with social or log in straight with passkey, generate a two FA with passkey, and then at that point be able to spin up an account abstraction while it's on top of it.

And you're going to see the front text of the world, et cetera, really become wallets for all intensive purposes and really be able to interact with third-party sites just like a rainbow or a MetaMask would do. They would have a QR code, maybe a wallet connector, anything of that sort. This is becoming more and more relevant as everything inherently becomes a wallet, as everything creates a passkey plus account abstraction stack. These types of ERC's become critical for DAPs to implement. And I will leave you with an optimistic thing, which is this stuff should matter to us for any developer on the line that is deep into Web3. It should matter to you and to no one else. The idea is that this should be our secret. No one should know about ERC 1271. No one should know about additional ERCs. They should be invisible to end users. They should be invisible to 99% of developers. It should just work.

Just like if anyone has Web2 experience, no one should know about the nuances of SAML. No one should know about the nuances of OAuth. No one should know about the complexities of TOTPs. That is for us to know and for 99% of developers to just continue with their day to build the experiences they want. I think I have two main takeaways at this point. I will say this is the third one around ERC 1271, and so forth.

‍

‍

‍

‍