Every USDC movement, counted once.
Live streams of everything Arc settles: transfers reconciled across both emitters, blocks with the certificate that finalised them, logs, blocklist changes and CCTP legs. Backfill from any block, then tail live, on one subscription.
StreamTransfers · USDC
sample- 4,210,8800x5d69...c5ce → 0x8099...66f3ERC-206.68
- 4,210,8800xba1b...9d01 → 0x907c...6fa2mint685.87
- 4,210,8800xa573...75a8 → 0x0be8...0f42ERC-201.28
- 4,210,8810x1107...75b2 → 0x6278...2032ERC-20memo456.96
- 4,210,8810xff34...4c71 → 0x78a5...6ec9ERC-209.70
- 4,210,8820x6ae3...51f2 → 0x4c58...707cnative51.11
- 4,210,8830xa207...e7c0 → 0x8d61...c56eERC-206,603.16
- 4,210,8840x6c1e...b64d → 0xad6b...99e0ERC-2066.64
Five streams, each built on something Arc actually emits.
No pending-transaction stream, because Arc refuses one at the protocol level. No reorg handling, because a block is final on commit. Everything below is something you can use today.
Two logs in. One record out.
One ordered stream of every USDC movement: native sends, the native leg of ERC-20 transfers, contract endowments, SELFDESTRUCT moves, mints and burns. Arc reports an ERC-20 transfer twice, once from the EIP-7708 system emitter at 18 decimals and once from the ERC-20 contract at 6. This stream merges the two into a single record, carries the amount in both conventions, and attaches the Memo when one was sent.
{ : "4210887:3:0", "block_number": "4210887", "block_time": "2026-09-16T14:02:11.500Z", "tx_hash": "0x9f2c...a41e", "kind": "ERC20_TRANSFER", "from": "0x7c4e...09b1", "to": "0x2d91...c3f0", : "1250000000000000000000", : "1250.000000", : "INV-2026-0914", : ["system", "erc20"]}The same guarantees on all five.
Backfill and live, one interface
Supply a from_block and omit to_block to replay history then tail indefinitely. No second pipeline, no schema fork between historical and real-time.
Resumable by cursor
Reconnect with the last cursor you received and delivery continues without a gap. A dropped connection never creates an undetectable hole.
Server-side filtering
Addresses, topics, kinds, amounts and Memo presence are evaluated before bytes leave us.
Signed gap report
Every delivered range comes with a signed statement of completeness, so a missing block is provable rather than suspected.
Final on commit
Arc has no reorgs and no confirmation depth. A record we deliver never needs a compensating write, and a webhook is safe at one confirmation.
Ordered by block and log index
Sub-second blocks share timestamps. Every record carries block number and log index so ordering is exact, never inferred from time.
One schema, four ways to receive it.
gRPC and gRPC-Web
Typed, resumable by cursor, with server reflection so grpcurl works with no proto files.
Scale
WebSocket
Standard eth_subscribe for newHeads and logs, so existing tooling subscribes unmodified.
Pro and Scale
Webhooks
Signed deliveries with a replayable log. Safe at one confirmation, because Arc finalises on commit.
10 on Pro, unlimited on Scale
Warehouse sinks
Straight into the systems you already query, with a signed gap report for every range delivered.
Scale
First transfer in under a minute.
Reflection is enabled, so grpcurl lists every service with nothing but your key. Prefer JSON? eth_subscribe works over WebSocket on every plan.
Get an API key
gRPC streaming is on Scale. WebSocket subscriptions and webhooks are on both plans.
Pick a stream and a filter
Addresses, kinds, minimum amount or Memo presence, evaluated before bytes leave us.
Backfill, then tail
Set from_block and leave to_block empty. History replays, then the stream continues live without a gap.
Timed from key creation to the first message on the wire.
# list services (reflection is enabled)grpcurl -H 'x-api-key: YOUR_KEY' grpc.arcrpc.com:443 list # every USDC transfer to one address, with a Memo, from a block onwardgrpcurl -H 'x-api-key: YOUR_KEY' \ -d '{"addresses":["0x2d91...c3f0"],"has_memo":true,"from_block":4210000}' \ grpc.arcrpc.com:443 \ arcrpc.v1.Transfers/StreamTransfersThe rest of the platform
Put every USDC movement behind one endpoint.
Reconciled transfers, finality and compliance state, delivered the way your stack already reads data.
Common questions
An RPC and data provider built for Arc, Circle's Layer-1 for stablecoin settlement. One API key covers JSON-RPC on mainnet 5042 and testnet 5042002, the unified USDC transfer feed, settlement proofs, gRPC streams and warehouse sinks.
Get an API key and put it in the URL: https://rpc.arcrpc.com/v1/{API_KEY} for mainnet, rpc-testnet.arcrpc.com for testnet. Any EVM library works unchanged. For streams, point a gRPC client at grpc.arcrpc.com:443 and send the key as x-api-key metadata.
CCTP v2 legs on domain 26 are in the transfer feed today. Gateway deposits and StableFX FxEscrow settlements are on the roadmap. Both contracts are live on mainnet, but Circle has not documented the FxEscrow events, so we will not ship that index until it is validated against real trades.
An ERC-20 transfer on Arc emits two Transfer logs: one from the EIP-7708 system emitter at 18 decimals, one from the USDC contract at 6. The unified transfer feed merges them into one record. If you index raw logs, filter by emitter.
No, and no provider can. Arc disables pending-transaction visibility at the protocol level and returns -32001, and arc-node hides pending data by default. The upside is that nobody can watch or front-run your transaction before it lands.
No. Arc finalises a block on commit. There are no reorgs, no uncles and no confirmation depth, so a webhook is safe at one confirmation and a delivered record never needs a compensating write.
Kafka, Postgres, ClickHouse and S3 are included on Scale. Snowflake, BigQuery, Redpanda and Kinesis are available on request.