In a decade we are going to look back on Externally owned accounts (EOAs), blockchain accounts controlled by a private key, as primitive. With an EOA, if you lose your private key, all your assets are lost. You’ll need a native token on every chain you use to pay for gas, and many transactions require multiple steps (e.g. submitting an approval transaction before a swap). The user experience is clunky.

Account abstraction (AA) has been hot recently because it’s an order of magnitude improvement over plain-old EOAs. Yet, even with all its hype, it is often misunderstood. AA is often referred to synonymously with smart contract wallets and gasless transactions which has been a great marketing play although a little misleading. Let’s dive into what AA and smart contract wallets are and then explore the benefits and challenges of each.

Before we can understand AA, we’ll need to go over the two types of accounts on EVM blockchains. First, there are EOAs which include the wallets of most existing crypto users. When users sign up for a wallet like MetaMask or Phantom, they’ll write down a seed phrase which is used to derive their private keys. Those private keys can sign transactions, which the wallet submits to a blockchain.

The other type of account is a contract account, an account with associated code. Examples of contract accounts include NFTs and DeFi protocols, which are often composed of multiple contract accounts.

Both EOAs and contract accounts have limitations. EOAs cannot have code associated with them and contract accounts cannot initiate transactions. Account Abstraction, in its pure form, will remove the limitations of each. EOAs will have code and contract accounts will be able to submit transactions, hence the name “account abstraction.”

Account abstraction is often referred to synonymously with smart contract wallets and gasless transactions due to EIP4337, but as previously mentioned, it is sometimes misleading. Let’s define each:

• Smart Contract Wallet: A contract account that is used as a wallet. The code in the associated account will define the wallet’s policy for sending transactions which often requires a signed message from a user.

• Gasless transaction: The technical term here is meta-transaction which is a signed instruction from a user that is executed on-chain by another account. The transaction still includes gas, but from the user’s perspective it is gasless because the user is not the one dealing with gas.

Smart contract wallets and gasless transactions have been around for years and are yet to have widespread adoption. We’ll cover gasless transactions further in the next article, but let’s go over the benefits of drawbacks of smart contract wallets before looking at how AA can improve upon plain old smart contract wallets.

Most smart contract wallets support gasless transactions where a user can sign a message authorizing a transaction and then another entity can submit that transaction for the user.

Send multiple transactions at once. For instance, instead of sending an approval transaction, waiting, and then finally submitting a swap, you can send both transactions at once.

A decentralized "forgot your password" flow. If you lose access to a private key, a few trusted friends, family or institutions can help you recover your account. Most people will likely opt for a trusted institution similar to how people use iCloud and Dropbox to back up their data, or how people use LastPass and 1Password to back up their passwords.

Traditionally you need to sign every transaction sent from a wallet like MetaMask. Session keys allow a user to authorize an entire session of transactions with one single click. Instead of signing a message for every transaction, you’ll authorize X amount of a token to be spent by a temporary private key living on the user’s device within a specified timeframe.

Users can upgrade their key management when they are ready. A user may start with a wallet controlled by 1 key that lives on their device. Then, when they are ready, they may upgrade to MPC or a hardware wallet.

It costs about 250k gas to deploy most smart contract wallets* on EVM blockchains. At the time of writing (gas cost is 42 gwei/gas), that’s $20 on Ethereum mainnet to onboard a user which is prohibitive for everyday users.

Onboarding costs are feasible on layer 2s and sidechains, though. It only costs about $0.02 to create a smart contract wallet on Polygon for instance.

*Technical note: This figure is based on the deployment cost of a minimal upgradeable proxy like the SafeProxy contract which is one of the smallest contracts you can deploy to create a new smart contract wallet.

Smart contract wallets do not have associated private keys to sign messages which makes smart contract wallets incompatible with applications that require user signatures like many on-chain order books. EIP1271 was created as standard for compatibility with signature-verifying protocols, but EIP1271 is not yet well supported.

Inability to sign messages also adds complexity for applications that use off-chain signatures for web2 authentication flows like Sign-In with Ethereum.

These problems will go away over time as smart contract wallets gain adoption and smart contract wallet compatibility becomes a requirement. In the meantime, though, these problems do add friction to smart contract wallet adoption.

