Account Abstraction
ERC-4337 Compatible Bundler & Paymaster
Last updated
ERC-4337 Compatible Bundler & Paymaster
Last updated
Users interact with Ethereum using externally owned accounts (EOAs) which are public-private key pairs. Anyone with access to the private key can perform actions within the rules of the Ethereum Virtual Machine (EVM). By design, the Ethereum network can only go through state transition when an EOA triggers a transaction and consequently pays a gas fee in ETH. These factors limit how users can interact with the blockchain.
Poor security
Lost private keys cannot be recovered
Compromised private keys give attackers instant access to all funds in the account
Rigid security rules (e.g., must use ECDSA)
Lack of customization
Must initiate or sign every transaction
Not programmable (i.e., can not define custom rules)
Gas payment
Account must hold ETH at all times in order to cover transaction fees
Can not use other tokens (e.g., ERC20
)
Smart contract wallets are the solution to these problems by allowing users to flexibly program better security and user experiences into their accounts. Account abstraction enables smart contracts to initiate transactions themselves, without the user having to manage a separate EOA and ETH balance. This opens up the door to many exciting use cases.
Smart wallets are wallets controlled by smart contracts following the . Ethereum has two types of accounts:
Externally Owned Accounts (EOAs)
Contract Accounts (Smart Contracts)
A Contract Account is managed by a Smart Contract rather than an EOA and relies on code instead of private keys to secure and recover wallet information.
Fully programmable
Can do anything a smart contract can
Upgradeable to add new features
Arbitrary verification logic & recovery
ECDSA (EOA controller account)
Social Login
Session Keys
Biometric
Atomic multi-operations
Combine multiple transactions into a single atomic transaction
Better efficiency as call overhead is only incurred once
E.g., approve & spend tokens
Gasless transactions
Fully sponsored & ERC-20
payment
Compatible with all smart contracts out of the box
Semi-abstracted nonces
Concurrent execution channels
The sender is an ERC-4337 compatible smart contract wallet storing the users assets.
It must implement the following interface:
A UserOperation
is a pseudo-transaction object sent by the user into an alternate mempool.
It contains the following fields:
Unlike , ERC-4337 avoids changes to the consensus layer itself increasing the chance of faster adoption.
The EntryPoint
is a singleton smart contract that handles the verification and execution of bundles of UserOperations
. This ensures much of the complicated logic is not required in the wallet itself and Instead, wallets trust the EntryPoint
to perform proper validation (similar to a ).
A bundler is a node that bundles together multiple UserOperations
from an alternate mempool and forwards them to the EntryPoint
contract as a single transaction. The bundler executes transactions via EOAs which cover the transaction fees upfront and are later compensated. The is built on top of the existing service and sponsors transactions via .
See .
A paymaster is a service that covers transaction fees on behalf of the user. Unlike other solutions, Gelato does not rely on the on-chain EntryPoint
to compensate transaction costs. Instead, fees are settled by the paymaster post-execution which avoids overcharging users and reduces the overall on-chain footprint.
See .
sender
address
Account requesting the operation
nonce
uint256
Anti-replay parameter
initCode
bytes
Account creation code (only required if not yet created i.e., first transaction)
callData
bytes
Data passed to sender
during execution
callGasLimit
uint256
Gas allocated for main execution
verificationGasLimit
uint256
Gas allocated for verification
preVerificationGas
uint256
Amount allocated to compensate the bundler for any gas overhead not tracked on-chain by the EntryPoint
maxFeePerGas
uint256
Similar to EIP-1559
maxPriorityFeePerGas
uint256
Similar to EIP-1559
paymasterAndData
bytes
Paymaster address and callData
(empty for self-sponsored transactions)
signature
bytes
Data passed to the account along with the nonce during the verification step