Docs: CCTP domain 26 finalized-finality attestations take hours — undocumented latency and retry guidance

[osr21]

Summary

CCTP v2 attestations for Arc Mainnet (domain 26) with finalityThreshold: "finalized" take several hours to be issued by the Circle Attestation Service. There is no documentation that explains this is expected, so developers building cross-chain flows assume the typical CCTP timing (~13 minutes for Ethereum finality) and build retry logic that gives up too early or fires too many requests.

Observed behaviour

After burning USDC on Arc Mainnet with finalityThreshold: "finalized":

1. The attestation API returns {"status":"pending_confirmations","message":null} for an extended period.
2. A reattest call returns "already finalized" — the burn is real, but the attestation service has not ingested the event.
3. There is no ETA or progress indicator from the API.
4. Attestations eventually appear, typically after 2–6 hours in practice.

Impact

• Developers expecting minutes build UI that shows "stuck" or "failed" states.
• Automated keepers / relayers time out and may double-submit or abandon valid burns.
• Support load increases from users who assume lost funds.

Request

Please add to the Arc developer documentation:

1. The expected attestation latency range for domain 26 finalized-finality burns.
2. Whether "fast" finality (if supported) has a different SLA.
3. The correct interpretation of pending_confirmations + message:null (waiting for indexer ingestion, not a failure).
4. Recommended retry interval and max-wait guidance for integrators.

References

• CCTP v2 Attestation API: https://iris-api.circle.com/v2/messages/{domain}
• Arc Mainnet CCTP domain: 26

[osr21]

Hi — could a maintainer assign this issue to me (@osr21)?

I have a docs PR ready covering the CCTP domain 26 attestation latency, the "pending" block tag correction for eth_getLogs, the Osaka/PUSH0 EVM compatibility update, and the Sourcify verification workaround.