On The Brink with Castle Island - Julien Niset (Argent) on Improving Self Custody with Account Abstraction (EP.393)

Episode Date: January 30, 2023

We host Julien Niset, co-founder of Argent in this episode on account abstract and smart contract wallets. We cover: Building the first smart contract wallet on Ethereum Why smart contract wallets improve the non-custodial experience Standardizing contract wallet implementations on L1s retroactively and on L2s natively Comparing and contrasting contract wallets and MPC (multi-party computation) wallets Capabilities (social recovery, gas abstraction, transaction batching) unlocked by smart contract wallets Follow Julien Niset here. Learn more about Argent here.   

Welcome back to On the Brink. This is Ria from Castle Island. In this episode, I had the chance to speak with Julianne Nise, who is the co-founder of Argent. Argent is the first wallet to leverage contract accounts to build capabilities like social recovery and test out features like gas abstraction to offer users a better self-custody experience. We talk about the barriers to adoption. of non-custodial wallets, different implementations of account abstraction, the history of standardizing account abstraction and smart contract wallets on Ethereum, and the opportunity to offer it natively on layer two networks from day one, among many other things.

So with that, here's my conversation with Juni Ann. Hi, everyone. This is Ria. Welcome back to another episode of On the Brink. I have the pleasure of being joined today by Julian Nisei, who is the co-founder of Arjean, and he's here to tell us a little bit more about account abstraction, which I've been spending a bit of time wrapping my head around, and I think it is really top of mind after everything that happened last year in hopefully making self-custody more user-friendly and convenient, so that that we can onboard a greater number of mainstream users into the crypto ecosystem. But before we talk about that, Julianne, can you tell us a little bit about yourself

and specifically what inspired you to build Arjean in the first place a few years ago? Sure. So first of all, thanks for having me. Excited about this conversation. So yeah, I'm Julianne. I'm one of the three co-founder at Argent, which are, you know, started building in 2017 with Tamara and Gerald, which have been, you know, long-time friends. We went to college together, and we are not that young.

So we've known each other for 20 years, even a bit more. So yeah, I think for us, the idea, the initial idea behind Arjun, first of all, we started to be excited about the blockchain technology from, I would say, technological point of view. So we thought that there was something happening. this technology was really exciting. And we felt that it had the potential to transform society and to be really an impactful technology like the internet was more than 20 years ago.

But back then we were still a bit young, still studying and too young to start a company or a startup. And so we felt that something was happening in the blockchain space and we wanted to be there. We wanted to be at the forefront of that technology. And so my two co-founder, Tamara and Gerald, they come from a very consumer business that created a mobile application for brain training, which I think had back then like 60 million users. So they were really customer focused, and I had a bit more of a technical slash cryptography and security expertise. And so initially, you wanted to do something for users. And so we started looking at different vertical, trying to see which one would be interesting. And we rapidly realized that before we could do something for users, we needed to fix the issue of these users interacting with the blockchain.

So we really realized there was like a big gap between the protocol and between what people were trying to build. And of course, that gap was the wallet. Being newcomers to the ecosystem, the way people interacted with the blockchain, rapidly appear to us as completely insane. I mean, the idea that we are creating an internet of value, but the first thing you need to do is to back up your password on a piece of paper and not do it once, but do it multiple times in case something wrong happens. If you take a step back, I mean, it makes no sense, literally.

And that was the statute code back then. The fact that to do your first transaction, you needed to understand what gas means. You needed to being able to set a gas price, transaction fees. I mean, all these friction made it pretty obvious to us that this would never reach normal users. And it would never reach mainstream adoption. And so we really felt like that was actually an opportunity. There was like a big problem to solve. And we felt that it was something we could do.

And so that's really how hard gen started. We really wanted to bridge that gap between the protocol and the application people were building, and we really identify all these friction point, and we said, okay, let's see if we can tackle them. And I think because we were a newcomer to the ecosystem, we started from a blank page. Instead of seeing smart contract and saying,

oh, if people have tried, this is not working, we really started looking what's the best way to crack these issues. And the main one for us was we did a seed phrase. Because in the end, I mean, one of the key properties of all this is self-custody, which is really, really, I mean, a great property. But if this self-custody is too hard to use, then people naturally would turn to something different.

So we really, and the fact that everything relies around this single secret makes self-custody really hard and really risky. And so we really wanted to tackle that. And that's where the idea of using smart contract, you know, came to light. And so that's really what we started building at the end of 2017. Yeah, it's a. huge issue and you know I think there are also contradicting there's contradictory messaging around

the seed phrase and protecting your wallet because your seed phrase if you lose your seed phrase you lose access to your account right so you want to make that many copies of that in theory so that by human error you don't lose access to your account but then the other piece of it is if somebody gets access to your seed phrase, then you also lose your account. So one issue that you're trying to solve for is human error and the other issue you're trying to solve for is theft, but the way that you address both of those are very contradictory. So that creates this huge issue. Exactly.

And that's why, I mean, it was pretty clear we needed a new paradigm. We needed to look at this from a completely different angle. There's been so many people trying to rename seed phrase to make it more user-friendly. There were people doing like customer research and saying we shouldn't call them seed-frey. We should call them something else. Again, this is not solving the issue. And so we really felt that we needed to come with a completely different angle. And in the end, what you want is you want the ability to program the security of your account.

I mean, it's kind of natural, right? You don't want to have just one option. You want the ability to say, actually, I want my account to detect if there is something, you know, out of the ordinary happening. And so the only way to do that and the best way to do that on the blockchain is actually to leverage the ability of a blockchain to be programmed. And that means using smart contracts. And as soon as you realize that, then you are, you know, you see a thing from a completely different angle. And all these problems, you can address them by just programming your account or writing your smart contract to tackle. all these issues one after the other.

So that's all well and great, but that's not the way that things work on chain today or how they've worked historically. So can you walk us through some of the challenges that you were referring to that add this level of friction and that place this onus of responsibility on the end user kind of, that stems from the fact that the default account type on L1s like Ethereum today is an externally owned account or an EOA. So what is an EOA consist of and what are the consequences of it being the default? When you think of it, I think an account does really four things. I mean, an account has four features or four action it needs to do. The first one is verifying transactions.

