Normally, new crypto users onboard to interact with some kind of application. Between storing seed phrases, adding token contracts, learning how to switch networks, differentiating between addresses, and understanding gas fees, the intricacies of Ethereum transactions and asset custody are two of the last things on a new user’s mind when onboarding.
Similar to the first users of the internet, early adopters are willing to tackle subpar user experience out of genuine curiosity and for the sake of furthering the space, but at a certain point of adoption, user experience and utility become more and more important.
Account abstraction is a long-term vision for improving and expanding the functions and potential of Ethereum accounts. Account abstraction as a concept was first introduced by Vitalik in 2016, and since then, multiple proposals and initiatives have been developed to push the agenda. The topic lost some steam partially due to the importance and necessity of the merge, but now that Eth2 is up and running, the fervor has returned. By focusing on the development of smart contract accounts, we can transfer the burden and logic of transaction sign-offs from human users to smart contracts. Human intervention will slowly phase out as more actions become dictated by smart contract code.
Before going into the differences between the two types of Ethereum accounts, we have to understand the role of the Ethereum Virtual Machine (EVM) in regard to Ethereum as a network. This will give further insight into the names of Ethereum accounts.
The EVM is a virtual computer maintained by thousands of connected computers running an Ethereum client, used for defining the rules for computing a new valid state from block to block. Ethereum’s state is a large data structure, holding all accounts, balances, as well as machine state, which can change from block to block according to a pre-defined set of rules, and which can execute arbitrary machine code. The specific rules of changing state from block to block are defined by the EVM. The EVM is the backbone of Ethereum and acts as the program that executes smart contracts, thereby providing a run-time environment on top of the Ethereum network.
There are two types of Ethereum accounts. The first is the externally owned account, which comes with send and receive functions, which exist outside (external) of the EVM. The second is the contract account, which exists within the EVM as smart contracts. Ideally, the goal of account abstraction is to combine these two account types so developers and users will no longer need to distinguish between different account types, and transacting (state changes) can take place fully within the EVM and off of the blockchain protocol.
In order for users to use the Ethereum network, they have to create an Ethereum Account. Ethereum accounts can be understood simply as bank accounts for the Ethereum network. Accounts can either be user-controlled or deployed as smart contracts. It is important to note that Ethereum wallets are not accounts. Ethereum wallets are simply an interface, usually in the form of a software application, that allows you to interact with your Ethereum account.
Ethereum accounts consist of five key components:
Nonce: The counter that tracks the number of transactions an account sends or contracts an account creates. By counting every time a transaction takes place, the nonce ensures that each transaction is made only once.
Balance: The amount of wei/ether owned by an account.
Codehash: The code tied to that account on the Ethereum Virtual Machine (EVM), this only exists for contract accounts and is an empty string on externally owned accounts.
StorageRoot: A 256-bit hash that encodes the account’s storage content (storage hash).
Contract Code: Not all accounts have contract codes, and contract codes cannot be altered once executed.
In order to understand the vision for account abstraction, we need to understand the two types of accounts currently available for users, how they work, and how they clash.
EOAs have three properties:
An ether balance
A nonce ensuring each transaction is unique
An address that acts as a unique identifier
Ethereum transactions modify the state of Ethereum accounts and thus modify the state of the blockchain. Currently, transactions can only be triggered from something external to the blockchain, and thus EOAs serve as the origin for all transaction initiations. EOAs are the first accounts to interact with transactions that are executed by the EVM, and corresponding accounts must pay a fee to the miner for the execution of the entire transaction.
EOAs are controlled by users through software applications e.g Metamask. These are simple accounts and do not contain a codehash. This is due to the fact that they exist “externally” from the EVM. EOAs use a private and public keypair to hold funds. A private key is used to sign off on digital messages, and a public key is used as verification that a given signature was signed by the proper private key. If you have a private key, you automatically have an account at the associated address.
With EOAs, we can see that the object holding tokens (the account) is the same object authorized to move said tokens (the signer). Technically, a user never really holds cryptocurrency, a user only holds private keys, and the funds are on Ethereum’s ledger. This causes certain vulnerabilities centered around private keys.
EOAs are convenient to create, they can trigger code to execute numerous functions such as token transfers or creating contracts, however, cannot list incoming transactions entirely revolve around the safe-keeping of a private key.
Contract accounts are smart contracts that exist as code written on the EVM. As always, these contracts cannot be altered once written, and the logic will define the nature of transactions that the accounts can complete. Because contract accounts can be programmed to use their own logic to verify transactions, there is the potential to decouple signers from accounts. We can say that contract accounts “exist within the EVM”. Similar to EOAs, contract accounts also have unique public Ethereum addresses which look the same as EOA public addresses, however, contract accounts essentially replace private keys with code, solving potential human error-related issues. Instead, as they have associated code and data storage, creating a contract account comes with certain costs. In addition, as of now, contract accounts can only send transactions in response to receiving transactions.
“Abstraction” is the act of pulling or drawing something away.
In the case of account abstraction, we can think of it as drawing the object holding our tokens (account) away from the object authorized to move these tokens (user): “Account has been abstracted”.
Currently, a fundamental aspect of the Ethereum protocol is that only EOAs can pay gas fees and start transaction executions. Ideally, account abstraction will allow contract accounts to be constructed in a manner that enables contract accounts to programmatically check the validity of transactions and decide to pay gas on their behalf, thereby effectively starting the execution without the requirement of an EOA. Smart contract logic will be able to specify the effects, fee payment, and validation logic of transactions. This will open new possibilities for how accounts can be tailored to accommodate different needs and purposes.
EIP-4337 is an account abstraction proposal that simplifies the creation and operation of smart contract wallets. The proposal directs signature verification, gas payment, and replay protection out of the core protocol and into the EVM, completely avoiding the need for consensus-layer protocol changes (an adjustment made from EIP 2938), instead, it replicates the functionality of the transaction mempool in a higher-level system called a UserOperation.
Under EIP-4337, UserOperations replace transactions. Users send UserOperation objects that package up the user’s intent with signatures and other data to be used for verification. Miners, also known as bundlers, will then be able to package these objects into a “bundle transaction” which then gets sent to an Ethereum block. The bundler pays the bundle transaction fee in ETH and is compensated through fees paid as part of all the individual UserOperation executions.
Smart contract wallets will require two functions: validateUserOp, which verifies the signature and nonce on the UserOperation, and OpExecution, which interprets call data as an instruction for the wallet to take instructions. The Entry point is a global contract utilized to simplify the contract wallet’s logic, essentially working as a gate to ensure only certain execution functions can cause the wallet to perform actions or pay fees.
Another alternative for those relying on EOA private keys is the Multi-party computation (MPC) wallet. This should not be confused with smart contract wallets and can be seen as almost a hybrid solution that overlaps parts of EOA and smart contract wallets.
MPC wallets differ from EOAs in the way that private keys are owned. MPC wallets distribute ownership of a private key between a chosen number of parties. Each party owns part of the key, as opposed to owning individual keys, and all parties must combine their part of the key in order to sign transactions. With MPC, key generation and signing do not require each user to reveal their inputs, creating a situation where one compromised key does not affect the overall security of the wallet.
In comparison to smart contract accounts, the most direct parallel is between MPC and smart contract multi-signature (multisig) wallets. MPC creates a singular, fragmented signature, whereas a smart contract creates a number of distinct signatures matched with distinct private keys for transaction sign-offs.
Account abstraction could allow for smart contract wallets to accept gas-less meta-transactions, and entirely avoid relay networks. Relayer-based networks are centralized intermediaries that currently profit off the facilitation of meta-transactions, adding additional base gas charges to transactions. In practice, this can reduce onboarding issues in regard to new users requiring some starting ETH for their accounts. In addition, smart contract wallets could also support a paymaster mechanism, that can be used to allow developers to pay certain fees on behalf of users. The paymaster can also act as an intermediary for facilitating transaction fees in other ERC20s outside of ETH by providing conversion services between ETH and other ERC 20s.
Account Abstraction allows users to change a wallet’s keys. Furthermore, it enables multi-signature functions by allowing the use of multiple keys for the same wallet. Going forward, there is the potential to eliminate the need for private keys, passwords, confirmation times, and transaction fees in native assets.
Current wallet recovery solutions include the ability for users to introduce guardians that are delegated to a user's account. In a situation where the user is unable to access that account, Guardians can be called upon to socially recover said accounts.
Account Abstraction could allow for emergency account hold features can be implemented to allow an account to be locked, access from a specific address deactivated, or funds transferred from that account to another account if malicious activity is detected. In addition, daily transaction limits can be set as a preliminary security function to control large, sudden outflows. Other security features include allowing users to specify that transfers are made only to known addresses, and dead man switch can be activated after extended periods of inactivity.
Account abstraction can allow users to deposit tokens directly in contracts. For example, users could potentially deposit tokens into Uniswap in advance. Next, Uniswap can store all user balances and associated public keys required for verifying transactions. Then, transfer transactions can occur according to a pre-determined logic.
Gaming is a segment that could potentially require numerous micro transactions at regular intervals. This could potentially create unwanted stoppage or user experience issues while in-game. Smart contract wallets can solve this issue through batch transactions that bundle and execute multiple transactions at the same time.
Account abstraction can eliminate the need for relayers or the on-chain link to deposit addresses traditionally used to pay gas needed by the withdrawal address. This solves privacy issues, as on-chain links between deposit addresses providing the initial ETH often ruin the initial purpose of mixing the accounts in the first place.
Argent has created the Argent Vault and Argent X. Argent Vault is a non-custodial smart contract mobile wallet with social recovery features. Argent Vault is a consumer-facing wallet that covers both Ethereum and ZkSync, with built-in DeFi features to make it easier for users to interact with DeFi dapps. Argent X is a browser wallet for StarkNet. Overall, Argent is highly focused on the Layer 2 and mobile experience in which users have a one-stop shop for all their DeFi needs.
Biconomy SDK brings blockchain-agnostic, web2-like experiences to web3 dapps, fully non-custodial. Biconomy allows developers to provide social login, simple fiat on ramping, sponsored transactions, customized ERC20 gas fees, and multichain transaction bundling. Biconomy is a well-rounded SDK focusing on almost every aspect of account abstraction.
Peaze SDK provides tools to build out functionalities such as sign-in through email or social, on-ramp via credit card or bank account, all on-chain. The Peaze SDK can be integrated into just a few lines of code and aims to remove key management, network switching, token swapping, and bridging. The Peaze SDK specializes in simplifying the web3 onboarding process.
Sequence provides both a wallet and a wallet creation solution that enables social login, multichain support, fiat on ramping, custom ERC20 fee support, as well as sponsored and bundled transactions. The Sequence wallet also has NFT support, bridges, and swaps. Sequence also provides SDKs for gaming and Unity.
Soul Wallet is a wallet that allows users to create, use and perform social recovery for smart contract wallets through plug-in extensions and mobile applications. Soul wallet supports social login, receiving funds without contract deployment, social recovery, and custom ERC20 payments. Soul Wallet is focused on providing solutions for account abstraction and social recovery.
Stackup SDK provides open-source APIs to enable the instant creation of smart contract wallets and meta transactions. Stackup allows developers to implement custom flows for social recovery, gasless transactions, and bundled transactions. It enables a modular design, giving full control over how developers implement PayMasters, Bundlers, and EntryPoints. Stackup specializes in onboarding as well as creating one-click experiences through bundle transactions.
Openfort SDK provides social login, multichain transactions, sponsored gas, bundled transactions, and social recovery. The Openfort SDK will also provide tools for deploying paymaster contracts which will enable full or partial gas sponsorship. Openfort is specifically focused on the blockchain gaming sector, looking to improve user experience throughout the entire workflow of onboarding and playing games.
Particle Wallet SDK provides fiat on ramping as well as a social login that can be integrated into any use case ranging from DeFi yield farming to NFT marketplaces. The Particle Wallet also comes with SDKs that support the display and trading of Tokens and NFTs in the Solana and EVM ecosystems across Android, iOS, Web, Unity, Flutter, and React Native.
The UniPass Wallet SDK provides social login and recovery, fiat on and off ramps, custom ERC20 payments, multi-calls, and sponsored transactions. Unipass is special in that it also has a consumer-facing UniPass wallet that is accessible through web, mobile, and browser plug-ins. The consumer-facing wallet comes with social login and guardian recovery features, two-factor authentication, and is fully EVM compatible and does not require manual network switching.
0xpass SDK provides a customizable social login and authentication, sponsored gas experience, pre-approval for common transactions, and transaction bundling. Currently, 0xpass is focusing on a login SDK built on top of ConnectKit’s and RainbowKit’s open-source wallet adapters, providing a ready-to-use wallet connector. The login SDK provides social identity data collection as well as token gating and allowlist capabilities.
Smart contract wallets are not the perfect solution and come with a few drawbacks that every potential user should be aware of. First of all, account abstraction and smart contract wallets as a topic are mostly confined to EVM chains for now. For the average user, smart contract accounts might pose new obstacles such as initial storage costs and higher fees for more advanced functions. For developers, there are a new set of functionalities and tools to become familiar with. For users, there are new interfaces, workflows, and habits to develop.
At the end of the day, contract accounts are just smart contracts, and smart contracts are vulnerable to bugs. In addition, smart contracts, once finalized, are immutable. This means contract accounts can be rigid in terms of adapting to future necessities. Fortunately, contract security concerns can be offset with regular auditing, and SDKs are being developed to simplify and standardize the experience of building smart contract accounts. There is a long road ahead for account abstraction, and solutions will develop slowly over time through different implementations and proposals. Far from perfect, account abstraction is a direction with the potential to assist in the next wave of crypto users, as well as improve existing experiences within different verticals that already exist in the space.
Account abstraction projects face a couple of obstacles ahead. First, most products offer similar login, recovery, sponsorship, and bundling functionalities. There is very little differentiation in terms of what is and what can be offered. This is due to the fact that every project is building along the lines of the same Ethereum improvement proposals. This poses challenges in business development in that road maps all follow similar paths. This creates a situation where the best approach may not necessarily win. Like the consumer software wallet segment, it becomes a situation where the best-connected team finds its way to the top.
Second, all these projects, for the most part, target the same pool of users. Unfortunately, the current pool of users from both the 2B and 2C side are limited. Account Abstraction projects currently either specifically focus on 2B or add a 2C segment as a proof of concept. On the 2B side, there is a huge focus on login/authorization as well as blockchain gaming. Login/authorization can be considered its own highly competitive segment, and blockchain gaming is at best a nascent segment. This creates a dependency on the growth and development of other sectors. On the 2C side, not only is it difficult to impose what a 2C product should look like but it is also forced to compete with MPC wallets as well as other custodial software wallets. Currently, it is difficult to differentiate consumer-facing account abstraction projects from traditional wallets as the overall interface and experience is still quite standard.
Third, the issue is that account abstraction-related benefits will not actually directly onboard users, rather the enhanced experience on individual dapps combined with these new functions will provide a more flexible and user-friendly experience. These benefits are a value-add, as opposed to being a standalone product. In fact, even if the functions are available via the dapp, the dapp still has to provide enough value to draw in users, many of which might not even understand the nuance of smart contract wallet functionalities.
The past two years of crypto have brought marvelous highs and miserable lows. The importance and awareness of self-custody are becoming more widespread, but practical options are still in development. That being said, we believe smart contract wallets and account abstraction are tools that will pave the way for a safer and more intuitive way to interact with decentralized applications in the future.
Stay tuned for part two where we will take a deeper look into the landscape and status quo of account abstraction projects.
<https://medium.com/1kxnetwork/wallets-91c7c3457578#:\~:text=Multi-signature wallets are smart,private keys to sign transactions.>