Smart Accounts in Production: What We Learned the Hard Way

Transcript

[music] [music] Yeah. Hello Don. It's nice to be here and also good morning. We will today talk about how smart accounts behave against real users in production and we will tell our experience about what we had, what worked well and where we see still there is a gap for some improvements.

Let me start introducing oursel. I'm Lush and my friend Alim. We have been working on account abstraction for around three years. Our journey has started by co-authoring [snorts] RIP 7212 which brought Pesky and R1 curve elliptic curve verification onchain to Ethereum and other EVM chains. Then we have built clave on top of this RIP by bringing a mobile experience a self-custodial mobile experience on ZK sync native account abstraction. Then we moved this journey to

becoming a crosschain wallets with unified balances with intense. Then we have joined to Peribu which is a local exchange in Turkey and brought this south custodial experience to 7 million users in in Turkey. It's our thesis that we will be talking in this presentation. It is one chain one app smart accounts work but across many there are still gaps and we will try to talk about this let's start with what were the initial

goals of the ERC 4337 what could actually achieved or or we believe it's not before the ERC C4337 word. You had one key of your account which only supports one elliptic curve. You are not able to create some recovery scenarios or support other elliptic curves. You had to have eat for gas and your account was able to only execute a single call per transaction and you were not able to build some custom logics on top of your wallets and

which actually blocks a pet to postquantum world or privacy supported world with with your account. And actually these are the promises of this ERC directly quoting from the motivation section of the ERC itself. They were the smart account will be your main account. Your transactions will be published through a separated public mele of account abstraction transactions and any bundler will be able to execute them. And your transactions, I mean calls can be batched into one operation

as as a transaction. And you will be able to pay gas in any tokens or get sponsored by the wallet or app itself. supporting any signature or custom recovery scenarios also and starting using your accounts with without any initial setup or guess. And these seventh and eighth items are actually not mentioned directly on the ERC but then extended by the community here. We will also me mention them later.

And these are thanks to our great community some account implementations we want to just mention and thank for the great community. In the early days of account abstraction maybe 3 years ago you had to build everything by yourself but now there is a great tooling and account infra. So we are really now in a great stage right now and let's come to our thesis and show how this account abstraction setup can have great impact in use case of one

chain one app and when this smart account is embedded through the app and when The use cases are basic around the one app. It works very well from the basic flows to extended custom places. We can start with a basic flow of how this smart account setup can be a great foundation of you using your account for not only the expired crypto users for for for everyone. The flow is you have your keys on your device directly with your pesky. You onboard directly. You

have your address before the deployment and you can directly start receiving funds prior to deployment as how EAS do that. And you don't have to fund your wallet with it for the initial transactions. And we saw that this on boarding made using wallets seamlessly in negrate sask custodial setup also as the main friction you when you have complex flows on on [snorts] your wallet on or on the D apps. It's the quickest win of using smart accounts batching

your different transactions and completing all of the flow in single operation with single signature with your pesky or other different supported [snorts] methods. And the one of the other quickest win is you don't need any to send transactions which is also the main friction when we saw how users behave when using their wallets. and the modules we can say that these were not in the

ERC spec itself but with the community contributions and different ERC's you can now build custom logics on top of your account which allows you to create other recovery or K usage scenarios. The best examples are we also used are the social recovery and email recovery. These helps people to use their existing [snorts] friends wallets or email to rotate their keys. So the key or private key itself is not the main blocker of

keep using your same accounts in every scenario. Also you are able to create scoped session keys that you can set some preconditions and use a separate key for different reasons. So it's also another great example of how account abstraction can remove many frictions in in the account ecosystem.

And these were actually what's worked very well understood by every type of user. But there are some gap still gaps and missing points where users still can issues or also the wallet builders like us have issues and it's the I believe most valuable part of our presentation what should still be improved to have uh the smart wallets to replace EOS and can be used in every place in in the chain and Alim will continue in

that part. >> Yeah. And thank you so much. Uh hello everyone again. Uh actually until that part we mostly focused on the one chain and one application site but uh users wants and need the multi-chains and multi- application. So now I want to talk about uh that what happened when we tried to build multi-chain and general purpose uh 4337 wallet actually. So uh let's start with it. The this one is the basically uh most basic and also super important one is that uh in all EVM

chains uh external owner accounts address are the same. So most of us don't think about that actually in normal life but for smart accounts um sometimes it's not possible uh it's because the contract does come from mostly crate 2 and it depends on the uh factory contract and sold and contract code. So if you can deploy this factory contract to the same address on every chain okay uh there's no problem but I think one of the uh best feature of the rollups and layer 2 is that they can customize the virtual machine for their use cases. So if these chains affect the

contract deployment part so users cannot may uh cannot get the same address on that chain. Actually we uh leave that uh we firstly built the uh self-custodial smart account on the zasync era and that time uh it uh working with the native account abstraction and because of the this change actually contract address uh was not the same in other uh EVM compatible chain. Uh because of that users uh had to have different addresses on different event chains and actually that that was a really bad uh user

experience and because of that some of the users sent the funds to wrong address on different chains. Uh so that's the one of the uh problem in the multi- chain actually. Uh the another one is that I think one of the best feature of the ERC4337 is that uh it leaves the signature scheme and validation part to wlet itself. So so it's it's it's great but uh uh thanks to this we try to replace PSI uh instead of uh classic K1 uh verification. So that that that's a good