So making sure that whoever gave the signal to the account to say transfer a token is actually authorized to do so. So there's the validity slash authorization phase. The second thing is the account needs to pay the minor. So there's the idea of paying transaction fee for whatever is about to be executed. The third thing is to make sure that transaction only happened once. And so you want to have some kind of uniqueness to be protected against replay attack. and then you want to actually execute whatever action was triggered by that transaction. And so an account needs to do these four things.

And I think out of simplicity, when these people started building the Ethereum Protocol, they hard-coded a way to do all these things. And so they literally hard-coded in the protocol, what would be the rule of an account for these key functionalities. And what they decide to do is to actually link, completely couple an account with a key pair, a pair of a private and public key. And how does it works? Well, they basically said that using, if you have a key pair, you can derive the address

and account from the public key of that key pair. And the private key is the only key that can actually trigger transaction. So the private key is the one that will be authorized to make transaction. On top of that, they added an incremental nonce, and then they say that the account would pay every transaction. But so the initial design is really to couple the account with this, what I call a signer, this key pair. And I mean, these are some obvious benefits. One of them is that as soon as you have a key pair, you actually have an account. So that means users can locally on their computer generate a key pair,

and they automatically have an account, an identity on chain, that they can use. to make transactions. So of course, that's kind of convenient. But the problem is that this create a strong coupling. Because if the key pair is the account and vice versa, that means that if you lose your key pair, you lose your signer, you lose everything. And if I have your signer, I have everything. And of course, for me, that's really the root of all these issues.

And the model I'm describing the fact that it was hard-coded in the protocol is what we call a NeoA for an external. on account because there's just one definition on how an account can be on Ethereum, an account that is controlled by something external, aka a user. So for me, the initial scene or the root of the issue is really the fact that this account is externally on account, first of all, is outcoded. There's no flexibility. And the design, the art coding is to make it completely coupled with that key pair that

that uses all. And as we see, that makes it very easy for someone to lose that keeper or to having compromised. And the majority of the issues, I mean, the large majority of the issues that we've seen in the past, you know, six years, they always relate to that keeper being either lost or compromised because there's no fallback. There's no, there's no security. And so that's how EOA works today. And of course the natural question is, can we change that? Instead of having this completely hard-coded, is there a way to define an account such that these key functionalities can be programmed instead of being hard-coded? Because if there are programmed, that means we can start to put different kind of logic, different kind of protection into the account. And that's

basically what account abstraction is. It's really the ability to program this key. these four key functionalities. Before we get into account abstraction, you created a smart contract wallet around solving this issue around the seed phrase, even though account abstraction isn't live on Ethereum today. For me, it's also a question of, I think, naming conventions in the sense that my understanding of account abstraction

is the ability to program this key feature of an account. For me, that's really what account abstraction is. And there's multiple ways to do that. And one way is to use existing smart contract on Ethereum. So at Argen, we started by saying, okay, we have this, you know, there's that strong coupling. This model is not working. What we want is to program some kind of rules into an account. And we decided to do that using the existing technology.

and so we did that on normal smart contracts. But to me, this is some form of account abstraction because the key properties of an account are abstracted. You start to program your account. So for me, in my definition, smart contract wallet are a form of account abstraction. Of course, it's not completely native and it's not standardized,

meaning that everybody can define and deploy his own logic and his own account. And so I think that's why people don't understand, it as account abstraction, but it is account abstraction. It's just that there is no standard. And so at Arjun, we develop one such smart contract. The great team at NOSIS, they developed the NOSIS safe, which is a multi-seek. It's also some form of account abstraction because you, again, can program these

key, these four functionalities and define, you know, how a transaction is verified, how the fee will be paid, you know, what's the replay attack, and our transaction must be executed. So there's been a few companies building smart contracts. wallet, which to me is a form of account abstraction, but they had to overcome some complexities and some issues. In terms of complexity, one of the key property of an account, an externally on account or a top-level account, is to being able to initiate transaction and to pay transaction fees. And of course, on Ethereum, only EOS can do that. Smart contract cannot pay fees.

And so we had a lot of thinking and research on how can we again simulate that on smart contract wallet. And the way to do that is to use what people call metatransactions and use relayer. So it is the idea that you will actually use an EOA controlled by some service that will prepay the transaction and the account will pay back that EOA for the service of triggering the transaction. And you can make all that such that is completely. trustless. And so at Arjun, we built that entire infrastructure, meaning that on 1, we have an infrastructure of

relays and we prepay transaction for users and then the smart contract pay us back to make sure that we don't subsidize transaction. And actually, we used to subsidize transaction. Again, that's a way, using that mechanism, you can decide to pay transaction for your users or not.

But so to make that to make some form of account abstraction on Ethereum, there was a lot of complexities, as I said and everything is custom. We have our own relayer. We have our own logic that works for the Argent smart contract. And those is build something different and, you know, other team build, again, something different and custom. So that was one complexity, but we overcame that. And so Argent for many years, the experience was amazing. And actually, initially, we started by saying,

you know what, we'll subsidize transaction for users. Because again, we don't want users to see that complexity, in the end, you don't pay when you don't pay the server, the Amazon servers when you go on the website. So why should users actually pay for transaction fees? And so we started with that great idea and, you know, people loved it. We had all the benefit of account abstraction. We, you know, we pioneered social recovery. So it started to be okay for users to lose their phone. We had like some kind of fraud monitoring to make sure that, you know, transaction out of the ordinary would be flagged by the account at the blockchain level. So we managed to develop all these great features that people talk about when they talk

about account abstraction. And we build that on Ethereum, but that required a lot of hard work to get everything right, all these metatransaction and so on. But then, of course, gas started to go crazy. And then the limitation or one of the, I would say, the drawback of smart contract wallet started to be obvious, is that if you put logic on chain, you need to pay for that logic. and it started to be, of course, much more expensive to use smart contract wallet

than to use plain EOS. If your transaction with Metamask, which at some point was, say, like $30 or $40 to do something, with a smart contract wallet, sometimes it was twice that. And of course, if you talk about $5 and you pay 10 cents to have all these great benefits, then it makes a lot of sense.

If you pay $50 to get all these benefits, it starts to be less interesting for the majority of money. users. And so that's why as gas started to go really crazy, I think our users started to, we started to be a product more for users with a lot of tokens, so whales, because of course, they still want all the benefits that we provide. And if you're trading, you know, $10,000, it's okay to pay $20 more on the transaction because you actually have all the benefits of the security of the model. But I think that's how we reach a point where,

