Skip to main content
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 Transfer event monitoring pattern used by exchanges. Every native USDC movement emits a standard ERC-20 Transfer(address,address,uint256) event from the system emitter 0xffff…fffe (Arc’s EIP-7708 implementation), covering native sends and the native leg of ERC-20 transfers. Key points for ramp deposit detection:
  • Subscribe to blocks via WebSocket (eth_subscribe("newHeads")) or poll via HTTP
  • Filter Transfer events on the native USDC system emitter (0xfffffffffffffffffffffffffffffffffffffffe)—not the ERC-20 contract (0x3600…0000), which misses plain native sends
  • Credit immediately after 1 confirmation—Arc’s deterministic finality guarantees no reorgs
  • The value field uses 18 decimals (native); divide by 10^12 for 6-decimal USDC
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 a native USDC transfer (the recommended path—cheaper gas and universally receivable)
  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.