bug: MetaMask shows "Network fee: Unavailable" for all Arc Testnet transactions — USDC-as-native-gas breaks wallet fee estimation

[osr21]

Summary

Every transaction on Arc Testnet shows "Network fee ⚠ Unavailable" in MetaMask (and likely other EIP-1193 wallets). The "Review alert" warning is surfaced, which adds friction and discourages users from completing the transaction.

The root cause: Arc Testnet uses USDC as the native gas token, not ETH. MetaMask's fee estimation calls eth_gasPrice / eth_maxPriorityFeePerGas and can compute a wei value, but it cannot display a human-readable USD/token amount because it doesn't know the exchange rate or symbol for USDC-as-gas. This causes the fee display to fall back to "Unavailable".

---

Reproduction

1. Add Arc Testnet to MetaMask (Chain ID 5042002, native currency USDC)
2. Open any DApp that calls eth_sendTransaction or wallet_sendCalls on Arc
3. Observe: MetaMask fee row shows "⚠ Unavailable" with no USDC amount and a "Review alert" badge

---

Root Cause

MetaMask assumes the native gas token is ETH (or a token with a known CoinGecko price feed). When the native currency is USDC:

• eth_gasPrice returns a valid wei value
• MetaMask cannot map that to a USD display amount or even a USDC amount without explicit metadata
• The "Unavailable" fallback is triggered

This is compounded when DApps omit the gas field from transaction objects — MetaMask then attempts eth_estimateGas internally and may fail or return an unreliable value, making the situation worse.

---

Workaround (DApp-side fix)

Explicitly include a gas limit in every transaction object. MetaMask can then compute fee = gas × gasPrice and display the raw USDC gas cost even without price-feed lookup:

// viem writeContract — add gas explicitly for all Arc Testnet calls
await walletClient.writeContract({
  address: CONTRACT_ADDRESSES.CONDITIONAL_ESCROW,
  abi: CONDITIONAL_ESCROW_ABI,
  functionName: "createEscrow",
  args: [...],
  chain: ARC_TESTNET,
  gas: 350_000n,  // ← explicit gas limit clears the "Unavailable" warning
});

Recommended gas limits per operation type:

Operation	Recommended gas
ERC-20 approve	80_000
Escrow createEscrow / Vesting createSchedule	350_000
Escrow release / Vesting claim	120_000
CCTP initiateConditionalTransfer	400_000

We applied this fix in osr21/arc-stablecoin-dapp across all contract-calling pages and the "Unavailable" warning no longer appears.

---

Suggested Platform Fix

The cleanest long-term solution is for the Arc node / wallet provider metadata to include USDC's price feed in the chain's EIP-3085 wallet_addEthereumChain response, so that wallets can price the gas token correctly:

{
  "chainId": "0x4CE052",
  "chainName": "Arc Testnet",
  "nativeCurrency": { "name": "USDC", "symbol": "USDC", "decimals": 6 },
  "rpcUrls": ["https://rpc.testnet.arc.network"],
  "blockExplorerUrls": ["https://testnet.arcscan.app"],
  "iconUrls": [...],
  "nativeCurrencyPriceFeedId": "usd-coin"  // ← non-standard but some wallets support this
}

Alternatively, Circle could publish an official wallet_addEthereumChain snippet that includes any wallet-specific metadata needed for proper USDC fee display.

---

References

• Fix applied in: osr21/arc-stablecoin-dapp — escrow.tsx, vesting.tsx, crosschain.tsx
• Related: Arc Testnet uses USDC (0x3600000000000000000000000000000000000000) as native gas token

[osr21]

Workaround confirmed — explicit gas field clears "Unavailable" in MetaMask

We hit the same issue building osr21/arc-stablecoin-dapp — every transaction showed "Network fee ⚠ Unavailable" in MetaMask with no USDC amount displayed.

The fix described in the issue body works: pass an explicit gas limit on every viem writeContract call. MetaMask can then compute fee = gas × gasPrice and display a raw USDC value even without a price-feed lookup, which clears both the "Unavailable" label and the "Review alert" badge.

await walletClient.writeContract({
  address: CONTRACT_ADDRESSES.CONDITIONAL_ESCROW,
  abi: CONDITIONAL_ESCROW_ABI,
  functionName: "createEscrow",
  args: [...],
  chain: arcTestnet,
  gas: 350_000n,  // explicit limit — clears MetaMask "Unavailable" warning
});

We applied this across every contract-calling page (escrow, vesting, cross-chain) and X402 Pay, and "Unavailable" is gone in all flows.

One nuance worth noting: Arc Testnet receipts do not auto-throw on revert — waitForTransactionReceipt returns normally regardless of status. When using explicit gas limits you also need an explicit status check on every receipt, otherwise a reverted-due-to-out-of-gas tx will silently appear to succeed:

const receipt = await publicClient.waitForTransactionReceipt({ hash });
if (receipt.status === "reverted") {
  throw new Error(`Tx reverted — hash: ${hash}, gasUsed: ${receipt.gasUsed}`);
}

