Circle CCTP bridge stuck — attestation pending or Iris 404? Why you're polling too early

Cross-chain USDC via Circle's CCTP has a rhythm: burn on the source chain, wait for Circle to attest, then mint on the destination. Most "CCTP is broken" reports are actually just polling too early — treating a not-yet-ready attestation as a failure.

pending_confirmations is not a failure

After you burn USDC on the source chain, Circle needs enough block confirmations before it will attest to the message. Until then, its Iris API returns pending_confirmations. That's the expected intermediate state, not an error — the attestation is being prepared.

Fix: keep polling the Iris API until the status is complete, then use the returned attestation to mint on the destination chain. Don't abort on pending.

Iris 404 usually means 'not indexed yet'

When it really is wrong: domain id and replay

• Wrong domain id. A persistent 404 or a mint that won't validate can mean you used the wrong CCTP domain id — which is NOT the same as the chain id. Circle assigns its own domain ids; map them correctly.
• nonce-already-used. If the mint reverts with a used-nonce error, the message was already minted (a replay). Don't re-mint — check the destination for the completed transfer.

For agents bridging USDC

An agent that treats pending_confirmations or a first 404 as a failure will abandon a transfer that was going to succeed. diagnose_infra_error returns the cctp family and tells the agent to keep polling vs when something is genuinely wrong (domain id, replay):

diagnose_infra_error({error: "cctp attestation pending_confirmations iris"})
// → { family: "cctp",
//      fix: "not a failure — keep polling Iris until complete, then mint; a first 404 = not-indexed-yet" }