How to get started with Account Abstraction on Ethereum

How to get started with Account Abstraction on Ethereum

Crypto's journey began with Bitcoin's rise to popularity in 2013, introducing the novel concept of "wallet" interactions. This shifted user authentication from traditional username/password systems to cryptographic keypairs.

Ethereum expanded this model with smart contracts—blockchain-deployed programs that users interact with through their accounts.

However, the complexity of these applications created barriers for mainstream adoption. Managing private keys, seed phrases, and transaction signing often intimidates new users and creates a less intuitive experience compared to traditional applications.

As cryptocurrency adoption grows, improving user experience remains critical. On Ethereum, Account Abstraction (AA) offers a promising solution by combining user accounts with smart contracts to create "Smart Accounts."

Though the concept of Account Abstraction isn't new (with Safe being a notable early implementation), ERC-4337 has emerged as the most widely adopted implementation standard on Ethereum, providing developers with a consistent approach to building Account Abstraction solutions.

AA offers significant advantages over traditional wallets. In this article, we'll explore these benefits, examine how Account Abstraction works in detail, and discuss how dedicated wallet infrastructure can enhance AA implementations.

Understanding different account types on Ethereum

To grasp how Account Abstraction works, we first need to distinguish between the two account types on Ethereum: Externally Owned Accounts (EOAs) and Smart Contract Accounts.

Externally Owned Accounts (EOAs)

Externally Owned Accounts are user-controlled accounts that most people use for everyday Ethereum activities like swapping tokens, trading NFTs, and receiving funds through their account address (e.g., 0xabc...).

These accounts are typically generated by wallets, which provide users with a seed phrase representing the private key that controls the account. This private key is essential for signing and approving all transactions from the EOA.

Importantly, EOAs can only initiate transactions and cannot execute code themselves. This limitation means they operate with a fixed set of functions, unable to adapt to evolving blockchain capabilities without network-level upgrades.

Smart Contract Accounts

Smart Contract Accounts are blockchain-deployed programs that, despite sharing the same address format as EOAs (e.g., 0xabc...), offer significantly different capabilities.

These accounts contain code and various data types that enable them to perform programmatic actions based on incoming or outgoing transactions.

For example, consider a simple NFT contract:

• When a user sends ETH to the contract, it automatically generates a new NFT and transfers it to the sender
• The user can return the NFT to the contract to "burn" it, with the contract reducing supply and transferring the NFT to an inaccessible address

Unlike EOAs, Smart Contract Accounts don't have associated private keys. Instead, they're deployed by EOAs (or other programs) that serve as the contract's "owner." Smart contracts can also feature distributed ownership or be completely ownerless.

Smart contracts can hold assets, interact with other contracts, and execute complex logic based on predefined conditions. This programmability enables features like multi-signature requirements, time-locked transactions, and conditional execution that are impossible with standard EOAs.

‍The Trade-offs

Smart Contract Accounts provide significantly more flexibility than EOAs but come with increased complexity and higher transaction costs. 

EOAs are simpler but require careful private key management and offer less flexibility, which can negatively impact user experience. A lost private key means permanent loss of all assets associated with that account—a risk that has resulted in billions of dollars in inaccessible cryptocurrency over the years.

Account Abstraction, particularly through the ERC-4337 standard, aims to bridge these two account types, combining smart contract benefits while addressing the security and user experience challenges associated with traditional EOAs. 

By merging the security of EOAs with the programmability of smart contracts, Account Abstraction creates a foundation for more user-friendly and sophisticated blockchain applications.

What is Account Abstraction? 

Account Abstraction refers to the use of smart contracts that perform actions on behalf of users. These smart contracts hold assets and can execute transactions like swaps and trades, while typically remaining under the control of a user's Externally Owned Account (EOA).

This approach creates a separation between authentication (verifying who can authorize actions) and execution (performing the actual blockchain transactions), which is the fundamental principle behind Account Abstraction.

Early Examples of Account Abstraction

One of the pioneering implementations of Account Abstraction came in the form of multi-signature wallets, which are smart contracts requiring approval from multiple EOAs before executing transactions.

These solutions represented a significant advancement in both security and user experience. Rather than relying on a single point of failure (one private key controlling all funds), multi-signature wallets distribute control across multiple signers, requiring a predefined threshold of approvals before funds could move.

Safe (formerly Gnosis Safe) emerged as an early champion of this approach. Their implementation allowed transactions to be proposed through a smart contract and required multiple signatures before submission to the network.

In this architecture, the user's account functions primarily as a signer. It signs proposed transactions that are then forwarded to a smart contract for validation and execution. This innovative separation between signing authority and transaction execution laid the groundwork for modern Account Abstraction implementations.

By removing the single-user dependency and enabling more complex authorization logic, these early examples demonstrated how smart contracts could fundamentally improve blockchain interaction while enhancing security through distributed control mechanisms.