Users will expect their wallet to be the same on every chain but wallet addresses and implementations may differ between different chains. Due to nuances between different EVM implementations (e.g. support for both EIP-155 transactions and pre-EIP-155 transactions), smart contract wallets may have different addresses on different chains if developers do not set them up correctly*.

Furthermore, smart contract wallet logic may differ across different chains. Most smart contract wallets can be upgraded (e.g. upgrading key management, upgrading the code of the contract) which will need to be kept consistent across different chains.

I suspect this problem will be solved off-chain. A potentially clean, decentralized solution for this would be to track upgrades to wallets on Arweave, a permanent storage ledger, and then upgrade wallet logic on specific chains as needed. All wallets would stay up to date without users paying for upgrades on dormant wallets.

*Technical note: contracts can be deployed on the same address on different chains using the create2 opcode which deploys contracts to a deterministic address based on the sender’s address, a salt (i.e. arbitrary data), and the to-be-deployed contract’s bytecode. If the sender’s address or bytecode are different on different chains, then the smart contract wallet will have a different address.

Typically contract deployments use a singleton factory to deterministically deploy contracts, which must be deployed at the same address on every chain to keep the sender address consistent. Some singleton factories use pre-EIP-155 transactions so that a single signed transaction can be submitted on any chain, but some EVM implementations do not support pre-EIP-155 transactions. The downside of the first mentioned singleton factory is that projects must trust the Safe team to properly safeguard their private key used to deploy it.

Pure AA, allowing EOAs to upgrade into contract accounts, has the potential to solve the two main drawbacks of smart contract wallets: onboarding costs and signing. Users will be able to create a wallet without the friction of an expensive contract deployment and then upgrade to a smart contract wallet when they are ready.

Regarding signing, if a smart contract wallet has a private key associated with its public address, that private key can be used. There are potential issues in this case if a user transitions control of their wallet to another key, but it would still lead to compatibility with more protocols while EIP1271 gains adoption.

Lastly, pure AA solves the potential issue with different addresses on different chains because the public address on different chains would be derived from the original private key.

Smart contract wallets have been around for a while. They have traditionally been used as MultiSig wallets where the wallet is controlled by multiple private keys and transactions are authorized in distinct steps. Signing transactions in distinct steps makes sense when the private keys are controlled by different individuals which is the case when the MultiSig is used to hold the funds of an organization, but it’s a clunky experience for advanced users that want improved security.

Safe has historically been the most popular MultiSig. Smart contract wallets need to be trusted and Safe’s long history of safety and security makes it the best option. There is some risk to using an early smart contract wallet given that some have been hacked in the past (*cough cough* Parity MultiSig hack). New smart contract wallets will need to prove themselves over a long time period before they can reach wide adoption.

Argent and Authereum were two of the earliest attempts to bring smart contract wallets mainstream but both teams have since pivoted because the deployment costs on Ethereum mainnet were (and still are) prohibitive for everyday users. Argent pivoted to focusing their wallet on Layer 2s, specifically Starknet and zkSync, while the Authereum team is now behind the Hop bridge.

Recently wallets like Waymont and Sequence have created much cleaner user-experiences around MultiSigs. The former is targeted at high net worth individuals and the latter is targeted for everydays users. Polymarket also uses smart contract wallets under the hood to offer their users gasless and batched transactions.

An article on smart contract wallets and account abstraction wouldn’t be complete without discussing EIP4337. EIP4337 is a standard for smart contract wallets and a design for a decentralized relayer (“bundler” in EIP4337 jargon) network.

Creating a standard for smart contract wallets is great, but I’ve long been critical of EIP4337 for creating a decentralized bundler network, making the standard more complicated without an immediate benefit to users or developers. With that said, EIP4337 will help Ethereum transition to native AA. If it gains enough adoption, blockchain validators will become bundlers and vice versa.

There are a number of companies building smart contract wallets on top of EIP4337 including Fun, ZeroDev, and Biconomy.

I expect smart contract wallets to gain significant adoption in the next couple years due to their benefits and eventually become the status quo for wallets when account abstraction is adopted in the protocol. There is an opportunity now for wallets like Metamask, Phantom, Rainbow, etc. to offer users a more secure and seamless experience by being early consumer smart contract wallets for users able to pay for their own onboarding costs.

