Skip to main content
Arc is fully EVM-compatible—same key derivation, same signing curve (secp256k1), same transaction formats. If your custody platform supports custom EVM chains, you can add Arc without code changes. This guide covers what’s different and what to configure.
Arc uses USDC as its native gas token. There is no separate ETH-like token to fund for gas. A single USDC balance covers both transfer value and transaction fees.

What custody engineers need to know

Arc behaves like any EVM chain with three key differences: Everything else is standard:
  • Address derivation: BIP-44 path m/44'/60'/0'/0/x
  • Signing algorithm: secp256k1 (identical to Ethereum)
  • Transaction types: Legacy (type 0) and EIP-1559 (type 2) both supported
  • Smart contracts: Solidity, same EVM opcodes
  • Multi-sig: Standard Ethereum multi-sig contracts (including SAFE) work without modification

Network configuration

Use these parameters when registering Arc as a custom EVM chain:
The native currency uses 18 decimals internally (like ETH uses Wei) but represents USDC which has 6 display decimals. Configure your balance display to show 6 decimal places to users while using 18 decimals for transaction construction.

USDC ERC-20 contract

For ERC-20 interactions (approvals, transferFrom, allowance checks), the USDC contract is deployed at a precompile address:
Native USDC transfers (simple sends) and ERC-20 transfer() calls both move the same underlying balance. There is no wrapped/unwrapped distinction.

Register Arc in your custody platform

Most custody platforms provide a “custom EVM chain” or “custom network” configuration flow. The following sections provide platform-specific guidance and a generic template.

Provider configuration reference

Generic custom EVM chain template

Use this configuration when your platform has a general-purpose “add custom EVM chain” form:

Transaction signing

Arc uses standard Ethereum transaction signing. No custom signing schemes or transaction types are required.

Key signing details

  • Curve: secp256k1 (same as Ethereum)
  • Address derivation: Keccak-256 hash of public key, last 20 bytes
  • HD path: m/44'/60'/0'/0/x (coin type 60, same as Ethereum)
  • Transaction serialization: RLP encoding, identical to Ethereum
  • Chain ID in signature: Required (EIP-155). Use 5042002 for testnet.

MPC and multi-sig considerations

MPC wallets

MPC (multi-party computation) signing works identically to Ethereum:
  • Key shares are generated for the secp256k1 curve
  • Threshold signing produces a standard ECDSA signature
  • The resulting address is a standard Ethereum address
  • No Arc-specific MPC protocol modifications are needed

Multi-sig wallets (SAFE)

SAFE multi-sig contracts deploy and operate on Arc without modification:
  • Same factory contract addresses
  • Same proxy pattern
  • Same signature verification logic
  • Transaction confirmation follows the same flow—but only 1 onchain confirmation is needed due to deterministic finality

Operational differences

Balance management

Because USDC is both the transfer currency and the gas token, custody operations are simpler:
  • No gas station network: You don’t need a separate process to fund addresses with gas tokens.
  • Unified balance: A single eth_getBalance call returns the USDC balance available for both transfers and fees.
  • Threshold alerts: Set a single low-balance threshold instead of monitoring separate gas and transfer balances.

Finality and confirmation tracking

Arc provides deterministic finality. Once a transaction is included in a block, it is final—no reorgs, no uncle blocks, no chain reorganizations. This means:
  • Set confirmation requirements to 1 in your custody platform
  • Remove pending-state tracking logic (no need to wait for additional confirmations)
  • Transaction receipts are immediately authoritative
  • No need to handle “dropped and replaced” scenarios
If your platform requires a minimum confirmation count greater than 1, setting it to 1 is still safe on Arc. There is no security benefit to waiting for additional blocks.

Blocklist enforcement

Arc enforces a protocol-level blocklist. Transactions from blocklisted sender addresses are rejected at the pre-mempool stage—they never appear onchain. For custody operations:
  • Check the blocklist before attempting to sign and broadcast
  • If a send fails with a blocklist rejection, it was not broadcast—no gas is consumed
  • Monitor compliance status of custody-managed addresses

Fee estimation

Gas estimation works identically to Ethereum:
The minimum base fee is 20 Gwei. Set your gas price floor accordingly to avoid underpriced transaction rejections.

Verification and testing

After configuring Arc in your custody platform:
  1. Generate a test address using your standard HD derivation path and verify it matches what you’d get on Ethereum for the same seed.
  2. Fund the address with testnet USDC through the Arc faucet.
  3. Send a transaction and confirm it appears on the block explorer within seconds.
  4. Verify the receipt shows status: 1 (success) with a single block confirmation.
  5. Test balance display to ensure your platform shows the correct USDC amount (6 decimal places).
The same address and private key work on both Arc and Ethereum. If your platform already derives Ethereum addresses for a given seed, those same addresses are valid on Arc.