Account abstraction: ERC-4337, EIP-7702 and smart accounts

HOW IT FITS TOGETHER

KEY TERMS

UserOperation and EntryPoint

A UserOperation is a struct (sender, nonce, initCode or factory, callData, gas limits and fees, paymaster fields, signature) signed by the account's owner. The EntryPoint singleton validates and executes bundles of them and handles gas accounting, deposits and refunds. Current releases are v0.7 (0x0000000071727De22E5E9d8BAf0edAc6f37da032), v0.8 (native 7702 support, EIP-712 op hashing) and v0.9 (paymaster signatures after the user, block-number validity ranges). Accounts are bound to one version; check which one your SDK and bundler target.

Bundlers and the alt mempool

Bundlers are relayers that simulate each op's validation, keep a separate UserOperation mempool, and submit handleOps transactions, earning the difference between what ops pay and what the transaction costs. ERC-7562 restricts what validation code may touch (no environment opcodes like TIMESTAMP, limited storage access) so one op cannot invalidate a whole bundle after simulation.

Paymasters

A paymaster is a contract with an EntryPoint deposit that agrees to pay for ops in validatePaymasterUserOp and can settle afterwards in postOp. Verifying paymasters check an off-chain sponsor signature (your policy service); ERC-20 paymasters charge the user tokens. Unbounded sponsorship is a faucet: rate-limit and allowlist by account, method and contract.

EIP-7702 delegation

A type-4 transaction carries an authorization list of signed (chainId, address, nonce) tuples. Each sets the signer's code to 0xef0100 || address, so calls to the EOA execute the delegate's code with the EOA's storage and balance. It persists until re-delegated (delegating to the zero address clears it). chainId 0 makes the authorization valid on every chain, which is rarely what you want.

ERC-1271 and ERC-6492 signatures

Contracts cannot produce ECDSA signatures, so verifiers call isValidSignature(hash, signature) on the account and expect the magic value 0x1626ba7e. A counterfactual account has no code yet; ERC-6492 wraps the signature with factory calldata and the 0x6492... suffix so a verifier can simulate deployment first. Verify with a library that handles EOA, 1271 and 6492 in that precedence.

Session keys

A secondary key the account accepts only under constraints: specific contracts and selectors, spend limits, expiry. There is no single standard yet; implementations are account modules (often ERC-7579 validators and policies), and ERC-7715 (draft) proposes wallet_requestExecutionPermissions so dapps can request them uniformly. Keep the scope narrow; a session key is a bearer credential.

Passkey signers (P-256)

WebAuthn passkeys sign with secp256r1, not Ethereum's secp256k1. RIP-7212 introduced a P256VERIFY precompile at 0x100 on rollups; EIP-7951 brought it to L1 in Fusaka (Dec 2025) with the same interface, corrected edge cases and a 6900 gas cost. Where it is absent, accounts fall back to a Solidity verifier costing hundreds of thousands of gas.

IN YOUR STACK

import { createPublicClient, encodeFunctionData, erc20Abi, http, parseUnits } from "viem";
import { createBundlerClient, toCoinbaseSmartAccount } from "viem/account-abstraction";
import { privateKeyToAccount } from "viem/accounts";
import { base } from "viem/chains";

const client = createPublicClient({ chain: base, transport: http() });
const bundlerClient = createBundlerClient({ client, transport: http(process.env.BUNDLER_URL) });

const account = await toCoinbaseSmartAccount({
  client,
  owners: [privateKeyToAccount(process.env.OWNER_KEY as `0x${string}`)],
  version: "1.1",
});

// Approve + deposit atomically: both calls run in one UserOperation.
const hash = await bundlerClient.sendUserOperation({
  account,
  calls: [
    { to: USDC, data: encodeFunctionData({ abi: erc20Abi, functionName: "approve", args: [VAULT, parseUnits("50", 6)] }) },
    { to: VAULT, abi: vaultAbi, functionName: "deposit", args: [parseUnits("50", 6)] },
  ],
});
const receipt = await bundlerClient.waitForUserOperationReceipt({ hash });
if (!receipt.success) throw new Error(`UserOperation reverted: ${receipt.reason}`);

import { createWalletClient, encodeFunctionData, http, type Address, type Hex } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { sepolia } from "viem/chains";

const eoa = privateKeyToAccount(process.env.EOA_KEY as Hex);
const walletClient = createWalletClient({ account: eoa, chain: sepolia, transport: http() });

// Audited batch-executor implementation the EOA will delegate to.
const DELEGATE: Address = "0x...";

const authorization = await walletClient.signAuthorization({
  contractAddress: DELEGATE,
  executor: "self", // the EOA sends the tx itself, so the auth uses nonce + 1
});

const hash = await walletClient.sendTransaction({
  authorizationList: [authorization], // type-4 (set code) transaction
  to: eoa.address, // call the EOA, which now runs DELEGATE's code
  data: encodeFunctionData({ abi: delegateAbi, functionName: "execute", args: [calls] }),
});

