Canonical: https://builtonarc.app/guides/arc-account-abstraction-providers

# Account abstraction on Arc, and what it adds on top of USDC gas

Updated 2026-09-02. Gas on Arc is already USDC. Here's what ERC-4337 smart accounts and paymasters actually add on top, and which providers document Arc support.

> Arc's gas token is already USDC, which solves the volatility problem account abstraction is usually pitched to fix elsewhere. What ERC-4337 smart accounts and paymasters add on top is who holds the USDC that pays gas and how a user authenticates — sponsored transactions so an end user needs zero USDC in their own wallet, session keys and passkey login instead of a seed phrase, and a paymaster system that can let other stablecoins cover gas indirectly. As of 2 September 2026, Circle's documentation names eleven third-party account-abstraction providers for Arc; this guide covers what each is documented to offer.

## Why account abstraction still matters when gas is already USDC

On most L1s, ERC-4337's headline pitch is abstracting away a volatile native gas token — sponsoring a user's ETH gas so they can transact holding only the app's token. Arc removes that specific problem at the protocol level: gas is USDC, 18 decimals, EIP-1559-style base fee. What's left for account abstraction to solve on Arc is narrower and still real: a wallet with zero USDC in it cannot transact at all, so someone still has to sponsor first-time users, and consumer-grade wallets still benefit from passkey or social login instead of seed-phrase custody, session keys, and batched transactions. Circle's own materials describe Arc's paymaster system as able to let *other* stablecoins cover gas indirectly — the paymaster holds or accepts a different asset and settles the USDC cost itself — a materially different pitch from "we sponsor your gas" on a volatile-token chain. Built on Arc did not find a fully specified public description of that mechanism's constraints as of 2 Sep 2026, so treat it as directionally confirmed, not fully documented.

## The providers Circle documents

Circle's account-abstraction reference names eleven providers, each with a stated Arc-relevant capability. Ten file under this guide's own category; **Blockradar** does not — see below.

**Biconomy**

> **Builds on Arc:** Provides modular smart accounts, paymasters and bundlers for Arc apps. · **Role:** Serves · **Category:** Developer Infrastructure → Account abstraction

**Circle Wallets**

> **Builds on Arc:** Circle's own developer- and user-controlled wallet platform for Arc. · **Role:** Serves · **Category:** Developer Infrastructure → Account abstraction

**Crossmint** — separately confirmed same-day Arc testnet support on 28 Oct 2025.

> **Builds on Arc:** Offers wallet-as-a-service with email/OAuth onboarding, live on Arc testnet since 28 Oct 2025. · **Role:** Serves · **Category:** Developer Infrastructure → Account abstraction · [Project page](/project/crossmint)

**Dynamic** — separately confirmed via a Circle-authored integration tutorial on developers.circle.com.

> **Builds on Arc:** Provides wallet orchestration with native ERC-4337 and passkey support for Arc. · **Role:** Serves · **Category:** Developer Infrastructure → Account abstraction · [Project page](/project/dynamic)

**Para**

> **Builds on Arc:** Offers wallet and authentication infrastructure for fintech apps on Arc. · **Role:** Serves · **Category:** Developer Infrastructure → Account abstraction

**Pimlico**

> **Builds on Arc:** Provides bundler and paymaster infrastructure for ERC-4337 accounts on Arc. · **Role:** Serves · **Category:** Developer Infrastructure → Account abstraction

**Privy**

> **Builds on Arc:** Provides embedded-wallet APIs with email/social login for Arc apps. · **Role:** Serves · **Category:** Developer Infrastructure → Account abstraction · [Project page](/project/privy)

**thirdweb** — independently confirmed via thirdweb's own Arc Testnet page, which documents EIP-4337 and EIP-7702 gas sponsorship directly.

> **Builds on Arc:** Ships EIP-4337/EIP-7702 gas sponsorship and embedded wallets for Arc via its own SDK. · **Role:** Serves · **Category:** Developer Infrastructure → Account abstraction

