Supporting Arc in Wallets: One Balance, USDC Fees, and Complete History
Summary
Arc uses the EVM interfaces that wallet teams already support. The wallet experience changes because USDC is both the asset users hold and the asset that pays network fees. For the wallet, native and ERC-20 USDC appear as one balance, fee estimates use USDC, and transaction history includes native balance movements.
Network configuration information can be found at the Add Arc to a Wallet how-to guide, and the following sections will also include links to relevant sections for implementation details.
What Arc's stablecoin-native model means for wallets
Arc lets wallets present USDC as both the asset users hold and the asset that pays network fees. Users can hold USDC, send USDC, and pay network fees from the same underlying balance.
The experience stays simple when the wallet keeps those views consistent. A second token row, an ETH fee label, or history that omits native sends can make the protocol model look more complicated than it is.
Register Arc as an EVM network
Register Arc with EIP-3085 and the published chain ID, RPC, explorer, and native-currency metadata. Set nativeCurrency.decimals to 18 to match Arc's native precision, then format the balance to 6 USDC decimals for display. Raw eth_getBalance results and native transaction values use 18 decimals.
Arc uses secp256k1 signing, Ethereum-style addresses, EIP-155 replay protection, EIP-1559 transactions, and standard ERC-20 calls. If the wallet accepts arbitrary EVM transaction types, reject EIP-4844 type-3 blob transactions because Arc does not support them.
For the type-3 restriction and other transaction differences, see Execution and opcode differences. Once Arc is registered, the first visible wallet decision is how to represent its balance.
Merge native and ERC-20 USDC into one balance
For wallet rendering, native USDC and the ERC-20 USDC interface are the same asset, not two separate tokens that happen to share a name. They expose that balance through different interfaces and decimal scales.
Display one USDC row. When a user imports the ERC-20 USDC contract, map it to the existing asset instead of creating a second “Native USDC” or “USDC” token.
Summing eth_getBalance with balanceOf, or formatting an 18-decimal raw value as if it were 6-decimal, double-counts or misstates the balance. nativeCurrency.decimals: 18 is chain precision for native units. It is not the UI display precision.
Convert native values before you compare or display them: divide by 1012, then show six USDC decimals. The ERC-20 view truncates values below 1×10−6 USDC, so balanceOf == 0 does not prove that the native balance is zero.
You can refer to Stablecoin native model for the asset model and Add Arc to a Wallet for wallet configuration.
Display fees in USDC
Arc fee RPCs return native USDC units with 18 decimals. Leaving wallet-library defaults in place labels those fees as ETH or Gwei. Convert the fee fields, divide by 1012 when you show USDC, and update fee and insufficient-funds copy to say USDC.
Use the Arc RPC fee fields to build EIP-1559 transactions and calculate the maximum fee. Fee display covers the estimation and formatting details.
The same native-value rules apply when the user sends a transaction. A balance check alone does not guarantee that a native-value transfer will succeed.
Send USDC and explain failures
Standard EVM signing and ERC-20 transfer() calls work on Arc. One USDC is 106 in ERC-20 units and 1018 in native msg.value units. Reusing the same raw integer across those paths sends far too little or far too much. Validate ERC-20 send amounts to 6 display decimals, and build native sends in 18-decimal units.
Native-value transfers can fail because of the zero address, the blocklist, a forbidden burn, or contract execution rules. A sufficient balance does not guarantee success for an arbitrary native-value transfer. The full list of restrictions can be found at Value transfer rules.
Support copy can name USDC and the actual failure:
Show transaction status
Arc finalizes transactions when they are included in a committed block. A wallet can show Pending and Final states without a confirmation counter. Once a receipt has a block number, the transaction is final. Use status: 1 for success and status: 0 for failure.
Before mempool entry, show the failure reason, such as a blocklist rejection. An onchain revert with status: 0 is a final failure. Track dropped and replaced transactions separately from pending transactions.
Transaction lifecycle defines the states and failure paths. Query the EIP-7708 logs to identify the balance movement for history.
Deduplicate history across Arc's dual emitters
Arc’s dual emitters require two history-handling rules: filtering only the ERC-20 USDC contract misses native sends, and treating both emitters as separate transfers double-counts every ERC-20 transfer().
Use the EIP-7708 system emitter as the native-movement stream. Filter transfers to or from the user's address, convert the 18-decimal event value before display, and credit each underlying transfer once. An ERC-20 transfer() also emits a 6-decimal Transfer from the USDC contract — match on the emitter and deduplicate that event rather than listing it as a second send. Keep fee lines separate from transfer history.
Current emitter addresses, event signatures, and pre-Zero5 Arc Testnet backfill rules live in USDC system events. The Arc USDC contract address is on Contract addresses. If a history provider supplies the data, verify that it supports the system emitter.
Pre-ship checklist
- Register Arc Testnet with EIP-3085 and set nativeCurrency.decimals: 18; format the displayed balance to 6 USDC decimals
- Display native and ERC-20 USDC as one asset, with the 18-to-6 conversion
- Display fees and insufficient-funds errors in USDC
- Handle zero-address, blocklist, and contract-call failure cases
- Show pending and final states, with receipt status for success or failure
- Index the EIP-7708 system emitter and deduplicate the ERC-20 event
- Test Arc-specific behavior against an Arc RPC, not only a local EVM fork
Use Add Arc to a Wallet for setup, Fee display for fee handling, Transaction lifecycle for status, and USDC system events for history indexing.
Arc is an open L1 blockchain launched by Arc Network Services LLC ("Arc LLC") and operated by a permissioned validator set. Arc LLC provides software services only and does not offer regulated financial or advisory services. Arc has not been reviewed or approved by the New York State Department of Financial Services or any other regulatory authority.
The Arc network is provided "as is" and "as available." Use of Arc involves inherent risks associated with blockchain technology, including smart contract vulnerabilities, network disruptions, and the absence of recourse for transaction errors or losses. The ability to transact on Arc depends on the ability to obtain and use USDC to pay gas fees. Neither Arc LLC nor any permissioned validator is responsible for the content, accuracy, legality, or functionality of third-party applications, protocols, or services built on or integrated with Arc. You are solely responsible for features or services you provide to users, including obtaining any necessary licenses or approvals and otherwise complying with applicable laws.
All Arc features may be modified, delayed, or cancelled at any time without notice. Nothing herein constitutes a commitment, warranty, guarantee or legal, regulatory, tax, or investment advice. Coming soon.
USDC is issued by regulated affiliates of Circle. See Circle’s list of regulatory authorizations.