Desktop section background image
Home
aa sdk iconLearn Account Abstraction

Understanding Account Abstraction

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

4337 diagram

Built by thought leaders in Account Abstraction

embedded account featured image
Announcements

Embedded Accounts Open Beta

Make wallets invisible. Introducing simple, non-custodial accounts to onboard users and transact with web2 UX.

modular-account-blog
Announcements

Hello, Modular Account

Modular Account provides enterprise-grade security, best in class cost, and robust account extensibility to developers building on Ethereum L2s.

aa-sdk-3
Announcements

Introducing AA SDK v3.0

Meet the most feature-complete developer kit for builders creating apps and wallets compatible with ERC-4337 on Ethereum and Layer 2 blockchains.

aa hub callout banner bg

Read the Q4 2023 Account Abstraction Industry Report

Read now
background image

What you can build with
Account Abstraction

Get your API key
    Onboarding
    Onboarding

    Self-custody without a seed phrase. No need to hold native crypto tokens. Frictionless login.

    Account automation
    Account automation

    Alternative signature schemes. Scheduled transfers. Reblancing portfolios. Dollar-cost-averaging.

    fast-transactions-icon
    Advanced transactions

    Scheduled, sponsor, and batch transactions. ERC-20 and stablecoin gas payments.

    Security
    Security

    Authentication and authorization schemes. Improved security access, such as 2FA. Multi-signature requirements. Account recovery mechanisms. Guarding approvals.

Desktop section background image

Start building

Your vertically integrated development stack for account abstraction.

embedded accounts
Embedded Wallets
Card background image

Plug-n-play embedded wallets

Make wallets invisible. Simple, non-custodial accounts to onboard users and transact with web2 UX.

Account Contracts
Account Contracts
Card background image

Smart contract accounts for every use case

Optimized ERC-4337, ERC-6900, and EIP-7702 smart contract accounts.

Code preview

Copied
import { useAccount } from "@alchemy/aa-alchemy/react";
gas manager
Gas Manager
Card background image

Sponsor gas, boost transactions

Get users to your magic moment faster by removing the biggest barrier with gas sponsorship.

Code preview

Copied
import { smartAccountClient } from "./smartAccountClient.ts"; // Send a sponsored UO from your smart account like this: const { hash } = await smartAccountClient.sendUserOperation({ target: "0xTargetAddress", data: "0xCallData", value: 0n, // value in bigint or leave undefined });

View docs

Explore API references, tutorials, and guides.

embedded accounts logo
Embedded Accounts Quickstart

A plug and play solution for simple, non-custodial accounts. Onboard users with either a smart account or an EOA!

Gas Manager Quickstart
Gas Manager Quickstart

Apply ERC-4337 compliant gas payment policies on your dapps' contracts. Remove barriers to access, drive growth and make dapp onboarding actually easy.

bundler icon
Bundler Quickstart

ERC-4337 compliant Bundler Services will enable dapps and wallets to submit batches of transactions to Smart Contract Accounts in a single request.

Your go-to guides to accelerate your learning

Read technical deep dives from Alchemy engineers and research analysts.

Featured content card overlay
14 min read
You Could Have Invented Account Abstraction: Part 1
Featured content card overlay
Account Abstraction
What is Account Abstraction (ERC-4337)?
Featured content card overlay
Account Abstraction
What are Paymasters? (ERC-4337)
Featured content card overlay
Account Abstraction
What is a bundler? (ERC-4337)
Featured content card overlay
Account Abstraction
What is Modular Account Abstraction?
Featured content card overlay
Account Abstraction
Account Abstraction (ERC-4337) vs. Meta Transactions (ERC-2771)

Frequently Asked Questions

Definitions and explanations of key concepts.

  • 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:

    1. Externally Owned Account (EOA)

    2. 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.

  • 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.

  • 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.

  • 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.

    ERC-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.

  • 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.

  • 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!

  • 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.

  • 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.

  • 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:

    1. Sponsor gas fees for their users 

    2. Enable gas payments in stablecoins 

    3. Enable gas payments in other ERC-20 tokens

    Want to test it out? Try our Gas Manager API!

  • An ERC-4337 compliant proposal for standardizing Smart Contract Accounts (SCAs) and account plugins:

    1. SCAs: fully programmable accounts that can store assets in on-chain smart contracts

    2. 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.

Desktop section background image

Build blockchain magic

Alchemy combines the most powerful web3 developer products and tools with resources, community and legendary support.

Get your API key