TL;DR
Account abstraction vendors split into two groups: those that run their own bundler and paymaster, and those that ask you to bring URLs for both. Openfort, Alchemy, Biconomy, Pimlico, ZeroDev and Thirdweb run their own. Privy defaults to Pimlico's public bundler and asks you to configure a bundler and paymaster URL per network before production. Safe ships contracts and an SDK and is explicitly provider-agnostic. EntryPoint coverage differs too: Openfort publishes paymaster addresses for v0.6, v0.8 and v0.9; Alchemy's bundler supports v0.6, v0.7 and v0.8; Safe's 4337 module defaults to v0.6 and needs module version 0.3.0 for v0.7. EIP-7702 is the sharpest divide — most vendors support signing a delegation, but few publish which chains it runs on. Openfort publishes a per-chain Delegated column; Pimlico names its chains; the rest do not enumerate.
Last updated: September 13, 2026.
Account abstraction is two standards, not one, and most provider comparisons still treat it as a single checkbox. ERC-4337 runs smart accounts off-protocol through bundlers and paymasters. EIP-7702 upgrades an existing EOA in place. A provider can support one, both, or one of them only on chains it does not name.
This post compares eight account abstraction providers — Openfort, Privy, Alchemy, Biconomy, Pimlico, ZeroDev, Thirdweb and Safe — on the specifics that separate them: who operates the bundler, who operates the paymaster, which EntryPoint versions are live, and where EIP-7702 actually works. Every cell below is sourced to the vendor's own documentation or left blank.
What is account abstraction?
Account abstraction is the replacement of Ethereum's default account model — an externally owned account (EOA) controlled by exactly one private key — with an account whose rules are written in contract code. The account, not the protocol, decides who may sign, how gas is paid, which calls are permitted, and how access is recovered.
That shift is what makes four things possible: gas sponsorship (the user transacts without holding the native token), transaction batching (approve and swap in one signature), session keys (a scoped key that acts within limits you set, without a prompt per action), and recovery (losing a device is not losing the account).
ERC-4337 and EIP-7702 are different mechanisms
ERC-4337 implements account abstraction without changing the protocol. A smart account is a contract deployed at a new address. Transactions from it are UserOperation objects sent to a bundler, which validates them, packs them together, and submits them to an EntryPoint contract. A paymaster contract can pay the gas. Three moving parts, all off-protocol, all operated by someone.
EIP-7702 changes the protocol instead. The user signs an authorization that points their existing EOA address at contract code. The address does not change, nothing is permanently deployed, and the EOA keeps control. EntryPoint v0.8 added native support for 7702 delegation, which is why a provider's EntryPoint version and its 7702 support are the same question asked twice.
The practical difference for a product: 4337 is how you give a new user a smart account; 7702 is how you upgrade a user who already has an address and assets they will not migrate.
Quick comparison
| Provider | Runs own bundler | Runs own paymaster | EntryPoint versions | EIP-7702 | AA coverage per chain | Gas sponsorship model | Session keys | Self-hostable component |
|---|---|---|---|---|---|---|---|---|
| Openfort | Yes — api.openfort.io/rpc/{chainId} | Yes — paymaster addresses published per EntryPoint version | v0.6, v0.8, v0.9 | Yes — per-chain Delegated column published | Bundler, paymaster and sponsorship on the same published EVM list; Solana sponsored via fee-payer relayer, not 4337 | App pays (project balance) or user pays in ERC-20 / SPL; policy engine gates both; external paymasters supported | Yes — on smart accounts and delegated accounts | Signer (OpenSigner) and contracts open source |
| Privy | No — defaults to Pimlico's public bundler; you register your own URL per network | No — you register a paymaster URL per network | Not published | Signs 7702 authorizations and type-4 transactions; delegation target is yours to choose | Per network you configure, with bundler and paymaster URLs you supply | Sponsored only if a paymaster URL is set; otherwise the smart wallet needs native currency | Not published | Not published |
| Alchemy | Yes | Yes — Gas Manager | v0.6, v0.7, v0.8 (v0.6 deprecation planned for 2026) | Yes — default mode of the Wallet APIs; only Modular Account v2 accepted as delegate | Chains served by Alchemy's bundler | Gas Manager sponsorship policies | Yes — ERC-6900 modules on Modular Account v2, with allowlists, ERC-20 and native spend limits, expiries | Not published |
| Biconomy | Yes — bundler.biconomy.io | Yes — sponsorship and token paymaster on one URL, selected by mode | v0.7 (Nexus); v0.6 (older bundler and paymaster list) | Yes, but routed to the Modular Execution Environment, not the 4337 bundler | Separate published chain lists for Nexus (v0.7) and for bundlers and paymasters (v0.6) | SPONSORED or ERC20 mode on the same paymaster URL; gas tank per project; self-hosted sponsorship URL supported | Yes — Smart Sessions module (ERC-7579) | Not published |
| Pimlico | Yes — and the bundler (Alto) is GPL-3.0 with a self-host guide | Yes | v0.6, v0.7, v0.8 | Yes — eip7702Auth on eth_sendUserOperation and eth_estimateUserOperationGas; chains named | Bundler and paymaster only; no wallet or auth layer | Verifying and ERC-20 paymasters; sponsorship policies | Not part of the product — belongs to the account implementation | Yes — Alto bundler, self-host guide published |
| ZeroDev | Yes — ZeroDev RPC, with a ?provider= parameter to select the underlying bundler | Yes — createZeroDevPaymasterClient | v0.7 in the SDK quickstart | Yes — delegates to Kernel v3.3 | Bundler and paymaster RPC per project and chain | Paymaster client with sponsorship policies; custom getPaymasterData hook for your own logic | Yes | Kernel contracts open source; infrastructure not published as self-hostable |
| Thirdweb | Yes — {chainId}.bundler.thirdweb.com | Yes — pm_sponsorUserOperation / pm_getPaymasterData on the bundler endpoint | v0.6 (default), v0.7 with a matching account factory | Yes — executionMode: { mode: "EIP7702", sponsorGas: true }; default mode for API user and server wallets | Chains served by the thirdweb bundler | sponsorGas flag; paymaster attached via EIP-5792 capabilities.paymasterService.url for external wallets | Yes | Not published |
| Safe | No — SDK is provider-agnostic; guides use Pimlico | No — you supply paymasterUrl and paymasterAddress | v0.6 by default (4337 module 0.2.0); v0.7 with module version 0.3.0 | Docs section published, still describing devnet and testnet availability | Contracts and module, on any chain where they are deployed and a third-party bundler runs | isSponsored with your paymaster URL, address and optional policy id; ERC-20 paymaster requires the Safe to hold the fee token | Not published | Yes — contracts and infrastructure are open source |
A blank or "not published" cell means the vendor does not document it, not that the capability is absent. The table compares capability depth per chain, not chain totals: a vendor listing a hundred chains where only a third run its paymaster is not comparable to one shipping bundler, paymaster and 7702 against a single published list.
The EIP-7702 support matrix
This is where the category is thinnest. Nearly every vendor will sign a 7702 authorization. Almost none publish which chains it runs on, which contract the EOA delegates to, or which EntryPoint handles the resulting UserOperation.
| Provider | Delegation target | EntryPoint for 7702 | Chains named in the docs |
|---|---|---|---|
| Openfort | Openfort 7702 Contract Delegator (audited by Quantstamp, September 2025) | v0.8 / v0.9 — delegated accounts require the latest EntryPoint | Arbitrum One, Base, BNB, Ethereum, Optimism, Polygon POS |
| Pimlico | Yours — passed as eip7702Auth | Not stated in the 7702 reference | Ethereum mainnet and Sepolia, BSC mainnet, OP-Stack chains including Base, Optimism and Zora, Odyssey testnet |
| Alchemy | Modular Account v2 at 0x69007702764179f14F51cdce752f4f775d74E139 — all other delegation addresses rejected | v0.8 adds native 7702 delegation | Not enumerated |
| ZeroDev | Kernel v3.3 | v0.7 in the SDK quickstart | Not enumerated; docs name Sepolia in the example and say any 7702-compatible network works |
| Thirdweb | Not stated | Not stated | Not enumerated |
| Biconomy | Nexus, via the Modular Execution Environment | Nexus runs on v0.7; MEE handles the delegated path | Not enumerated |
| Privy | Yours — Privy signs the authorization, you pick the implementation | Whichever your AA provider uses | Not enumerated |
| Safe | Not stated | Not stated | Docs still describe devnet and testnet availability |
Openfort publishes the delegation matrix as a column in its supported blockchains table, and every factory, account implementation and paymaster address on its entity addresses page. The EntryPoint addresses themselves are the canonical ones: v0.6 at 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789, v0.8 at 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108, v0.9 at 0x433709009B8330FDa32311DF1C2AFA402eD8D009.
Openfort
Openfort runs its own 4337 bundler and its own paymasters. Both are reachable at the same endpoint — https://api.openfort.io/rpc/{chainId} — with a publishable key in the Authorization header, so the same URL serves as bundler and paymaster in a viem createBundlerClient / createPaymasterClient pair.
What is published and verifiable:
- Bundler methods:
eth_sendUserOperation,eth_estimateUserOperationGas,eth_getUserOperationReceipt,eth_getUserOperationByHash,eth_supportedEntryPoints. - EntryPoint versions: paymaster addresses for v0.6, v0.8 and v0.9, each smart account implementation listing the EntryPoint it targets.
- Account types: EOA, smart account (ERC-4337) and delegated account (EIP-7702). Gas sponsorship, batching and session keys are available on the latter two; key rotation is supported on smart accounts and not under 7702. The full matrix is in account types.
- EIP-7702 chains: Arbitrum One, Base, BNB, Ethereum, Optimism and Polygon POS carry the Delegated column.
- Audits: five dated independent audits — CertiK (December 2023), Cure53 (September 2024), Omniscia (December 2024), Quantstamp on the 7702 Contract Delegator (September 2025) and Quantstamp on key management (October 2025). The signer, OpenSigner, is open source.
Gas sponsorship model: two modes, both gated by a policy engine. App pays bills sponsored gas to your project balance. User pays charges the end user in an ERC-20 on EVM chains or an SPL token such as USDC on Solana, at a live or fixed rate, and never debits your balance. Policies scope sponsorship by contract, function selector, value cap, chain and recipient allowlist, at either project scope (applies automatically) or transaction scope (requires an explicit policyId). External paymasters can be registered and linked to a policy. Details in gas sponsorship.
Solana: sponsorship works through a Kora fee-payer relayer rather than a paymaster. It is not ERC-4337, and Openfort's docs say so rather than counting Solana as an AA chain.
Limitations: EntryPoint v0.7 is not in the published paymaster set — Openfort ships v0.6, v0.8 and v0.9. Smart accounts and delegated accounts are EVM-only. Chain coverage is narrower than providers that resell a bundler they do not operate.
See Openfort vs Pimlico, Openfort vs Biconomy and Openfort vs Alchemy for the head-to-heads.
Privy
Privy is an embedded wallet and auth product with a smart wallet layer bolted on top of other people's account implementations. Its docs list the supported implementations as Alchemy, Kernel (ZeroDev), Safe, Biconomy, Thirdweb, and the Coinbase Smart Wallet.
The infrastructure question is answered directly in Privy's dashboard configuration docs: for each network you can optionally provide a bundler URL and a paymaster URL. If no bundler URL is set, Privy defaults to Pimlico's public bundler at https://public.pimlico.io/v2/{chainId}/rpc, and Privy recommends setting your own before production because the default is heavily rate limited. If no paymaster URL is set, the user's smart wallet must hold the network's native currency to pay gas.
EIP-7702: Privy supports the low-level interfaces — signing authorizations and sending type-4 transactions — so any 7702 implementation can be used. The delegation target, bundler and paymaster come from whichever AA provider you pair it with.
What this means in practice: Privy is a strong auth and embedded wallet layer, and its account abstraction is an integration surface rather than infrastructure Privy operates. If the AA layer is the part you care about, you are choosing a second vendor regardless.
Compare directly: Openfort vs Privy.
Alchemy
Alchemy runs its own bundler and its own paymaster (Gas Manager), and its bundler supports EntryPoint v0.6, v0.7 and v0.8. v0.6 has no fixed deprecation date, but Alchemy says deprecation is planned for sometime in 2026 and advises migrating to v0.7 or v0.8.
EIP-7702: Alchemy went further than most — 7702 delegation is the default mode of its Wallet APIs. Using an owner address directly with wallet_prepareCalls enables 7702 automatically, and the API accepts only 0x69007702764179f14F51cdce752f4f775d74E139 (Modular Account v2) as the delegation target; every other delegate address is rejected. Undelegation is a re-delegation to the zero address.
Session keys: Modular Account v2 supports session keys and WebAuthn validation as separate ERC-6900 modules, with allowlists, ERC-20 spend limits, native spend limits that account for gas, and expiries.
Limitations: the delegation target is fixed to Alchemy's own account, which is the trade-off for 7702 being the default path. Alchemy does not publish which chains carry 7702.
Compare directly: Openfort vs Alchemy.
Biconomy
Biconomy runs its own bundler (bundler.biconomy.io/api/v3/{chainId}/{key}) and its own paymaster, with sponsorship and token payment served from the same URL and selected by a mode parameter — SPONSORED checks eligibility and returns 0x if the operation cannot be sponsored; ERC20 returns data for the token paymaster.
Nexus, Biconomy's ERC-7579 modular account, runs on EntryPoint v0.7. The older bundler and paymaster chain list is a separate v0.6 list, and Biconomy's supported-networks page keeps the two apart.
EIP-7702 — read the caveat: Biconomy's ERC-4337 bundlers and paymasters work with Companion Accounts. For wallets delegating to Nexus under 7702, Biconomy directs you to its Modular Execution Environment, where the quote takes delegate: true and an authorization field. So 7702 support exists, but on a different execution path than the 4337 stack.
Session keys: Smart Sessions, an ERC-7579 module, with validation modules covering multisig, ECDSA ownership and ERC-7739 nested typed-data validation.
Sponsorship: per-project gas tank, activated in the dashboard, with an API key required on all requests. A self-hosted sponsorship URL with custom gas tanks is supported.
Compare directly: Openfort vs Biconomy.
Pimlico
Pimlico is the bundler and paymaster layer, sold as such. No wallets, no auth, no UI. It is also the only vendor here whose bundler you can run yourself: Alto is published under GPL-3.0 at pimlicolabs/alto with a self-host guide covering executor wallets, utility wallet refills, safe-mode validation against ERC-7562 rules, and the CLI flags for EntryPoints and RPC.
EIP-7702: supported by accepting an eip7702Auth object on eth_sendUserOperation and eth_estimateUserOperationGas (a dummy authorization is allowed for estimation), and submitting a type-4 set-code transaction with an authorization_list. The userOpHash depends on the delegate address, so the user signs over the authorization object. Pimlico names its 7702 chains: Ethereum mainnet and Sepolia, BSC mainnet, OP-Stack chains including Base, Optimism and Zora, and the Odyssey testnet.
EntryPoint: v0.7 and v0.8 take an unpacked UserOperation, with packing handled bundler-side per spec.
What you still need: an account implementation, a wallet layer, auth, and whatever sits above them. Pimlico is infrastructure for teams building infrastructure — which is exactly why other vendors, Privy's default configuration included, point at it.
Compare directly: Openfort vs Pimlico.
ZeroDev
ZeroDev runs bundler and paymaster RPCs per project at https://rpc.zerodev.app/api/v3/{project-id}/chain/{chain-id}, and its docs recommend sourcing both from the same provider because mixing a paymaster from one provider with a bundler from another is sometimes incompatible. A ?provider= query parameter selects the underlying bundler.
Kernel is the account: modular, ERC-7579, and the delegation target for 7702. The SDK quickstart uses getEntryPoint("0.7") and KERNEL_V3_3, with the authorization signed via walletClient.signAuthorization({ contractAddress: KERNEL_V3_3 }) and passed as eip7702Auth to createKernelAccount.
Gas sponsorship: createZeroDevPaymasterClient, with a getPaymasterData hook if you want your own sponsorship logic, and a self-funded ERC-20 paymaster for custom tokens.
Limitations: no embedded wallets, no auth — by design. You pair ZeroDev with a wallet provider and handle login yourself. ZeroDev does not publish a self-host path for its bundler or paymaster, though Kernel itself is open source.
Thirdweb
Thirdweb runs a bundler with integrated paymaster services at {chainId}.bundler.thirdweb.com, versioned in the path (/v2 recommended), exposing pm_sponsorUserOperation and pm_getPaymasterData plus a stub method for estimation without sponsorship.
EntryPoint: the TypeScript SDK's smartWallet defaults to v0.6 and supports v0.7 when passed a compatible account factory — either DEFAULT_ACCOUNT_FACTORY_V0_7 or your own.
EIP-7702: enabled with one config flag on in-app wallets — inAppWallet({ executionMode: { mode: "EIP7702", sponsorGas: true } }) — and it is the default execution mode for thirdweb API user and server wallets. For external wallets such as MetaMask, the same capabilities are reached through EIP-5792 sendCalls, with the paymaster attached via capabilities.paymasterService.url.
Limitations: account abstraction is one product among contracts, payments, storage, RPC and bridging. Thirdweb does not publish which chains carry 7702.
Compare directly: Openfort vs Thirdweb.
Safe
Safe is not an AA vendor in the same sense as the others: it ships contracts and an SDK, runs no bundler and no paymaster, and is explicitly provider-agnostic — its own ERC-4337 guides use Pimlico as the example provider and note that any ERC-4337-compatible provider works.
How 4337 works on Safe: through the Safe4337Module, which acts as both a Fallback Handler and a Safe Module, implements the 4337 interface, and is restricted to one EntryPoint address. It requires Safe v1.4.1 or newer and can be enabled at deployment or afterward.
EntryPoint versions: the Safe4337Pack defaults to module version 0.2.0, which is compatible only with EntryPoint v0.6. Passing safeModulesVersion: '0.3.0' gets you v0.7. The pack has not always validated that the chosen EntryPoint matches the module the loaded Safe uses, so verify the pairing yourself.
Sponsorship: set isSponsored and supply paymasterUrl, paymasterAddress and optionally a sponsorshipPolicyId. For an ERC-20 paymaster, the Safe must hold a balance of the fee token; the SDK encodes the approval internally.
EIP-7702: Safe maintains a docs section for it, but the published text still describes availability on devnets and testnets ahead of the Pectra upgrade.
Best for: shared treasuries and multisig custody, where Safe is the default and has been for years. Not the shortest path to consumer smart accounts.
Choosing between them
The decision reduces to three questions.
1. Do you want to operate the AA layer, or consume it? If you want to run it, Pimlico's Alto is the only self-hostable bundler here, and Safe's contracts are the only fully self-hostable account stack. If you want to consume it, the question becomes whose infrastructure you are actually consuming — which is the point of the bundler and paymaster columns above.
2. Do you already have wallets and auth? If yes, Pimlico or ZeroDev give you the AA layer and nothing you already own. If no, Openfort, Alchemy and Thirdweb bundle wallets, auth and AA in one SDK, and Privy bundles wallets and auth while pointing AA at someone else's stack.
3. Are you onboarding new users or upgrading existing ones? New users get ERC-4337 smart accounts. Users who already hold assets at an address they will not migrate need EIP-7702 — and there the question is not whether a vendor supports it, but whether they publish which chains it runs on. Most do not.
Detailed feature comparison
| Feature | Openfort | Privy | Alchemy | Biconomy | Pimlico | ZeroDev | Thirdweb | Safe |
|---|---|---|---|---|---|---|---|---|
| Operates its own 4337 bundler | Yes | No | Yes | Yes | Yes | Yes, with a ?provider= override | Yes | No |
| Bundler endpoint published | api.openfort.io/rpc/{chainId} | — | Yes | bundler.biconomy.io/api/v3/{chainId}/{key} | Yes | rpc.zerodev.app/api/v3/{id}/chain/{id} | {chainId}.bundler.thirdweb.com | — |
| Operates its own paymaster | Yes | No — you register a URL | Yes (Gas Manager) | Yes | Yes | Yes | Yes | No — you supply URL and address |
| EntryPoint v0.6 | Yes | Not published | Yes | Yes (older list) | Yes | Not published | Yes (SDK default) | Yes (module 0.2.0) |
| EntryPoint v0.7 | Not in published paymaster set | Not published | Yes | Yes (Nexus) | Yes | Yes (SDK quickstart) | Yes (with v0.7 factory) | Yes (module 0.3.0) |
| EntryPoint v0.8 | Yes | Not published | Yes | Not published | Yes | Not published | Not published | Not published |
| EntryPoint v0.9 | Yes | Not published | Not published | Not published | Not published | Not published | Not published | Not published |
| EIP-7702 delegated accounts | Yes | Signs authorizations; implementation is yours | Yes — default mode of the Wallet APIs | Yes — via the Modular Execution Environment | Yes — eip7702Auth | Yes — Kernel v3.3 | Yes — one config flag | Docs describe devnet/testnet |
| 7702 chain list published | Yes | No | No | No | Yes | No | No | No |
| Delegation target named | 7702 Contract Delegator | Yours | Modular Account v2 (only target accepted) | Nexus | Yours | Kernel v3.3 | Not stated | Not stated |
| Gas sponsorship: app pays | Yes — billed to project balance | Only via your paymaster | Yes | Yes — gas tank | Yes | Yes | Yes — sponsorGas | Only via your paymaster |
| Gas sponsorship: user pays in ERC-20 | Yes | Not published | Not published | Yes — ERC20 mode | Yes — ERC-20 paymaster | Yes — self-funded ERC-20 paymaster | Not published | Yes — Safe must hold the fee token |
| Sponsorship gated by a policy engine | Yes — contract, selector, value cap, chain, recipient allowlist | Not published | Yes — Gas Manager policies | Yes — dashboard-activated | Yes — sponsorship policies | Yes | Not published | sponsorshipPolicyId passed to your paymaster |
| External / third-party paymaster supported | Yes | Your paymaster is the only paymaster | Not published | Yes — self-hosted sponsorship URL | Not applicable | Yes — custom getPaymasterData | Yes — via EIP-5792 capabilities | Yes — provider-agnostic |
| Onchain session keys | Yes | Not published | Yes — ERC-6900 modules | Yes — Smart Sessions | Belongs to the account implementation | Yes | Yes | Not published |
| Embedded wallets in the same SDK | Yes | Yes | Yes | Not published | No | No | Yes | No |
| Auth in the same SDK | Yes | Yes | Yes | Not published | No | No | Yes | No |
| Solana fee sponsorship | Yes — Kora fee-payer relayer, not 4337 | Not published | Not published | Not published | No | Not published | Not published | No |
| Open-source bundler | No | Not applicable | Not published | Not published | Yes — Alto, GPL-3.0 | Not published | Not published | Not applicable |
| Open-source signer / key management | Yes — OpenSigner | Not published | Not published | Not published | Not applicable | Not applicable | Not published | Not applicable |
| Self-host guide published | Signer only | No | No | Sponsorship URL only | Yes — bundler | No | No | Yes — contracts and infrastructure |
| Per-chain contract addresses published | Yes | Not published | Delegate address published | Not published | Not published | Kernel addresses in SDK constants | Not published | Deployment repo published |
| Dated independent audits published | Yes — five, 2023–2025 | Not published here | Not published here | Not published here | Not published here | Not published here | Not published here | Not published here |
"Not published here" means the claim was not verifiable from the documentation cited in this post — it is not a statement that no audit exists.
Related reading
- Gasless transactions on Ethereum — how sponsorship works end to end
- EIP-7702 explained and the Openfort 7702 delegator account
- Gas sponsorship via paymasters
- Best wallet-as-a-service providers and top embedded wallets — the wallet-layer equivalents of this comparison
- Best agent wallets for developers — session keys and policies applied to autonomous agents
Account abstraction is infrastructure. The vendor you pick decides who answers the page when UserOperations stop landing, whose rate limits you inherit, and whether an existing user can be upgraded without changing address. Those are the columns worth comparing — not the chain count.
If you want bundler, paymaster, 4337 smart accounts and 7702 delegated accounts from one vendor, with per-chain addresses and audit dates published, start with the Openfort docs or the account abstraction overview.
