Understanding Account Abstraction
Your go-to Account Abstraction resource. Whether you're an Account Abstraction newbie or already a total expert, we have what you need to keep growing.
How ERC-4337 supports Account Abstraction
%20(1).png)
NonceManager, ReentrancyGuard {
using UserOperationLib for UserOperation;
SenderCreator private immutable senderCreator
Account Abstraction Fundamentals
A person (or entity’s) representation on the blockchain that can send and receive cryptocurrency, as well as interact with other on-chain accounts.
Every Ethereum account is either a:
- Externally Owned Account (EOA)
- Smart Contract Account (SCA)
Ethereum transactions must originate from EOAs, which today are set up and accessed through wallets e.g., MetaMask, Phantom, Rainbow, etc.
%20(1).png)
EOAs are used for storing and transferring ETH, ERC-20 tokens and digital assets. EOAs are derived from a public key and controlled by a private key:
- Public key: The EOA’s 20-byte hexadecimal identifier, e.g., 0xF37E1D6b84db4053cE452B35A7DA79494dCbdb33, that the Ethereum network address is derived from, and is used by others to identify the account for a transaction
- Private key: The EOA’s password or seed phrase, used to sign transactions, and known only by the owner of the account
EOA transaction validity is not based on code or smart contract logic. As long as a private key is known, the owner of the account can perform any transaction, pending validation of the user’s signature and nonce.
.svg)
.svg)
An SCA is the target of the UserOperation. SCAs are fully programmable accounts that can store assets in on-chain smart contracts. Rather than being controlled by a private key, SCAs are controlled by arbitrary, customizable verification logic.
This equips SCAs with:
- Security benefits: Not controlled by a single private key means that access is not dependent on a single person remembering that private key.
- Functionality expansion: Can set rules for things like transfer limits and social recovery.
Account Abstraction proposes people use SCAs instead of EOAs as their primary accounts. Each user who wants the security and functionality benefits of SCAs will need their own SCA.
%20(1).svg)
.png)
Fully programmable accounts with built-in security and functionality benefits compared to Externally Owned Accounts (EOAs).
NonceManager, ReentrancyGuard {
using UserOperationLib for UserOperation;
SenderCreator private immutable senderCreator
%20(1).png)
An Ethereum proposal for using Smart Contract Accounts (SCAs) as people’s primary accounts, and effectively supporting users in the hard parts of managing web3 accounts.
4337 runs on top of the blockchain and does not require any changes to the blockchain itself.
This makes it usable today, on Ethereum or any EVM chain, without any significant changes to the underlying blockchain infrastructure.
Read the full proposal here.
.png)
The ERC-4337 flow kicks off with a UserOperation, which is a transaction-like object, representing a user’s transaction intent. A UserOperation can contain multiple requests and additional data to execute transactions that a Smart Contract Account (SCA) can carry out.
Although in many ways, UserOperations resemble traditional transactions, there are key differences:
- Additional fields: UserOperations include new fields in the transaction structure, e.g., EntryPoint, Bundler, Paymaster and Aggregator
- Alternate mempool: UserOperations are sent to a separate mempool, where bundlers can package them into transactions which get included in a block
- Intent based: Today, transaction inputs are specific, e.g., swap 2k USDC for 1.2ETH. In contrast, UserOperations can be decorated with additional metadata to be more outcome focused, e.g., I want to trade 2k USDC for the most amount of ETH possible
.png)
A user creates their UserOperation, representing their transaction intent, and submits it to the mempool. This kicks off the ERC-4337 process.
.png)
NonceManager, ReentrancyGuard {
using UserOperationLib for UserOperation;
SenderCreator private immutable senderCreator
Bundlers are a type of Ethereum node that supports UserOperations, instead, (or in addition to) typical Ethereum transactions.
UserOperations are sent to a network of Bundlers, who monitor the mempool and bundle multiple UserOperations into one transaction, packaging and submitting them to the blockchain on behalf of users. In return, Bundlers are compensated for doing this on behalf of users.
Because we want to abstract away the necessity for everyone in web3 to have their own EOA, yet all Ethereum transactions need to be initiated by an EOA, Bundlers are a critical piece of infrastructure to actualize ERC-4337.
Want to test it out? Try our Bundler API!
Bundlers monitor the UserOperation mempool, and “bundle” multiple UserOperations, before submitting them to an EntryPoint.
NonceManager, ReentrancyGuard {
using UserOperationLib for UserOperation;
SenderCreator private immutable senderCreator
.png)
A singleton smart contract that receives transactions from Bundlers, then verifies and executes UserOperations.
- Verification: Check to see if the wallet has enough funds to pay the maximum amount of gas it might possibly use (based on the gas field in the UserOp). If not, the transaction is rejected.
- Execution: Execute the transaction, and take money from the Smart Contract Account (SCA) to reimburse the Bundler (with the right amount of native token to pay for the gas.
The EntryPoint is a smart contract that receives transactions from Bundlers, and is responsible for verifying and executing UserOperations while ensuring Bundlers are compensated for their work.
NonceManager, ReentrancyGuard {
using UserOperationLib for UserOperation;
SenderCreator private immutable senderCreator
%20(1).png)
If multiple messages are signed with different keys, then an Aggregator can generate a single, combined, verified signature, which implies that all the constituent signatures are also valid.
By combining multiple signatures into a single signature, aggregators help save on data availability, with multiple bundled UserOperations validated in a single step.
For specific accounts that work with specific signature types that support aggregation (e.g., BLS), the account's signature check logic is deferred to this external contract, which in turn has to check a single signature over an entire bundle.
Vitalik’s thoughts on the importance of signature aggregation here.
Aggregators combine multiple signatures into a single signature, so that multiple UserOperations can be validated in a single step.
NonceManager, ReentrancyGuard {
using UserOperationLib for UserOperation;
SenderCreator private immutable senderCreator
.png)
The ERC-4337 defined smart contract that handles the implementation of gas payment policies and enables developers to provide their end users gas-free experiences via sponsored or ERC-20 gas policies.
These policies create flexibility for (1) how gas is paid (e.g., in what currency) and (2) by whom, thereby effectively removing the prerequisite for users to hold native blockchain tokens in order to interact with the blockchain.
Paymasters allow application developers to:
- Sponsor gas fees for their users
- Enable gas payments in stablecoins
- Enable gas payments in other ERC-20 tokens
Want to test it out? Try our Gas Manager API!
Paymasters handle the implementation of off-chain gas payment policies, creating flexibility for how gas is paid and by whom.
NonceManager, ReentrancyGuard {
using UserOperationLib for UserOperation;
SenderCreator private immutable senderCreator
%20(1).png)
An ERC-4337 compliant proposal for standardizing Smart Contract Accounts (SCAs) and account plugins:
- SCAs: fully programmable accounts that can store assets in on-chain smart contracts
- Account plugins: smart contract interfaces that allow for composable logic within SCAs
ERC-6900 is a proposed standard to coordinate the implementation work between SCA developers and plugin developers, and defines a modular SCA capable of supporting all standard-conformant plugins.
This will allow users to have greater portability of their data and for plugin developers to not have to choose specific wallet implementations to support.
Read the full proposal here.
.png)
Your go-to guides to accelerate your learning
Protect our assets
How we got to ERC-4337's UserOperation, Bundlers, and Entry Points.
Paymasters
Sponsoring transactions using paymasters.
Wallet creation
How factories specialize in creating different kinds of wallet contracts.
Aggregate signatures
How aggregate signatures enable validation of many ops at the same time, with just one signature.
Ready to start building? We got you covered
Bundler APIs
ERC-4337 compliant Bundler Services will enable dapps and wallets to submit batches of transactions to Smart Contract Accounts in a single request.
Gas Manager APIs
Apply ERC-4337 compliant gas payment policies on your dapps' contracts. Remove barriers to access, drive growth and make dapp onboarding actually easy.
