If you sent USDC through Circle's Cross-Chain Transfer Protocol and your funds have not landed yet, you are not stuck. A CCTP transfer is two separate onchain events plus an attestation step in between. Once you know where to look, you can trace every burn, every signature, and every mint to the exact block. This guide walks through the explorers and tools that make that visible.
​

CCTP moves USDC by burning it on the source chain and minting fresh USDC on the destination. There is no wrapped token, no liquidity pool, and no bridge custodian. Circle's attestation service signs the burn message, and the destination contract mints once that signature is presented.
​

That means a single transfer produces three artifacts you can verify:

Any CCTP explorer is really just a UI over those three artifacts.
​

CCTPScan (cctpscan.xyz) is the explorer most users hit first because it surfaces all three artifacts in a single view. Paste a source transaction hash, a destination hash, or the message hash itself, and it returns the burn block, the attestation status, the mint block, the source and destination domains, and the recipient address.
​

What CCTPScan is good at: showing whether your attestation is ready, ready-but-unclaimed, or still pending. Pending attestations on V1 take roughly 13 to 19 minutes on Ethereum mainnet because Circle waits for hard finality. On V2 Fast Transfers, attestations resolve in seconds because Circle accepts a soft-finality assumption and charges a small fee for the speed.
​

Circle ships its own developer-facing tooling at developers.circle.com. The main entry point is the iris attestation API: https://iris-api.circle.com/v1/attestations/{messageHash} on mainnet, or iris-api-sandbox.circle.com on testnet. The response includes a status field (pending_confirmations or complete) and, when complete, the 65-byte attestation signature you submit to the destination contract.
​

For most users this is invisible because wallets and apps poll iris under the hood. But if you are debugging a stuck transfer, hitting iris directly is the fastest way to confirm whether Circle has signed your message. If iris returns complete and your USDC still has not arrived, the problem is on the destination side: nobody has submitted the mint transaction.
​

For anyone who wants ground truth, the source and destination block explorers are still the canonical record. On Ethereum, the TokenMessenger lives at 0xBd3fa81B58Ba92a82136038B25aDec7066af3155. On Base, it is 0x1682Ae6375C4E4A97e4B583BC394c861A46D8962. On Arbitrum, Optimism, Polygon PoS, Avalanche, Solana, and Noble, each chain has its own pair of TokenMessenger and MessageTransmitter addresses, all documented at developers.circle.com.
​

To trace a transfer manually:

It is more work than CCTPScan, but it is the only method that does not depend on a third-party indexer.
​

Each tool answers a slightly different question. Use this table to pick the right one.

In practice: start with CCTPScan, fall back to iris if CCTPScan looks stale, and drop into Etherscan when you need to prove a specific event fired.
​

CCTP V2 went live on Ethereum, Avalanche, Base, and Arbitrum in March 2025 and added two features that change how you read transfers in an explorer.
​

Fast Transfers replace the 13-to-19-minute wait with a sub-30-second path by letting Circle attest before hard finality. The trade-off is a small fee paid in USDC. In explorers, Fast Transfers show up with a finalityThresholdExecuted value of 1000 rather than 2000, which is the easiest visual cue.
​

Hooks let a CCTP transfer trigger an arbitrary call on the destination chain in the same transaction as the mint. Instead of mint-then-swap, you mint-and-swap atomically. In an explorer, hooks appear as a single destination transaction whose internal calls include the mint plus your downstream action. CCTPScan decodes the hook call data; raw Etherscan shows it as a generic internal transaction you have to decode yourself.
​

Most "stuck" CCTP transfers fall into three buckets, and each has a different fix.
​

Attestation pending for over 30 minutes. Hit the iris API directly. If iris still shows pending_confirmations, the source chain has not finalized. This can happen during Ethereum reorgs or when a chain pauses block production. Wait. If iris shows complete but no mint has occurred, the receiving wallet or app simply has not submitted the destination transaction. Most wallets retry automatically; if yours does not, you can call receiveMessage on the destination MessageTransmitter yourself with the message and attestation. Circle's docs show the exact call.
​

Wrong recipient address. CCTP encodes the recipient at burn time. If you sent to the wrong address, the mint will go to that wrong address and the funds are gone, the same as any onchain transfer. There is no Circle support button that reverses this. Always double-check the recipient before signing the source transaction.
​

Wrong destination domain. Each chain has a numeric domain ID in CCTP (Ethereum is 0, Avalanche is 1, Optimism is 2, Arbitrum is 3, Base is 6, Polygon PoS is 7, Solana is 5, Noble is 4). If a frontend bug sent your transfer to the wrong domain, your USDC mints on the wrong chain. The funds are recoverable since you control the recipient address on every CCTP-supported chain, but you will need to do another CCTP transfer back.
​

Every CCTP transfer has a unique 32-byte message hash. It is the keccak256 of the raw message body emitted by the source MessageTransmitter's MessageSent event. This hash is the join key across all three artifacts: the burn event references it, iris keys its attestations by it, and the destination mint consumes the message whose hash matches.
​

If you only have a source transaction hash, you can derive the message hash by reading the MessageSent log on Etherscan and hashing the message bytes parameter. CCTPScan does this automatically. Once you have the message hash, every downstream lookup (iris, destination explorer, support requests to Circle) becomes a one-line query rather than a guessing game. If a wallet shows you only a source tx hash and nothing else, ask for the message hash first.
​

Inside Eco Routes, CCTP is one of the internal transport rails we use to move USDC between chains. When a developer asks Eco to settle a payment from Base to Arbitrum in USDC, we may route the underlying funds through CCTP, through native bridges, or through a solver depending on speed and cost. The CCTP burn-mint flow described above is what happens under the hood for the CCTP path.
​

If you are tracking a payment that Eco Routes settled, you will still see the same CCTP burn and mint events in CCTPScan or Etherscan. The difference is that the recipient on the destination chain is often a solver contract or the end user's wallet rather than the original sender.
​

This guide reflects CCTP V1 and V2 behavior as of May 2026. Contract addresses, domain IDs, and event signatures were pulled from Circle's developer documentation at developers.circle.com/stablecoins/cctp-getting-started. Attestation timing assumptions reflect Circle's published finality thresholds for each chain. Fast Transfer and Hooks behavior is documented in Circle's CCTP V2 launch notes (March 2025). CCTPScan feature claims are based on the public cctpscan.xyz interface.
​