Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.arc.io/llms.txt

Use this file to discover all available pages before exploring further.

Add Arc as a supported blockchain for buy and sell orders in your on/off-ramp service (Transak, MoonPay, BVNK, Socure, and others). Arc shares its EVM foundations with networks you already support, but its native USDC model and deterministic finality simplify your integration and improve the end-user experience.

Prerequisites

Before you begin:
  • Familiarity with EVM-based blockchain integrations
  • Access to Arc RPC endpoints for deposit monitoring and transaction broadcasting
  • Existing infrastructure for deposit detection and withdrawal processing on EVM chains

Network configuration

Register Arc with the following parameters in your platform’s chain registry:
ParameterValue
Network nameArc (testnet: Arc Testnet)
Chain ID5042002 (testnet)
RPC (HTTPS)https://rpc.testnet.arc.network
RPC (WebSocket)wss://rpc.testnet.arc.network
Block explorerhttps://testnet.arcscan.app
Native currency symbolUSDC
Native currency decimals6
USDC ERC-20 contract0x3600000000000000000000000000000000000000
CCTP domain26
Confirmations required1
Arc uses USDC as both the native gas token and the primary transfer asset. There is no separate gas token like ETH. Configure your platform with a single asset entry for USDC on Arc.

Deposit detection for buy orders

When a user completes a fiat purchase and you need to detect the resulting onchain USDC deposit, use the same unified Transfer event monitoring pattern used by exchanges. Arc emits a standard ERC-20 Transfer(address,address,uint256) event for every USDC movement—whether sent as a native transfer or through the ERC-20 interface. Key points for ramp deposit detection:
  • Subscribe to blocks via WebSocket (eth_subscribe("newHeads")) or poll via HTTP
  • Filter Transfer events on the USDC contract (0x3600000000000000000000000000000000000000)
  • Credit immediately after 1 confirmation—Arc’s deterministic finality guarantees no reorgs
  • The value field uses 6 decimals (ERC-20 interface)
For complete implementation details including code samples, address generation, and sweep logic, see Detect and process deposits.

Withdrawal processing for sell orders

When a user sells crypto for fiat and you need to send USDC to a settlement address or back to the user, the withdrawal flow is identical to exchange withdrawals:
  1. Validate the destination address (EIP-55 checksum)
  2. Check the blocklist before sending
  3. Build and sign an ERC-20 transfer transaction
  4. Broadcast and confirm (single confirmation = final)
Gas fees are paid in USDC from the same balance—no need to maintain a separate ETH float for gas. For complete implementation details including transaction construction and gas estimation, see Process withdrawals.

Displaying Arc in your UI

Arc’s native USDC model affects how you present the network to end users:
UI elementRecommendation
Network nameDisplay as Arc (or Arc Testnet for test environments)
Asset shownUSDC only—do not display a separate gas token
Gas fee displayShow estimated fees in USDC (typically fractions of a cent)
Confirmation timeDisplay “Instant” or ”< 1 second”—no countdown or block wait indicator needed
Network iconUse the Arc brand assets (contact the Arc team for logo files)
Because there is no separate gas token, you can skip the “ensure you have ETH for gas” warning that other EVM chains require. Users receive USDC and can immediately transfer it without acquiring a second asset.

Settlement timing

Arc provides sub-second deterministic finality. Once a transaction is included in a block, it is final—there are no reorgs, no probabilistic confirmation windows, and no need to wait for additional blocks. For your ramp platform, this means:
  • Buy orders: Credit the user’s crypto balance immediately upon 1 confirmation
  • Sell orders: Mark the withdrawal as complete after the transaction receipt is returned
  • Settlement display: Show instant confirmation to the user rather than a progress bar or block countdown

Address validation

Arc uses standard Ethereum addresses:
  • 20 bytes, 0x-prefixed (42 characters total)
  • EIP-55 mixed-case checksum encoding
  • Compatible with existing Ethereum address validation logic in your platform
No additional address format validation is required beyond what you already implement for EVM chains.
import { getAddress, isAddress } from "viem";

function validateArcAddress(address: string): string {
  if (!isAddress(address)) {
    throw new Error(`Invalid Arc address: ${address}`);
  }
  return getAddress(address); // Returns EIP-55 checksummed
}

Compliance screening

Arc enforces a USDC blocklist at multiple levels:
  • Pre-mempool: Transactions from or to blocklisted addresses are rejected before entering the mempool
  • Runtime: Transfers involving blocklisted addresses revert during execution
Your platform should check addresses against the onchain blocklist before initiating withdrawals. If a destination is blocklisted, the transaction reverts and gas is consumed without transferring funds. For implementation details on blocklist monitoring and event subscription, see Monitor blocklist compliance.
Always verify destination addresses against the blocklist before broadcasting withdrawal transactions. Sending to a blocklisted address wastes gas fees and creates a failed transaction that you must handle in your reconciliation flow.

Crosschain USDC routing

If your platform supports crosschain transfers (for example, a user buys USDC on Ethereum and wants delivery on Arc), use Circle’s Cross-Chain Transfer Protocol (CCTP). Arc’s CCTP domain is 26. For bridging implementation details, see Bridge USDC with CCTP.