Account abstraction, smart wallets, smart contract wallets, smart accounts… These are some of the “fancy” names that have sounded in the web3 space the last few weeks. Probably, you are asking you what these terms mean or why you need to know about them.
The first one question is quite easy to answer. They are all the same thing, just one thing, a contract. A classical smart contract just like the other ones you use to interact in your daily routine. There are no reasons to panic. You already know what account abstraction is and how to deal with it. It is an smart contract and what's more, you may have already interacted with it or at least with very similar contracts.
Key: An smart contract is able to “hodl” web3 assets and start transactions. Therefore: Account abstraction is an smart contract which “hold” assets and start transactions.
Let’s go ahead to solve the second and most important question about account abstraction, what account abstraction is offering to us, the web3 community.
Account abstraction has the capabilities to solve some important trade-offs regarding user and developer experience. Some of them are:
Account Recovery: a contract can be configured to allow an user to set up several addresses as backup. If the user lost the access to his/her main wallet, he/she is still able to interact with the contract trough the backup addresses.
Account Freezing: if any wallet or device is compromised, an user is able to lock the assets in the contract to avoid any possible attack. And then, revoke the access to the compromised wallet and/or device.
Granular access control: an user is able to set up roles with different levels of access to the contract. This is a powerful feature with endless applications like allowing a secondary address to transfer some tokens while to transfer NFTs requires the signature of the main wallet. Or requiring several signatures to protect the most valuable assets while sending regular transactions only requires one signature.
Whitelists: similar to the previous one, an user is able to whitelist or blacklist addresses, allowing to send funds only to the previously chosen addresses or avoiding the interaction with some known malicious contracts.
Transaction Limits: a contract can be configured to non allow transactions after reach certain limit, based on the amount of tokens transferred for a period of time and/or the total number of transactions among others. For example an user may set up a limit of 42 transactions per week, a limit of 1 ether per week…
Gasless transactions (sponsored transactions): an user may sign a transaction while another user (the sponsor) may pay the gas for the transaction. This should make UX (user experience) easier to web2 users helping us with mass adoption.
Pay gas with tokens: a contract is able to swap any token into the native one on the fly to allow an user to pay the gas with any token. Did you know that the uniswap unicorn has wings? Well, now you do.
Inheritance: an user may set up a contract to manage his/her wills. An user may set up several beneficiaries whose will be able to claim the assets in he contract after reach certain date.
An example of this application can be found in Inheritas by J. Valeska (of course, I have to update it to leverage the EIPs). Thought, Inheritas is currently not implementing the EIPs, it is a great sample of how account abstraction is nothing but a contract. And how anyone is able to build account abstraction based contracts before even know what account abstraction is.
As you can see, all of these features have one thing in common, they all improve the user experience while allow developers to explore endless possibilities. As I said before, it is no time to panic, it is builder time! So, let’s buidl a better web!