# Bringing your own cryptographic identity to smart accounts by Ernesto García | Devcon SEA

- Speakers: [Ernesto García](https://streameth.org/speakers/ernesto-garcia)
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 25:05
- Watch: https://streameth.org/watch/yt-wftGivq47QE
- YouTube: https://www.youtube.com/watch?v=wftGivq47QE

## Description

OpenZeppelin Contracts is the backbone behind some of the most important components behind Account Abstraction. In our efforts to improve the account development experience and amplify the design space, we're working on an Account Abstraction framework to securely develop ERC4337 accounts to comply with ERC-4337 and ERC-7562 validation rules for storage access and other related EIPs.

Speaker(s): Ernesto García
Skill level: Expert
Track: Developer Experience
Keywords: Identity, Cryptography, Account Abstraction, erc-4337

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] how's it going okay is it working perfect uh how's it going you're doing great perfect um okay so what we're going to do today is talk a little bit about smart accounts in the context of open seing contracts this has been a really requested feature that we had been working on for quite a while and we have a couple of things to discuss on regarding this so let's get into it all right so this is the agenda first we're going to start with some a little bit of background uh where are we starting from this uh from this work also how to do account abstraction like on a general perspective just as a quick recap of what account obstruction means then we're going to custom signature algorithms which is uh one of the main topics and is the thing that is like the most important about this this talk um we're to go over some technical goals we have for an account implementation in open selling contracts then we'll review a couple of security considerations we we have to understand to make better accounts and finally I will guide you through a quick way of how to build an account using open sing contracts um I'll let you know but like uh all of this code is already on Alpha so we will be releasing over the following weeks okay let's start with uh some some background the first thing you need to know is that we recently received a grant from theum Foundation to work on on account abstraction right so this means that we are going to make a a library that is consumable for you developers so you can use use open spelling contracts the the same way you have been doing it before and in this way you will have available like a couple of variants for making accounts uh extending accounts and also having some Primitives that you can use on your own accounts if you want right um given this context we started started doing some research and what we found out is that there is number one already a wide range of implementations right like we already know a couple of implementations out there some quite popular like Alchemy safe bomy and some others right so basically like all of these development that has already been made like we don't want to compete with that but we we would like to provide a way to also like create new accounts innovate on on top of these ones and also providing Primitives to also enable developers to build on top of those um second thing is that there are a couple of emerging secuity challenges that have come up because of the explosion of creation of accounts so we want to address those as well and having a clear framework for you to move forward when you're building an account the next thing is that there is a lack of an straightforward approach when you are trying to build your own account you basically have to research a lot of different implementations if each one has different modules or approaches to bring your own functionality so the idea is that you should be able to um have more expressivity on the way to design on an account and also you you should have like a a straightforward path right like the same way you use import erc20 and literally you use deploy it there should be something similar to that right so okay um our observations of this sort of research uh is that we would like to uh divide or layer the account implementation into like different layers um the first one should be like a base layer for ERC 4337 the thing with ERC 4337 is that it only defines like a very simple and what do you call it like yeah simple interface right and a set of rules but on the implementation things can get very different so we would like to have like a base layer for ERC 4237 account that is super solid battle tested as everything in open sing contracts is then from there we go to the validation layer which means um this is like the the place where you put the logic to validate a transaction right if you are using a regular eoa to sign a transaction and putting into an account this is where the logic for validating the signature should go uh we think this thin layer should be also kind of customizable and you guys should be able to bring your own uh functionality at this layer right although there is another layer which is the modularity layer right here in which there are a couple of competing eips or standards uh we think there is a lot of innovation coming on here and also happening right now here um so yeah we want to provide you like a way of using either a custom validation mechanism on the previous layer and also like a modularity approach if you want to finally the idea is that we have or we end up having a similar to a wizard like experience who has used wizard like open wizard from here all right so for those who don't have context open simping wizard is like our tool to build a smart contracts in an opinionated way so you can go to wizard. opening.com uh and you will see what I'm talking about so basically we would like you to come to uh wizard create your own account you select a couple of options and you're ready to go all right um talking about Mass adoption I think we have been very hyped about the fact that account obstruction is bringing a lot of opportunities to bring new people but there are a couple of challenges we need to address first so we'll we'll eventually get there uh but there are a couple things to do um in order to understand what we need to do there are a couple of related erc's and best practices you need to understand and follow the first one of course is ERC 4337 I mean is the base um the base ERC and it has a couple of rules that are quite interesting you know um all all that is related to pay masters aggregators all of that is quite complex we'll eventually get there too but for now we want to focus on the account side of 4337 then the second DRC to take into consideration is ERC 7562 which corresponds to the validation uh storage validation well not a storage uh there are a couple of validation rules for for 337 but the main or the most important ones in my opinion are the storage validation rules uh why is this important because there are some um what do you call it like setups in which you can create an account and basically you are violating some storage rules uh some storage validation rules why is this important because otherwise you wouldn't be able to use the decentralized uh peer-to-peer Network to process user operations you can still use um a private bundler that would be fine but ideally we would like to have an implementation that works out of the box with um the decentralized network and finally um ERC 7739 uh this is uh a thing we stumbled upon uh when we were implementing the account because basically uh there there are a couple of issues with replayability if two accounts own are owned by the same key I'll I'll get into that but this is a cool ERC to get to know more about like how to um bind a signature to an specific account implementation which is pretty important to avoid replab ility all right so let's get into how to do account obstruction just for a quick reminder uh remember that an smart account is is way more than just the validation mechanism right you can add modules you can have like custom logic all of that but ideally you will focus only on the validation logic if you are building your own account from scratch uh from this we have seen a couple of in amazing Innovations like CK email which is using your email to send a transaction from a smart account this is pretty clever um also CK identity we have seen a couple of options like using passports and these kind of uh this kind of things so this is why we think the validation logic layer is like an important part that should be extensible for developers because a lot of innovation is happening right here but it's being brought up as modules which is also a valid um a valid approach all right so ideally this is what you should do uh if you're you using open suppling contracts this is not public yet we're still working on that but this is like what we are uh trying to achieve as you can see it's only importing an account easy DSA in this case this is controlled by an eoa and there are a couple of things to note here um let's get into that so number one is this upgradable um not really the thing is that in order to create an account you probably will need a factory right and if you need a factory you basically need some way of initializing the account so upgradable contracts are perfect for initializing right they are basically designed for that and it doesn't mean that the account is upgradeable it just means that it's a clone that you deployed and then you initialized uh second thing is it is a draft uh well yes some of these ercs are still a draft so we have a couple of challenges there because we guarantee backwards compatibility for all of you so you don't have to manage or deal with that so based on this we wanted to uh or we want to provide you with an implementation but make it clear that it is still a draft couple of things of things may change and of course we will keep uh working on this and we appreciate the feedback um next thing is is it clonable yes because as I mentioned you need a factory and because of of this you basically need some way of cloning an account so that it is pretty cheap to just create and generate new instances of accounts right okay so let's get into custom Uh custom identities or custom signature algorithms which is the main the main thing we want to discuss here um so to get into this um let's explore a little bit on digital signatures right right now the majority of implementations of account already use some sort of validation mechanism or they accept something like ERC 1271 which is for smart contract validating signature validation so in this case then the most naive approach to bring your own cryptographic identity to an smart account is just use an interface like 1271 include the validation algorithm and then you're ready to go but in reality uh digital signatures are more than that and we have seen that for example a couple of traditional private uh sorry public infrastructures like in governments corporations Banks and these kind of environments these are already widely used it's just that is not used in the context of an a smart account so this is why it is important to bring your own cryptographic primitive because it it be it makes it easier for players in the industry let's say traditional Finance to just come here use the same key that we were probably using for authorizing transaction within their organization and they should be ready to go um so they are widely adopted as well and battle tested I'm adding a quote here because well uh it's not the same environment they have been around for years but you know like in Clos environments it's different to these um to the crypto industry with where everything is open source is pre battle tested so yeah I think this is a cool um it's a cool experiment but definitely we we need to see how it behaves over time all right um particularly with this thing the wide adoption of some digital signature schemes regularly means that is cool for regulation right there's some sort of Regulation around like traditional finance using access control mechanism so we can also leverage that for real use cases um right now in open sing contracts for signatures we already have three different signature algorithms available the first one is the good old uh ecdsa right the one that is controlled by an EA this is already there and has been there for a couple of years we recently implemented a p256 implementation this is in solidity and the reason why we did it is because we identifi that some change particularly some l2s may not have already enabled rip 7212 which is the one that uh validates this kind of signatures so because of that we came up with an implementation that we think is uh efficient enough and is well designed for you to use it but also if it detects that the pre-compile is available it will fall back to this pre-compile so you can use use it out of the box removing all of the considerations that you should you should have as a developer you use import it and use it as everything in open spelling contracts uh also we are adding an RSA Library this is because we have found a couple of uh government public infrastructures that depend on this particular algorithm so it is there for consumption also is pretty popular in some use cases like for example DNS SEC uh ens uh probably you have your ens but ens depends on this algorithm for some DNS providers so it's also a good primitive to have we already have it in open spelling contracts all right um for let let's um like recap a little bit on what a digital signature means just for you to understand a couple of issues that are coming so basically a cryptographic signature is just a message that you hash you generate like some piece of data by story2 and then you use a private key with a signature algorithm to produce a signature right eventually then you will use a public key and your signature with the same digest to uh pass it through a verification algorithm and it will return true or false depending on whether it was successful or not so the thing with this is that we can find out that there are two main algorithms in this number one there is a hashing algorithm and number two there is a signature algorithm right so this is important because um you as developers you probably will be constrained by whatever is an offchain is is offchain signer right usually people already have like a device a UV key some sort of uh software that doesn't depend on you and is probably using one of these custom hashing algorithms we're pretty used to use um kak 256 but in reality some signers like op chain signers for example the one you have on your iPhone the secure Enclave will'll try to use chat to 56 right so this this is not really a problem like we can just reash it but we think this is too opinionated and this is the sort of thing that we would like to have um more more contribution and opinions from you um this is basically the idea uh because some of the op chain um op chain signers are constrained to specific algorithms like we need to work around this right and this will happen um depending on how you compose your accounts uh is probably becoming a mess if we don't take care of like standardizing this or something similar so another thing to take into consideration is replab across same key accounts this is let's say you have account a account B and both are controlled by the same key well then there is the possibility in which if you sign a transaction to send let's say one ether to balik on one account that same signature can be used on your other account to transfer one it again to uh balik right this is not ideal this is an issue that was originally discovered by curious Apple um there is a good write up on the internet that you can also search just look for replab ility on Smart accounts you will find it so the idea uh to solve this is that we need some way of binding the signature to the current domain in which it it is used right so this is perfect to do um or sorry EIP 712 is is perfect for doing this uh are you familiar with EIP 712 okay I see a couple of hands for those who don't have any context uh EIP 712 is a way of constructing signatures with types basically you can uh sign a message that has an u in 256 type and a couple of others it's like a struct you can sign and what is special about this struct is is that it also includes the address of the current contract and also the chain ID which makes it um you cannot reply a signature because it is B to the current implementation that you're signing the message for right this is actually what ERC 7739 is proposing is like a way of rehashing a hash so that it adds some context for you to understand better what is going on instead of you signing an opaque signature an opaque hash sorry so all right next thing is um another thing to consider is that what if we want accounts to be owned by accounts so in theory this is possible like we have seen multi signatur schemes in which you have a single account owned by multi multiple accounts but in this case if an smart account wants to own another smart account it comes with a lot of gchas uh the first thing is like okay if B is owner of a what should B sign like should they just sign a message that is for the domain of b or should should it uh sign a message for the domain of a what if there is another domain like probably you're signing from B to authorize on a an interaction with an application C right so it it's starting to become a mess in this way and it's becoming a pack for whoever is signing this on their user s okay uh second issue like how how should we validate from a that the signature is correct from B right because this is this has to do with um storage validation rules in 4337 uh so yeah like for example if in the validation phase which is literally where use check signatures if you go to another contract and check storage let's say to uh record the public key then you are violating some of these rules right so these are some of the challenges that come in when you want to like add composability to accounts we we have we have found this as an issue and we of course want to work like to solve this um just a quick quote uh this is a uh this is a a popular yoke in you know computer science there are three not really four things in computer science and one of these is signatures in account abstraction wallets right um but yeah this is why we want your collaboration um and this is how we're doing it basically we have three main goals with our implementation we want it to be secure uh we want it to be layered and we also want it to make it extensible right we don't want you guys to start you open supping contracts and then become vendor locked in to whatever we have basically the idea is that you can uh take any of the components a user for your own implementations so that we can foster a barrier um Innovation space and also a more expressive what do you call way of creating accounts um for this there are a couple of security considerations like for example we want some audited building blocks for you to be safe whenever you you're building your account uh also we want to have a strong cryptography Primitives this have been audited by the research team at open zeppin so shout out to them they have been doing an amazing job number three replab ility issues as I mention number four we would like to maintain user operation reability we don't want the user to end up signing something they don't understand because this is super dangerous and number five we want it to be community-driven which means we we really want your feedback on this and try to C the development with the community so this is how we build an account um this is ideally the the sort of steps you you should follow so number one you pick a base account starting from account base which has a virtual function for validation right then you add your 7739 signer and from this you get immediate replayability protection then you just have to fill uh both virtual functions that are there one of these is the validate signature using ecdsa recover and you don't have to worry this already has the replab ility protection in in in place so whatever you receive as a hash is already bounded to the account number four use deploy and that that's it thank you so much is there any question thank you thank you so um now we're going to the Q&A section for those who want to ask any questions we have this uh QR code on the left scan it add your question and upv questions that are very interesting thank you ano for the uh talk now we're going to ask I think we're going to start with the popular question so the first one is why not incorporate uh all or as many popular algorithms so as to apply to as many uh external opinions and implementations right this is a great question um the honest answer is that it is really difficult to implement cryptographic schemes especially in solidity it comes with a couple of challenges so it's it's a it's a tiring process right we're open to receive contribution on that is just that it is exhaustive it takes time and we also have to audit those um also I forgot but at the end of the presentation there was a QR code for the community repository everything that you want to add like on the community side is welcome on that repository we have less um we we have more relaxed policies on that repository so everything is welcome from your side fantastic thank you very much now for the next question is uh would you be Implement uh you you would you be able to implement your own custom function such as TFA or social recovery yeah the short answer is yes the the long answer is that we would like to understand exactly what it means to have tofa right because what if we want to be compatible with like uh regular Web Two workflows or do we want something completely new that is EIP 712 based right these kind of things are like worth discussing but we eventually we'll get there fantastic um how can we solve fragmentation problem in RC 4337 good question um I would say having like a sort of what do you call like a a straightforward framework like a set of steps that are pretty clear enough to everyone we'll probably sort of solve it but in reality we already have implementation so I guess we we have to work out and sorry work around them which is like uh the usual what you call like wasting this the way things work right we just like continue building on top what is going on gotcha gotcha yeah um okay so for the next question there are few conflicting eips for plugins and modules will open zaplin uh take an opinion on these or will'll leave that up to the implementations also really good question uh we would like to have an opinion because we don't uh usually we try not to provide you with two versions of the same thing right but like we definitely need to experiment with this module uh modular standards to understand for which cases are better so probably our opinion will end up looking something like okay for these use cases you should use this ERC and for this other you should use this other but again uh we are implementing this on the community rep of open sabling contract so basically all of the ercs that are for for for modularity are very welcome to to be implemented in from contributions from you okay and we have one more question um if you want to ask more feel free to do it is it possible to create smart accounts that work with iPhone security Enclave so I guess with a a different um signature yes uh 100% the p256 algorithm that we just implemented is the one that is used by the securing clave so yeah you just need to create your account uh make sure uh that you can select well make sure that you're using the same hashing algorithm as is as in The Enclave this is just pretty easy just grab the the message or the hash in another hash and that's it but yeah the answer is is yes nice and I think I have one question from me um what's your favorite thing about account abstraction what's what like what you trying to solve overall for the uh General users yeah I think I'm excited about users bringing like usually users already have some way of authentication that they are familiar with and I'm I think I'm pretty excited of seeing all of these people bringing these into their own account so we can onboard people more easy fantastic Ernesto thank you again for the wonderful presentation on account um smart accounts and account abstraction please give him a round of applause thank you very much