---

One additional observation: the eth_signTypedData_v4 path for EIP-3009 TransferWithAuthorization (relevant for x402/gasless flows) has a separate MetaMask quirk worth documenting — see the comment on PR #190 for details on the invalid_exact_evm_signature error and fix.

[chihkaiyu]

Thanks for the detailed write-up and the workaround. After testing this on Arc Testnet, I think the root cause is different from what's described here — it's not USDC-as-native-gas, and it's not really about the gas field. The real variable is whether the transaction reverts.

How to reproduce

You can confirm this with MetaMask and any way of issuing a raw eth_sendTransaction. Send the same Arc USDC call (to: 0x3600000000000000000000000000000000000000, value: 0x0) in four variants and compare the MetaMask fee row:

1. Reverts, no gas — transferFrom(0x0000…0000, <your address>, 1000000). The zero address has no allowance, so this reverts. Omit the gas field.
2. Reverts, explicit gas — same call, but add gas: 0x186a0.
3. Succeeds, no gas — transfer(<recipient>, 1000000) from an account holding ≥1 USDC. Omit gas.
4. Succeeds, explicit gas — same successful call, but add gas: 0x186a0.

Open each in MetaMask (don't submit) and look at the Network fee row.

Results

Case	gas field	Fee display
Succeeds	omitted	✅ shows fee (in USDC)
Succeeds	explicit	✅ shows fee
Reverts	omitted	⚠️ "Unavailable" + Review alert
Reverts	explicit	✅ shows a fee — but the tx still reverts on-chain

Why gas makes the difference

The fee MetaMask shows is gas limit × gasPrice. gasPrice is always available, so the only missing piece is the gas limit:

• Without a gas field, MetaMask has to derive the limit itself by calling eth_estimateGas, which simulates the transaction. For a reverting call that simulation fails, so MetaMask gets no limit, cannot compute gas × gasPrice, and falls back to "Unavailable" + the Review alert. For a succeeding call the simulation returns a limit, so the fee renders normally — which is why the two successful cases work fine with no gas field.
• With an explicit gas field, MetaMask already has the limit and skips eth_estimateGas entirely. It can always compute gas × gasPrice, so the fee renders in every case — including the reverting one. But nothing about the transaction actually changed: it still reverts when mined. The explicit gas didn't fix a fee bug, it just bypassed the simulation that was failing.

So "Unavailable" is not a pricing problem and not a USDC-as-native-gas problem — it's MetaMask correctly signaling that eth_estimateGas reverted, i.e. the call would fail. Adding a hardcoded gas suppresses that warning rather than fixing the underlying revert, which is exactly the "silently appears to succeed" behavior noted in the comment above.

[osr21]

Thanks for the detailed experiment — the mechanism you've described is correct, and it changes how we should frame this.

What your analysis nails

The four-case table is clear: MetaMask shows "Unavailable" specifically when eth_estimateGas simulation fails, because that's how it derives the gas limit needed to compute gas × gasPrice. Passing an explicit gas field skips that simulation entirely, so the fee always renders — even if the tx still reverts on-chain. That's a more precise root cause than "USDC-as-native-gas," and the issue title should probably be updated to reflect it.

The silent-revert risk you called out is also real. Our workaround comment should have been clearer: explicit gas is not a correctness fix, and without a receipt.status check a reverting tx will appear to succeed.

The Arc-specific piece your test doesn't cover

Your four cases test whether MetaMask can estimate gas correctly — and on a chain with a working RPC it can, for valid calls. But the original report was that all Arc Testnet transactions showed "Unavailable," including transfers from funded accounts that ultimately succeeded on-chain.

If Arc Testnet's eth_estimateGas returns an error (or an unreliable value) for valid calls — not because the transaction would revert, but because the RPC node itself is unreliable for estimation — the "Unavailable" will still appear for non-reverting transactions. That fits your framework (MetaMask can't get a gas limit → shows "Unavailable") but is a distinct bug: the simulation failure is a node artifact, not a signal that the call would revert.

We didn't test this carefully enough to rule it out. The specific question for Arc node maintainers is: does eth_estimateGas return a correct result on Arc Testnet for a simple valid transfer from a funded account? If it does, then all the "Unavailable" we saw were masking real reverts (and we should be fixing the calls, not the gas). If it doesn't, there's a separate RPC reliability issue on top of what your test demonstrates.

Practical takeaway for DApp developers (combined)

Situation	Right action
eth_estimateGas fails because the call reverts	Fix the call — don't suppress the warning with hardcoded gas
eth_estimateGas fails due to Arc RPC unreliability on valid calls	Explicit gas is a valid workaround; still check receipt.status
Any Arc Testnet tx	Always check receipt.status === "reverted" on every receipt — receipts don't throw on revert

We'll update the issue body to correct the root cause framing. If anyone can confirm or deny whether eth_estimateGas is reliable on Arc Testnet for valid calls, that would close the open question.