Ethereum Assumptions That Break on Arc Mainnet

The Arc mainnet was launched on September 16, 2026, with BlackRock, DTCC, Visa, Mastercard, and Intercontinental Exchange as the founding validators. The blockchain was created by Circle whose main product is USDC Stablecoin, using the Reth client and being fully EVM compatible. It was also positioned as a network allowing Solidity contracts to be deployed as-is. This is largely correct, but there are fundamental changes which needed to know before porting Ethereum contracts to Arc.

One of the decision that the USDC stablecoin as the native token of its network. This single change makes Arc Chain differ from Ethereum in few ways. The teams that port their contracts over to Arc, believing Arc is another EVM fork are about to learn the hard way.

Why Arc Looks Familiar But Isn't

Arc uses the Reth client for the execution layer and the Malachite consensus mechanism, which is Tendermint BFT engine achieving finality in less than a second. Solidity, Foundry, Hardhat, viem, and etherjs are all compatible. A team porting their contract should be able to deploy it on Arc testnet without issues.

On Ethereum, ETH is the native currency and every ERC-20 token such as USDC is a separate contract with its own balance mapping. But on Arc, USDC is the native currency. It exists in the balance field of the eoa and contract account just like ETH exists on Ethereum, and it is also accessible via ERC-20 interface from the same contract address it is available on Ethereum.

A single token having two interfaces with different decimals is the root cause of the issues.

Transfers Can Fail Even With Enough Balance

The transaction on the Ethereum network will be successful if the contract has sufficient ETH. In case of the Arc Chain, even the transfer of the native USDC will not succeed if the account sending the currency has more than sufficient amount of USDC (native token) balance, as Arc Chain applies restrictions at the protocol level.

The transfer to zero address will not be possible since USDC burn on Arc is not supported. Transfers to/from blocklisted addresses will also not succeed. Transfer to a contract address which previously did selfdestruct. If the native token (USDC) is transferred to a contract, then it does not mean that the contract receives value as in ERC-20 transfers.

Below is a withdraw function example that is safe on Ethereum but cannot be safely work on Arc:

1function withdraw(address payable to, uint256 amount) external {
2    require(address(this).balance >= amount, "insufficient balance");
3    (bool ok, ) = to.call{value: amount}("");
4    require(ok, "transfer failed");
5}
6

In this withdraw function case, the balance check is passes, but the call may fail. Within a large function, e.g. liquidations or batch payouts, one failed transfer from the blocklist will cause all the transfers to fail and eventually failing the whole transaction.

Use eth_call or transaction tracer before sending to simulate and ensure that each native send and contract calls has its own failure scenario rather than relying on the balance check being the sole point of failure.

SELFDESTRUCT No Longer Behaves Like Ethereum

SELFDESTRUCT on Ethereum sends a contract's ETH balance to a given address and clears the contract's code and storage. If that contract also held ERC-20 USDC, those tokens are untouched, since they live in the token contract's own storage mapping, not the destructed contract.

Arc changes this because USDC is the native balance. Self-destructing a contract on Arc moves USDC, the same way SELFDESTRUCT moves ETH on Ethereum. SELFDESTRUCT paths can also revert under Arc's native token transfer rules, and a non-zero-value call to an address that already self-destructed earlier will reverts on Arc, whereas this would succeed on Ethereum.

1contract LegacyVault {
2    function close(address payable to) external {
3        selfdestruct(to);
4    }
5}
6
7contract Migration {
8    function run(LegacyVault vault, address payable treasury) external {
9        vault.close(treasury);
10        // This second transfer can revert on Arc if treasury
11        // was the beneficiary of a self-destruct earlier in
12        // this same transaction. On Ethereum it would succeed.
13        (bool ok, ) = treasury.call{value: 0.01 ether}("");
14        require(ok, "top up failed");
15    }
16}
17

Any migration script, cleanup job, or factory pattern that touches SELFDESTRUCT needs to be tested against Arc directly, not assumed safe because it worked on Ethereum for years.

One USDC, Two Decimal Systems

USDC on Arc has two deicmal systems, on that is native token has 18 decimals, meanwhile they also have an USDC token interface on standard address as other evm chains have which is 6 decimal point token.

This mix of decimal values can cause serious rounding bugs in the ethereum contracts, if they were used as its is on Arc Chain.

1const DECIMAL_OFFSET = 12n;
2
3function nativeToErc20(nativeAmount: bigint): bigint {
4  return nativeAmount / 10n ** DECIMAL_OFFSET;
5}
6
7function erc20ToNative(erc20Amount: bigint): bigint {
8  return erc20Amount * 10n ** DECIMAL_OFFSET;
9}
10

If you skip this conversion in a LTV calculation, or a oracle price feed, or a share price formula, and the contract can cause serious rounding errors and mispricing everything with twelve order.

CallFrom Breaks a Compliance Assumption

Arc chain added two predeployed contracts, namely Memo and Multicall3From, which delegate calls via a precompile named CallFrom. This precompile manages to preserve the actual caller's address as msg.sender through batched and delegated calls. It is useful, an application could allow one contract to execute actions on behalf of a user while maintaining knowledge of who started this action.

Offchain blocklist monitoring tools that focuses only on the immediate caller, i.e., whatever address appears as the sender of a call trace, may get bypassed by delegating calls via Memo or Multicall3From, as the call still have the original msg.sender as its sender address rather than the sender address of the router.

Arc's official documentation states this, advising the compliance teams to look into the Memo and Multicall3From contract addresses for their monitoring tools in addition to the addresses transactions seem to originate from. If a team built their screening algorithm without this knowledge previously, they may want to take another look now.

Local Testing Won't Save You

Standard Foundry anvil runs a generic EVM, it does not reproduce Arc chain value transfer rules i.e., zero address, blocklist enforcement, SELFDESTRUCT changes, or the CallFrom precompile. A contract can pass a full existing local test suite and still fail the first time, because the local simulator was never testing the behavior that actually run into production

Arc Foundry, Circle's fork with arc-forge, arc-cast, and arc-anvil, reproduces the value transfer rules and precompiles that standard anvil doesn't.

What This Means Before You Ship

Arc chain run solidity code but it doesn't run like Ethereum network. There are many rule changes which are clearly documented by Circle team in their documentation. All of this is easy to miss with the rush of shipping to a new chain which have potential to attract new liquidity, but this rush makes it more dangerous, as protocol would learn the hard way if they don't focus on these required changes. Reading documentation and testing with these new rules is very important, this might lead to many changes in your existing solidity code, which needed to be fixed on day one.

Conclusion

Arc rewards teams that read the documentation and punishes those who assume EVM compatibility means another Ethereum L2. Native USDC, the decimal split, SELFDESTRUCT, and CallFrom are behavioural changes which needed to be studies before shipping. Test against Arc directly, test your assumptions.