EMERGENCY: CCTP Transfer Stuck 3+ Hours - USDC Not Arriving on Polygon

[longlongcao2-cmd]

Title: EMERGENCY: CCTP Transfer Stuck 3+ Hours - $861 USDC Not Arriving on Polygon

Labels: bug, urgent, cctp

Body:

Summary

$861 USDC burned on Arbitrum via CCTP depositForBurn has NOT arrived on Polygon after 195+ minutes (expected: 10-20 minutes). Circle Iris API returns 404 for attestation.

This appears to match the scenario described in issue #105.

Transaction Details

Burn Transaction (Arbitrum):

• TX Hash: 0x434e52adcc4f838a30b248af6bef32f9a7c4c0ad7b0233736a0f2133237579e8
• Explorer: https://arbiscan.io/tx/0x434e52adcc4f838a30b248af6bef32f9a7c4c0ad7b0233736a0f2133237579e8
• Block: 455132395
• Timestamp: ~18:32 HKT 2026-04-22 (195+ minutes ago)

Contracts Used:

• TokenMessenger: 0x19330d10D9Cc8751218eaf51E8885D058642E08A (same as issue CCTP V1: Arbitrum→Polygon burn succeeded, receiveMessage consumed nonce, but no USDC minted (missing TokenMinter mapping) #105)
• Burn Token: 0xaf88d065e77c8cC2239327C5EDb3A432268e5831 (Arbitrum native USDC, same as CCTP V1: Arbitrum→Polygon burn succeeded, receiveMessage consumed nonce, but no USDC minted (missing TokenMinter mapping) #105)
• Destination Domain: 7 (Polygon)

Wallet: 0x0C038E47e82EC77e1FeDBe1038225371907E7F23

Verification

✅ Burn successful on Arbitrum:

• Transaction status: SUCCESS
• Arbitrum USDC balance: $0.00 (funds left wallet)
• Transfer events show: wallet → TokenMinter → burn address

❌ NOT received on Polygon:

• Polygon USDC balance: $0.00
• Message hash: 0x2ca330444aa7ef85aec2406c0eef23f20f7901a62da118fd370e0085b8665437
• usedNonces (Polygon MessageTransmitter): 0 (message NOT processed)

❌ Attestation unavailable:

• Iris API: 404 "Message hash not found"
• Tried endpoints: /v1/attestations/{txHash}, /v1/attestations/{messageHash}
• All return 404 after 195+ minutes

Comparison to Issue #105

This matches issue #105 exactly:

• ✅ Same route: Arbitrum → Polygon
• ✅ Same TokenMessenger contract
• ✅ Same native USDC token
• ✅ Same problem: burn succeeded but no mint on destination

Issue #105 was opened and closed on 2026-03-22 with no public resolution posted.

Impact

$861 USDC is missing. Funds successfully left Arbitrum but never arrived on Polygon.

Questions

1. Is CCTP V1 broken for Arbitrum → Polygon transfers?
2. How was issue CCTP V1: Arbitrum→Polygon burn succeeded, receiveMessage consumed nonce, but no USDC minted (missing TokenMinter mapping) #105 resolved?
3. Can Circle manually recover these funds?
4. What is the expected timeline for resolution?

Requested Action

1. Provide attestation signature for manual receiveMessage call
2. If protocol bug: manual recovery by Circle engineering
3. Status update on resolution timeline

Environment

• Source Chain: Arbitrum One
• Destination Chain: Polygon PoS
• CCTP Version: V1 (assumed, based on contracts)
• Time Stuck: 195+ minutes and counting

---

Time-sensitive: Funds urgently needed.

[longlongcao2-cmd]

UPDATE (212+ minutes elapsed):

Attestation still unavailable after 3.5+ hours. Circle Iris API continues to return 404.

This appears identical to issue #105 which was resolved (though no public explanation was provided).

@WabiSabikk - Since you encountered this exact scenario in #105, can you share how it was resolved?

Current status:

• Burn TX verified successful on Arbitrum
• $861 USDC burned and left source chain
• Destination (Polygon) balance: $0
• Message not processed (usedNonces = 0)
• Attestation unavailable (404 on all endpoints)

Need: Either attestation signature OR manual recovery assistance from Circle engineering.

Time-sensitive: Funds needed urgently. Any guidance appreciated.

cc: Circle team - requesting emergency assistance

UPDATE (212+ minutes elapsed):

Attestation still unavailable after 3.5+ hours. Circle Iris API continues to return 404.

This appears identical to issue #105 which was resolved (though no public explanation was provided).

@WabiSabikk - Since you encountered this exact scenario in #105, can you share how it was resolved?

Current status:

• Burn TX verified successful on Arbitrum
• $861 USDC burned and left source chain
• Destination (Polygon) balance: $0
• Message not processed (usedNonces = 0)
• Attestation unavailable (404 on all endpoints)

Need: Either attestation signature OR manual recovery assistance from Circle engineering.

Time-sensitive: Funds needed urgently. Any guidance appreciated.

cc: Circle team - requesting emergency assistance

@longlongcao2-cmd My #105 turned out different from what I originally thought. The receiveMessage actually succeeded
and minted USDC, just to the wrong address. I had encoded mintRecipient with right-padding instead of left-padding.
The mint TX is 0xe6b0032fdbfae45e8833941507d448e19a0f1da2692a223747261c4f8c55d3be. Funds went to an address nobody
controls. Circle confirmed this and refused recovery: CCTP is irreversible by design.

Before you wait longer for the attestation, decode your burn TX and check the mintRecipient field. Address-to-bytes32
must be left-padded: 24 zero hex chars, then your 20-byte address. If you padded the other way, the USDC may already
be minted on Polygon to a wrong address and no attestation will ever come. Search Transfer events on the Polygon USDC
contracts (0x3c499c542cef5e3811e1192ce70d8cc03d5c3359 and 0x2791bca1f2de4661ed88a30c99a7a9449aa84174) for your message
hash or nonce.

If your encoding is correct, your case is different from mine. Your nonce is still 0, which means the message was
never processed. That's a better position than I was in. Keep pushing Circle on the missing attestation.

I went through customer-support@circle.com. First reply came in about a day, technical investigation took about three
days. The final answer didn't change.

[longlongcao2-cmd]

URGENT ESCALATION (15+ hours)

@WabiSabikk confirmed my encoding is correct and this is different from their issue #105.

Status:

• Burn TX verified successful
• Amount: $861 USDC
• Nonce: 888112
• Message NOT processed (nonce=0 on Polygon)
• Attestation service returning 404 for 15+ hours
• All parameters verified correct

Request to Circle Engineering:
This appears to be a Circle attestation service failure, not a user error. The burn succeeded, parameters are correct, but your attestation API has not indexed this transaction after 15+ hours.

Requesting immediate assistance from Circle team:

• @circle/cctp-team (if this tag works)
• Can any Circle engineer provide attestation signature manually?
• Is there an emergency recovery process?
• Status update on attestation service?

This is time-sensitive. Funds are stuck in protocol limbo through no fault of the user.

Burn TX: https://arbiscan.io/tx/0x434e52adcc4f838a30b248af6bef32f9a7c4c0ad7b0233736a0f2133237579e8

cc: Anyone who knows Circle CCTP engineers - please tag them.

[longlongcao2-cmd]

Requesting Circle Engineering Attention

Tagging Circle engineers from this repo:
@epoon-circle @jhilaire-circle @dlee-circle @walkerq @ams9198 @mdbere

Summary:

• Valid CCTP burn (nonce 888112, $861 USDC)
• Arbitrum → Polygon (domain 7)
• All parameters verified correct (left-padded recipient)
• Burn successful 15+ hours ago
• Attestation service returning 404 for 15+ hours
• Message not processed on Polygon (nonce=0)

This is not a user error - this is a Circle attestation service failure.

Your status page shows "operational" but this transaction is clearly stuck.

Urgent request:

1. Check why attestation service hasn't indexed burn TX 0x434e52adcc4f838a30b248af6bef32f9a7c4c0ad7b0233736a0f2133237579e8
2. Provide attestation signature for manual mint, OR
3. Advise on emergency recovery process

Customer support email sent to customer-support@circle.com but given time-sensitivity, need engineering intervention.

[osr21]

We've built an attestation polling flow on top of CCTP V2 across multiple chains and have hit most of the variants of this failure mode. A few things worth checking:

1. Production vs sandbox Iris API endpoint

The most common cause of persistent 404 is querying the sandbox endpoint for a mainnet transaction:

• Mainnet: https://iris-api.circle.com/v1/attestations/{messageHash}
• Testnet/sandbox: https://iris-api-sandbox.circle.com/v1/attestations/{messageHash}

If you're querying iris-api-sandbox.circle.com for a mainnet burn, it will return 404 indefinitely — the sandbox only indexes testnet transactions.

2. Message hash computation

The Iris API takes the keccak256 hash of the raw message bytes emitted in the MessageSent event — not the transaction hash, and not the event topic. The correct way to get it:

// From the tx receipt
const receipt = await provider.getTransactionReceipt(txHash);
const messageTransmitter = new Contract(MESSAGE_TRANSMITTER_ADDRESS, [
  "event MessageSent(bytes message)"
], provider);

const log = receipt.logs.find(l =>
  l.address.toLowerCase() === MESSAGE_TRANSMITTER_ADDRESS.toLowerCase()
);
const decoded = messageTransmitter.interface.parseLog(log);
const messageBytes = decoded.args.message;
const messageHash = ethers.keccak256(messageBytes);  // ← this is what Iris expects

3. Iris API response codes

Code	Meaning
404	Message not yet indexed (common for up to 30 min; rare but possible for longer)
200 + pending_confirmations	Indexed but awaiting finality
200 + complete	Attestation ready to use

A 404 after 15+ hours on mainnet (where Arbitrum finality is fast) is unusual and does point to an Iris API indexing issue rather than a user error. Circle's engineering team should be able to look up the nonce (888112) and message hash directly in their infrastructure.

4. Recovery path

Once Circle resolves the indexing, the attestation will become available and you can call receiveMessage on Polygon's MessageTransmitter with the original message bytes + attestation — the funds are not lost.