DeFi integration - Arc Docs

For DeFi protocols on Arc, use the ERC-20 USDC interface at 0x3600000000000000000000000000000000000000 for all pool accounting, token addresses, and reserve math. Arc’s native USDC has a built-in ERC-20 interface at that address, so no WETH-style adapter contract is needed.

Key differences for DeFi protocols

Three Arc design decisions affect every DeFi porting decision:

Concern	Arc behavior	Impact on DeFi protocols
One balance, two decimal views	Native USDC uses 18 decimals (`msg.value`, `address.balance`); the ERC-20 interface uses 6 decimals (`balanceOf`, pool math). Both views draw from the same underlying balance.	Use 6-decimal ERC-20 values exclusively in pool invariant math. Mixing 18-decimal native values with 6-decimal ERC-20 values breaks constant-product calculations by a factor of 10¹². Do not pair the native interface against the ERC-20 interface as two separate pool tokens; they are the same asset.
No protocol adapter needed	Native USDC has a built-in ERC-20 interface at `0x3600000000000000000000000000000000000000`. No WETH-style adapter is required. See EVM differences for the full list of protocol divergences.	Use the ERC-20 address directly as the pool pair token.
Allowances do not gate native transfers	ERC-20 `approve` and `allowance` control only the `transferFrom` path. Native transfers (`msg.value`, direct sends) bypass the allowance check entirely.	Pool sweep logic that relies on allowance limits does not protect the native balance.

What you need

Each integration guide in this section requires the following:

Requirement	Details
RPC access	`https://rpc.testnet.arc.io`
Chain ID	`5042002` (testnet)
USDC ERC-20 contract	`0x3600000000000000000000000000000000000000`
Existing EVM contract codebase	A Solidity codebase to port to Arc

Integration guides

AMM and pools

Port liquidity pools and AMM contracts to Arc using the ERC-20 USDC address as the canonical pool token.

⌘I