There are two types of accounts on Ethereum:
1. Externally Owned Accounts (EOA) - controlled by an ECDSA key
2. Contract Accounts (Aka Smart Contract Wallets) - controlled by code
The key limitations of EO are:
No access control granularity -same for all EOAs
No multisig wallet
No spending policies
Gas is paid directly by the EOA
Must maintain ETH balance to pay gas
No privacy (send ETH)
No way to batch operations(approve + transferFrom)
Vitalik Buterin mentioned that he didn’t wantt o have EOAs and that all accounts should have been smart contracts in the first place. However, he decided to launch Ethereum without adding another layer of complexity.
With Contract Accounts, each user account is as mart contract allowing for any custom authentication or execution logic. It’s much more than just multisig. You can set time locks and spending limits or set up different recovery mechanisms (e.g., social recovery) or seedless onboarding.
Contract Accounts are mutable, meaning you can change the authentication scheme, rotate keys, add/remove signers, and change signature verification rules.
To make any transactions on Ethereum, you need ETH to pay transaction fees, and you cannot pay it in any other ERC-20 tokens(e.g., USDT). On top of that, most protocols aim to subsidize your transaction fees to increase the accessibility and usability of their protocol. However, they cannot do that right now. Contract accounts are also helpful with gas abstraction and tackle this issue to pay transaction fees in ERC20 tokens and by another smart contract.
There are a few myths about contract accounts:
1. Contract Accounts can’t sign messages
Reality: Smart contracts can sign messages via EIP 1271.
2. Contract Accounts produce a different address on each chain
Reality: CREATE2 opcode creates the ability to predict the address where a contract will be deployed without ever having to do so.
3. Contract Accounts have huge gas overheads
Reality: the permanent gas overhead is ~3k gas (delegatecall)
How will we get Account Abstraction?
ERC 4337 is the main proposal regarding account abstraction, which avoids the need for consensus-layer protocol changes.
ERC 4337 allows:
- Changes to verification logic (add signature, multisig, and ECT)
- Wallet upgradeability (can change the code entirely)
- Execution logic flexibility (wallets can add custom logic for the execution)
- Pay transaction fees with EIP-20tokens (allows developers to pay fees for their users)
EIP-3074 allows the EOA to delegate control to a smart contract. With the extraordinary growth of tokens on Ethereum, it has become common for EOAs to hold valuable assets without holding any ether.Today, these assets must be converted to ether before they can be used to pay gas fees. However, without ether to pay for the conversion, it’s impossible to convert them. Sponsored transactions break the circular dependency.
EIP-5003 allows for the conversion of existing EOAs to smart contracts. The timeline is unknown for all proposals, and we can only say that ERC-4337 is available on a testnet.
So far, we have only reviewed AccountAbstraction on Ethereum. What about multiple Ethereum killers? They should haveAccount Abstraction from the very beginning, given that they don’t need to work with a “legacy” system. Right?
Let’s look at Solana
The most popular wallet on Solana is Phantom, which doesn’t provide any innovation apart from the ability to reset your seed phrase (not private keys):
I didn’t find any wallets adopting account abstractions:
- No social recovery
- No spending limits
- No key recovery if the key gets lost
- No change in the verificationlogic
Solana implemented subsidization of transaction fees, and you can pay in analog of ERC-20 tokens transaction fees instead of SOL tokens. Solana isn’t a brand-new Ethereum “killer.” Solana released a beta version of its mainnet in March 2020. However, they probably didn’t have enough time to move in this direction.
Another Ethereum “killer,” but a brand-new one. They aim to bring the masses to web3. They definitely thought about the current issue of the crypto space and implemented Account Abstraction during protocol design.
In Apto’s white paper in section 6.2, theymentioned hybrid models of custody where you can rotate the account’s private key to one or more custodians or various private key recovery schemes.
But for the time being, this is what the first wallet, Petra, looks like:
The first Aptos wallet is a copy of Fantom from Solana. The recovery mechanism is a copy of the older brother (Solana).But so far, so bad. There are no hybrid models of custody or different recovery mechanics.
Unlike Aptos, the Sui blockchain didn’t touch the Account Abstraction topic in its documentation. Theoretically, every account is an object in the Sui ecosystem and programmable, leaving space for custom logic adoption at the verification execution level.
Like Aptos, Sui’s first wallet looks the same in terms of recovery:
There is no social recovery or other mechanisms. It seems that it’s not the first priority for Sui.
Any conversation about Account Abstraction is incomplete without mentioning MPC.
What is MPC?
When considering Accounts Abstraction, we should also touch on MPC technology and MPC wallets.
MPC stands for multiparty computation, which is a cryptographic protocol that distributes a computation across multiple parties where no individual party can see the other parties’ data.
MPC can be used to replace individual private keys for signing transactions. Each computer possesses a piece of private data representing a share of the key, and together they cooperate in signing transactions in a distributed way. When a transaction needs to be signed, rather than invoking a single private key, the MPC process is triggered and each independent node cooperates to sign the transaction in a distributed way.
The difference between multisig and MPC is that multisig crypto wallets are secured by several distinct on-chain signatures generated by different private keys. However, MPC relies on a single signature created off-chain.
MPC is a popular choice for enterprise keymanagement solutions such as Bitgo, Qredo, or Fireblocks. Coinbase alsointroduced an MPC beta version into their wallet this year.
The main advantages of MPC Wallets:
- Off-chain recovery, which is cheaper and easier but not as flexible
- Truly cross-chain, with no dependence on smart contracts
- No gas overhead
- No need for any changes in dApp
But there are also disadvantages:
- You cannot change authentication rules (immutable rules)
- You only can recover accounts once
Most MPC wallets are semi-custodial, and you’re dependent on these service providers to recover your account. Qredo is building decentralized custody to record asset ownership across different layer 1 blockchains where you don’t depend on the Qredo service and can initiate a transaction by a Qredo client or MetaMask wallet (at least, this is what they claim in the white paper).
MPC technology alone doesn’t address all Account Abstraction issues but can solve a private key problem. However, it doesn’t resolve other questions, such as recovery or custom execution logic.
What will the future wallet look like?
For the time being, a mix of MPC technology that stores distributed key shares on a trustless blockchain where the recovery mechanism doesn’t depend on an MPC service provider. Plus, smart contract wallets on a protocol level provide social recovery, arbitrary access control, and batching transactions.