 My name is Liraz Siri, and this is Dror Tiroosh. I know your name. And we've been working on account abstraction in various forms for a few years now. And Yorah Weiss, who is not here, is from the Ethereum Foundation, and he has been our colleague. And yeah, we're working on this in collaboration with NetherMind. And originally we were working as the OpenGSN team on meta transactions, and all of it kind of merged into account abstraction ERC4337 standard. But we're going to talk about how account abstraction is generally useful, regardless of the implementation. So let's talk a little bit about accounts in Ethereum. So right now the default account, well, what you get is an externally owned account. And it is a one-size-fits-all EEC DSI key. And the other option you have, if you want to have your own smart contract, that would be controlled by code, but you would still need an EOA to interact with it. Probably your current wallet is an externally owned address. There are some limitations with that. The first one is maybe some of us have gotten used to it by now, but key management can be hard. And there's a little bit of a paradox with key management intrinsically, because there's a secret that you're on one hand trying really hard not to lose. Because if you lose it, you can't do anything with your account anymore. And when you don't want to lose something, what do you do? Well, you create many copies of it, and you make sure the copies don't get lost. But on the other hand, you also don't want the key to be stolen. And when you don't want something to be stolen, what do you do? You try to hide it from adversaries, make it really hard to access, minimize how many copies there are to be stolen in the first place. And the engineering strategies, when you just have this one key that you're trying both to prevent from being stolen and from being lost, they're kind of mutually exclusive or they pull in different directions. So key management is hard even if you know what you're doing. The other big limitation of EOAs is just access control. Whether you're just playing a blockchain game or you're a multi-billion-dollar corporation using an EOA, it's like the same access control policy. So that's very limiting. You don't have a grand gamut already. You wouldn't have multi-sig support. There's no ability to implement roles. You can't have spending policies. It's just one size fits all mechanism based on this access to a secret key. The other big limitation of EOAs is gas payment. So you're paying gas directly from the EOA, and it has to be an ETH, the native token. Now, potentially there are many other ways that you might want to be paying gas if you're a fan of dog coins. If you want to pay gas in that, you don't want to hold ETH. The other big limitation is that, if you do have to maintain an ETH balance in every account, it's hard to split up your activity between a lot of accounts. Because then you have to top off ETH and alter the accounts. And the ETH that you top off, it has to come from somewhere that's probably attached to your identity. I mean, you may be KYC at exchanges, and our identity is known to at least some players, and then it's not too hard to track. And even if we split up activity, oh, this is all coming from one source. So that's a privacy problem. The other big limitation of EOAs is just in terms of efficiency. Many times, what you actually want to do, it spans more than one transaction. So let's say you want to approve, and then you want to transfer. Those are two transactions, but really you are thinking of them as one operation. With EOAs, you would have to send two separate transactions, and that might not work out. It also might be a little bit more expensive because of that, but there's no atomicity built in. And if there is a revert on chain, that's pretty expensive. And that happens sometimes, especially with things that are very time-sensitive. So what is the alternative? What is account abstraction? Well, basically what we're saying is, EOAs are the one-size-fits-all-past, and we want to move beyond them to a world where we can really manage the logic that controls our account, and the logic can be pretty arbitrary. And then that opens up a lot of possibilities. And that is the future of how accounts are going to work. So what are the use cases for this? The one that's been talked about since the beginning is social recovery. Let's say something bad happens to that secret that you're trying to both prevent from being lost and from being stolen. Well, maybe you have some friends that you plugged into your account, and three out of five of them can help you restore your wallet. And you can do even fancier things. Let's say your friends suck, and they're trying to steal your money. Well, you could have a delay mechanism built in. So if your friend suddenly tried to recover your wallet when you don't need a recovery, you as the account owner would see that in advance, and the operation wouldn't happen immediately, so you would have time, let's say maybe a week, to respond to that. The other really interesting use case is a dead man switch. Nobody lives forever, unfortunately. And then what happens if you need to pass on your crypto, but you're not around to help do that? So with the dead man switch, you could have a mechanism like, if you haven't accessed your account from your main key for the last year, then another key that your family members have access to, it would become active. So usually you're in control, full control of your account, but then a year later, you haven't been active, something wrong happened, your account automatically passes to multi-stake control by your family. Just one thing I want to explain. These are all features that account abstraction can give, but it's not that everything is completely baked in. Account abstraction opens the door for wallet creators to add all those features. None of those features are something that will be on day one, maybe a limited set. These are options that are open to do more. Oh, now we can both talk, even if we can talk over each other if we need to. That's a good point. I was talking to you all about that when we were preparing for the talk. This is, oh yeah, maybe, that would be nice. So that's a really good point. This talk is intended to inspire hate. We can do these things now, but we have this infrastructure built in. But this all depends on the code that's running your smart wallet account. And that's up to wall developers. That's up to anyone that wants to get involved. And most likely there are many use cases that are interesting that will not be covered by this talk. So use, you know, the sky's the limit in terms of imagination. But we would like to talk about some of the use cases that we've been thinking about. So one of the cool things that happened during ETH Bogota is there was a project that implemented an idea that we've been thinking would be pretty cool, is, well, there's this signing mechanism in most mobile phones. The problem is the signing mechanism doesn't support ECDSA curves. So it's using some other mechanism. But because account abstraction doesn't lock in ECDSA as the only way to sign, what you can do is you can have pre-devised keys that essentially, you know, you get your phone and you link your phone to your account. Now your phone can authorize operations on your account. And a team actually implemented that in the recent hackathon which we thought was pretty cool. Multisig is a very obvious use case. So, you know, now you would be able to just get that out of the box. Another one is BLS aggregation which requires a little bit of explanation. BLS is a mechanism to aggregate signatures. And that's cool because it reduces your gas costs. And because we have the ability to implement any signature verification mechanism in the account, then now we can have more efficient signature validation and save some costs. The other big one is eventually, we know that the signature mechanisms that we're using are going to be broken. It's only a matter of time. Quantum computing is making significant progress. It's no longer theoretical. The Q-bits are getting up there eventually. We will all have to stop using ECDSA. But there are alternatives. And hopefully by the time this becomes, you know, a pressing problem, we will just be able to use any quantum-resistant signature mechanism that we want, that is maybe like gas-efficient and secure. And you can swap that. So you have a lot of flexibility once you abstract away how you do signatures and it's not hard-coded. So other interesting use cases are spending limits. I mean, you know, if you're using your wallet for small day-to-day things, maybe you're paying for coffee, for a meal, or for something, you know, that is not usually life-changing, then it makes sense for that to be something that you can do very easily. That shouldn't be too hard. But then if you're making, you know, a very big investment, then you might want to add like a more secure way of doing that. So you go get your ledger really depending on what is the spending limit that you're comfortable with for different levels of security. And you would be able to implement that because, again, you can have arbitrary logic inside a contract that is controlling your account. The other cool thing that you can do is, well, you can have different roles and you can delegate specific actions to those roles. So, you know, if the account is a corporate account, you can give payroll authorization to people who are in charge of that, and you can specify the spending limits. Another example would be if you're, you know, if you have a legal department or you just want to delegate voting power for certain tokens, you could do that in a way that still limits your exposure just to that. So, they would be able to vote with the tokens, perform governance actions, but not, you know, like transfer the tokens, for example. And usually in companies, I mean, this is something that's very common in corporate bank accounts. You give different roles in the company, different powers. So, in the CFO, I'd be able to transfer a larger sum, but there's still a 24-hour delay. And then, you know, maybe other C-level executives could veto that if maybe the, you know, the CFO's key was hacked or their computer was hacked. Or the CFO is untrustworthy for some reason. But another example would be, well, you want to give an auditor the power to monitor payments. And then the auditor has responsibility. If something, you know, they have the responsibility to reach out, to authorize parties, and then verify what they're seeing happening on chain is what is supposed to happen. So, this way, you can tap, like, maybe like a third-party accounting firm, maybe the one you already work with. So, hey, like, you know, we owe it to our shareholders that our treasury management doesn't get compromised. And how about, like, we plug you into our treasury in a way where, yeah, you can't perform. We don't have to rely on maybe your computer security or your staff. We don't want exposure to them in terms of being able to transfer funds. But we do want to give you the responsibility of whatever you see happening. You know, talk to the people who are in charge. Make sure that it is an authorized action. And, you know, within this delay limit, if it isn't, just veto it. Just, like, cancel the transaction. So you could give them the power to cancel, but not initiate transactions. And I think the one that's going to be, like, very useful very soon is session keys. So, in fact, I think this is something Argent recently implemented for their Starknet wallet. So the idea is, well, you want to play some blockchain game, and you don't want to have to click approve every time, like a message needs to be signed. That would really, you know, distract from the gaming experience. But you also don't want to give this game full power over your wallet. That would be crazy. Like, you know, what if there's a security bug in the game? So ideally, you want to create a session key. And the session key has the ability to do whatever is needed, but limited to the gaming contract. Nothing else. And then the worst thing that can happen is, I don't know, maybe you're like your game sword, your NFT items are stolen, if the game gets hacked, but everything else is safe. And you could just store this key inside your browser. So as soon as you authorize this, as you generated the session key, from that point onwards, you don't have to be in the loop in terms of authorizing transactions, and it just becomes transparent. So that's a really nice one. The session keys also, you can mix what we were talking about before. So you could have a session key, not only has maybe limited access to a specific contract, but maybe you have multiple devices, and you want very easy things to be like very, not secure things, things that are not very risky to be very easy from your computer. So maybe if you just want to sign into an event or something that doesn't have world-changing implications, if your computer gets hacked, so you authorize your browser. And you would still have control over your account in case something goes wrong. Browsers are not the most secure platforms, but you could just limit how much power the browser has over your assets. So there's also a big UX issue with gas, where the traditional Web 2 world, where most of our users will be coming from, gas is not really a concept. So if you have a server, you're not really thinking about who's paying to run the server, and how do I share in the costs? It just somehow works behind the scenes. And users who are using this space will not be really familiar with the concept of gas, and it's also a hassle even for people who are familiar. So with abstract accounts, you can have a lot more flexibility in how you handle this. So, for example, if you're a game, especially if you're running on a cheap layer 2, you could decide, hey, it's worth just subsidizing the transactions. As part of my onboarding process, it's very common to have to budget some amount in order to acquire users. So if it's not prohibitively expensive, maybe you want to do that, and then later that's worth your while. Another very obvious one is just being able to pay gas in any ERC-20 token, anything that has value. So if I pay you in USDC, there's no reason that I would also need to send ETH into your account for you to move to that USDC and maybe pay your bills with it. It's nice if you have an account, whatever you have of value there, someone sends you a PayPal transfer, they don't have to send you some other PayPal tokens so you can move your US dollars in PayPal to somewhere else. So payment becomes a lot easier. But also, maybe you're participating in some governance and the governance of that project doesn't want you to have to think whether it's worth your while to pay the gas for the interaction or not. So they just decide to subsidize that. Or maybe you have some allotment and if you go beyond the allotment you have to pay in that project's tokens. The nice thing about being able to interact with a blockchain without needing ETH is it also has some privacy bonuses. Because if you go through the usual KYC process, someone knows who you are and there are companies that are dedicated to linking all the information together so you don't have privacy. But that wouldn't be an issue if you can just receive payment in any token and also pay for the gas in any token. Because let's say I'm a contractor and I work online for you and I'm pseudonymous, I do the work, I give you an address, you pay me and I would be able to pay my bills or buy something online or whatever and I would need to also acquire ETH. And I could also separate, let's say I'm working with different customers, I could give each of them a separate address and the customers wouldn't necessarily need to, they don't need to peek into my bank account or my equivalent of bank account and see how much I'm making and what is the balance there. We're doing that and maybe some of us have gotten used to it but it's really weird where you're working for someone and you give them the number of your bank account and they can see exactly what's going on there. That's not very private. And once we have gas abstraction as a built-in feature then we don't really have to worry about that anymore because we could just easily generate new addresses for everyone that we interact with if we wanted to. There's also an interesting use case for enabling cross-chain operations. There are many ways to do that. Yeah, that's just something that becomes a lot easier once you have this functionality built into the protocol. There's also some savings that you get from just being able to batch different transactions together. Also from being able to guarantee that the transactions are going to execute with atomicity. So for some things, it's useful if everything happens together and if everything doesn't happen together then you don't want it to happen because it wouldn't make sense for the transactions to execute separately. And whether this happens in a gaming environment or there are some financial scenarios, I mean imagine the simplest one would be you have to approve, you have to give some authorization for a contract to perform an action on your behalf and then you want to give them another transaction to actually perform the transaction and those both need to execute together. Otherwise you just wasted gas. And there's a general use case that's interesting you can actually implement these time delay flows. So for example, let's say I want to be selling my ETH when it hits 5,000 but I don't know when that's going to happen. I don't want to sit in front of my computer. So it would be possible for me to just pre-create the transaction but make it conditional on certain things happening. Like, okay, only if the price of ETH is 5,000 or only after this time or whatever the condition is. And so my wallet would agree to execute and pay for the gas for that transaction and also maybe a transaction fee and you would put that into a registry and the registry of a future time delayed or event driven transactions and searchers, they would be able to monitor this registry and see, oh, these are transactions that their conditions have just been met so they can compete on executing it for you. And that opens up a whole range of interesting use cases because now it doesn't have to be you that pulls the trigger at the exact moment that the conditions are met. If the conditions are met, the transaction will be executed for you by searchers and it could be time delayed, it could be based on essentially whatever the conditions make sense. Maybe another example would be there's an NFT series and you have to be, or I don't like an event, they have to subscribe to for in a certain time window. Okay, so a little bit about ERC4337 which is, so this is the standard that we have been working on and the role here is the guy who implemented the contracts. So please, if there are any technical mistakes, correct me. Okay, so this is the first step towards protocol level account abstraction. The nice thing about our approach is that it doesn't require any change to the rules of consensus. So we can kind of experiment for free and we don't have to solve governance in advance. The way we're doing it is, okay, we essentially create mempool, a new type of mempool for anyone that wants to participate in this and a single, you don't need more than a single network. This mempool, it essentially it accepts, it accepts something that is essentially a transaction, we're calling it user operation, but a user operation is equivalent to a transaction, but it's a transaction that works with these account contracts. So what that does is it makes a contract while it's a first class citizen and it totally does away with the need for having an EOA. You don't need an EOA to control this account. And I mean, the way that works, maybe a little bit about how that works, it's kind of similar to how flashbots, MEV, private mempools, like the principle behind it is you can have a mempool where bundlers, they are provided an incentive to submit your transaction. And essentially, we took that idea, originally this was Vitalik's idea and we added the gas abstraction part to it to make it a more general purpose. And the bundlers, their job is to just take these user operations and eventually they bundle them together and they submit them when they're creating bundles that go to actual blocks. The other advantage of doing things this way is that we're separating validation from execution. So if I'm a bundler and I am paying for the gas of your transaction, there's some risk involved for me because if you don't pay me, what happens if I execute your transaction on-chain and it turns out that it ends up, well, at the very least you expect to be repaid in gas because otherwise, why would you participate in the scheme? So to make it very safe for bundlers to participate, what we've done is we've provided a contract that will guarantee that you're always going to be paid back regardless of what happens with your transaction when it's executed on-chain. So we've separated validation from execution and what the bundle needs to do when they accept the transaction is they're just verifying that they're doing this off-chain initially just, okay, if I accept your transaction, I'm calling this huge function and am I going to be paid back for the gas? That's all they're verifying, so it's pretty cheap for them to do that. And later, totally separately, when the transaction is submitted and gets executed, but by then you don't really care as a bundler even if it reverts it's your problem just like with a normal transaction because you're still going to get paid. And without this, it wouldn't really be possible to create a permissionless pool of bundlers that are participating in this protocol because the bundlers will have to trust that they're not going to get cheated. We use the term bundler, which are node validators just like any node validator that also supports account obstruction. One of them is enough to run a network, the more they are, the more resilient to censorship and other things. But a bundler eventually, and eventually all validators hopefully will be also bundlers. So right now we have, you don't need a consensus chain, you don't need like 51% of validators participating in this scheme because ultimately you're generating just regular legal blocks. And we have another mind as an implementation that is supporting this. The more clients support this, the faster your transactions are going to get executed. But yeah. Okay, so with ERC 4337, then once we have this scheme, we can also use it to make rollups cheaper because you can batch transaction, you can aggregate signatures. So yeah, that's another advantage. And like I said, it doesn't require any protocol changes. So on any VM chain, we can start experimenting with this. Is there anything you want to add? Okay. Technically a bundler can run as a separate entity. It is much, much better for it to be a node to be more resilient. So the way to add it right now, the way we currently adding it and girly because it's still in test, is adding it as a separate server. The wallets don't care its implementation. In order to be highly scalable and to be able to batch more, it has to be a node in the network. Another mind already have a node that can run on another mind. And there's a work to add it also with a get code. So what's next? Well, yes, we can start experimenting and have account abstracts in any VM compatible chain without consensus changes. But the goal is to do away with EOAs eventually. We don't need EOAs. And we know we're going to have to move away from them eventually at some point. And there are various ways of thinking about this. So we want to have account abstraction as a basic feature of the protocol. But we want to do it in a way that doesn't enshrine any particular wallet or gives an unfair advantage to any particular wallet. And because the EOAs are a fact and they're very, very common and they probably will be until we move away from them and it will take a few years, we need a way to convert EOAs seamlessly to smart contracts. So there will be some default implementation where, yes, everything in the future is an abstract account, including EOAs. But if you haven't upgraded your EOA, if you haven't inserted code into your EOA, if you haven't activated it in some way, then it just, you know, behind the scenes continues behaving like an EOA, but it has the functionality requiring, allowing you to upgrade it. Of course, this would require a consensus change. And there are various ways it can be achieved where we're discussing. You know, one way would be there's a great new transaction type and then you can set the code for your EOA. This is now the code that's running your EOA. Or, you know, there's also been a suggestion, EIP 3074, maybe that in combination with another EAP. We could also set default proxy contract for all addresses. Do you want to add anything? Yeah, by default. Basically, two options. One is to let the user decide the exact point of time where he wants to upgrade its EOA into a contract wallet, either using a transaction type or a new opcode or such. The other way is to decide that at one point of time all EOAs start using some default implementation we've deployed and tested thoroughly before which behaves exactly like an EOA. So all users will not notice a difference except that from now they have a way to modify or replace the actual implementation. So they have a smart contract that just behaves exactly like an EOA until they decide otherwise, right? Yes. The basic contract doesn't offer any of the advanced features we described earlier except the one feature which is replace implementation. The user can replace implementation. Once it is replaced, disguise the image. Yeah, which are the use cases that we've... Use cases and all the use cases that other people will try to find. Okay, I think that is if anyone has a question. Well, we still... Now we're going to talk about... Well, how do you join this? Yeah, yeah, here. So how do you join this? Count abstraction revolution. You can start experimenting with ERC4337 right away. And at ETHBocata we had eight wonderful submissions. And this is something that's already working. So you don't have to wait. And you can add useful features like the one we discussed, you know, batching or key recovery, or any of the things that we've been talking about. You could build features that were truly not possible with the OAs that we haven't thought about. And if you do, if you're building anything cool, then you should definitely apply for an EF grant because we want to see this... We want to see this used and adopted. And we want to see the experimentation and we want to update this presentation with more interesting use cases. So definitely apply for an EF grant if you have a cool idea that builds on ERC, on the CRC. The other thing is, if you are building a DAP, you have to think about a future where contract wallets are first-class citizens. I mean, contract wallets are already pretty common, especially for teams, you know, multi-SIGs are an example, but still many DAPs assume that they're going to be interacting with an EOA. And that is just an obstacle for us to move forward. It means you're a DAP already can't interact with things like binosus safe wallet. If you're assuming you're making assumptions like how signatures are validated, so there are easy ways to make your DAP compatible, both with smart contracts right away and abstract accounts in the future. And that's ERC 1271, which checks if the caller has code and then there's a mechanism where it can just invoke a function instead of assuming that they can rely on this ECDSI key. The other one is if you can benefit from batching in your user interface, and many DAPs, especially games, can, then you should check if you're connected to a contract wallet that supports it. And that will create a better experience for your users. It will save gas costs. The other thing is with how gas is paid. So if you have a DAP, you should think about different types of gas payment models. An easy example is if you have a token, then it makes sense, perhaps, that your users should be able to pay for the transactions in your token when you're using your DAP. And if you don't have a token or you want to subsidize your users, that's easily accomplished with account abstraction. You set up a contract that authorizes to reimburse your users for whatever criteria you feel comfortable with, maybe the onboarding process, maybe they have to perform some action, but it's something that's possible now. And a lot of the improvements that we're going to get for DAP usability is going to also require some wallet support. So wallets are an important part of usability for DAPs. And as a DAP developer, you have some influence by collaborating with Wallet Dev, saying, okay, this is something that would be beneficial for my use case, and you can have a bit of an influence by just saying, okay, this is useful for me. I need this feature in the wallet, for example, supporting account abstraction. So other than talking with us, we're happy to help anyone that's implementing different use cases. We do have an SDK up later. We'll share on his Twitter the links, but there's an SDK. Or you can come up to us and we'll give you. Yeah, or we'll just give you, but I think you can just open this right now and show where this is pointing to. Wait, this is very small. Why is it so small? Yeah. So we have our SDK. It's on GitHub. Ethanfinitism account abstraction. It's not SDK, it's the contract. Oh, where's the SDK? Ethanfinitism bundle. Okay. Oh, the link is broken then. All right, we'll fix that. Okay. Oh, this is the SDK. This is the reference implementation of a bundler, a simple bundler, and the SDK. Oh, cool. So that's the SDK. We will fix the link later. You can also read up on the ERC. Oh, maybe that's the right link. No, that's for the... Yeah. That's the ERC itself. Yeah, that's the ERC itself. So you can read the ERC. It's very detailed. But you can get very precise understanding of how it works. There's also a discussion on the Ethereum magicians form. And... And of course, it's nice to be able to talk with people. So we have a Discord. We have a Discord server. And you're very welcome to join and ask questions. And even after this event, like if there's something that you don't get to ask us in person. And yeah, maybe now we will just take some questions. Yeah. Yes, over there. Okay, the... In terms of development roadmap, what we've developed are the interfaces and the core contract that performs this magic. We call it entry point. It was audited, but then it was extensively modified to support L2s that is not yet audited. We still have some work on it. The API probably won't change. So a wallet will be able to work. So it's not deployed on mainnet, only on testnet currently. But you can create and start experimenting with wallets on top of that. The interface of a wallet, the change of wallet needs to be quite minimal. I can go through it adding a single method. Or two. Yeah, we have a sample. Yeah, we have a sample that uses... that adds account abstraction support to IgnosiSafe. You add a module and you basically make, okay, a single owner, IgnosiSafe, an account abstract to the compatible. So yes, you can create, and there are some work on creating wallets today. In terms of applications, yes, it's chicken and egg. Application needs a wallet in order to work. There is a... No, it's for a basic hackathon. And application can work without a wallet, but it's not something that you use to want to sign blindly a hash. If you're good with that, it's also possible that an application can work with account abstraction even today. The way gas abstraction works is that when you submit a user up, the contract itself validates itself, the signature and its nonce in order to accept the request, but there's also a pointer to what we call a paymaster. A paymaster is a contract that, before submitting the transaction, has a chance to decide whether it agrees to pay or not. If it says, okay, it doesn't revert, it will use its own balance, its own stake and everything to pay for this transaction. Now, what this paymaster does on-chain depends on the paymaster. So the most obvious example of a paymaster is that the validation will be, I will check that this user has a balance of enough die and has approval from me to use this die and I will grab enough die to cover this transaction. And at the end, I will refund it with the excess. Eventually, I pay, the user pays with tokens for the transaction. This is the most obvious use case of a paymaster, but there are other use cases if you want voting that and you don't want the user to pay anything, okay? So the check is that the user is eligible to vote. If a user is eligible to vote and didn't vote yet, I agree to pay. It's another example of a paymaster. Other examples are still open. You can write whatever you like. Just to contrast, right now, if you're using Gnosisafe, then someone on your team has to pay the ETH from their account. Even if the Gnosisafe has plenty of ETH, someone still needs to pay from their own accounts just to have that transaction finalized. So with a counter obstruction, that wouldn't be necessary. Your account would be able to pay for yourself and this doesn't require a paymaster. But let's say you're safe for going back to the Gnosisafe example. If a Gnosisafe doesn't hold an ETH, it doesn't hold a sufficient ETH where you don't want to have to care about the balance and continually like exchanging and topping it off. And whatever you have a balance of assuming it's enough to pay for the gas, you would essentially include in your transaction a reference to something we're calling a token paymaster. And token paymaster can be a completely autonomous contract on chain that it just accepts tokens. It would pay for the transaction in ETH and then it would settle in some way. So an older reference implementation recreated with just using Uniswap and that single transaction, which was kind of expensive for you, there are cheaper ways of doing it. But just it's very simple. In one single atomic transaction it gets paid, it gets an allowance in whatever token you have. It pays for the gas, it charges the transaction fee and then it gives you back the remaining tokens. So with a count abstraction if you want to use that, for example, then you would just include the entity that is paying for the gas is a token paymaster, but there is a way for the token paymaster to receive a commitment from your account to pay it back. So it's not just subsidizing the transaction, that's also possible. It makes it possible, right now you have to split it because of different concerns. If you need some corporate level security and if you want a game you will use a metamask and if you use a private you use a treasure. Now if you want them all in a single address, yes you will be able to do it with account abstraction. Probably you still might have multiple abstracted accounts for different purposes but for different reasons if the reason to have multiple addresses is only security, then yes you will be able to use an abstracted account to find something that can cover all bases. Yeah, because you can just limit your risk exposure to each device depending on how much you trust it. Again, I'm not saying that there will be one wallet that will give you all these use cases. You will find a wallet that will give you all the uses case you need and use that. And you always can switch. I think the first use case of a signature is change signature. Just think about it, you start using metamask and after a few years you collected a lot of NFTs and a lot of money but you can't change the security model. Your browser holds your private key so you have no idea if anyone hacked into your computer and grabbed it through a copy of your computer. Without changing the address, you can't change the security. With account abstraction, with a single portion of change owner. Now the shares are on the same account. Even with the basic simple account, I just change the owner and now I am really secured because the previous private key is no longer relevant. Even before you get into the fancy stuff that you can do with account abstraction the basics are actually pretty useful just by themselves because right now if anything goes wrong then it's really hard to transfer everything from one EOA to another. You would have to create separate transactions for each asset that you hold that could be pretty expensive and if your computer got compromised, you might need to do that in a huge hurry. So it's just not the best situation to be in. Even very simple improvements like this will make a big difference.