Arc-native APIs

USDC transfer feed

One event per movement of value, across both emitters, with the payment reference and the crosschain leg already attached.

Why a raw log stream double counts

An ERC-20 transfer() on Arc emits two logs: a 6 decimal Transfer from 0x3600000000000000000000000000000000000000, and an 18 decimal EIP-7708 Transfer from the system emitter at 0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE. A plain native send emits only the second. Gas deductions emit nothing at all, so gas has to be derived from the receipt.

The feed

http

# backfill
GET /v1/$KEY/usdc/transfers?from=5100000&to=5185952&address=0x2c…

# or subscribe
wss://stream.arcrpc.com/v1/$KEY?feed=usdc.transfers

{
  "block": 5185952,
  "logIndex": 3,
  "txHash": "0x91c4…7fe",
  "from": "0x8f…",
  "to": "0x2c…",
  "native18": "250000000000000000000",
  "display": "250.00 USDC",
  "path": "erc20",
  "memo": "INV-40192",
  "cctp": null,
  "final": true
}

Fields

Field	Meaning
path	erc20, native, mint, burn or selfdestruct. Which mechanism moved the value.
native18	Canonical amount at 18 decimals. display carries the formatted string.
memo	Decoded Memo event from 0x5294E9927c3306DcBaDb03fe70b92e01cCede505, the payment reference for reconciliation.
cctp	The matching DepositForBurn or MessageReceived leg when the movement is crosschain.
final	Always true. Arc finalises on commit, so the feed never retracts an event.

Ordering

Order by (blockNumber, logIndex). Sub-second blocks share a block.timestamp and timestamps are non-decreasing rather than strictly increasing, so sorting by time produces an ambiguous sequence.

Completeness

Every backfill returns a gap report: a signed statement that no block in the range was skipped. On a payments chain, completeness is the product, and a feed that silently drops a block is worse than one that is down.