having smart contract wallet on L1, even though it provided all the UX benefits that people wanted to, and I think we proved the model. I mean, at some point, we had a billion dollars being secured in Argentinvolts. I think on NOSIS saved, there's like 10 billion being secured or secure at some point.

So we validate that the security is working, all the flows that we develop, social recovery and everything users love it. It is working, but because of the high price of gas, it became a product for very wealthy users, which in the end is not the mission of origin. We really want to build a product that anyone can use.

And so that's why we started looking at L2s. I want to tap into some of the things that you mentioned. And, you know, one is obviously the high cost of deploying smart contract wallets on L1. And it sounds like that was definitely like the key barrier to it. option. But I think something that you've talked about in the past is also that because it's not natively implemented in the protocol and because there's no kind of standardization, there is another one of the challenges that you faced was the ability to interface with different decentralized applications using a smart contract wallet. So could you talk about?

that a little bit too? Yep, because indeed, I mean, Ethereum is built and daps and the entire ecosystem, the tooling is built around this EOA paradigm. And if you come with a smart contract wallet, you are a different beast. So there are stuff that you do a bit differently. One obvious one is the ability to validate off-chain signatures. So some daps, for example, or if you imagine a dex, for example, the flow is usually to sign an order, an off-chain order that you submit to smart contract.

And with an EOA, how does it work? You sign with your private key. And the smart contract receiving that signed order can easily verify that the order was signed by the correct account because you can use ECRecover and that will give you the public key in a sense, which is directly connect with the address of the account. So by just verifying the signature, you can actually verify that the person signing is the correct account. So there is a link between the verification of the signature and the identity of the user producing that signature. Smart contract wallet, they cannot sign.

So that created a difference. There is a solution to that, and that's an EIP that was developed mostly by Pedro of Wallet Connect, which is EIP 1271, which is actually a solution to fix exactly that for smart contracts. contract wallet, which is to say for a smart contract wallet, if someone produces a signature and claims that it's a valid signature for a certain smart contract wallet, just being a certain method of that contract and ask the account if the signature is valid. Because in the end, only the account can tell if it's a legit signature or not, because is maybe rotated, there may be different conditions.

So verifying an off-chain signature on a smart contract wallet is actually very easy. instead of verifying locally, which DAPs do, either they do that locally in a smart contract using EC recover and upcode, or they do that even in the DAP by verifying that locally. And so with smart contract wallet, you cannot do that. What you need to do is you need to ping the smart contract and say, hey, I've received this signature for your address. Is this signature valid or not?

And the smart contract wallet will reply. So it's a very, very small change. but of course, pushing that to the entire ecosystem is very, very complicated because the majority of actually that developers, they're not even aware, or we're not even aware that smart contract wallet existed. So if you bring them, you discuss with them, they understand, they see the benefit, and many of them update either their contract or their app. But of course, it doesn't really scale having to go to every single app developer

and say, you know what, this is not working, this is what you should change. And a good example for that is OpenC. During the NFT craze, open C in the smart contract, they are using EC recoverer directly, which means that some of the flows were not working with smart contract wallet. And so we identified that, actually made a pool request to their contract. It was basically a single line to change, but changing a smart contract takes time because you need to go through audit and everything. So by the moment we realized that this is why some of the flows were not working.

working on OpenC and the moment they updated their smart contract, there was probably something like six months or more. And of course, the NFT craze was, you know, partly gone. And I think that illustrates these difficulties. If the entire ecosystem was thinking about smart contract wallet, these issues would be really easy to solve because the tooling like etters.js. or all the libraries that developers use would naturally incorporate and consider smart contract wallet. But because it was not the case, smart contract wallet had friction with some daps and in the end that created the experience for users because one of the amazing thing about

the blockchain is that everything is permissionless and you can actually explore everything. And if you go on a DAP and 30% of the DAPs are not working for you as a user, that's not a great experience. But all these issues, they are very easy to solve. There's basically two friction points. One is the verification of signature that I mentioned. And for that, there's a solution and, you know, open Zepin as a library for that. So it's literally a one-liner for that developers.

Another problem is that some daps are actually explicitly blocking smart contract wallet. I think because their security model is actually not good. And so they want to make sure that this is triggered by a new way. And so they use, in solidity, they use transaction.orgion, which is basically in their contract, they are asking what's the EOA that initiated the transaction. And they use that to make some kind of logic to make sure that something is not happening. And of course, with a smart contract wallet, the EOA that initiated a transaction is just a relayer that was pre-paying for the transaction. But it has nothing to do with actually the account.

And so smart contract wallet would break on these flows. So these are the two problems, I would say, the two friction that we identify for DAPs. They're very simple to use because transaction origin, everybody agrees that it's a terrible idea to use. So nobody should be using that. And easy recover. There's an easy solution. It's a one-liner. And you can do that on your smart contract or off-chain.

So very easy to solve. But again, because the entire ecosystem is thinking, it's like people's brain is wired around the OAs. you know, it's a lot of effort to make that ecosystem change. And I think it will change at some point, and we see a lot of momentum now. So I think for me, that's what gets me excited, because for many years, either people, you know, didn't consider us or some of them, you know, did not agree. Now, everybody agrees that this is the right way. And basically what we've been saying for more than four years, everybody agrees, everybody is actually using it. Our wording is using, you know, the material that we've produced.

for many years. So I think the entire ecosystem has now realized that this is the way to go. And so I think that means that the mind and the mental model of people is slightly gradually changing. And now developers are considering smart contract wallet, which I think is great. But yes, these are some of the issues that we faced the past three or four years. And I think that's the main reason why smart contract, I mean, smart contract wallet haven't taken over Ethereum yet. It's because of these small friction points. Yeah, the amount of content and discussion around smart contract wallets and account abstraction has truly exploded in the last humans. And I think part of it is obviously everything that happened last year that really brought the importance of self-custody to the forefront.

