The State of Ethereum Account Abstraction Developer Tooling

# The State of Ethereum Account Abstraction Developer Tooling **As of September 17, 2025** AA is real and shippable. But you must pick a stack with clear answers to four things: (1) account type (ERC‑4337 smart account, EIP‑7702 “smart EOA,” or both), (2) gas policy (who pays & how), (3) infra you control (bundler/paymaster) vs vendor, and (4) chain coverage. Tooling is solid around Safe, Kernel/ZeroDev, Biconomy Nexus, OpenZeppelin’s AA library, plus infra from Pimlico, Alchemy, Coinbase, and Etherspot. 7702 is live on mainnet with Pectra (May 7, 2025). EntryPoint v0.8 is current. The ecosystem is converging on ERC‑7579 for modularity, and passkeys (P‑256/WebAuthn) are first‑class in multiple stacks. The biggest rough edges are gas estimation, mempool fragmentation, and vendor lock‑in around paymasters. --- ## What actually changed in 2025 - **EIP‑7702 is live on mainnet (Pectra).** You can “attach” contract code to an EOA for a transaction, then fall back to EOA later. You keep the user’s familiar address while using smart‑account features when needed. Tooling (MetaMask Delegation Toolkit, Alchemy docs, Remix) reflects this. Practically: easier migrations and fewer “new address” UX headaches. - **EntryPoint v0.8** shipped with small but meaningful updates (e.g., new examples, cleanups). If you’re still on v0.6/0.7, plan upgrades; multi‑version support is common but creates footguns. - **Modularity via ERC‑7579** is winning. Safe has a 7579 adapter; Biconomy Nexus and ZeroDev Kernel are 7579‑native; a shared module ecosystem (validators, executors, hooks, passkeys, session keys) is forming. Less “wallet‑specific plugin” work; more portable modules. - **Passkeys (P‑256/WebAuthn)** are first‑class in OpenZeppelin’s AA library and multiple wallet stacks (Safe, Biconomy, Kernel). “Sign in with device biometrics” finally feels native. - **Viem exposes AA primitives** (with permissionless.js wrapping common flows and account types), which simplifies TypeScript integrations and reduces lock‑in to a single infra vendor. - **Shared mempool rules (e.g., ERC‑7562)** and shared‑mempool efforts are maturing, but real‑world bundling still tends to be “one userOp per bundle.” Great during low traffic, less great for efficiency. --- ## The mental model (what you actually integrate) 1. **Account:** Safe / Kernel (ZeroDev) / Biconomy Nexus / OpenZeppelin Account / “Simple” accounts. Increasingly 7579‑modular and passkey‑capable. 2. **Bundler:** Pimlico, Alchemy, Etherspot Skandha, or Coinbase’s endpoint on Base. Your app sends `eth_sendUserOperation` here. Choice affects inclusion, reliability, and how much “real bundling” you get. 3. **Paymaster:** Verifying or ERC‑20 paymaster for sponsorship. Key questions: policy controls, simulation quality, and whether it’s tied to a specific bundler (lock‑in). 4. **SDKs & glue:** viem AA primitives + permissionless.js, plus wallet‑specific SDKs (Safe Core, Biconomy SDK, ZeroDev SDK), with 7702 quickstarts in MetaMask and Alchemy docs. Remix has 4337/7702 helpers. --- ## Where the tools are solid vs. shaky ### Solid (ship‑ready) - **Accounts:** Safe (battle‑tested, now 7579‑compatible), Kernel v3 (gas‑efficient, modular), Biconomy Nexus (7579), OpenZeppelin AA contracts (clean, multi‑signature‑scheme support). Good docs and audits. - **Infra:** Pimlico (bundler + paymaster + permissionless.js), Alchemy (bundler + Gas Manager), Etherspot Skandha (open‑source bundler; v0.8/7702 support). Real uptime, clear APIs. - **Dev UX:** Viem AA primitives; MetaMask 7702 quickstart; Remix 4337/7702 panels; good how‑to docs across providers. ### Shaky - **Gas estimation remains touchy.** Dummy signatures, `preVerificationGas`, and policy checks keep tripping teams. Expect vendor differences; simulate twice. - **Bundling efficiency.** Most bundles still include a single userOp; aggregation helps but isn’t common yet. This impacts fees and latency. - **Paymaster lock‑in.** Some paymasters only work with their own bundler (e.g., Coinbase today), which simplifies support but reduces portability. Decide if you accept that trade. - **Counterfactual signatures.** If you rely on `permit`/EIP‑712 before deploy, support **EIP‑6492** or you’ll hit “signature invalid until deploy” bugs. --- ## The stacks ### Safe stack **Why:** Mature, multi‑sig first, huge ecosystem, now 7579‑compatible; passkey modules available. **How:** Safe {Core} + Safe4337 pack or permissionless.js; optional 7579 adapter; pair with Alchemy/Pimlico/Etherspot for bundler/paymaster. ### ZeroDev Kernel stack **Why:** Gas‑efficient, 7579‑native, strong docs; good for consumer apps needing permissions/session keys. **How:** ZeroDev SDK + permissionless.js; pick Pimlico/Alchemy/Etherspot infra. 2D nonces (parallel ops) are first‑class. ### Biconomy Nexus stack **Why:** 7579 modular accounts + handy passkey validator; DX‑oriented SDK. **How:** Biconomy SDK + Nexus client; pair with their bundler/paymaster or go via permissionless.js. ### OpenZeppelin Accounts **Why:** Clean primitives, 7702 + ECDSA/P‑256/RSA signers; great if you want to own more of the code. **How:** Compose OZ account + signer libs; wire to permissionless.js or viem AA; pick your infra. ### Coinbase AA kit (esp. on Base) **Why:** Smooth out‑of‑box path on Base; credits; guardrails. **Caveat:** Paymaster currently coupled to their bundler. Good DX if you’re fine with the vendor vertical. --- ## Performance & economics: constraints you’ll feel - **Gas overhead is real.** A plain ERC‑4337 transfer can be ~4× an EOA transfer. You also pay for longer calldata and verification phases. Design with fewer round‑trips, batch smartly, and sponsor selectively. - **Bundler incentives are thin.** Many bundlers run at low margin; some monetize via paymasters or platform upsell. Don’t assume aggressive fee smoothing unless you control the bundler. Public data shows tight revenue and single‑op bundles dominating. - **2D nonces unlock concurrency.** Use nonces as (key, value) pairs to run independent flows in parallel (e.g., background approvals vs swaps). Your account must expose `getNonce(key)` and your SDK must support keys. --- ## Security & safety rails you shouldn’t skip - **Implement EIP‑6492** for off‑chain signature checks (logins, permits) before deployment. Without it, users “sign fine” but on‑chain checks fail until first tx. This mismatch burns time. - **Understand ERC‑7562 rules.** Bundlers enforce validation‑phase limits to avoid unpaid computation. Your account’s `validateUserOp` must respect those constraints or you’ll get dropped from mempools. - **Paymaster risk model.** If your sponsored op fails validation or execution, **you** pay. Simulate with realistic dummy signature/paymaster data; monitor policy drift. --- ## What’s mature vs experimental **Mature today** - Accounts: Safe, Kernel v3, Biconomy Nexus, OpenZeppelin Accounts. - Infra: Pimlico, Alchemy, Etherspot Skandha (v0.8 + 7702 support). - Tooling: viem AA primitives, permissionless.js, MetaMask 7702 quickstarts, Remix AA panels. **Emerging / improving** - Real multi‑userOp bundling, signature aggregation, shared mempools. - Native AA on L2s via the RIP‑7560 path; 7702‑plus on L1. Track, but don’t block launches on it. --- ## Practical recipes ### A. Consumer app with passkey login + gas sponsorship (multi‑chain) - **Account:** Kernel v3 (7579) or Safe + 7579 adapter; enable P‑256/WebAuthn. - **Infra:** Pimlico bundler + verifying/erc‑20 paymaster; or Alchemy bundler + Gas Manager. - **SDK:** viem + permissionless.js; add EIP‑6492 for off‑chain signatures. **Result:** one‑click actions, device biometrics, selective sponsorship. ### B. On‑Base app that wants the least moving parts - **Account:** Safe or Kernel. - **Infra:** Coinbase paymaster + bundler (accept vendor link), enjoy credits. - **SDK:** viem AA primitives, follow Coinbase quickstarts. **Result:** fast path to production; less portability. ### C. Power user app (DeFi/agents) with parallel flows - **Account:** Kernel v3 (great nonce control) or OZ + custom modules. - **Infra:** Pimlico or Etherspot Skandha to keep flexibility. - **SDK:** permissionless.js + explicit 2D nonce keys. **Result:** parallel userOps, session keys, fine‑grained policies. --- ## Footguns to avoid - **“Works locally, fails on bundler.”** Your validation must satisfy 7562 rules; don’t use banned opcodes or state reads in validation. Test against the vendor’s simulator, not just `eth_call`. - **Dummy data during estimation.** Provide a correctly‑shaped dummy signature and `paymasterAndData` so estimation doesn’t undercharge `preVerificationGas` or revert. Vendors differ here. - **Pre‑deploy signatures.** Support EIP‑6492 on day one. Without it, logins/permits break until deploy. - **Bundler assumptions.** Don’t depend on multi‑op bundling saving you gas or improving latency; most production bundles are still single‑op. --- ## Quick tool index (by job to be done) - **Build accounts (4337/7702, P‑256/RSA):** OpenZeppelin Accounts; Safe; Kernel; Nexus. - **Send userOps (TS):** viem AA primitives; permissionless.js. - **Bundlers:** Pimlico; Alchemy; Etherspot Skandha; Coinbase (Base). - **Paymasters:** Pimlico verifying/erc‑20; Alchemy Gas Manager; Coinbase Paymaster (Base). --- *This file is meant to be a practical reference: clear, simple, and opinionated about what works in production right now.*