import { createPublicClient, http, type Address, type Hex } from "viem";
import { base } from "viem/chains";

const client = createPublicClient({ chain: base, transport: http(process.env.RPC_URL) });

// Login: the client signed a server-issued, single-use challenge.
export async function verifyLogin(address: Address, message: string, signature: Hex) {
  // Tries, in order: ERC-6492 wrapper (counterfactual account), ERC-1271
  // isValidSignature on deployed code, then plain ecrecover for EOAs.
  const valid = await client.verifyMessage({ address, message, signature });
  if (!valid) throw new Error("invalid signature");
  return address;
}

// On-chain equivalent (OpenZeppelin):
//   SignatureChecker.isValidSignatureNow(signer, hash, signature)
// handles EOAs and ERC-1271, but not ERC-6492 counterfactual wrappers.

import { createPublicClient, http, type Hex } from "viem";
import { createBundlerClient, createPaymasterClient, toSimple7702SmartAccount } from "viem/account-abstraction";
import { signAuthorization } from "viem/actions";
import { privateKeyToAccount } from "viem/accounts";
import { sepolia } from "viem/chains";

const client = createPublicClient({ chain: sepolia, transport: http() });
const owner = privateKeyToAccount(process.env.EOA_KEY as Hex);
// The EOA's own address, running eth-infinitism's Simple7702Account (EntryPoint v0.8).
const account = await toSimple7702SmartAccount({ client, owner });

const bundlerClient = createBundlerClient({
  client,
  transport: http(process.env.BUNDLER_URL),
  paymaster: createPaymasterClient({ transport: http(process.env.PAYMASTER_URL) }),
  paymasterContext: { sponsorshipPolicyId: process.env.POLICY_ID }, // provider-specific
});
const needsDelegation = !(await account.isDeployed());
const hash = await bundlerClient.sendUserOperation({
  account,
  calls: [{ to: GAME, abi: gameAbi, functionName: "claimDaily" }],
  // First op only: carry the 7702 authorization; the bundler adds it to a type-4 tx.
  authorization: needsDelegation ? await signAuthorization(client, account.authorization) : undefined,
});

import {
  createWebAuthnCredential, toCoinbaseSmartAccount, toWebAuthnAccount, type P256Credential,
} from "viem/account-abstraction";
import { bundlerClient, client } from "./clients";

// Registration: the authenticator creates a P-256 key; only the public key leaves it.
export async function register(username: string) {
  const credential = await createWebAuthnCredential({ name: username });
  await api.saveCredential({ id: credential.id, publicKey: credential.publicKey });
  return credential;
}

// Later sessions: rebuild the owner from the stored id and public key.
export async function sendWithPasskey(credential: Pick<P256Credential, "id" | "publicKey">) {
  const owner = toWebAuthnAccount({ credential });
  const account = await toCoinbaseSmartAccount({ client, owners: [owner], version: "1.1" });
  const hash = await bundlerClient.sendUserOperation({
    account,
    calls: [{ to: RECIPIENT, value: 1_000_000_000_000_000n }],
  }); // triggers the OS passkey prompt to sign the userOpHash
  return bundlerClient.waitForUserOperationReceipt({ hash });
}

WHEN TO REACH FOR WHAT

WHERE IT BITES

• Treating a mined handleOps transaction as success: the bundle succeeds even when your op's execution reverted. Read UserOperationEvent or the op receipt's success flag.
• Verifying signatures with ecrecover only. Smart accounts need ERC-1271, and freshly created ones need ERC-6492 until deployed.
• Mixing EntryPoint versions: an account built for v0.6 or v0.7 cannot be submitted to a bundler endpoint for v0.8, and userOpHashes differ per version and chain.
• Signing 7702 authorizations with chainId 0 or to an unaudited delegate. The delegate controls everything the EOA owns, on every chain the authorization covers.
• Running an open paymaster without per-user quotas; bots will drain the deposit within hours.
• Assuming the P-256 precompile exists on every chain, or that its gas cost matches RIP-7212's on L2s.

WHEN IT BREAKS IN PRODUCTION

• A Web3 payment feels like developer tooling
• Signatures fail because the wallet is on the wrong chain
• Sending fails at gas estimation with "execution reverted"
• Token approvals fail or leave users exposed
• A transaction is pending forever and blocks the rest

SOURCES

• ERC-4337: Account Abstraction Using Alt Mempool (opens in new tab)Checked 2026-11-06
• eth-infinitism/account-abstraction releases (EntryPoint v0.7–v0.9) (opens in new tab)Checked 2026-11-06
• EIP-7702: Set Code for EOAs (opens in new tab)Checked 2026-11-06
• ERC-6492: Signature Validation for Predeploy Contracts (opens in new tab)Checked 2026-11-06
• EIP-7951: Precompile for secp256r1 Curve Support (opens in new tab)Checked 2026-11-06
• viem: Account Abstraction (opens in new tab)Checked 2026-11-06