And then also, which we'll talk about on this episode a little later, you know, is the integration or implementation of, smart contract wallets and account abstraction natively within L2s. But before we get to that point, I do want to talk about the fact that account abstraction and its standardization is something that Vitalik and the Ethereum developer community have articulated and understood the value of for many years now. And I think there have been like three or four Ethereum improvements. proposals put forward that seek to make it more standardized and, in your wording, make smart contract wallets a first-class citizen just as externally owned account wallets, our first-class citizens on Ethereum.

So can you walk us through some of those EIPs and maybe talk about where progress stands today as it relates to standardizing it on Ethereum L1. So yeah, you're completely right. Account abstraction is by no mean a new ID. And I'm pretty sure Vitalik already had that in his mind when they started designing Ethereum. I think they probably settled for EOAs because you need to start somewhere. And it was much simpler. But the first EIP around account abstraction is from 2016.

So you see that with the beginning of Ethereum, there's already a proposition. to abstract some of the functionalities of an account using, I think it's the IP 80 something, 86, if I remember correctly, the idea is to define some kind of forward a contract. So that can kind of play the role of an account. Then 2017, 2018, I would say the beginning of smart contract wallet. That's when we started at Argen. I think that's when NOSISA started to be a bit more popular. And so for me, that's one form of account abstraction, but not a standard.

And then there was this two EIPs, I would say, I think something around 2020, two years ago. One of them, and it's funny because they take completely, I would say, complementary or opposite approach. One is to enable top-level account features to smart contract. And by that is the ability for a smart contract to initiate transactions. And that's an EIP that introduces a few opcodes such as pay gas and so on. So to take care of the validation and the paying of transaction fees from smart contracts. So trying to give some of the top level account to smart contract. And roughly at the same time, there's another EIP which does exactly the opposite,

is trying to give some kind of smart contract feature to existing top level account, EOA. So it's the ability for an EOA to delegate to a smart contract, the power to validate and execute transaction. And so there's been these two EIPs, I think, 2020. And so the problem of these three EIPs that I mentioned, so the started in 2016 and then 2020, is that they all require a protocol change. So they all rely on the addition of new upcodes,

new transaction types. And so basically changing the protocol. And I think people, I mean, there's a lot of, you know, I mean, Ethereum is an evolving protocol. There's different priorities. And I think people didn't see account abstraction as one of the main priority. People focus on, you know, is two. People focus on 1559.

So there were, you know, proof of stake 1559. there were, of course, most important issues to kind of create a solid foundation for the protocol. And so enable the protocol for me as well to scale. So lay the foundation of a strong protocol that's decentralized enough, secure enough, that is green enough with proof of stake, and on which we can also enable scaling. And so these EIPs, even though they were interesting, I think people didn't really see the value and they were not like the main priority for the ecosystem. Until 2021, I think, 2021 or 2022 came a new EIP or ERC as a matter of fact, ERC 4337 that people

have talked a lot about. And the key idea behind 4337 is exactly that. is trying to enable account abstraction, but without requiring a protocol change. Because I think Vitalik, again, all these EIPs, except one, were always pushed by Vitalik. I think it came to the conclusion

that it would be hard to push account abstraction, but actually we could do something now. There's no point waiting for all these important, you know, fork to happen and in all these important features to come to the protocol to start thinking about account abstraction. The idea of 4357 is, to say what can we do today to enable some form of account abstraction.

And so that's the IP 413, or ERC, it's an ERC because it doesn't require a protocol change. That's ERC 4337. And if you look at that ERC, it's again kind of the same realization that we are at Argen. What can we do today? Well, what we can do today is use smart contract, existing smart contract. And so from an architectural design point of view, ERC 4337 is actually a normal smart contract wallet like Argent, but it decentralizes the piece of architecture that is necessary to write and operate smart contract wallet.

So everything related to the meta transaction, the relayer, which means on urgent, it's a central point. I mean, even though you can use your own metamask to send a transaction, if you use Argent, you go to this central relayer. So here 3437, it's basically an average. architecture to build a normal smart contract wallet on Ethereum, exactly like Arjun, except that the mechanism to trigger this transaction, to pay the fee goes, is completely decentralized and standardized.

And again, that comes to my first point. Smart contract wallet. They've been there for, you know, since Arjun and those is safe, but there was no standard. I think the beauty of ERC 4337 is actually, it's a standard to write and operate smart contract wallet. And so the way it works is purely at the application level, it kind of reproduces the mempool or it creates a mempool at the application level to execute this relay a part of smart contract wallet. And the second benefit, and that means that if that entire complexity is taken care by ERC 437, it becomes very easy to write a smart contract wallet. because now ERC 4337 defines a clear interface the methods that your smart contract wallet needs to have.

And that means that anybody can much more easily write a smart contract wallet on an EVM chain. But again, ERC 4337 is a smart contract wallet. It's just a standard for smart contract wallet on EVM today with most of the complexity being decentralized and standardized. And I think that's why it got a lot of traction because it can be implemented today, which a lot of people don't realize. You see a lot of these block posts or people talking about account abstraction, they say, oh, when account abstraction or when 437 will be implemented,

actually it's there. There's already people doing it. There's nothing stopping us. It's, again, we need to build that infrastructure and people need to commit to building it, but there's nothing to wait for. We don't need to have yet another fork or to wait for some something to happen at the protocol level. It's just a matter of do people want to build that

infrastructure. So that's kind of the story of account abstraction from 2016 to, I would say, today. But 4337 for me has two main benefit. One is that there's so much momentum and excitement that now it becomes clear to anybody and everybody that we need to have account abstraction. But the second thing is I think ERC 4337 is a great architecture. So the design is actually very, very clean. And so that means that you can almost take that design, which on ERC 4337 happens at the application level, meaning that there's nothing for the protocol.

It doesn't change the protocol. But you can bring that almost immediately to the one level down to the protocol. And that's basically what Starknet and ZK Singh are doing today. which means that on layer two, it's very easy to actually build native account abstraction at the protocol level by using and being inspired by ERC 4337, which to me is the second great benefit of that ERC. With this standardization and the decision or design to kind of decentralize this one piece of infrastructure that right now, Argent kind of built itself and is operating in maybe a more

centralized way than is ideal. Does that address, does that do enough in addressing some of the limitations you talked about around cost and, you know, developers having to actively go into their code and add support for smart contract wallets? Yes, so that's a very good question. and our position at Arjun is that it does not and that's why even though we are clear supporter of 4337 for different reasons that I will list we feel that it's not the end goal so it's a great step it's a step in the right direction

