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 documented in full on the EVM differences page:

• Deposit events come from the system emitter: Every native USDC movement emits a Transfer log from the system emitter (0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE), not from the ERC-20 USDC contract (0x3600000000000000000000000000000000000000). Plain native sends emit no log at the ERC-20 contract address. 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 decimals; divide by 10¹² before crediting user balances. 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.
• Empty-account drain: A USDC meta-transaction (transferWithAuthorization) that fully drains a brand-new deposit address reverts. Unlike a regular native send, a meta-transaction does not increment the deposit address’s nonce, so after a full drain the resulting state (zero nonce, zero balance, no code) triggers Arc’s empty-account check and the transaction reverts. Initialize any deposit address with a prior transaction before sweeping it using a meta-transaction. A protocol fix is planned for a future release. See Known limitation: draining an empty account.
• 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