docs: Gas and fees example sends 1e-12 USDC instead of 1 USDC (native value uses 6 decimals)

[bilalayvaz]

Where

https://docs.arc.io/arc/references/gas-and-fees
Section: "Submitting transactions" → "Set an adequate max fee", first code block.

Problem

The example uses:

value: ethers.parseUnits("1", 6), // 1 USDC via native send

value in a native send is denominated in 18-decimal native USDC units.
parseUnits("1", 6) returns 1,000,000, which is 0.000000000001 USDC,
not 1 USDC as the comment says.

The transaction succeeds without any error, so anyone copying this
snippet will silently send a negligible amount.

Verified on Arc Mainnet

Chain ID 5042, block 22000964. Reading the same account at the same block:

eth_getBalance (native)   : 455068172605872
USDC.balanceOf (ERC-20)   : 455
USDC.decimals()           : 6
floor(native / 1e12)      : 455  (matches balanceOf)
eth_gasPrice              : 20.78 gwei

Native value uses 18 decimals and the ERC-20 interface uses 6 on
mainnet as well, so the example is wrong on mainnet, not only on testnet.

Suggested fix

Either use 18 decimals for the native send:

value: ethers.parseUnits("1", 18), // 1 USDC via native send

or switch the example to an ERC-20 transfer on
0x3600000000000000000000000000000000000000 with 6 decimals, which is
consistent with the docs' own recommendation to use the ERC-20
interface for application-level transfers.

Also

The note at the bottom of the page still says the parameters
"reflect the current Arc Testnet configuration" and "may change before
mainnet launch". Now that mainnet is live, it would help to state
whether the listed values (20 Gwei floor, 20,000 Gwei ceiling,
30M gas/block) apply to mainnet.

Related

• USDC decimal ambiguity: 18 decimals as native gas token vs 6 decimals as ERC-20 — undocumented, causes silent value bugs #91 (USDC 18 vs 6 decimal ambiguity)
• docs: add MetaMask integration guide with USDC token setup #100 (balance-side documentation)

[kutluhaneth46]

Requesting assignment for the gas-and-fees docs fix (native send should use 18 decimals for 1 USDC). Happy to take this if docs live in-repo or point me at the docs source.

[AlphAiOffical]

A regression test with two explicit paths could make this harder to reintroduce: a native send of 1 USDC should assert the recipient's native balance increases by the expected 18-decimal amount, while an ERC-20 transfer should assert balanceOf increases by the expected 6-decimal amount. The docs example could label which interface it uses and include a post-send balance assertion.

[kutluhaneth46]

Thanks @AlphAiOffical — agreed a two-path regression (native 18-decimal send vs ERC-20 6-decimal transfer) would lock this in well. Happy to include labeled examples + a post-send balance assertion once assigned.

@ZhiyuCircle requesting assignment for the docs fix (parseUnits("1", 6) → 18 decimals for native send, or switch the example to the ERC-20 path). Quick note: the snippet lives on https://docs.arc.io/arc/references/gas-and-fees and I don't see that page under this repo's docs/ tree — if the source is in another Circle docs repo, please point me at it (or assign here if the fix lands via this tracker).