EVM differences

​

Integration guidance

​

USDC as the native gas token

• The ERC-20 view truncates, so it is not exact. The 6-decimal balanceOf drops anything less than 1×10⁻⁶ USDC, so a native balance of 0.0000001 USDC reads as 0 and 100.0000001 USDC reads as 100. A balanceOf of 0 does not imply a native balance of 0.
• A native transfer can revert even with a sufficient balance. On Ethereum, a transfer with sufficient funds always succeeds. On Arc, transfers to the zero address or to or from a blocklisted address fail regardless of balance.
• Don’t treat an ERC-20 allowance as a complete spending control on a contract. USDC.approve bounds transferFrom calls only. If the contract you’re building also exposes functions that send native USDC, those paths move USDC regardless of any allowance. Account for all transfer paths in your access controls, not just the ERC-20 interface.
• Guard rescue functions against sweeping USDC. A recoverToken-style function that sweeps stranded ERC-20 tokens also drains the contract’s native USDC balance, because native USDC and ERC-20 USDC are the same balance. Add an explicit guard to prevent USDC from being swept unintentionally.
• Native USDC and ERC-20 USDC share one underlying balance. Don’t display them as separate rows; always show a single USDC balance.

​

Execution and opcode differences

​

Value transfer rules

• 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.
• Transfers to or from a blocklisted address revert. Check receipt.status === 0 after any USDC transfer to detect a blocklist revert and handle it explicitly.
• Sending native value to a contract is not 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.

​

SELFDESTRUCT

// Within one transaction:
contractA.selfDestruct(payable(b)); // succeeds; emits Transfer(A, B)

// Later in the same transaction, any non-zero-value send to A:
(bool ok, ) = address(contractA).call{value: 1}(""); // reverts on Arc

​

Native USDC Transfer events (EIP-7708)

• Filter on the system emitter, not the ERC-20 contract address. Plain native USDC sends emit no log at 0x3600…0000. Filtering the ERC-20 address alone silently misses them.
• Don’t count logs from both addresses. An ERC-20 transfer() emits a log from both the system emitter and the ERC-20 contract. Counting both inflates balances. Use the system emitter only.

​

Fee market and block behavior

• The base fee is paid to the block beneficiary, not burned. Arc has no EIP-1559 burn. Both the base fee and the priority fee are credited to the block’s beneficiary.
• The next block’s base fee is published in the parent header’s extra_data (an 8-byte big-endian value). Read it there rather than re-deriving it. The fee is computed from an exponentially smoothed view of gas usage and is clamped to bounded minimum and maximum values, so it moves predictably. See Stable fee design and 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 do not 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.

​

Known limitation: draining an empty account