# Account Abstraction: Why does it matter?

**Published by:** [0xProdMan](https://paragraph.com/@0xprodman/)
**Published on:** 2023-07-12
**URL:** https://paragraph.com/@0xprodman/account-abstraction-why-does-it-matter

## Content

You might have read or heard about account abstraction recently as it’s gained popularity as a term used across CT. Even large Web3 players like alchemy and biconomy are jumping onto the scene with SDKs - trying to help builders build. And Vitalik has also suggested its one of three transitions that needs to be implemented or Ethereum may fail! You might be asking, wow - this is big, but what is Account Abstraction? In a multipart series, we’ll take a look at AA - it’s background, why it matters, and dive into some promising products/projects that are already on the scene. First a bit of background: Ethereum has two types of addresses: EOAs and Contract Accounts EOAs - Externally Owned Accounts If you’ve used any blockchain service, odds are you used/created an EOA To create an EOA, a seed phrase is used to generate a deterministic key pair (private/public). This key is then used to interact with the blockchain This type of wallet requires a ‘real human’ to generate keys from a seed and store that phrase (or private key) somewhere they feel safe There are many different ways to create EOAs including hardware wallets and software wallets and chrome extensions (ledger, trezor, metamask, trust wallet, etc) Once you’ve created the EOA, you can use it to store, receive and send ETH and interact with contracts (ERC-20 tokens, ERC-721 tokens, use DeFi, build your own contract, etc) Contract Accounts Contracts are created by EOAs They can hold funds of any kind and are bound by rules set by the owner (the EOA that created the contract) Contract accounts are software only and do not create keys or seed phrases themselves Contract accounts have created all sorts of utilities that people (and bots) interact with including Decentralized Finance (DeFi), Fungible (ERC-20) and Non-Fungible Tokens (NFTs), Bridges, etc. When you hear the phrase ‘Smart Contract’ its really referring to a contract account with a specific address that you can interact with. That contract is said to be ‘permissionless’ because any address (contract or EOA) can use it Projects have built front ends that interact with their contracts which creates transactions on the users behalf that interact with that contract address and reduce the UX burden OK, now that we have some background, whats the problem? Seems like it’s working okay, right? Wrong! The crypto community highly values two things: self-custody and security Self-custody is amazing! And something we haven’t had in our society since we traded with gold and bartered for goods. Instead, we switched over to trusting centralized parties with our value (banks, governments, custodians, brokerage firms, etc), but that has proven to be problematic. You’ve probably heard the phrase “Not your keys, not your coins” - but that should really be extended to “Not your keys, not your property” True ownership of your assets prevents some big problems If you hold your assets with a custodian and they go down, you’re money likely goes down with them (ex: FTX) If you’re a bank customer and you have deposits, if they go down your deposit might be lost (ex: SVB) Governments can seize your property or bank accounts without much explanation, or inflate away your savings But with great power comes great responsibility. Self-custody is hard because whoever creates the account must now manage the security of those assets. Should anything get compromised, everything could be lost. Which is a big risk when you’re talking about large sums of money. Keys are very technical, and not for the faint of heart. It requires a good amount of IT skills and the ability to identify possible attack vectors ahead of time. And you need to keep up with anything you might have done that could have compromised that security. So, what happens when you lose or compromise your keys? You are S.O.L. - there is no way to recover your value if its lost or stolen. Even more painful because its was ultimately your fault. You didn’t secure your keys properly... There’s no one to yell at over the phone except yourself. There must be a better way?! Contract Accounts as wallets have been proposed to solve the user experience problem while maintaining the two important features of self-custody and security. These contract accounts that serve as wallets are generally referred to as Smart Contract Wallets (SCW). Cited benefits of SCWs include simplified onboarding, frictionless transactions, enhanced security, and new capabilities over EOAs (more on this later) The concept of SCWs is not new Vitalik initially envisioned Smart Contract Wallets as the default wallet experience for users in Ethereum (rather than creating EOAs), but it was too difficult to implement at the time. Many projects have had success and failure in this space The biggest success is Safes (spun out from Gnosis) which creates a multi-signature smart wallet This has been extremely helpful for crypto projects that want to manage their treasury, but has not been widely adopted by ‘normal’ users - mostly because of transaction costs Other live projects include Argent, Avocado, SoulWallet, PatchWallet and Ambire Some defunct SCW projects include Authereum and Dharma - RIP But what is Account Abstraction? Recently (March 2023) a proposal was passed called EIP-4337 and included in the Shanghai Ethereum release. This proposal was nicknamed Account Abstraction since the idea is to have wallet features without the account management - abstracting it away. EIP-4337 has drummed up more attention to SCWs because it creates a way for them to be native to the protocol - standardizing the implementation and creating common features such as security, gas payers, and transaction batching. This makes SCWs first class citizens of the chain and allows a standard for these accounts rather than relying on individual projects coming up with their own versions (aka AA anarchy). For example, in order to track Gnosis Safe transactions, you’d have to know the all the contract addresses of the type ‘safe’. Now you can simply track all transactions that are of type UserOp (how AA wallets transact). The best analogy is how Crypto Punks are NFTs, but require a separate marketplace (and different tracking) because they don’t conform to ERC-721 or 1155 standards. Safes are similar to Crypto Punks in that they were implemented before the standard existed. With the new standard, there will be efficiencies for all the new projects that pop up. (maybe we’ll see as many new wallets as we saw PFP projects!) So, what are the benefits of Account Abstraction? Superior key management With Account Abstraction, you can use all different types of authorization methods to secure your account - email/password, SMS, Google, Facebook (gasp!). And what’s nice is that you can use more than one method to secure your account, creating a multi-sig of sorts around your keys. Because the security is not tied to a hardware device, you could access the wallet on multiple devices Security You can change permissions more frequently or set rules for interacting with a specific dApp (using a timer or volume amount). Right now you need to revoke access using a tool such as revoke.cash. This is extremely difficult to do, but will be effortless with AA Much like how you can turn off and turn on credit card / bank account features, a much more intuitive model of security can be implemented to prevent wallet exploits. Scrutiny can be added to large transactions such as time locks or additional signers before the transaction is committed. New methods to pay for transaction fees Most individuals still think of fees in terms of their local fiat currency (USD, EUR, etc) - but we’re still paying those fees in ETH because the network requires it. With AA, you can pay for transaction fees in ERC-20 tokens such as USDC which is much more intuitive than ETH. Transaction fees could be paid for by projects or subsidized through incentives The payer doesn’t need to be owned by the signing wallet, so in theory projects could pay for the gas fees. Of course there would need to be some sort of incentive for them to do this, but perhaps MEV rewards could be enough to offset the costs or simply interacting with the protocol enough could unlock more gas being paid for. Ability to batch transactions The new 4337 implementation allows for batching of transactions (across many wallets within the relayer) This not only saves on gas fees, but it also allows for really easy UX such as combining approvals and transactions into one. Plus, more sophisticated strategies such as flash loans or dependent transactions can be simply created for most users - which previously required advanced contracts to be deployed. That’s all for now. Stay tuned for the next post where we’ll dive into some projects and do some product analysis. Please subscribe!

## Publication Information

- [0xProdMan](https://paragraph.com/@0xprodman/): Publication homepage
- [All Posts](https://paragraph.com/@0xprodman/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@0xprodman): Subscribe to updates