USDC for Every Action: How Arc Simplifies Building Onchain

On most EVM-compatible chains, users need one asset for USDC transfers and another for gas

Arc simplifies that model by making USDC the native gas asset while preserving familiar EVM execution, tooling, and integration patterns.

Solidity still works. Foundry, Hardhat, viem, ethers.js, and standard Ethereum wallet patterns still apply. Existing contracts can usually deploy unchanged. Existing engineering teams can keep familiar workflows for signing, RPC access, contract deployment, and application architecture.

That familiarity is what makes Arc’s USDC model important to understand. USDC is the native gas asset on Arc. That means fees and native value are denominated in USDC, while the same underlying balance is additionally exposed through an ERC-20 interface. Developers need to understand how native and ERC-20 USDC fit together before they build.

The problem Arc solves

An application may be built around USDC. Its users may hold USDC. Its accounting may be in USDC. But before a user can take the first action, they still need a separate gas token. That creates an extra dependency at the protocol layer and an extra state for every product team to handle.

In practice, that leads to a familiar class of failure:

• the user has the asset they want to use
• the app is ready for them to act
• the transaction still fails because they do not hold the network’s gas token

For developers, that means extra balance checks, onboarding logic, support cases, and failure handling around an asset the application may not otherwise use.

USDC as the native gas token

On Arc, transaction fees, native balances, and native value transfers are all denominated in USDC. Users can arrive with the asset they plan to use and start transacting.

From an integration standpoint, it means the protocol uses one stable asset where other EVM chains typically separate:

• application asset
• gas asset
• native value asset

Using one asset  reduces onboarding friction. It also makes fees easier to estimate and display in dollar terms, since Arc uses USDC-denominated fees with EWMA-smoothed base fees. For developers, it changes how to reason about native balances, ERC-20 balances, fee accounting, and value movement inside contracts and backend systems.

One asset, two interfaces, one balance

Arc’s USDC model starts with one core idea: there is one underlying USDC balance, exposed through two interfaces.

• The native interface uses 18 decimals and is used for gas accounting, native sends, and msg.value.
• The ERC-20 interface uses 6 decimals and is used for application-level transfers, approvals, and allowances.

The native and ERC-20 interfaces point to the same underlying asset, with no wrapper in between, which is why addr.balance and USDC.balanceOf(addr) are two views of the same balance expressed through different decimal systems.

Note: For developers, this is the first rule to keep in mind: do not model native USDC and ERC-20 USDC as separate holdings.

Native is the canonical source of truth

One of the most important details in Arc’s model is that the native balance is canonical.

The ERC-20 interface is a familiar way to interact with the same underlying balance. The value itself lives in the native account model. That model explains an important behavior: the ERC-20 view truncates. As a result, values smaller than 1 x 10^-6 USDC do not appear in the 6-decimal ERC-20 representation. A balanceOf result of 0 does not necessarily mean the native balance is 0.

Developers should treat the native and ERC-20 views as two precision views of the same balance, which means raw values should not be compared without conversion.

How does decimal conversion work?

This is the most important numerical detail in the model.

• Native values use 18 decimals
• ERC-20 values use 6 decimals
• The conversion factor between them is 10^12

Developers should never compare or reuse raw values across the two interfaces without converting first, since that affects:

• balance display
• fee display
• msg.value
• contract calls
• accounting systems
• indexers and analytics pipelines

Native values should be handled as 18-decimal quantities, while ERC-20 values should be handled as 6-decimal quantities, so conversion should always be explicit.

Why does this improve user experience?

Arc’s USDC design removes a longstanding mismatch because the asset users already hold is also the asset used for fees, so there is no separate gas-token acquisition step before they can transact. At the same time, teams still keep familiar EVM tooling and deployment flows.

What is different on Arc

Arc is EVM-compatible. Some protocol-level behaviors still differ from Ethereum.

Most differences are transparent to application code, but a few matter enough that developers should know early:

• some native USDC transfers can revert under Arc’s value transfer rules, even in cases that would succeed on a standard EVM chain
• SELFDESTRUCT has Arc-specific behavior when native value is involved
• native USDC movements emit Transfer events that indexers need to handle correctly
• local EVM simulators do not reproduce Arc-specific behavior, so final validation should happen against Arc RPC

This foundation piece sets the baseline. Developers should expect a familiar EVM environment and should still validate a small set of protocol-level differences before production deployment.

Where to go next

• App developers should start with Connect to Arc, Deploy on Arc, and EVM differences.
• Wallet teams should review Add Arc to a wallet, Transaction Lifecycle, and Display transaction fees.
• Exchanges should review Detect and process deposits and Process withdrawals.
• Relayer and paymaster teams should review Operate an EIP-3009 relayer on Arc and Deploy an ERC-4337 paymaster on Arc.
• Contract and infrastructure teams should review Port an AMM or liquidity pool to Arc, Infrastructure Integration, Index Arc events, and EVM differences.
• Explore open-source Arc apps built with Circle developer tools, from payments and FX to DeFi, wallets, and treasury flows.

Across all of those guides, the same model applies: one underlying USDC balance exposed through native and ERC-20 interfaces.