but it's by no mean the end goal so to be precise about your question in terms of cost I think the answer is probably yes because people are you know today are building on their twos which means lower cost So the impact or the overhead of all that logic of smart contract wallet is much, I would say is much less. So in terms of, you know, of compute, of CPU, of gas, it's exactly the same. So it's a smart contract and it will be in the end as efficient, more or less as NOSA for Argen today on L1.

So it's not changing anything with that respect. But of course, if you do that on layer two, the cost will be much, you know, much more. So I think that will be addressed not by that ERC per se, but by the fact that people will implement it on the... No, the compatibility issues with DAPs, I don't think it will... I mean, it will probably improve the state of affair because there's so many people talking about it

and if every single DAP developer is getting excited, then people will actually start considering smart contract wallet. And so you can imagine that the EVM world will reach a point, where every DAP, every smart contract, when they need to verify a signature and of chain signature, they will consider EOAs and smart contract wallet. So I do think that this is going in the right direction, but this will, as it is, it will not remove EOS.

So there will still be EOAS. Today, there's tens of millions of users, with funds, NFTs, whatever, on EOAs, and these people will still be there with still that completely, complexity, I think, and the risk of using these EOS. So it's a step in the right direction, but I think it will take time for all these gaps and for the message to propagate if you want. So yes, our point of view is that it's not, you know, it's not the ultimate solution

and that we should actually go one step forward. And I think, again, most people agree, the people behind the RC-437, which is, you know, mainly Vitalik, Yoav, from the Ethereum Foundation, already discussing with them. And of course, that's their clear intention. The next step is to bring that EIP or that ERC one level down and make it something that we can implement on the EVM, you know, as soon as possible. So ERC 437 is a great step in the right direction because I think it popularized and it evangelized people and dab developers about smart contract wallet.

but in the end I still think there will always be friction, there will still be daps that are not completely working because it will take time for that message to propagate everywhere, for every single line of tooling to be changed. And there will still be people that will think that you need to have a new way. You know, there's that phrase, not your keys, not your coins. And I think this is very wired in a lot of people's brains. I don't think it's a good description of self-custody,

because with the urgent model, I can give you my key and you know that you will still not be able to actually do a transaction because I have my guardians that will, you know, prevent that from happening. So anyway, all these to say that, yes, step in the right direction, but I do think we should go one step further. And again, everybody agrees that we should go, I mean, the people beyond account abstraction and the people that think about these issues, I think most of the people are aligned that we should go one step further.

And so the message we've been pushing at Argen is that we are seeing the rise of layer 2s. And that's an amazing opportunity to actually implement these ideas natively. Because something that is really hard. And that's one of the reason why Ethereum is still not implementing account abstraction is that it's really hard to go from a model where you have EOS to a model where you have account abstraction. If you have billions of funds, you have thousands of daps which are already built in that. paradigm. So know that we are seeing the rise of layer 2s. If we agree that this is the direction that we should go to as an ecosystem, let's make this change now. And let's not wait, you know, two or three years and start building again with that ERA paradigm and then wait for a perfect

EIP to come to start to implement it. No, I think we should do it now because there's relatively limited funds on layer 2s yet. We know that the account model is. a problem is a friction point in terms of ux of the theorem so we've identified clear issue we have a solution let's implement it now instead of starting i think with you know something that has limitation and say yeah but we'll do that you know in a couple of years so what we've been pushing out arjan is really to say this is an opportunity it's it's kind of a new start all these layer twos are a new start of ethereum so let's take all the stuff that worked amazingly well build on that and fix the few points that we all agree are in issue.

And now is the right moment. So that's why we've been really pushing about saying, okay, 4-57 is great, but let's not settle with that. Let's actually go one step further as soon as possible. You know, you've done a lot of great work around lobbying for that and lobbying for having account abstraction natively integrated from the get-go on day one, on L-2s, and specifically you know, ZK roll-ups like StarkNet and ZK Sync. So can you talk a little bit about some of that lobbying work

and maybe the L2 specifications, I think specifically Starknet in your case that you're excited about? I think as I mentioned, we identify problems with our model on L1, and so it became rapidly clear that we needed to know the future of Arjun was on layer 2s. And so we started two years ago, I would say, started to review the different possibility, discuss with the different team. And for us, it was, I would not say obvious, but we were much more excited and attracted

towards ZK roll-ups than optimistic roll-ups. Again, love optimistic roll-ups. But we felt that ZK roll-up was kind of the long-term solution. And at Arjun, we've always tried to build for the long-term. and so we started engaging much more closely with ZKSync and Starknet, but as well with optimism and arbitrage, but decided that or at least short-term future was on ZK roll-up, or first bets, if you want, would be on ZK roll-up.

And I think in parallel Starknet, as you know, I mean, that's what I love about Starknet, is that again, they are opinionated. They're not afraid to make bets. And for example, that's why they decided to go for their own smart contract language instead of using solidity. So I think they really have that mentality of let's build the right tool for the right problem instead of reusing and the legacy that we have. And so naturally, again, I think we have some credit for where account abstraction is on Starknet, but not the initial impulsion. Starknet was really looking at account abstraction. but they identified there's some problems because account abstraction is actually complicated

in terms of security. And then came ERC 4337, which was actually solving all the problems that they were having. So they were like, okay, we think we should go in that direction. We had identified these difficulties and we hadn't really time to try to crack them. And suddenly there's like a perfect solution. And so they started looking at how. how to implement ERC 4237 at the protocol level. And that's when we were discussing, you know, we didn't, I mean, we've been closed with

Starknet and ZK Singh for a while. But at that point, they reached out to us and say, okay, we think we really want to go in that direction. And you guys have experienced, you have concrete experience about what it means to build like an abstraction because you build smart contract wallet for the past four years. So, you know, can we, can you help us and try to give us feedback, help us point us in the right direction? And so that's when we started engaging very closely with them and really working, okay, they want to go in the direction of 4337.

They can take care of bringing that to do at the protocol level. But what does that mean in practice, you know? And again, I mentioned that an account has different functionalities. Do we want to abstract all of them? You know, of course, on paper, you want the design to be as open as possible. But then if you do so, you realize that every single decision you make as complexities or add extra complexity. So I would say we kind of help them find the right tradeoff because of course as a developer, we push for it to be as open as possible.

