Skip to main content
Arc is an EVM-compatible Layer-1 blockchain. Solidity, Foundry, Hardhat, Viem, ethers.js, and standard Ethereum wallets work without modification, and you can deploy existing contracts unchanged in most cases. Arc targets the Osaka hard fork as its baseline, including features such as EIP-7702 (set-code transactions). Arc also ships select features from Ethereum’s upcoming Amsterdam hard fork ahead of upstream, notably EIP-7708 (standard Transfer logs for native value movements). All comparisons are against Ethereum at the Osaka hard fork, Arc’s baseline. Most differences are transparent to application code, but a few change execution semantics in ways that matter when you port a contract. If you are porting an existing contract, start with the Porting contracts to Arc checklist.
Tools that locally simulate the EVM (such as Foundry’s anvil) run a standard EVM, not Arc’s, and can’t reproduce Arc-specific behavior. Use Arc Foundry’s arc-anvil --network arc instead. See Build and deploy with Arc Foundry.

​
Integration guidance

The following guides translate Arc’s protocol-level differences into practical guidance for specific integration types:

Wallets

Balance display, transaction history, and USDC fee handling.

Exchanges and CEXs

Deposit detection, withdrawal processing, and CCTP-based liquidity management.

On/off-ramp platforms

Single-asset USDC configuration, deposit detection, and instant settlement for fiat ramp providers.

DeFi and protocol operators

USDC pool implementation, decimal handling in pool math, and contract porting.

Indexers and block explorers

Indexing EIP-7708 Transfer events and avoiding double-counting from two emitter addresses.

Relayers and paymasters

USDC-denominated gas infrastructure and decimal precision in fee calculation.

​
USDC as the native gas token

Arc’s native token is USDC, not ETH. USDC on Arc has two interfaces that share one balance: a native interface (18 decimals) and an ERC-20 interface (6 decimals), so no WETH-style wrapper is needed. To display a native value as USDC, divide by 10¹². Don’t use the 6-decimal value when crediting or recording balances; truncation at the 6-decimal boundary records less than was transferred. A zero balanceOf doesn’t mean the native balance is zero. The ERC-20 view truncates sub-USDC fractional amounts, and the USDC remains onchain. For the full model, including the two-interface table, truncation behavior, EURC, and USYC support, see Stablecoin native model. For how balance changes surface as events, see USDC system events.

​
Execution and opcode differences

EIP-7702 set-code transactions, CREATE2 (including EIP-7610 residual-storage behavior), and EIP-2935 historical block hashes all behave as on Ethereum. In particular, the EIP-2935 block-hash-history contract is deployed and functional, unlike the EIP-4788 beacon-roots contract noted in the table. To check an existing contract before deploying it to Arc, see Porting contracts to Arc.

​
Value transfer rules

Because the native token is USDC, value transfers are subject to rules that don’t exist on a standard EVM chain. A native transfer can revert even when the sender has sufficient balance.
  • Transfers to the zero address are forbidden. A value-bearing transfer to 0x0 reverts with "Zero address not allowed"; a zero-value transfer to 0x0 succeeds. (Mint and burn, the only operations that involve 0x0, go through the native-coin precompile.)
  • Burning is forbidden. Self-destructing to yourself with a balance, or transferring value to an account that has already self-destructed, reverts.
  • The blocklist is enforced at runtime. A value transfer to or from a blocklisted address reverts. An included transaction that reverts on a blocklist check still consumes gas.
  • Sending native value to a contract isn’t guaranteed to succeed. A call to a contract that forwards native value can revert for any of the reasons listed here, which breaks a common DeFi assumption.
  • Sending to an address with no code (EXTCODESIZE == 0) succeeds and emits a Transfer log. Sending value to a precompile address reverts.
A liquidity pool that pairs native USDC against the ERC-20 USDC interface (as if they were two assets) is meaningless on Arc, because they are one asset. Don’t mix msg.value with USDC.balanceOf() in pool or LTV math: they use different decimals (18 vs 6) and raw values are off by 10¹².

​
SELFDESTRUCT

SELFDESTRUCT is allowed on Arc, including during contract deployment, and follows EIP-6780 (the account is fully deleted only if it was created in the same transaction). A self-destruct reverts when its value transfer would violate a native value rule: Three behaviors differ from every other EVM chain and deserve attention: 1. Self-destructing a contract that holds USDC moves that USDC out. On Arc a contract’s USDC is its native balance, held in the account, so SELFDESTRUCT transfers it to the beneficiary. On other chains the contract’s ERC-20 USDC balance lives in the token contract and is unaffected by self-destruct. 2. A non-zero-value call to a self-destructed account reverts. On Ethereum, sending value to an address that self-destructed earlier in the same transaction succeeds. On Arc it is treated as a transfer to a destructed account, a forbidden burn, and reverts.
3. A successful self-destruct that moves a balance emits a Transfer log. Unlike Ethereum, the moved native value is recorded as an EIP-7708 Transfer log from the system emitter (18 decimals). Index it like any other native movement; see USDC system events. To check an existing contract’s SELFDESTRUCT usage before deploying to Arc, see Porting contracts to Arc.

​
Native USDC Transfer events (EIP-7708)

On a standard EVM chain, a plain native send emits no log. Arc’s EIP-7708 implementation emits a standard ERC-20 Transfer log from a system address for native sends, contract endowments, self-destruct transfers, and precompile-backed operations. Gas deductions don’t emit a log; derive gas cost from the transaction receipt. For emitter addresses, the log format, and indexing guidance, see USDC system events.

​
Fee market and block behavior

Arc’s fee market and block behavior differ from Ethereum in ways that affect cost estimation, event ordering, and confirmation logic:
  • The base fee is paid to the block beneficiary, not burned. See Stable fee design.
  • The next block’s base fee is in the parent header’s extra_data. See Gas and fees.
  • The minimum base fee is 20 Gwei. Transactions with maxFeePerGas lower than 20 Gwei are silently dropped by the mempool. They produce no error receipt and never appear in a block. Set maxFeePerGas to at least 20 Gwei before submitting any transaction to Arc.
  • Block timestamps are non-decreasing, not strictly increasing. Timestamps come from the proposer’s wall clock at one-second granularity, so sub-second blocks may share a timestamp. Use the block number for ordering, and don’t assume block.timestamp strictly increases between blocks.
  • Finality is deterministic and instant. Transactions finalize on inclusion; offchain systems can act after a single confirmation. See Deterministic finality.