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
# backfill a rangeGET https://rpc.arcrpc.com/v1/{API_KEY}/usdc/transfers?address=0x2d91...c3f0&from_block=4200000&to_block=4210887 # or stream it, backfill then live (Scale)grpcurl -H 'x-api-key: {API_KEY}' \ -d '{"addresses":["0x2d91...c3f0"],"from_block":4200000}' \ grpc.arcrpc.com:443 arcrpc.v1.Transfers/StreamTransfers { "transfer_id": "4210887:3:0", "block_number": "4210887", "tx_hash": "0x9f2c...a41e", "kind": "ERC20_TRANSFER", "from": "0x7c4e...09b1", "to": "0x2d91...c3f0", "amount_native": "1250000000000000000000", "amount_usdc": "1250.000000", "memo": "INV-2026-0914", "cctp_leg": null, "final": true}Fields
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.