Gasless UX on Arc: What USDC Gas Fixes, and What It Doesn't

Arc removed the worst part of onboarding by making USDC the gas asset — a new user no longer has to acquire a volatile token they do not want in order to spend the stable one they do. That solves the asset problem and leaves the balance problem untouched: an address with zero USDC still cannot send its first transaction. Sponsorship closes that last gap, using the familiar patterns — account abstraction, paymasters, meta-transactions — applied to a fee denominated in dollars.

This page covers Arc in its first weeks of mainnet. Where a piece of the account-abstraction stack is still landing we say so rather than guess, and we revise this page as the ecosystem fills in. Last reviewed: September 2026.

What does "gasless" actually mean?

Nothing is free; "gasless" means the fee is paid by someone other than the signer. The user signs an intent, a third party submits it and settles the fee, and the user's balance is never debited for gas. Implementations vary only in who holds the funding account, how the sponsor's willingness to pay is expressed onchain, and how the sponsor stops being drained.

That framing matters on Arc because the naive reading of "gas is paid in USDC" is that the problem is solved. Fee denomination and fee funding are separate problems: Arc solves the first outright and leaves the second untouched.

What does Arc's USDC gas already fix?

It removes the two-asset requirement. On a conventional EVM chain, a user who wants to move a stablecoin must hold a second, volatile asset purely to pay for the privilege — a separate acquisition path, a swap, and an explanation. On Arc, gas is paid in USDC, so the asset the user holds and the asset the network charges are the same one. Fees on testnet averaged about $0.004 per transaction as of August 2026.

Three benefits follow: fees are quotable in the unit the user thinks in, so a UI can say "half a cent" rather than a gwei figure; treasury forecasting stops being an exercise in predicting a token price; and no volatile dust is left on every user account. The fee model is covered in gas fees on Arc.

What is left is the cold-start case. A wallet created thirty seconds ago holds zero USDC and cannot claim an airdrop, sign up, or touch state at all: the first transaction requires a balance the user cannot obtain without a transaction. Breaking that circularity is why gasless UX still matters on a chain with stablecoin gas.

How does account abstraction solve it?

ERC-4337 moves transaction validation out of the protocol and into a smart contract account, with no consensus change required. The user signs a UserOperation rather than a transaction; a bundler collects those and submits them to a singleton EntryPoint contract; an optional paymaster contract agrees to cover the fee. Because the paymaster is a contract, its willingness to pay is programmable — sponsor a specific user, function or campaign, and stop.

The EntryPoint is the piece that has to exist on the chain you are targeting. It is deployed deterministically, so the canonical deployments carry the same address on every chain that has one: 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789 for v0.6, 0x0000000071727De22E5E9d8BAf0edAc6f37da032 for v0.7 and 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108 for v0.8, per the eth-infinitism account-abstraction repository as of September 2026. Version matters to your code: v0.6 takes an unpacked UserOperation, v0.7 introduced the packed struct below, and v0.8 added native handling for EIP-7702 delegated accounts. An address existing on a chain is not the same as a bundler willing to serve it, which is the next section.

struct PackedUserOperation {
    address sender;                // the smart account
    uint256 nonce;
    bytes   initCode;              // account deployment, if not yet deployed
    bytes   callData;              // what the account should execute
    bytes32 accountGasLimits;
    uint256 preVerificationGas;
    bytes32 gasFees;
    bytes   paymasterAndData;      // paymaster address + its own calldata
    bytes   signature;
}

The paymaster interface is where your sponsorship policy lives. validatePaymasterUserOp is called during validation and either accepts the operation or reverts; postOp runs afterward with the actual cost, which is where accounting and per-user budgets get updated.

interface IPaymaster {
    function validatePaymasterUserOp(
        PackedUserOperation calldata userOp,
        bytes32 userOpHash,
        uint256 maxCost
    ) external returns (bytes memory context, uint256 validationData);

    function postOp(
        PostOpMode mode,
        bytes calldata context,
        uint256 actualGasCost,
        uint256 actualUserOpGasPrice
    ) external;
}

A verifying paymaster — the most common production pattern — checks policy off-chain and proves the decision onchain with a signature, keeping validation cheap and business rules out of the contract:

function validatePaymasterUserOp(
    PackedUserOperation calldata userOp,
    bytes32 userOpHash,
    uint256 maxCost
) external view returns (bytes memory context, uint256 validationData) {
    (uint48 validUntil, uint48 validAfter, bytes calldata sig) = _parse(userOp.paymasterAndData);

    bytes32 digest = _hash(userOp, validUntil, validAfter);   // must exclude the signature field
    bool ok = ECDSA.recover(digest, sig) == sponsorSigner;

    // packed as (sigFailed, validUntil, validAfter) per ERC-4337
    validationData = _packValidationData(!ok, validUntil, validAfter);
    context = abi.encode(userOp.sender, maxCost);
}

Two details cause most paymaster bugs. The signed digest must exclude the paymaster's own signature bytes, or you have a chicken-and-egg hash. And ERC-4337 restricts what storage validation may read: a paymaster reading arbitrary storage is rejected by bundler simulation even though it compiles and passes unit tests.

Whose account abstraction is actually running on Arc?

Arc is EVM-compatible, so ERC-4337 — a contract-level standard — works wherever the EVM does. The infrastructure does not transfer automatically: bundlers, EntryPoint deployments and hosted paymaster services are per-chain deployments run by specific vendors, and Arc mainnet went live on September 16, 2026, so that vendor picture is still filling in week by week.

