Every EVM developer knows two constants by heart: ETH has 18 decimals and USDC has 6. On Arc, the second one is wrong — native USDC carries 18 decimals at the protocol level. If you port code that assumes `1e6` equals one dollar, you will be wrong by a factor of a trillion, and this article exists so you find that out here rather than in production.
Why does USDC have 18 decimals on Arc?
On every other chain you've used USDC, it's an ERC-20 contract with 6 decimals — 1000000 units equals $1. On Arc, USDC is the native token: it plays the role ETH plays on Ethereum, paying gas and moving via msg.value rather than a token contract call. The EVM's native-value plumbing was built around 18-decimal arithmetic, and Arc keeps that convention at the protocol level. The result: on Arc, one dollar of native USDC is 1e18 units, not 1e6.
This is a protocol design choice, not a bug, and it buys real consistency: msg.value, gas math, and every tool that assumes 18-decimal native units work on Arc exactly as they do on Ethereum. The cost is a single, sharp migration gotcha for anyone carrying 6-decimal assumptions across.
Where exactly does this break your code?
Hardcoded decimal constants. Any 1e6, 10**6, or 1_000_000 standing in for "one USDC" in native-value context is now off by 10^12. Payment checks like require(msg.value >= 100e6) — intending $100 — will pass with $0.0000000001.
Price and amount conversions. Off-chain services that format native Arc balances by dividing by 10^6 will display numbers a trillion times too large. Divide native balances by 10^18, exactly as you would format ETH.
Cross-chain accounting. If your system tracks USDC across chains, Arc-native USDC and 6-decimal ERC-20 USDC elsewhere are the same asset at different scales. Normalize at the boundary — pick one internal representation and convert on ingest, or the first reconciliation report will be memorable.
Assumptions inherited from libraries. Token lists, SDK defaults, and price-feed adapters frequently pin USDC to 6 decimals by symbol lookup. Audit anything that resolves decimals from a symbol rather than from the chain itself.
The safe pattern is the boring one: never hardcode decimals. Read them from the contract when dealing with ERC-20s, and treat native value on Arc like you treat native value everywhere — 18 decimals, formatted with the same utilities you use for ETH.
Why does my wallet say "ETH"?
The sibling symptom of the same design: because Arc's native token occupies the ETH slot in the EVM, some wallets label the native balance "ETH" out of habit. The balance is USDC — the label is cosmetic. It confuses end users more than developers, and it's worth a line in your app's UI or docs. Setup details and the full explanation live in how to add Arc to MetaMask.
What does this mean for gas?
Gas on Arc is paid in native USDC, so fees are dollar-denominated by construction — testnet fees have averaged around $0.004 per transaction. When you estimate gas programmatically, the values you get back are in 18-decimal USDC units. Format them like wei, price them like dollars. The gas fees guide covers the model end to end.
How should you test for it?
Before shipping to Arc mainnet (September 16, 2026 — parameters MAINNET-TBD until launch), run your full payment path on testnet: chain ID 5042002, faucet USDC from faucet.circle.com. Assert in tests that one dollar of native value equals 1e18, grep your codebase for 1e6 and 10**6 near value math, and check every display path renders a known balance correctly. If you're deploying contracts on Arc, make this a standing item in your review checklist — it's the one Arc-specific bug class that unit tests catch trivially.
FAQ
Is bridged USDC on Arc also 18 decimals?
The 18-decimal behavior described here is the native, protocol-level USDC — the one that pays gas and moves via msg.value. For any token you interact with as a contract, read its decimals() rather than assuming — that habit makes the question moot.
Does this change anything for regular users? Practically nothing. Wallets and apps handle the math; the only visible symptom is the occasional "ETH" mislabel on a native balance. Users sending USDC on Arc just see dollar amounts.
Why didn't Circle just use 6 decimals natively?
The EVM's native-value machinery — msg.value, gas accounting, tooling — assumes 18 decimals. Keeping the convention preserves compatibility with the entire Ethereum stack, which is much of Arc's pitch (is Arc EVM-compatible?).
What's the single most common bug this causes?
Hardcoded 1e6 constants in payment checks. A require(msg.value >= 100e6) intended to gate $100 will accept a trillionth of that.
Where can I verify how a transaction's value was denominated? On the explorer — testnet.arcscan.app shows native values in USDC. The Arcscan guide walks through reading transactions.
Skip the decimal math entirely — mint your token on Arc with Team Finance's audited creator, with fees quoted flat in USDC.Open Team Finance →Sources: docs.arc.network, arc.io. Decimal behavior and network parameters verified against Arc testnet documentation, August 2026.
Last verified: August 2026