In a decade we are going to look back on Externally owned accounts (EOAs), blockchain accounts controlled by a private key, as primitive. With an EOA, if you lose your private key, all your assets are lost. You’ll need a native token on every chain you use to pay for gas, and many transactions require multiple steps (e.g. submitting an approval transaction before a swap). The user experience is clunky.

Account abstraction (AA) has been hot recently because it’s an order of magnitude improvement over plain-old EOAs. Yet, even with all its hype, it is often misunderstood. AA is often referred to synonymously with smart contract wallets and gasless transactions which has been a great marketing play although a little misleading. Let’s dive into what AA and smart contract wallets are and then explore the benefits and challenges of each.

Before we can understand AA, we’ll need to go over the two types of accounts on EVM blockchains. First, there are EOAs which include the wallets of most existing crypto users. When users sign up for a wallet like MetaMask or Phantom, they’ll write down a seed phrase which is used to derive their private keys. Those private keys can sign transactions, which the wallet submits to a blockchain.

The other type of account is a contract account, an account with associated code. Examples of contract accounts include NFTs and DeFi protocols, which are often composed of multiple contract accounts.

Both EOAs and contract accounts have limitations. EOAs cannot have code associated with them and contract accounts cannot initiate transactions. Account Abstraction, in its pure form, will remove the limitations of each. EOAs will have code and contract accounts will be able to submit transactions, hence the name “account abstraction.”

Account abstraction is often referred to synonymously with smart contract wallets and gasless transactions due to EIP4337, but as previously mentioned, it is sometimes misleading. Let’s define each:

• Smart Contract Wallet: A contract account that is used as a wallet. The code in the associated account will define the wallet’s policy for sending transactions which often requires a signed message from a user.

• Gasless transaction: The technical term here is meta-transaction which is a signed instruction from a user that is executed on-chain by another account. The transaction still includes gas, but from the user’s perspective it is gasless because the user is not the one dealing with gas.

Smart contract wallets and gasless transactions have been around for years and are yet to have widespread adoption. We’ll cover gasless transactions further in the next article, but let’s go over the benefits of drawbacks of smart contract wallets before looking at how AA can improve upon plain old smart contract wallets.

Most smart contract wallets support gasless transactions where a user can sign a message authorizing a transaction and then another entity can submit that transaction for the user.

Send multiple transactions at once. For instance, instead of sending an approval transaction, waiting, and then finally submitting a swap, you can send both transactions at once.

A decentralized "forgot your password" flow. If you lose access to a private key, a few trusted friends, family or institutions can help you recover your account. Most people will likely opt for a trusted institution similar to how people use iCloud and Dropbox to back up their data, or how people use LastPass and 1Password to back up their passwords.

Traditionally you need to sign every transaction sent from a wallet like MetaMask. Session keys allow a user to authorize an entire session of transactions with one single click. Instead of signing a message for every transaction, you’ll authorize X amount of a token to be spent by a temporary private key living on the user’s device within a specified timeframe.

Users can upgrade their key management when they are ready. A user may start with a wallet controlled by 1 key that lives on their device. Then, when they are ready, they may upgrade to MPC or a hardware wallet.

It costs about 250k gas to deploy most smart contract wallets* on EVM blockchains. At the time of writing (gas cost is 42 gwei/gas), that’s $20 on Ethereum mainnet to onboard a user which is prohibitive for everyday users.

Onboarding costs are feasible on layer 2s and sidechains, though. It only costs about $0.02 to create a smart contract wallet on Polygon for instance.

*Technical note: This figure is based on the deployment cost of a minimal upgradeable proxy like the SafeProxy contract which is one of the smallest contracts you can deploy to create a new smart contract wallet.

Smart contract wallets do not have associated private keys to sign messages which makes smart contract wallets incompatible with applications that require user signatures like many on-chain order books. EIP1271 was created as standard for compatibility with signature-verifying protocols, but EIP1271 is not yet well supported.

Inability to sign messages also adds complexity for applications that use off-chain signatures for web2 authentication flows like Sign-In with Ethereum.

These problems will go away over time as smart contract wallets gain adoption and smart contract wallet compatibility becomes a requirement. In the meantime, though, these problems do add friction to smart contract wallet adoption.