But then of course they wanted to limit the risk or the complexities. And so I think we kind of helped them. And together we went into a direction and the design that is great. That has the majority of the benefits of account abstraction. But there's still a few identify, I would say, functionalities that are not. fully abstracted yet. And one example is the question of the replay attack. Typically on Ethereum, we use an incrementing nonce and account abstraction doesn't force you to do that. But of course, using a completely open known has a lot of complexity, so they decided to start with an incrementing

norms like an Ethereum, which limits some of the possibilities of account abstraction. So it's, they haven't opened like 100% of the design space, but I would say that 19, of it is open and we can do a lot of experiments on that. So yeah, so we've been working closely with StackNet and with Open Zeppelin because they were closed with Open Zeppelin as well, which was there to kind of help standardize and bring some of their standard to the Starknet ecosystem. And so we really worked on designing what would be the interface of an account. So that really developers, there was like a clear interface that the protocol would understand and that developers could start implementing.

So we worked on defining that interface, and that's still the model that is running on Stacknet today. And so today there's, you know, I mean, we've been building from day one with our product, Argent X, but there's also two or three other companies which are experimenting on accounts on Stacknet. For example, Ledger is experimenting in the Starknet ecosystem as well. There's a company called Cartridge. a company called Bravo.

So now there's different people that are really trying to experiment with that new design space around the functionalities of an account. I realize that we've touched on what features can be unlocked with account abstraction and smart contract wallets. And I think maybe it would be helpful just to take a step back and talk about some of those in more depth. You know, we've talked about it. high level how with account abstraction, you can add programmability to transaction verification.

But that's pretty vague. And, you know, maybe difficult to grasp for some listeners that haven't gone more in the weeds around what capabilities can truly be unlocked by this. And, you know, you mentioned things like social recovery and fraud monitoring and, you know, things like multi-call and batching and, you know, I think visa. published a blog post around being able to do auto payments on Starknet. Maybe let's take each of those and talk about what account abstraction actually unlocks. What are these features that is attractive for end users and that really improves the user experience?

Sure. So first of all, I think some of the stuff we'll discuss are the ideas that are the improvements that we've identified. but I really believe that the design space is much broader. We are really just scratching the surface of what can be done. So this is the low-hanging fruits in a sense or the obvious ones, but I'm sure there's so much more we can build an account abstraction. So, yeah, as we mentioned, one of the key functionalities of account is to validate transaction, making sure they are legit transaction

and that the account should execute and pay for this execution. And so typically on Ethereum, you have one key. We discussed that with a new way of a signer, and it's hard-coded that the private key of that signer must sign a certain message on a certain elliptic curve using a specific signature scheme called ECDSA. Now, if you can start programming that, you can put different rules there.

And so, for example, you can imagine that node is validation, you say, you know what, instead of having one key, I'll enable, you know, N out of M keys that I have defined that needs to validate transaction. And suddenly you have a native multisig because you can list on your account these are the M signers or the M keys and the validation logic will say

every time I have three signatures of these N keys, then the transaction will be valid. So you can imagine that you can now build a multisig that can initiate transaction. But that's not too innovative. What we did at Arjun is something we pioneered, is social recovery. I think one of the main friction point of blockchain

and of, you know, EOAs is what happens if you lose your key. And so, of course, on Ethereum, that's why you write your seed phrase on a piece of paper. And we wanted to get rid of that. And so the model that we design is something that's very similar to what you have today with your bank. You have a bank account. You see your account on the blockchain as your bank account.

And typically you have a credit card or a debit card that is what you use to basically spend funds or to do transaction on that account. And with the normal financial system, if you lose that card, what do you do? You call your bank. You say, hey, I've lost my card. Can you freeze it? And reprogram my account with a new card and send that new cards to me. So that's a very natural flow that everybody understand. And so for me, social recovery, it's exactly that, except that you choose who's acting as your bank.

So instead of relying on a centralized solution, you define on your account the identities, the parties, that will basically, that have the power to authenticate you and reset your account with a new controlling key. So in practice, that means that let's take a very simple example. On your account, you have one key that you put in your mobile phone. That's what you do at Arjun. And now imagine that you program your account, you set a second key that you call your guardian and you give that key to me because we're a friend and you trust me. That means that for the everyday operation of your account,

only the key that you have on your phone can trigger transactions. So only the key on your phone, only the key you control can transfer token, can buy an FTA, can interact with any swap and so on. But the day you lose your phone, what you can do is that you just call me and say, hey, Gillian, you know what? I've lost my key. I've reinstalled the application on a new phone with a new key. Can you please reprogram my account and to reset the ownership to the new key that I have on my new phone? And because you trust me, I can do that. So that's the only operation I can do on your account.

I cannot transfer token. I cannot interact with the app. The only method or the only action that I'm able to do is actually reprogram your account and set a new key that you control because you've trusted me to do that. And of course, you can do that with one guardian. So you can hit me. But you can imagine that actually you don't fully trust me. And you decided to use five of your friend.

and you say that any three of them can do that action. So you know that if one of them starts to be goes rogue, he won't have the power to actually reset your account. Or maybe you don't trust anybody. So you want to use a hardware wallet, but you put that hardware wallet in a safe at the bank because you know that you can still use urgent every day. It's very convenient.

And the day something happened, you just need to go to the bank and you can reprogram your account. So for me, that's social recovery, is the ability to program your account and define what we call guardians that can help reset the ownership of the account. And this guardian, they can be anything and you choose what your guardians are. And to give a concrete example, meet on my Argen account. I have three guardians. One is a friend.

One is a hardware wallet that I control. And the third one is a service that we've developed at Argen and that use email and SMS for this authentication phase. And any two of these guardian can help me recover access to my account if I was to lose my phone. Yeah, I think that's a really important point because I think when people hear social recovery, they just think, oh, you know, what if I don't trust, you know, I'm the most crypto-native. I'm the most technically savvy. I don't trust anyone in my network to be a guardian. but I'm really happy that you kind of went into the fact that, okay, a guardian can be a person

