[mainnet] 8 CCTP v2 attestations stuck 3+ weeks (Base domain 6 -> Arc domain 26) — contradictory pending/finalized state, 900 USDC frozen

[fadai216]

Summary

8 CCTP v2 depositForBurn transfers from Base (domain 6) -> Arc (domain 26) on mainnet have been stuck for 3+ weeks. Circle's production IRIS never issued attestations for them, so receiveMessage() on Arc is impossible and 900 USDC is frozen (burned on Base, never minted on Arc). Filing here because domain 26 is the Arc chain and this is an Arc-side attester/indexer gap.

Related: circlefin/evm-cctp-contracts#110 reports the same domain-26 attestation gap on testnet. This report is the mainnet, real-funds counterpart.

Environment

• Source: Base 8453 (CCTP domain 6), production
• Destination: Arc 5042 (CCTP domain 26), production
• IRIS: https://iris-api.circle.com (v2)
• Recipient (all 8): 0xE63c444851Fd3585F3Ce36F9CbC1cDfc121f3C97
• Burned: 2026-06-25. A batch of ~900 identical-parameter burns attested and minted fine; only the last 8 are stuck.

The contradiction (re-verified 2026-07-09)

# IRIS: not confirmed yet
GET https://iris-api.circle.com/v2/messages/6?transactionHash={burnTx}
  -> { status: "pending_confirmations", attestation: "PENDING", message: null, delayReason: null }

# reattest: already finalized
POST https://iris-api.circle.com/v2/reattest/{eventNonce}
  -> HTTP 400 { "message": "Cannot re-attest requested message.", "error": "Message is already finalized." }

Each message is simultaneously pending confirmation and already finalized. No attestation is ever produced.

Correlation with a Circle incident

Circle's status page logged 2026-06-25 "USDC & CCTP on Pharos — Delayed mints, burns, and transfers" (critical) — same day as our burns. Arc domain 26 was never separately posted. This batch appears to have fallen into an unlogged attester-incident window and was never re-processed.

The 8 stuck messages

idx  amount  type      burnTx                                                              eventNonce
992    1 USDC fast      0x8ffe8c8a09d50324a27c54b85bd0721bd060cf65504e52b1fda9dafc564f251f  0x09fb4f648102aa7a2036b44d16e7843c3f9e91c9b6a3d45529edafe1a474ce75
993  119 USDC standard  0xaa1a12aaa189a3d85bd7d7bd251a40c51c7301f5bfb2bea9c61c7dfb5d369732  0x1f38cb5384ce1f6e52897cf74bec1f716c0e61d3b6683defe8dd733f616fad1a
994  130 USDC standard  0xbf2df6776b61f31ad6d7ea3c6bc4a67f1def192fbce009f03ee21dcc8c156105  0x30cb5509c977a4e3aec004e16615b9c8bc6a680a6f97c0352679539dd73e3b50
995  130 USDC standard  0xb351852316968d6e061549a843c7376ca8f743cdc2107227ff10b5346b3c4a79  0x6c8b8f106600b5161bdd77a7e82e6c14b7a8350565367e4befbb337d5ae7cd45
996  130 USDC standard  0xe2dfdebe3f3b13ec67c088f758674457abb506dc9d9487490a77d246189d1556  0xeb44421f6ba31e991d52d702b763d39c5c273b9e462e39b9a075a00efce9f254
997  130 USDC standard  0xaa5c7b19bd5d2d75b06d24bfeff6fb3179477f06a91b2341e07b5da030496805  0x7edc22274daf4fdf3961438a732795b116ba01f0223c3e42cb4cea2e207b81a3
998  130 USDC standard  0xb378ec8016fecdc880c8dbf1375a66af01e1e78574c300a32740f9ee4a676fd2  0xe42d46c04007c9f2372f58e537fa7e5f76cbca3e1b9670f81521ec50fb5725f0
999  130 USDC standard  0x893685767128df4bc1c33fad7f7356a5272fd653495a4c98794cd7ce55328a2a  0x5d8e601a45250364830d6e519b7a4ee748bc609b456113dca355e87c5efca1ac

