Arc-native APIs

USDC balances

USDC on Arc has two interfaces over one balance. This endpoint returns both, plus the display string, so the two can never be crossed.

The model

Native USDC carries 18 decimals and is what gas accounting uses. The ERC-20 interface at 0x3600000000000000000000000000000000000000 carries 6. They are the same balance viewed twice, so dividing the native value by 10¹² gives the ERC-20 value.

A zero balanceOf does not mean an empty account

The ERC-20 view truncates sub-USDC fractions. An account holding 0.4 of a cent reads as zero through balanceOf while the native balance is non-zero. Credit from native18, display from display, and never record a user balance from the 6 decimal value.

The call

http

POST /v1/$KEY
{"jsonrpc":"2.0","id":1,"method":"arcrpc_getUsdcBalance",
 "params":["0xa1b2c3…", "latest"]}

{
  "native18":    "1250000000000000000",
  "erc20_6":     "1250000",
  "display":     "1.25 USDC",
  "truncated":   false,
  "blockNumber": 5185952
}

truncated is true when the ERC-20 view is lossy for that account at that block. It is the field to alert on if your ledger reconciles against balanceOf today.

Pool and LTV math

A pool that pairs native USDC against the ERC-20 interface as if they were two assets is meaningless here. Mixing msg.value with balanceOf in the same expression is off by a factor of 10¹², and the error is silent because both numbers look plausible.