For developers building on Circle products, post Q&A, best practices & SDK/API insights. Use Tags

Circle Products & Developer Toolings

In the Arc Technical Office Hours on 3 September, we focused on 

. You all were really engaged and asked plenty of good questions. There were definitely a number that deserved cleaner answers than I was able to give in the moment. This follow-up pulls those together in one place.

If there are more questions you want us to cover in a future session, drop them in the thread.

Jessica Onah asked: How does Arc ensure state migration or sign-in portability if a developer wants to switch smart account implementations?

Arc does not migrate smart accounts between wallet products for you and neither do other EVM chains. A smart-account address is created by the provider's factory contracts. If you move from one implementation to another (for example ZeroDev to Circle Modular Wallets), users typically get a 

. Any balances or allowances have to be moved in a migration you design.

What developers usually want instead is continuity 

Stay on that product and rotate access there (new passkey, recovery key, or modules on the 

Or keep a plain EOA address and add smart-account behavior with 

Choose the account stack that owns the identity you care about before you ship. Switching vendors later is an app-level migration, not a chain feature.

Vijay Kanani asked: If gas is already paid in USDC on Arc, what additional UX and security benefits does account abstraction provide, and what is the recommended architecture for builders today?

Paying gas in USDC is a property of Arc’s fee market. EOAs already do that with normal transactions. Account abstraction (ERC-4337 smart accounts) is optional but still useful as it solves a different set of problems:

A paymaster (or other sponsor) pays USDC gas so users can act before they hold gas themselves

: Scoped signers (limits, allowlists, expiry) so an app or agent can act without holding the user’s root key, when the AA stack implements them

: Several calls in one UserOperation (for example approve + spend)

 Passkeys, recovery paths, and policy logic in the account instead of a single EOA key

 Contracts verify the smart account’s signature, not only ecrecover on an EOA

You would want to decide on what type of signing or custody you want to offer (EOA, embedded wallet, or smart account). Use an 

 if you only need gasless USDC transfers. Use 

 (hosted or self-run) if you need gasless arbitrary calls. Sponsorship should be funded in native USDC (18 decimals), while Apps should use the ERC-20 USDC interface for transfers and approvals. Arc’s 

 lists compatible providers, and you can assess which ones fit your needs better.

sain asked: How does account abstraction on Arc interact with CCTP? Could a user bridge USDC through CCTP and immediately execute another transaction on Arc without having to separately manage gas or approvals?

It is worth noting that CCTP and ERC-4337 are independent layers. CCTP burns on source and mints native USDC on Arc, while Account Abstraction only matters for how the user’s account later signs and who pays gas.

 the gas token (same balance as the ERC-20 interface). After the mint lands in the user’s address, they can pay gas for a follow-up transaction without holding ETH. Bridging still does not grant app allowances, and an ERC-20 approve / permit is needed when an app pulls USDC.

Account abstraction helps the second step as a smart account can batch approve + spend in one UserOperation, and a paymaster can sponsor gas so the user need not spend bridged USDC on fees. Account Abstraction does not change CCTP itself.

Furkan Ahmad asked: Could wallets eventually adapt their transaction permissions based on what an application is actually trying to do, instead of giving users the same approval experience for every transaction?

Yes, that is a major reason teams use smart accounts instead of a single unbounded EOA approve UX.

Account abstraction does not invent a new wallet UI by itself. It gives the account programmable rules so a wallet or app can tailor permissions per intent, for example:

Scoped signers (session keys) let you apply spend caps, contract or method allowlists, expiry, so an app or agent acts without holding the root key

Policy modules that allow installation or removal of rules on the account (allowlists, spending limits, custom validation), depending on the account standard and vendor

Batched UserOperations where you can encode a specific intent in one signature (for example approve exactly N, then call the app) instead of leaving a standing infinite allowance

Whether users actually see an adaptive approval experience depends on the wallet product and standards those stacks ship (session-key formats, intent APIs, UX). Arc runs standard ERC-4337 so those patterns work onchain. It does not provide a chain-level “smart permission UI.” Pick an Account Abstraction stack that documents the permission model you need.

akinremi nurudeen asked: How does native account abstraction handle USDC gas fee abstraction, and can apps sponsor gas for users natively without needing a custom paymaster setup?

This is one of the key things we highlighted during the office hours. Arc does not have a separate “native account abstraction” that abstracts gas.

USDC as gas is built into Arc. Every transaction pays fees in native USDC (18 decimals), including ordinary EOA transactions. Users do not need ETH for gas.

Account abstraction is optional ERC-4337 on top of that. Smart accounts, bundlers, and paymasters work as on other EVMs. The chain does not auto-sponsor anyone.

So USDC gas removes the volatile gas-token problem but that does not mean apps get free sponsorship without infrastructure.

Apps can sponsor without deploying their own paymaster contract: use a hosted paymaster from an Account Abstraction provider, or if they only need to perform gasless USDC transfers, an EIP-3009 relayer would be sufficient. Sponsoring arbitrary contract calls still goes through paymaster (or equivalent) infrastructure. There is no protocol switch that sponsors EOAs for free.

medet tofan asked: On Arc, what’s the safest pattern for exactly-once USDC settlement and retries, and how do ERC-4337, Paymaster, EntryPoint, bundlers and wallets differ when USDC is native gas?

With regard to settlement and retries, Arc has deterministic finality. This means once a transaction is included, it is final. You do not wait N confirmations or an epoch-based finality window the way you often do on chains with probabilistic or delayed finality (e.g. PoW reorg risk, Ethereum PoS pre-finality, many L2 soft-confirmation models). That makes included transfers irreversible. However, it does not by itself give exactly-once delivery if your backend broadcasts the same intent twice. Before a retry, check whether the prior transaction already landed (receipt / balance / your settlement id). It is recommended backend practice to keep an idempotency key in your own system.

Arc can emit two Transfer logs for one payment, one from the native system address (0xff…fe, 18 decimals) and one from the ERC-20 USDC contract (6 decimals). Prefer one canonical stream per payment type: use the ERC-20 USDC contract logs when the app moved USDC via the ERC-20 interface, and the system address (0xff…fe) when you need native sends that never touch the ERC-20 contract. If you subscribe to both, filter by emitter (or otherwise dedupe per transaction) so each payment is counted once.

As for ERC-4337 when gas is USDC, the roles do not differ that much, only the fee asset changes.

Wallets / smart accounts will validate and execute the UserOperation.

The Bundler packs UserOps into an EntryPoint transaction.

EntryPoint is the canonical 4337 singleton contract on the chain

The Paymaster is still the optional sponsor or fee mediator (fund and price in native USDC, 18 decimals)

Onur Akdemir asked: Could smart accounts on Arc set separate USDC limits for payments and gas sponsorship, so a compromised app or paymaster can’t spend beyond the user’s defined policy?

Technically yes, however, payment and gas sponsorship should be treated as two different controls.

Payments (moving the user’s USDC) belong in the smart account: whatever scoped signers, allowlists, or policy modules your AA stack supports. On Arc, an ERC-20 approve only gates transferFrom; it does not cap native USDC sends. Anything with execution rights on the account can move native balance unless the account’s own rules stop it.

Gas sponsorship (who pays fees) belongs in the paymaster (or other sponsor): validation logic and spend caps on the sponsor’s USDC. That usually protects the app’s sponsorship budget. It is not the same thing as a user setting “how much of my USDC may be spent on gas” though.

A compromised app that only holds a limited signer should be bounded by that account policy. A compromised paymaster can drain sponsorship funds up to its own limits. Under normal ERC-4337, it does not get a free pass to transfer the user’s USDC unless the account also granted it execution rights.

Arc runs standard ERC-4337. There is no built-in “payment limit vs gas limit” toggle. That particular UX depends on the wallet/account abstraction product you integrate.

fatih karaca asked: Is the base fee in extra_data a prediction or a commitment? Can it differ from what the block actually charges? Could a paymaster quote a firm price on it?

It is the next block’s base fee, published in the parent header, not a soft estimate you re-derive later. Integrators are 

 from the parent’s extra_data (8-byte big-endian) rather than recomputing the EWMA formula. Block 

 is expected to use that value as base_fee_per_gas.

The base fee is EWMA-smoothed and clamped between protocol min and max, so it moves gradually. Arc does not burn the base fee. The base fee and priority fee both go to the block beneficiary.

That locks in the base fee rate for the next block. What a user (or paymaster) actually pays still depends on gas used and EIP-1559 caps (maxFeePerGas, maxPriorityFeePerGas). A paymaster can treat the published base fee as known for the next block and add tip + gas-limit headroom but it cannot promise one fixed USDC total for an unbounded UserOp without its own gas limits and validation.

fatih karaca also asked: Modular wallets can't call Memo or Multicall3From, since both are EOA only. Will Arc's two signature predeploys stay closed to passkey users, or is there a path through the paymaster?

As of time of writing, the premise is correct, and a paymaster does not open a path.

Memo and Multicall3From both route through the CallFrom precompile so the outer transaction’s EOA stays msg.sender on the inner call. 

 require submitting those entrypoints from an EOA. Smart contract wallets are not supported as the direct caller, including ERC-4337 accounts such as Circle Modular Wallets, DevC/UserC SCAs, Safe-style wallets, and any flow where the outer transaction comes from EntryPoint or a bundler. If a smart account calls them, msg.sender is the wallet or EntryPoint context, not an EOA, and the call reverts (sender spoofing not allowed).

A paymaster only sponsors gas. It does not change who CallFrom treats as the sender.

Documented workarounds for memo metadata: trigger a separate EOA-signed Memo.memo(...) transaction, or attach the metadata in your application layer. The same EOA-direct rule applies to Multicall3From.aggregate3(...).

Thank you all once again for spending your precious time with us, learning and geeking out over the technical details of Arc's implementation. We will continue to have these Technical Office Hours regularly so please stay tuned for the next ones :)

2026-Sep-03 Arc Technical Office Hours Q&A Follow-Up

Home

Forum

Events

Content

Courses

Collections

People

Contributors

Albums

Groups

Chat

Channels

Not being used

Help

Join the global network of builders developing the Economic OS for the internet. We’re reimagining how value moves, creating the tools that make the economy work for everyone.

Arc House

What do you do professionally (be specific especially if you are self employed)

Join a global network of builders developing the Economic OS for the internet. We’re reimagining how value moves, creating the tools that make that economy work for everyone. 

Arc House | Build the economic OS for the internet with us

Copyright

Terms of Service

Privacy

Code of Conduct

Your Privacy Choices

It looks like there is no account associated with the email you provided. The event is for members only. Please complete the application to join our community first.

Thank you for your interest in joining us

Thanks for your interest in joining the event. However, your account is still pending. Once it's approved, you'll be able to register for the event. Please contact us via dev@arc.io if you need support.

Pending Approval

Login to the The Arc Community Hub community to connect with others, attend community events, and more!

Login or Sign Up for even more

To unlock all parts of the community complete your profile using verifiable and real information.

Hey, complete your profile

It looks like there is no account associated with the email you provided. Please complete the application to join our community.

Thank you for your interest in joining Arc House.

Thanks for your interest in joining Arc House. We will review your request shortly and email you once it's approved. Meanwhile, please feel free to contact us via dev@arc.io for any questions.

Accounts are unapproved when profile information cannot be verified or when activity patterns indicate spam, inorganic participation, or behavior that undermines trust in the program.

To strengthen your profile for future consideration, sign in with a verified LinkedIn account, use real and current profile information, and participate constructively in other community spaces.

Commercial customers should raise concerns through their support channel.

https://www.arc.network/community-guidelines