> ## 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.

# How to: Add Arc to Your On/Off-Ramp Platform

> Register Arc as a supported network in your fiat-to-crypto and crypto-to-fiat ramp service, including chain configuration, deposit detection, withdrawal processing, and UI display guidance.

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:

| Parameter                | Value                                        |
| :----------------------- | :------------------------------------------- |
| Network name             | `Arc` (testnet: `Arc Testnet`)               |
| Chain ID                 | `5042002` (testnet)                          |
| RPC (HTTPS)              | `https://rpc.testnet.arc.network`            |
| RPC (WebSocket)          | `wss://rpc.testnet.arc.network`              |
| Block explorer           | `https://testnet.arcscan.app`                |
| Native currency symbol   | `USDC`                                       |
| Native currency decimals | `6`                                          |
| USDC ERC-20 contract     | `0x3600000000000000000000000000000000000000` |
| CCTP domain              | `26`                                         |
| Confirmations required   | `1`                                          |

<Note>
  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.
</Note>

## 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](https://eips.ethereum.org/EIPS/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](/integrate/exchanges/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](/integrate/exchanges/withdrawals).

## Displaying Arc in your UI

Arc's native USDC model affects how you present the network to end users:

| UI element        | Recommendation                                                                 |
| :---------------- | :----------------------------------------------------------------------------- |
| Network name      | Display as **Arc** (or **Arc Testnet** for test environments)                  |
| Asset shown       | USDC only—do not display a separate gas token                                  |
| Gas fee display   | Show estimated fees in USDC (typically fractions of a cent)                    |
| Confirmation time | Display "Instant" or "\< 1 second"—no countdown or block wait indicator needed |
| Network icon      | Use the Arc brand assets (contact the Arc team for logo files)                 |

<Tip>
  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.
</Tip>

## 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.

```typescript theme={null}
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](/integrate/infrastructure/compliance).

<Warning>
  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.
</Warning>

## 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](/integrate/exchanges/cctp-bridging).