We are deliberately not freezing a vendor list here, because it would be wrong within a fortnight. Arc's own developer documentation maintains an account-abstraction page listing the smart-account SDK, bundler and paymaster providers that have integrated the chain; when we checked it in September 2026 it named Biconomy, Pimlico, ZeroDev and Blockradar, and it is the page to read before you pick a dependency. Confirm two things there rather than assume them: which EntryPoint version Arc carries, since a v0.7 bundler will not accept a v0.6 operation, and whether your provider supports Arc for sponsored operations or merely lists it as a network.

The same caution applies to EIP-7702, the lighter-weight alternative to migrating users onto smart accounts. It shipped on Ethereum mainnet in the Pectra upgrade on May 7, 2025 and introduces a set-code transaction, type 0x04, carrying an authorization list: an EOA signs an authorization naming a contract, and the account's code field is set to the delegation indicator 0xef0100 followed by that address, so the EOA executes the contract's code while keeping its address, balance and nonce. That buys you batching and sponsorship without deploying an account per user. Whether Arc's EVM target includes it belongs in Arc's EVM-differences documentation, which is where the chain records its departures from upstream Ethereum, and is worth checking on the day you build.

The wallet side matters as much. Circle names MetaMask, Ledger, Binance Wallet and Fireblocks among Arc's day-one integrations, but signing UserOperation payloads is a separate capability from network support — see best wallets for Arc — and should be tested per wallet.

Are there simpler options than full account abstraction?

Yes, and for many products they are the right call. Full ERC-4337 requires smart accounts, a bundler dependency and a deployment step per user. Two lighter patterns cover most real use cases without any of that.

The first is ERC-2612 permit plus a relayer. The user signs an off-chain approval; your backend submits a transaction calling permit then transferFrom, paying the fee itself. The user never sends a transaction and never needs a balance. This works for any token implementing permit, which is a decision you make when you write the token — see token standards on Arc.

function depositWithPermit(
    address user, uint256 amount, uint256 deadline,
    uint8 v, bytes32 r, bytes32 s
) external {
    IERC20Permit(address(token)).permit(user, address(this), amount, deadline, v, r, s);
    token.safeTransferFrom(user, address(this), amount);
    _credit(user, amount);
}

The second is a push model: instead of having users pull, you send. Distributions, refunds and airdrops execute from your own funded account, so the recipient needs no balance at all. This is the least clever and most reliable answer to "my users have zero USDC", and it costs one integration — a multisender, say — rather than an infrastructure stack.

Worth naming so you reject it deliberately: dusting new users with a fraction of a cent of USDC so they can pay their own fee. You are sending value to unverified addresses at your expense, and a script will drain it.

How do you stop a paymaster being drained?

Scope the policy narrowly and enforce it in validatePaymasterUserOp, not in the UI. A policy that accepts any operation from any sender is a faucet, and it will be found within hours. The defensible pattern is an allowlist of target contracts and function selectors, a per-address lifetime cap, and a global daily ceiling that fails closed.

error NotSponsored(address target, bytes4 selector);
error CapExceeded(address user);

function _checkPolicy(address user, address target, bytes4 selector, uint256 maxCost) internal view {
    if (!sponsoredSelector[target][selector]) revert NotSponsored(target, selector);
    if (spentByUser[user] + maxCost > perUserCap) revert CapExceeded(user);
    if (spentToday + maxCost > dailyCap) revert CapExceeded(user);
}

Sponsor the first transaction, not every transaction. The economic case for gasless UX is onboarding — breaking the zero-balance circularity once. After a user funds an account, indefinite sponsorship is a subsidy with no conversion argument behind it. Budget it as acquisition cost with a hard ceiling, and instrument spend per activated user.

To confirm a sponsorship worked, read the settled transaction rather than your own logs. On the explorer the sender is the bundler's address, not your user's, and the fee is debited from the paymaster's EntryPoint deposit, so the user's USDC balance should be unchanged before and after. If it moved, your paymaster silently declined and the operation fell back to self-payment. Reading transactions on Arcscan covers the fields.

FAQ

Do I still need gas sponsorship if Arc charges fees in USDC?

Yes, for any flow where a user's first action happens before they hold USDC. Arc's USDC gas removes the need to acquire a separate volatile token, the larger half of the onboarding problem, but a zero-balance address still cannot submit a transaction. Sponsorship covers first claims, sign-ups and any product where the first onchain action precedes the first deposit.

Does ERC-4337 work on Arc?

ERC-4337 is implemented entirely in smart contracts, and Arc is EVM-compatible, so the standard itself applies without modification. The part that is chain-specific is the surrounding infrastructure: which EntryPoint version is deployed, which bundlers accept Arc UserOperations, and which hosted paymaster services support the network. Arc mainnet is weeks old at the time of writing, that picture is still filling in, and Arc's own account-abstraction documentation is the current list rather than anything published here.

What does a sponsored transaction cost the sponsor on Arc?

The same fee the user would have paid, in USDC, plus any margin a hosted paymaster provider charges and the ERC-4337 verification overhead, which adds meaningfully to a bare transfer's cost in percentage terms and almost nothing in absolute terms. Arc's testnet fees averaged about $0.004 per transaction as of August 2026, and mainnet costs should be measured on your own flows rather than extrapolated from that. At this order of magnitude the dominant cost of a sponsorship programme is abuse, not gas.

Can I sponsor gas without smart accounts?

Yes. ERC-2612 permit with a backend relayer covers approve-and-deposit flows, ERC-2771 meta-transactions cover contracts you control and can make trusted-forwarder-aware, and pushing tokens from your own funded account covers distributions. All three avoid the bundler dependency and per-user account deployment that ERC-4337 requires.

What is the main risk in a gasless flow?

Unbounded sponsorship. A paymaster that validates without a policy is a public faucet paid for in USDC, and enforcement must live in validatePaymasterUserOp because anything enforced only in your front-end is not enforced. Constrain by target contract and selector, cap per address and per day, and treat the paymaster deposit as a hot wallet.