Account Abstraction today and ERC-4337

Today, "account abstraction" typically refers to ERC-4337, a standardized set of smart contracts on Ethereum that provides a framework for developers to create Smart Wallets for their users.

This approach adheres closely to the fundamental principle of separating roles: the EOA serves as a signer, while the smart contract manages execution.

Before exploring the technical details of ERC-4337 and examining specific implementations, let's consider the key benefits of Account Abstraction and why developers might integrate it into their applications.

Why Use Account Abstraction?

Traditional end-user accounts present significant challenges in both user experience and security.

Applications frequently demand multiple signatures and approvals, resulting in repetitive pop-ups that frustrate users. Additionally, individuals must manage their private keys and assets with only a seed phrase for recovery. EOAs also lack flexibility compared to the programmable nature of smart contracts.

Account Abstraction, particularly through ERC-4337, addresses many of these user experience limitations. This standard provides a framework for smart wallet implementation, enabling advanced transaction capabilities including batching, sponsored transactions, custom verification patterns, and multisignature functionality. Let's examine these benefits in greater detail.

Simpler Transaction Flow

Account Abstraction allows multiple user actions to be bundled into a single transaction. This significantly reduces pop-up fatigue by consolidating flows that would normally require multiple approvals. Transactions can also be sponsored by other accounts, simplifying users' first blockchain interactions. These batched transactions often prove more gas efficient than standard approaches.

Authentication Features

ERC-4337 includes signature support that enables developers to implement familiar authentication methods like passkeys, biometrics, and social recovery. This creates a more intuitive experience for newcomers by replacing the immediate introduction of private keys and seed phrases with authentication systems they already understand.

Custom Verification Patterns

Smart Accounts can incorporate features such as automated recurring payments or specialized functionality. Users can benefit from guardrails like limiting interactions to reputable DEXs or setting spending caps to help beginners safely navigate crypto applications. This category also includes the previously discussed multi-signature capabilities.

ERC-4337 and Account Abstraction effectively bridge EOAs and smart contracts, creating Smart Accounts that deliver the security and flexibility of on-chain contracts without the limitations associated with traditional EOAs.

A closer look at ERC-4337

An important part to note about ERC-4337 is that it doesn't change the core protocol whatsoever; the account abstraction mechanisms are built on top of smart contracts on Ethereum.

For developers, there are a few key pieces of architecture to understand:

• `UserOperations` - Transaction-like objects created by users (in an app) to be sent to a smart account for execution.
• `Bundlers` - Collect `UserOperations` and group them to post to the `EntryPoint` contract on Ethereum. A kind of node. 
• `EntryPoint Contract` - Validates and executes `UserOperations`.
• `AccountContract` - The smart contract which represents a user's account onchain.
• `Paymaster Contracts` (optional) - Special contracts that can be used to pay gas fees on behalf of a user.

UserOperations

The ERC-4337 docs refer to userOperations as a “pseudo-transaction object”. It’s best to think of this as the kind of shape a transaction will take, but isn’t actually a transaction itself. It just contains the instructions and other data provided by an EOA for a smart wallet to execute.

Some of the key fields in the userOperations struct include:

```solidity
struct UserOperation {
    address sender; // address of user’s smart contract account
    uint256 nonce; // for verification
    bytes callData; // function(s) to be executed
    uint256 maxFeePerGas; // similar to normal gas
    uint256 maxPriorityFeePerGas; // similar to normal gas
    bytes paymasterAndData; // optional for gas sponsorship
    bytes signature; // for verification
}
```

The standard flow of interaction might be a userOperations object created in the frontend of a crypto app, this is encoded to the Ethereum ABI, and sent to a bundler to be validated. These are actually sent to a separate mempool to normal EOA transactions, which bundlers take these from, validate, and send onto the EntryPoint contract to verify and execute.

Bundlers

Bundlers are typically provided by third-party solutions or run by validators. Developers can use solutions such as Infura or Alchemy to submit userOperations to bundlers, although some solutions provide full support for the entire flow (which we’ll get into shortly).  

EntryPoint Contract

Bundlers send validated userOperations to the EntryPoint contract. These are single contracts on each chain, which actually execute the code related to the user’s Account Contract (the smart contract associated with their EOA). 

Account Contract 

This is the smart contract associated with a user, and is generated with the `CREATE2` opcode. CREATE2 is an EVM opcode for creating smart contracts which can have pre-computed addresses for other EVM chains. This is important in order to create a consistent contract address for users across different chains.

Here’s the example provided in the ERC-4337 docs using ethers.js.

```js
const accountAddress = ethers.utils.getCreate2Address(
    fromAddress,
    salt,
    initCodeHash
);
```

Paymaster Contracts