Root-cause hint: burns 994–999 share one pre-attestation messageHash (0xcc8c6414b29c6ed29ef3be3543bcfaa0b11f100a8d36053dcf276e1979fdba16) — CCTP v2 zeroes the nonce field pre-attestation and those six 130-USDC burns are otherwise identical, so they collide on messageHash and are distinguished only by eventNonce. If the attester de-duplicates by messageHash, that would explain the stuck subset.

Ask

Please backfill / re-issue attestations for these 8 eventNonces so we can call receiveMessage on Arc. Full 45-word CCTP v2 message bytes for each burn are archived and available on request. Happy to provide anything else that helps reproduce.

[osr21]

Independently hit the same IRIS contradiction (pending_confirmations + reattest → "Message is already finalized.") on testnet while building an Arc-facing CCTP v2 bridge.

A few observations that may help narrow down the attester-side bug:

Duplicate messageHash de-duplication hypothesis looks solid

Your burns 994–999 (6× 130 USDC, same recipient) sharing a single pre-attestation messageHash is the strongest signal here. CCTP v2 zeroes the nonce field before hashing for attestation purposes, so parameter-identical burns are indistinguishable to the attester at that stage. If the attester de-duplicates or caches by messageHash and only processes the first occurrence, the remaining five would be marked finalized internally (the attester "handled" them by deduplication) but never produce an attestation payload — exactly the pending_confirmations + already finalized contradiction you observed.

Practical impact for bridge UIs

For any bridge that lets users retry: a timed-out attestation followed by a second burn of the same amount to the same address will produce another messageHash collision and a second stuck message. We updated our timeout error to explicitly warn users not to re-burn until the first attestation resolves, and to check https://status.circle.com before assuming the bridge is at fault.

Testnet counterpart

evm-cctp-contracts#110 (already linked above) describes the same domain-26 attestation gap on testnet. The pattern there matched: attestation never returned despite confirmed burns, and reattest rejected with already finalized. If Circle's attester infrastructure shares code between mainnet and testnet for domain 26, a fix for the mainnet case should also resolve the testnet one.

Happy to provide message bytes or event nonces from our testnet cases if they help reproduce on Circle's side.

[osr21]

Circle App Kit useForwarder: true — different attestation path, same underlying gap

Adding to the de-duplication hypothesis above from building ArcLend's fast bridge layer (using @circle-fin/app-kit@1.9.0 / bridge() with useForwarder: true).

How the forwarder path differs

Standard CCTP v2 (domain 6 → 26): DApp burns → polls IRIS → calls receiveMessage() on Arc.

With useForwarder: true in App Kit: the App Kit submits the burn, then Circle's forwarder infrastructure watches for the attestation and calls receiveMessage() on behalf of the user. The DApp never polls IRIS directly.

The relevant finding: In the forwarder path, the App Kit's internal step machine still transitions through fetchAttestation → mint, but the attestation fetch is delegated server-side. This means the same pending_confirmations + already finalized contradiction that's freezing these 8 messages would likely cause the forwarder to hang at fetchAttestation indefinitely — no client-side error, no timeout surfaced to the user. The funds would be equally frozen, just silently.

What the IRIS state machine likely means

The contradiction (status: "pending_confirmations" + reattest → "Message is already finalized.") suggests the attester wrote a finalized tombstone to its state store before emitting the attestation bytes — possibly during the 2026-06-25 incident window. The attestation bytes were never persisted, but the state gate that would trigger re-processing already closed.

The forwarder path doesn't help here because the forwarder also depends on IRIS attestation bytes being available.

Mitigation we're using in ArcLend

For the fast bridge UI, we added explicit step-level timeout detection: if fetchAttestation hasn't completed within 90s, we surface a "attestation delayed" warning with a link to the IRIS status page and the burn tx hash. This doesn't fix the underlying issue but at least prevents silent hangs.

If Circle can expose a manual re-process endpoint (distinct from reattest which just checks state), the eventNonce values in your report are everything needed to retry.