**Turnkey**

> **Builds on Arc:** Provides programmable key infrastructure and policy controls for Arc wallets. · **Role:** Serves · **Category:** Developer Infrastructure → Account abstraction

**ZeroDev**

> **Builds on Arc:** Provides an SDK for ERC-4337 smart accounts with session keys on Arc. · **Role:** Serves · **Category:** Developer Infrastructure → Account abstraction

## Blockradar files elsewhere

**Blockradar** appears on Circle's own account-abstraction reference alongside the ten above, with infrastructure and APIs for smart-account management and transaction bundling at scale, and is also a Circle Developer Grants Cohort 1 recipient reported to have processed over $950m across 182,000 wallets (a reported figure, not Circle-confirmed). Built on Arc's canonical map files it under Wallets & Custody → Embedded wallets instead — the product is embedded wallet-as-a-service, not a developer-facing AA SDK.

> **Builds on Arc:** Provides embedded smart-account infrastructure for Arc apps at scale. · **Role:** Serves · **Category:** Wallets & Custody → Embedded wallets · [Project page](/project/blockradar)

## What's absent from the documented list

**Safe** and **Alchemy's** Account Kit do not appear on Circle's account-abstraction vendor list as of 2 Sep 2026, and Built on Arc found no independent Arc-specific integration documentation from either. Alchemy does appear elsewhere in Circle's stack as a documented RPC provider, a different layer from AA specifically. This is an absence from the confirmed record, not a statement that either company has decided against Arc.

## Reading these claims correctly

Appearing on Circle's list means Circle's documentation describes the provider's stated capability on Arc; it is not an audit of reliability, an endorsement, or a pricing claim. Dynamic and thirdweb have a second, independent confirmation beyond Circle's list — a stronger signal than the list alone. Everyone else here is confirmed only through Circle's curated documentation, and none of the eleven's own sites makes a mainnet-specific Arc claim as of 2 Sep 2026 — the whole category is documented against testnet.

For end users deciding which wallet to actually use, rather than which infrastructure a builder integrates, Meme Central covers that consumer-facing question: [best wallets for Arc](https://memecentral.fun/guides/best-wallets-for-arc?utm_source=builtonarc&utm_medium=guide&utm_campaign=arc).



Sources:
- [Arc account abstraction providers](https://docs.arc.io/arc/tools/account-abstraction.md)
- [Arc gas and fees reference](https://docs.arc.io/arc/references/gas-and-fees.md)
- [thirdweb: Arc Testnet](https://thirdweb.com/arc-testnet)
- [Circle: Dynamic integration tutorial](https://developers.circle.com/wallets/modular/dynamic-integration)
- [Crossmint, X post, 28 Oct 2025](https://x.com/crossmint/status/1983146042888474902)

*Built on Arc is an independent directory. Arc is a Circle product; we are not affiliated with, endorsed by, or operated by Circle.*

## Questions

**Does account abstraction change what gas token Arc uses?**

No. Arc's gas token is USDC regardless of whether an app uses smart accounts. AA changes who pays it and how a user authenticates, not the underlying asset.

**What exactly does "the paymaster can allow other stablecoins to pay gas" mean?**

Per Circle's framing, a paymaster contract can accept a different stablecoin from the user and settle the actual USDC gas cost on their behalf. Built on Arc did not find a detailed public specification of which stablecoins or what conversion mechanism is supported as of 2 Sep 2026.

**Is any one of these eleven providers a Circle-official recommendation?**

Circle's documentation lists all eleven without ranking or singling one out, and Built on Arc mirrors that.

**Do I need account abstraction to build on Arc?**

No. Arc supports standard EOA wallets and ordinary EVM transactions without any AA layer; AA is additive, not a requirement.

**Has any of these providers committed to Arc mainnet specifically?**

Not as far as Built on Arc could verify — every documented integration reviewed here is written against Arc Testnet.
