Built for teams that move dollars on Arc.
Arc is a settlement chain, so the people building on it are payments, treasury and the teams who index them. Each setup below names the problem in your terms, the capability that answers it, and the plan it needs.
Know the moment a customer pays, and which invoice it was.
For PSPs and merchants receiving USDC on Arc who need every incoming payment matched, final and provable.
- An ERC-20 transfer arrives as two logs, so naive crediting pays out twice.
- The payment reference lives in a separate Memo event nobody joins for you.
- A customer's payment below the gas floor looks sent and never lands.
Recommended plan: Pro, or Scale for gRPC and sinks
{ "event": "usdc.transfer", "to": "0x2d91...c3f0", "amount_usdc": "1250.000000", "memo": "INV-2026-0914", "final": true}Books that close, with evidence behind every line.
For finance and treasury teams reconciling USDC positions on Arc against internal ledgers and bank statements.
- Balances read with the wrong decimals are off by a factor of a trillion.
- Last week's numbers are archive queries, often billed at a multiple.
- Auditors want proof of settlement, not a screenshot of an explorer.
Recommended plan: Pro
{ "native18": "20000000000000000000000", "erc20_6": "20000000000", "display": "20000.00 USDC", "truncated": false}Follow USDC across chains without stitching events.
For on and off-ramps, bridges and cross-border payment flows moving USDC into and out of Arc over CCTP.
- A burn on one side and a mint on the other arrive as unrelated events.
- Net flow per remote chain means joining two contracts by nonce yourself.
- Releasing funds needs finality, not a guess at confirmation depth.
Recommended plan: Scale
{ "nonce": "881204", "direction": "OUTBOUND", "remote_domain": 0, "amount_usdc": "50000.000000"}Balances users can trust, and sends that don't vanish.
For wallet teams showing USDC balances and submitting transactions for users on Arc.
- A zero ERC-20 balanceOf does not mean an empty account.
- A send priced below 20 Gwei disappears with no error to show the user.
- A transfer to a blocklisted address reverts and still burns gas.
Recommended plan: Pro, pre-flight on Scale
{ "will_revert": true, "reason": "RECIPIENT_BLOCKLISTED", "gas_would_burn": "46213"}Pipelines that don't double count and don't roll back.
For indexers, explorers and analytics platforms building datasets on top of Arc.
- Two USDC emitters at two decimal scales, reported for one transfer.
- Sub-second blocks share timestamps, so ordering by time is ambiguous.
- A silently skipped block is invisible until someone's totals disagree.
Recommended plan: Scale
{ "from_block": 0, "kinds": ["ERC20_TRANSFER", "NATIVE_SEND"], "order": "BLOCK_LOG_INDEX"}Prove settlement to people who check.
For institutions and their compliance teams who need finality they can verify and data residency they can state.
- Deterministic settlement is Arc's promise, but nothing hands you the proof.
- Blocklist state has to be known before a transfer, not after it reverts.
- Data and support tooling must stay in one jurisdiction.
Recommended plan: Scale or Enterprise
$ npx @arcrpc/verify proof.json --validators arc-mainnet.json✓ receipt included in block 4210887✓ block hash signed by 4 of 4 validatorsDon't see your setup?
Tell us what you are building on Arc and we will tell you honestly whether we fit, and which plan.