that you trust, it can be another device that you have, or it could be a third-party service that you kind of outsource that role of a guardian too, which I think is really powerful. Yeah, and it can be any combination of that. Yes. Yeah, I think the term social recovery is actually a bad term and it has done some damage to the concept because of that, people, you know, say, oh, you know, I don't trust my friends to do that. But actually, no, it's really a protocol at the blockchain level. Any account, any account on the blockchain can be a guardian. So it can be another smart contract.

It can be just, you know, an EOA. It can be whatever you want. And then you can encapsulate that into different parties. Yes. So that's social recovery. That's one. A second thing that you can do. And so I think that's all the problem of what happens.

I lose whatever is controlling my account. So social recovery solves that. And I think that's already a big, you know, pain phone on the blockchain in the ecosystem today. A second thing that we see a lot or another problem is what happened if I make a mistake or if someone steals my private key. If you store it, you know, if you if you start it in your phone very deeply encrypted protected by secure and clear, well, it's complicated, but you can imagine what happened if

some reason, you know, I leave my phone open on my table or actually, you know, my uncle has access to my password, has access to my phone, whatever. You can imagine scenarios where someone will try to initiate an unauthorized transaction. Or simply you make a mistake or simply you go to a DAP, you think it's uniswap, but actually it's not uniswap. And so you make a transaction thinking you're interacting with uniswap, but actually you're signing a completely different operation because what you see on the UI is not necessarily what's happening at the blockchain level. So one solution to to protect against that is the idea of fraud monitoring that that we do at Arjun on L1 and that we are replicating on Stacknet.

And so the idea is to say let's imagine again that I program a second key on my account and I program my account such that the second key must cosign every transaction I make. Okay? So now every time I make a transaction, I need two signatures. The one I control and that second key that we call the fraud monitor.

And that key, I will give it to a service, a off-chain service, and every time I make a transaction, my wallet will send the raw data to that service, and that service will decide, is it a legitimate operation? If I'm sending you money frequently and I send you money again,

There's no reason to be worried. That's perfectly normal behavior. So in that case, the service will automatically co-sign, send back the signature to the wallet, and it's transparent to the user. As a user, I just said, send transaction, this exchange happened, the transaction is validated by the fraud monitor, it's deemed secure. The transaction is sent directly. Now, imagine that you interact with a phishing website, and it's a known scam.

In that case, the monitoring service will say, oh, but the address, you know, the wallet is sending money to is actually a scam. It's been flagged by many people. In that case, either it will broke the transaction or it will just raise the flag on your wallet, say, you know what, you're interacting with this website that, you know, with an address that has been blacklisted or that has been, you know, listed as a scam. Are you sure you want to continue? Usually you will say no.

If you say yes, the service will ask you to prove. that you are you, that it is not someone controlling your wallet. Again, for me, I mean, coming from Belgium, that's typically the kind of flows we have when we do online banking. And so suddenly, you are required to provide a second factor, which can be Google oath, it can be email, it can be SMS. And so that's really fraud monitoring, is the ability to, so you delegate, you ask an external service to help you identify transaction, which are okay from transaction that seems to be

either unknown or problematic, and then, you know, the service can ask you to confirm the transaction with a second factor. But again, this is not giving the right to that service to actually censor you, because as the owner, you always have the right to revoke that right to that service. So if the service is done, if the service is not behaving, you are always in control and you can just revoke that second key, that fraud monitor key, and set a new one. Again, the fraud monitor one can be a hardware wallet that you control because you want to make sure that every time you make a transaction, you think about it and you need to confirm with your hardware wallet. So again, it's just a protocol. You can choose what you do. But our goal at Argen is really to enable, I think, flows, UX flows that people are used to. And so social recovery, it's a flow that is very normal.

You lose something. You call some people. You interact with the service to get back access. the fraud monitor is again, when you interact, you make a financial transaction. In certain situation, you just want to confirm that you are indeed you, and it's not someone that has stolen your key or taken control of your phone. So that's fraud monitor with 2FA. It's another thing that you can do with account abstraction.

Another feature that I think is really cool is called session keys. And again, what's really fun is that all these ideas, we develop them four years ago on Ethereum, nobody cared, you know, nobody used it, but actually all this has been available on Argent for four years. And so session keys, we call them DAP keys, but it's exactly the same concept. So the idea of a session key or a DAP key is the ability for a DAP to create a temporary key that will only be valid for a certain session, so a certain time and that will be restricted to do very specific operation on very specific smart contract that you decide. And once you, as the owner, you have approved that key, that means that

now the DAP can actually send transaction on your account directly without requiring a confirmation. But you have the guarantee that the transaction, the valid transaction it can make are within the context that you have approved. So for a certain period of time, interacting with with certain method on certain smart contract. And so I think one use case where it can be very interesting is in the area of on-chain gaming. Because today, if you play an on-chain game, every time you make a game action,

you see your wallet popping up, you need to confirm the transaction, you come back to the game. Of course, that's a terrible experience. It's like every time you play chess, every time you move upon, you need to see your wallet, confirm the action,

and then go back to the game. It is very annoying. With session keys, actually, you only need to confirm once because you start the session, which is again very normal. You know, identify, start a session, you see what you're authorizing, you say yes. And then for the duration of the session, you can actually play your game without having to confirm any transaction with your wallet. But still, full security, full guarantee that you know exactly what is happening and there's

no risk of that key doing something that you don't want it to do. Yeah, because you can define certain parameters. Exactly. Within which it automatically signs, confirms, yeah, actions. And so again, for me, it's really enable a web-to-like experience, but, you know, on-chain and still fully non-custodial, because as the user, you are fully in control. So, yeah, we've touched on social recovery, fraud monitoring,

that session keys. There's other, I mean, there's other stuff that we are looking at. I think one problem, a question a lot of people ask themselves is what happened if I you know, will my spouse or my kids or my partner be able to have access to my crypto? Again, with account abstraction, that's something that you can program. Because you can imagine that you register a key and you say that key can only make transaction if the account has been inactive for two years. And now with some new technique, you know, called storage proofs that you can have specifically

on, I mean, that you can have on blockchains, you can actually prove, for example, that your account has been inactive for a certain period of time. So you can imagine to solve that problem. And now you say there's that key, it cannot do anything, but if something happens, if I don't touch my account for that amount of time, then it's not that key becomes the one in control or can, you know, exit the funds. So that's another thing that you can do with account abstraction. Another area of, sorry, go ahead.

