Arc is not Ethereum
with a new chain ID.
Three behaviours break an integration that assumes Ethereum defaults, and each one fails quietly: a balance off by 10^12, a transaction that never existed, a ledger that counts every transfer twice. We checked 30 Arc providers. These are the calls that prove each problem, and what we return instead.
One balance, two interfaces, a factor of a trillion.
Native USDC has 18 decimals. The ERC-20 interface at 0x3600...0000 has 6. They are the same balance. At least one provider's published Arc reference states the native token has 6 decimals, which is exactly the mistake this example makes.
How much USDC does this account hold? One balance, two interfaces: eth_getBalance returns it at 18 decimals, the ERC-20 view at 6. Format the native number with the ERC-20 decimals and the answer is wrong by construction.
eth_getBalance(0x7c4e...09b1, 4,210,887)
/ 10^6 ← 6 decimals, per one Arc reference20,000,000,000,000,000.00 USDC
Treats native USDC as 6 decimals. The raw balance is right; the scale is not.
arcrpc_getUsdcBalance(0x7c4e...09b1, 4,210,887)
native18 / 10^18
erc20_6 / 10^620,000.00 USDC
Both representations returned together, already scaled, with a flag when the ERC-20 view truncates.
Below 20 Gwei, a transaction simply never existed.
Arc’s mempool silently drops any transaction whose maxFeePerGas is below the base fee floor. No receipt, no error, never mined. A wallet or payment service that forwards it as-is reports success for a payment that did not happen.
We reject it at the endpoint with a message that says why, so the failure happens where your code can see it.
# what Arc does with maxFeePerGas = 12 gwei$ cast send --gas-price 12gwei ...0x6e1f...b40c # a hash comes back, so it looks sent $ cast receipt 0x6e1f...b40cError: transaction not found # and it never will be# the same transaction through ArcRPC$ cast send --rpc-url https://rpc.arcrpc.com/v1/$KEY --gas-price 12gwei ...Error: (code: -32000, message: maxFeePerGas 12 gwei is below the Arcbase fee floor of 20 gwei; the network would drop this transactionwithout a receipt)Every ERC-20 transfer is reported twice.
Arc emits a Transfer from the EIP-7708 system emitter at 18 decimals and another from the USDC contract at 6. Index both without filtering by emitter and every ERC-20 transfer is booked twice. Index only the contract and every native send is missed. Both errors produce a number that looks plausible.
The transfer feed reconciles both into one record per movement.
# eth_getLogs for one ERC-20 transfer(), no address filter[ { "address": "0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE", # system, 18 dec "logIndex": 6, "value": "1250000000000000000000" }, { "address": "0x3600000000000000000000000000000000000000", # USDC, 6 dec "logIndex": 7, "value": "1250000000" }]# sum both and 1,250 USDC is booked as 1,250,000,000,001,250Everything else that breaks a default EVM assumption.
The mempool is closed
eth_newPendingTransactionFilter and newPendingTransactions subscriptions return -32001. eth_getBlockByNumber("pending") fails too: Circle's public mainnet endpoint answers -32014, other nodes return null. arc-node hides pending data by default since v0.7.0, so there is no public mempool to watch or front-run.
Finality is deterministic
A block is either absent or irreversible. There are no reorgs, no confirmation depth and no uncles, so an indexer needs no rollback path and a webhook is safe at one confirmation. The finalized tag returns the latest block.
The base fee is not burned, and the next one is in the header
Base fee and tip both go to the block's miner address. The next block's base fee is published as 8 big-endian bytes in the parent header's extraData, so a fee quote needs no estimate. The floor is 20 Gwei and the ceiling 20,000 Gwei.
tx.from is not always the payer
Memo and Multicall3From keep the original caller as msg.sender through the CallFrom precompile, and relayed transfers carry the real sender only in the Transfer log. Attribute USDC movement from the log, not from the transaction.
History starts about a minute behind the tip
At half-second blocks the usual 127-block archive boundary is roughly sixty seconds old, so almost every historical read is an archive read.
Timestamps are non-decreasing, not increasing
Sub-second blocks share a block.timestamp. The ordering key is block number and log index, never the timestamp.
A transfer can revert with a full balance
Transfers to the zero address, burns, transfers to a self-destructed account or a precompile, and any transfer touching a blocklisted address all revert. The revert still consumes gas.
Said plainly, so the rest can be trusted.
Publishing what is not possible is the fastest way to show the rest of this page was written by someone who read the chain's documentation.
Check our numbers before you trust them.
Every claim on this page is reproducible against Arc's own documentation and a public endpoint. The method matrix lists what every call actually returns.