Users will expect their wallet to be the same on every chain but wallet addresses and implementations may differ between different chains. Due to nuances between different EVM implementations (e.g. support for both EIP-155 transactions and pre-EIP-155 transactions), smart contract wallets may have different addresses on different chains if developers do not set them up correctly*.

Furthermore, smart contract wallet logic may differ across different chains. Most smart contract wallets can be upgraded (e.g. upgrading key management, upgrading the code of the contract) which will need to be kept consistent across different chains.

I suspect this problem will be solved off-chain. A potentially clean, decentralized solution for this would be to track upgrades to wallets on Arweave, a permanent storage ledger, and then upgrade wallet logic on specific chains as needed. All wallets would stay up to date without users paying for upgrades on dormant wallets.

*Technical note: contracts can be deployed on the same address on different chains using the create2 opcode which deploys contracts to a deterministic address based on the sender’s address, a salt (i.e. arbitrary data), and the to-be-deployed contract’s bytecode. If the sender’s address or bytecode are different on different chains, then the smart contract wallet will have a different address.

Typically contract deployments use a singleton factory to deterministically deploy contracts, which must be deployed at the same address on every chain to keep the sender address consistent. Some singleton factories use pre-EIP-155 transactions so that a single signed transaction can be submitted on any chain, but some EVM implementations do not support pre-EIP-155 transactions. The downside of the first mentioned singleton factory is that projects must trust the Safe team to properly safeguard their private key used to deploy it.

Pure AA, allowing EOAs to upgrade into contract accounts, has the potential to solve the two main drawbacks of smart contract wallets: onboarding costs and signing. Users will be able to create a wallet without the friction of an expensive contract deployment and then upgrade to a smart contract wallet when they are ready.

Regarding signing, if a smart contract wallet has a private key associated with its public address, that private key can be used. There are potential issues in this case if a user transitions control of their wallet to another key, but it would still lead to compatibility with more protocols while EIP1271 gains adoption.

Lastly, pure AA solves the potential issue with different addresses on different chains because the public address on different chains would be derived from the original private key.

Smart contract wallets have been around for a while. They have traditionally been used as MultiSig wallets where the wallet is controlled by multiple private keys and transactions are authorized in distinct steps. Signing transactions in distinct steps makes sense when the private keys are controlled by different individuals which is the case when the MultiSig is used to hold the funds of an organization, but it’s a clunky experience for advanced users that want improved security.

Safe has historically been the most popular MultiSig. Smart contract wallets need to be trusted and Safe’s long history of safety and security makes it the best option. There is some risk to using an early smart contract wallet given that some have been hacked in the past (*cough cough* Parity MultiSig hack). New smart contract wallets will need to prove themselves over a long time period before they can reach wide adoption.

Argent and Authereum were two of the earliest attempts to bring smart contract wallets mainstream but both teams have since pivoted because the deployment costs on Ethereum mainnet were (and still are) prohibitive for everyday users. Argent pivoted to focusing their wallet on Layer 2s, specifically Starknet and zkSync, while the Authereum team is now behind the Hop bridge.

Recently wallets like Waymont and Sequence have created much cleaner user-experiences around MultiSigs. The former is targeted at high net worth individuals and the latter is targeted for everydays users. Polymarket also uses smart contract wallets under the hood to offer their users gasless and batched transactions.

An article on smart contract wallets and account abstraction wouldn’t be complete without discussing EIP4337. EIP4337 is a standard for smart contract wallets and a design for a decentralized relayer (“bundler” in EIP4337 jargon) network.

Creating a standard for smart contract wallets is great, but I’ve long been critical of EIP4337 for creating a decentralized bundler network, making the standard more complicated without an immediate benefit to users or developers. With that said, EIP4337 will help Ethereum transition to native AA. If it gains enough adoption, blockchain validators will become bundlers and vice versa.

There are a number of companies building smart contract wallets on top of EIP4337 including Fun, ZeroDev, and Biconomy.

I expect smart contract wallets to gain significant adoption in the next couple years due to their benefits and eventually become the status quo for wallets when account abstraction is adopted in the protocol. There is an opportunity now for wallets like Metamask, Phantom, Rainbow, etc. to offer users a more secure and seamless experience by being early consumer smart contract wallets for users able to pay for their own onboarding costs.