Exchange Integration

Arc is an EVM-compatible Layer 1 blockchain where USDC is the native gas token. For exchanges, this means simpler hot wallet operations, instant settlement finality, and a single asset to manage for both trading and transaction fees.

​

Key differences for exchanges

Three Arc design decisions affect every exchange integration:

​

Operational areas

Exchange integration covers three workflows:

• Deposits—Subscribe to new blocks and detect incoming USDC transfers. Deterministic finality means a single confirmation is final.
• Withdrawals—Build, sign, and broadcast USDC transfers from your hot wallet. Gas is paid in USDC from the same balance.
• Liquidity (CCTP bridging)—Move USDC between Arc and other blockchains using Cross-Chain Transfer Protocol to manage treasury and liquidity pools.

​

Arc behaviors relevant to this integration

The following Arc behaviors can affect exchange operations. Each is covered in EVM differences:

• Filter deposit events on the system emitter, not the ERC-20 contract address: Every native USDC movement emits a Transfer log from the system emitter (0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE). Plain native sends emit no log at the ERC-20 contract address (0x3600000000000000000000000000000000000000); filtering that address alone silently misses them. An ERC-20 transfer() emits logs at both addresses; count only the system emitter to avoid double-crediting. System emitter log values are in 18-decimal precision. See Detect deposits.
• balanceOf zero does not mean no USDC: balanceOf() returns 0 for amounts under 1×10⁻⁶ USDC (6-decimal minimum). Accounts hold sub-minimum dust spendable as gas. See USDC as the native gas token.
• Blocklist enforcement: Transfers to or from a blocklisted address revert at runtime. The transaction is included in the block and consumes gas, but state changes roll back. Check the destination address against isBlacklisted() on the USDC contract before submitting withdrawals. See Process withdrawals.
• Deposit attribution in EIP-3009 relayer flows: For deposits submitted by an EIP-3009 (transferWithAuthorization) relayer, attributing from tx.from credits the relayer’s address, not the depositor’s. Use the from field in the system emitter’s Transfer event for accurate attribution. See Detect deposits.
• Block timestamps are non-decreasing, not strictly increasing: Sub-second blocks can share the same timestamp. Use block number, not block.timestamp, for deposit sequencing and event ordering. See Fee market and block behavior.
• Minimum base fee is 20 Gwei: Transactions with maxFeePerGas under 20 Gwei are rejected by the mempool. This applies to all hot wallet operations, including withdrawals and deposit sweeps. See Process withdrawals.
• Transaction attribution with Memo contracts: For transfers routed through the Memo contract (0x5294E9927c3306DcBaDb03fe70b92e01cCede505) or Multicall3From (0x522fAf9A91c41c443c66765030741e4AaCe147D0), the CallFrom precompile preserves the original sender, so tx.from and the Transfer event’s from are still your EOA wallet. For compliance attribution, read from the Transfer logs and the Memo event’s indexed sender. See Process withdrawals.

​

What you need

Before you start, confirm you have the following:

​

Integration guides