one actually. So with that we on board the users more easily and more smutter but uh problem that with that time there was a chains didn't support the this pesky curve called P256 natively because of that the gas uh fees gas uh cost were really high uh that's why and our team uh released an RIP to support this curve as natively. Uh actually community accepted it and then in it went to uh live on mainet and also most of the uh a lot of L2s. So it

sounds like a happy story uh standard was written and community accepted it and it went live. But uh with all of that still some of the EVM chains don't follow the this kind of standards for example hypervm1 they still don't have don't have this per compile and if you want to verify the pesky signatures you have to use uh solidity contracts to do that. So it's also working in the hypervm there is no problem. But uh annoying part is that if you want to use custom validation instead of uh K1 so there is uh

uh there there is uh they might be still some problems on the some EVM chase like uh Hyper EVM1. Okay, we can still use it, but there is no guarantee to it works the same way on uh each EVM chain. So with uh this uh reality, it's super super hard and risky to build custom signature scheme and uh validation methods. Actually uh the the another one is that uh we wanted to use programmable features of the smart contract accounts and try to

uh bring unified balance with intent. So it's basically work like user has one eat on chain A two eat on chain B and want to spend it three of the eat on the chain C. Basically a solver sends the tree it on the chain C and brings it back from the chain A and chain B. So it was basically working like that. So in our application and uh the some of the application it works really well because users sees only one balance. So it was good but when user wanted to connect to uh decentralized application for example

via uh volt connect uh some problems started uh like uh for example when the user connected to some D apps the apps uh directly read the balance of the disc contracts from the chain but uh actually it was the unified one that's why the the app blocks the user But actually the user has the balance uh comes from the feature of the account abaction and smart contracts wallet. So actually there's a standard for this to solve uh called 76 uh 82 uh this ARP let's wallet to tell the app that okay this wallet

has more balance than you can see on onchain but don't block the user. user can send the funds to uh contract but most of the devs still don't support it. So we we have the standards to solve the issues but ecosystem still doesn't adopt it. uh that's why we have still a lot of problems with uh decentralized applications actually and also the another one the also the basic one most of the apps still skip the ERC 121 signatures so basically it's break the usage of the smart contracts actually

and another example is that poly market one so basically for the polymer market orders. Uh user have to sign uh with 712 signatures uh and uh the server of the poly market checks this these signatures onchain and also offchain. So uh they are uh doing that offchain because of the uh there are a lot of orders and they don't want to send RPC call to blockchain for for each of them. uh that that's why if you want to use 1271 and different custom validations

uh the verifier have to send the RPC call to the blockchain to verify it uh but they don't do it and that that that means you cannot still use uh smart contract wallet on poly market and the another one hyperlit for example uh it's not directly EVM for the hyper core stuff. Uh you cannot uh deploy the contract to the hyper core. Uh so basically that's breaks the most of the things but uh except that they can only still support the K1 curves. So basically if you use custom validations

and different signature schemes uh it's totally breaks the rules on that part. So if you want to use the smart account wallets as your main wallet so it's you you you cannot on the hyperlicate one. So it's the also the another problem actually uh to adapt it and that mostly when we check the uh this kind of use cases on one chain or one application uh features works really well like okay uh you cannot uh you you can change the validation you can set batch transactions pay masters actually the promises of the ERC 4337 7 works

really well but when you want to use it on multi-chain and for all the apps so we have still a lot of problem uh to solve this we have the standards uh I think ecosystem is great and working well on that side but adoption is not that successfully until now so to solve this uh we need to work together basically and thank so much. [applause] >> All right, that was a great session.

Guys, please come at the center of the stage. We have a bunch of interesting questions for you. Uh I'm going to start with a very heavy one. Uh will these new smart account standards be safe in the postquantum world? Uh actually uh now there there is no standards to use in the future like frame transactions. So mostly uh uh we are the ecosystem working on that because of the mostly post uh postquantum word and Qday uh stuff. But for Ethereum case, I think there are more there are some problems

except the wallet side like we need to update consensus and uh on the execution part we still need to update the accounts of course uh for 4337 part uh you can add different validation and signature schemes that's why we can produce the way to use for uh postquantum uh traits but uh I think for 337 is uh not the solution for that.

>> Sure. Uh next question I'm going to select this one. So how do you scope session keys in production per contract per function per spend limit and also what's the one permission you have learned never to grant? I don't actually remember any never to grant permission. Do you know any? But for for for the scopes, I think it shouldn't be limited to the per contract because many of the contracts are upgradable and you don't know what actually happen in the future. So we mostly

go with per function plus per spend limits and I think it should be as limited as much as possible. Cool. Thanks. Uh next one I can take a couple of more. So do we need another AI standard if it doesn't get adopted on the EVM level? uh I believe that we need a new standard because uh I believe uh this kind of adaptation problems also comes from the way uh we bring account abstraction with for 337.

So for 337 no need to change uh on uh protocol. So mostly it's it's it sounds great actually to use but I believe because of that the ecosystem is still don't adopt it because no need to change anything for the other part of the protocols. uh that that that's why uh for Twitter 7 learned a lot of things to us but now I think we need to wrap up everything and find the latest last solution for Ethereum.

>> Cool. Thank you so much. Uh a lot of people here wants to know if your wallet is open source. >> Uh yeah actually contracts are the totally open source. So you can find it from the getclave >> [snorts] >> uh rep get clave github account actually. >> Cool. Uh I think I can take one more. Uh would you like to share the challenging issue that you faced while implementing this? >> I think the most of the challenge came when we try to implement the specific application. It can be high premium or or the poly markets. And we have a saying in Turkish that you show your ear with your

reverse stand. And some of the implementing some of the apps was just like that. [music]