Skip to main content
Version: SDK V2

Account Abstraction

Account abstraction provides users the ability to use accounts at a higher level with less knowledge of the processes going on underneath. Like using a Gmail account without knowing how it functions.

Type of Accounts​

Currently, there are two types of wallets on Ethereum, one is EOA (externally owned account) and the other is a smart contract wallet. To initiate a transaction on Ethereum a trigger must come from something outside the blockchain, and hence transactions can only be executed via externally owned accounts.

  1. EOAs. Every EOA is associated with a public and a private key. A public key is used to indicate the address of an account and a private key is used to sign transactions. The private key signature is proof that the transaction is valid and has in fact been initiated by its associated public key address. The problem with EOAs is that accounts are tightly coupled with signatures, to own a particular wallet address, you need to have its associated private keys and this functionality is hardcoded in the EVM. This creates a few problems as losing a key means losing your account.

  2. Smart Contract Accounts. There is one solution that saves the day - Smart Contract Accounts. Unlike EOAs, the account and signer are not coupled here. The accounts are defined by the contract code and the transaction-validating functionality has been abstracted away from the accounts. Smart contract accounts can have their own logic to define what a valid transaction is. To use better UX features like multisig, social recovery, and social signing schemes - you need to use smart contract accounts as EOAs can not provide those functionalities. In summary, account abstraction removes the need to remember seed phrases. It decouples the account and its transaction validation functionality. Account abstraction gives users a self-custodial account that can be customized to suit their needs.

With account abstraction, there is an overall UX improvement that will be reflected across the domains of DeFi, GameFi, DAOs, and much more.

ERC-4337: Account Abstraction Via Entry Point Contract​

The following section gives a brief technical breakdown of ERC 4337. The ERC logic replicates the functionality of the current transaction mempool in a higher-level mempool which takes in smart contract wallet calls.

There are four main components to ERC 4337: UserOperation, EntryPoint, Sender Contract, Paymaster, and Bundler.

There is also an Aggregator which is a helper contract trusted by wallets to validate an aggregated signature. It is part of a newer addition to the EIP and has not yet been included in the explanation below.

UserOperations: These are transaction objects created to execute transactions on behalf of the user. The execution happens after confirmation from the Sender Contract. These operations are generated by the Dapp.

EntryPoint: The EntryPoint contract handles the execution and verification of the transaction operations passed to it. The global EntryPoint contract takes in the bundled transactions from respective Bundlers and goes through each user operation to run a verification and execution loop.

Bundlers: A bundler takes in UserOperations from the mempool, and bundles them together to send them to the EntryPoint contract for execution.

Sender Contract: These are user wallet accounts in the form of a smart contract.

Paymaster: These are optional contracts that can pay gas for a transaction on behalf of the user. Instead of relying on their wallet, users can get their transaction fees sponsored by a paymaster.

Verification loop​

The contract goes through each user operation and calls a 'validation function' in the Sender Contract. The Sender Contract runs this function to verify the signature of the UserOperation and to compensate the bundler for bundling these transactions.

Execution loop​

Sends the callData in each UserOperation to the Sender Contract. The wallets run an execution operation to execute the transaction(s) that are specified in the operation. The Sender Contract is then refunded with the gas left after the execution of the operation.

Bundlers​

Bundlers are required to relay bundled UserOperations from various sources to the EntryPoint contract and then to the network. A Bundler performs the following functions:

  • Picks UserOperations from the high-level UserOperation mempool (which is not the same as the regular transaction mempool).
  • Bundles the transactions into one large transaction.
  • Routes them to the EntryPoint contract.
  • Informs inclusion of the said bundle in the next block that is to be broadcasted to the network.

Sender Contract​

There are basically two functionalities that a Sender Contract is expected to perform:

  • It is expected to verify the operation’s signature and pay the fee if the wallet considers the operation valid.
  • Wallet contract is expected to have an execute function that parses the callData as a series of one or more calls that the wallet should make.

Paymaster​

A paymaster contract is an optional feature that allows application developers to cover gas costs for their user’s operation, allow users to pay fees with EIP-20 tokens, and many other use cases. A paymaster must stake ETH with the EntryPoint contract, which is enough to pay for the UserOperation.

A paymaster is required to perform two functions:

  • It is expected to validate a UserOperation by showing its willingness to pay for the operation.
  • It is required to have custom logic for fee payment which gets called during the execution loop.

Was this page helpful?