These are contracts you can deploy and fund as a developer in order to sponsor your user’s onchain actions. This is great for onboarding, as many non-crypto native users aren’t familiar with the idea of paying gas fees to perform some action on an application. 

Most account abstraction solutions will offer ways for developers to sponsor transactions, including Turnkey, a wallet infrastructure solution for building better crypto experiences.

In your userOperations object, if you don’t want to sponsor a transaction you can enter “0x” as the value in the paymasterAndData field to pass in an empty byte array. To sponsor a transaction, you would instead pass in the address of the Paymaster contract concatenated with its signature, and any other relevant data.

Here’s what it might look like in your crypto app in practice.

```js
// 1. Create initial UserOperation
const userOp = createInitialUserOp();

// 2. Request paymaster sponsorship
const response = await fetch("https://paymaster-api.example.com/sponsor", {
  method: "POST",
  body: JSON.stringify({
    userOp: userOp,
    entryPoint: entryPointAddress,
    chainId: chainId
  })
});

const { paymasterAndData } = await response.json();

// 3. Update UserOperation with paymaster data
userOp.paymasterAndData = paymasterAndData;

// 4. Sign the UserOperation with your signer
userOp.signature = await wallet.signUserOp(userOp);

// 5. Send to bundler
await bundler.sendUserOperation(userOp, entryPointAddress);

```

This will likely depend on the exact implementation you are using. 

For more details on how ERC-4337 works, you can check out the documentation on the architecture here.

These are some of the core building blocks for helping developers create ERC-4337 abstracted wallets, or what are more commonly referred to as Smart Accounts/Smart Wallets. However for most developers, it is more than likely they will build on existing Account Abstraction solutions. 

Getting Started with Account Abstraction 

Developers can build their own wallet abstractions on top of ERC-4337, and crypto app developers can integrate them into their own applications in order to improve UX.

Most developers will likely build on top of existing tools which have been developed to help simplify the AA experience for other developers. These include Biconomy’s AbstractJS SDK, and Alchemy's AccountKit, which offer their own bundlers and can deploy Smart Accounts on behalf of users. These solutions also offer support for some of the newer Ethereum proposals such as EIP-7702, which is a further expanded version of Account Abstraction. 

Here’s a couple of code snippets from Biconomy’s documentation, so you can see how it works:

```js
import { privateKeyToAccount } from "viem/accounts";
import { createSmartAccountClient, toNexusAccount } from "@biconomy/abstractjs"; 
import { baseSepolia } from "viem/chains"; 
import { http, parseEther } from "viem"; 
 
const privateKey = "PRIVATE_KEY";
const account = privateKeyToAccount(`0x${privateKey}`)
const bundlerUrl = "https://bundler.biconomy.io/api/v3/84532/nJPK7B3ru.dd7f7861-190d-41bd-af80-6877f74b8f44"; 
 
const nexusClient = createSmartAccountClient({ 
  account: await toNexusAccount({ 
    signer: account, 
    chain: baseSepolia, 
    transport: http(), 
  }),
  transport: http(bundlerUrl), 
});
const smartAccountAddress = await nexusClient.account.address; 
```

Something you might have noticed is that while ERC-4337 allows users to build abstracted onchain accounts, there is still a need for a signer at the base-level. This means at some point in the process a private key must be generated and managed, which is usually done on behalf of the user through dedicated wallet infrastructure solutions. 

Most solutions are flexible, and allow developers to choose which signing service they want to use. Biconomy, for example, has many integrated signers to choose from. Alchemy offers their built-in Alchemy Signer, which uses Turnkey under the hood to generate non-custodial wallets for users.

For developers building with Account Abstraction, this is where Turnkey can come in.

How Turnkey can improve the Account Abstraction experience

Turnkey offers enterprise-grade key management infrastructure that can serve as the secure signer for ERC-4337 smart accounts. By pairing Turnkey with Account Abstraction, you get the flexibility and improved UX of smart accounts while maintaining institutional-grade security for the underlying signing keys.

The steps are as simple as:

1. Signing up to Turnkey
2. Generating an API keypair
3. Importing the Turnkey client/utilities into your project
4. Signing transactions

Here’s Biconomy’s example using Turnkey and viem.

Turnkey integration extends Account Abstraction benefits by supporting passkey/biometric authentication and social recovery to create secure login flows for user private keys.

This gives developers flexibility to offer users non-custodial, user-friendly login options for their end users while maintaining fully onchain transaction flows via Account Abstraction, by utilizing Turnkey as a signer.

With Turnkey, developers can sign userOperations that forward to bundlers and Smart Accounts while preserving advantages like sponsored transactions. Organizations benefit from Turnkey's granular control over signer configuration and the ability to pre-generate wallets that can later serve as signers for smart accounts.

To get started, check out our docs here.