No, go ahead. Then I was going to say another thing that we are exploring with actually the folks at ledger and cartridge is the ability to build an account that is fully modular in a sense because it's realizing that not all users want the same functionalities. And so you can imagine that you create an account, which is some kind of a base layer, but you can enable plugins on that account. And each plugins will contain one of these features. So maybe someone wants to have a multi-seg, someone wants to have social recovery,

someone wants to have a Neo-A-like behavior, or someone wants to play game and have session keys, but that other person may not want to enable session keys because he uses wallet for, you know, defy and to transact with, you know, lots of token, lots of value. So the idea of plugin is really to say we can create an account that is fully modular and users can pick and choose the kind of features they want to enable or disable on their account.

So I think these are some of the stuff that we are exploring. I'm really happy you mentioned that last point because it also, well, it was going to be a follow-up question, but then it also goes back to something you mentioned earlier around the fact that, you know, a lot of the features that we're talking about today are the low-hanging fruit and we, there's so much more that we haven't even on earth that you could potentially enable via account abstraction. And if you have this kind of modular wallet that's more configurable, and to which you can add and take away Lego blocks, then you can see the wallet experience for a user being more flexible and evolving over time, which I think is really necessary because we're still so early and don't know what we might want to do and we'll be able to do in the future. Yes, 100%. And for me, in addition to exploring a new use case,

it's also very convenient if you think of a user's journey, typically when you start in blockchain, you won't have like tens of thousands of, you know, token immediately. Maybe you just want to play a game because in the end people come for an application. And if you play a game and, you know, it costs you $5, 10 to play the game, your security requirement is not the same as if you start, you know, to do some crazy, you know, stuff on Defi with, you know, lots of money.

But of course, you may want to maintain or to keep your identity throughout that period. So you want to be the same account, but have your security mechanism to evolve over time based on your evolution and what you do with your account. So having something that is modular means that you can have the right experience at the right moment, but still keep your identity over time, which I think is another important property of the plugin system.

I know we are very close to the end of our time together, but there is one question. and maybe I'm going to regret, or you won't appreciate that I'm opening this can of worms now. But I think a lot of the features that we just talked about as it relates to smart contract wallets have also been mentioned in the context of MPC wallets. And there has been some discussion around, you know, the pros and cons of one versus the other. And you clearly are, you know, obviously are biased in favor of smart contract wallets. But maybe at a super high level could you talk about some of the biggest differences between the two and, you know, because you are the co-founder of Argent, which is a smart contract wallet, why you think smart contract. wallets are a better, you know, long-term solution.

Yeah. So disclaimer, I am not biased at all, of course. I will get honest and evident opinion on the matter. No, more seriously. So first, some contexts, I don't know if everybody is familiar with MPC, but the idea of MPC is multiparty computation. So the idea is that multiple parties can actually do a computation, say signing a message. And if they sign one after the other,

the end result will be the signature of a known account. So it's like you recreate the signature of an EOA by multiple persons signing the message. And you can also, just like in a multi, so that looks like a multi-sig, because you can also say there's actually three parties and the signatures of two of the parties will actually produce the correct signature of the EOA.

So you de facto have a two out of three multisig. And so again, if you start giving one of this party to a service, you can do some of the features that we discussed with account abstraction. You can imagine to have some kind of fraud monitoring as well because you can give one of the party to a centralized solution that will inspect the transaction and only sign based on certain parameters that you've decided. So yes, some of the benefits of MPC or you can recreate some of the flows that you have with account abstraction. But for me, I think there's two main difference. One is I think MPC is much more rigid in the sense that is really like it's hardcore cryptography. And of course, that evolves and that progress much slower than what you can do by simply programming an account. So by design, yes, there are some of the benefits of account abstraction can be emulated with MPC.

but as we mentioned, I think we're just scratching the surface of what you can do with account abstraction, while we pretty much know what you can do with MPC. In the end, it's only an out of M, you know, multisig. Then you can choose what you do with these, you know, these different parties, but that's very, very limited. So I think one clear difference for me is that MPC is very rigid, while with smart contract and account abstraction, you can basically program whatever logic you want. you want to change, you know, you want to change cryptography and use a, you know, a signature

scheme that is quantum secure, quantum resistant. It's very easy. You just need to program the logic. And a lot of people know to program that while actually changing the cryptography and, you know, doing MPC on a different elliptic curve is complicated. So there's the the rigidity aspect or the, yeah, or the flexibility of benefit of account abstraction. But another for me important point is around censorship resistance because and the question of revoking keys with a smart contract with account abstraction is very easy as I mentioned if you trust someone to do the fraud monitoring service for you the day you don't want that person to do that you can simply revoke that key and that's written in the smart contract so that key is useless has no more power with mpc if

file it in the end, you just reproduce the signature of a new way. So even if you change the parties, in the end, existing parties can always sign and always have that right. So if someone, one of the parties becomes rogue, he will always have that power to make signatures. There's no way to revoke because in the end, you are just recreating the signature of an EOA. So for me, that's the main drawback of MPC is the inability to revoke the signers. And that opens a lot of questions with respect of censorship resistance and so on. While with smart contract wallet, you can revoke parties at the smart contract level, at the level of your account.

So for me, that's the other key difference. Do you think that there is a world where the two kind of complement each other? 100%. And again, I think instead of seeing the difference and seeing which one is better over the other, I strongly believe that in the end account needs to have some kind of programmability. But yes, if you can offload some of that computation off-chain and still have some of the benefits, then you reduce the cost of executing action on your account. And so, yes, I think combining both is a good solution.

You can imagine, for example, that MPCs are your guardian. So on your account, you just one key, but actually you do the end out of M, you do that in MPC. But that creates one signature, which is the guardian of your account. You have kind of the best of both worlds because no, you can revoke the MPC by just changing your guardian. So I do think that, yes, instead of seeing that as competing technology, of course, at Arjan, we are strong believer that smart contract account are much better at the account level, but I do think that MPC has a role to play on the ecosystem. So I think both technologies are interesting. Amazing. Julia, it's been such a pleasure to have you on. We covered a lot, but I really appreciate you answering all of the questions

and giving such a comprehensive overview of the history, the challenges, the benefits, and where we stand today. So thank you so much.