You are here. See how this question connects to other ideas.
Select a node to open its page · Expand to read within the map
One question
Porting to Circle Arc: what EVM compatibility leaves to check
Check value semantics before reusing Ethereum code.
Circle Arc supports familiar Solidity and Ethereum tooling, but compatibility does not mean every Ethereum assumption carries over unchanged. Arc's official differences guide is the starting point for a port.
One balance, two interfaces
The native interface reads the account balance at protocol level; ERC-20 is a common token-contract interface for balance queries. Arc exposes USDC through both, using 18 and 6 decimal places respectively. For example, 1 USDC is 10¹⁸ native units or 10⁶ ERC-20 units. Normalize units before comparing; the native reading also preserves amounts below the ERC-20 precision. They refer to one balance, so adding them as separate assets would double count. Code that assumes native value always means ETH also needs review.
The documented differences include native-value transfer restrictions and opcode behavior. A standard local EVM simulation alone cannot establish that Arc-specific behavior is correct.
A useful porting review follows a concrete operation: how it reads balances, moves native value, handles a revert, and records the result. Test those assumptions on the intended network before calling a port complete.
An ARC Blocklet operates at the application layer; contract and network integration remain separate engineering work. Reusing the word ARC is not an integration test.
Documentation checked September 29, 2026.
Sources and further reading
Check your understanding
Should native and ERC-20 USDC readings be added together?
No. On Arc they expose the same balance through different interfaces.