Can USDC still be transferred after a CCTP attestation expires?
For a CCTP V2 Fast transfer where USDC has already been burned on the source chain but minting has not yet completed on the destination chain, Circle’s documentation provides a re-attestation path. When investigating, check the source-chain record, attestation validity, and destination-chain execution separately; don’t rely solely on an app showing “success” or “timed out.”
For this review on October 30, I read-only checked Circle’s technical guide, the re-attestation API reference, and the fixed-version EVM contract source linked in the documentation. The webpages did not specify clear publication dates, so this article explains the current documentation. I did not initiate a transfer or request a re-attestation, and I have not verified the recovery of funds for any user.
Consider a hypothetical scenario: a Fast transfer to Arbitrum has a burn record on the source chain, but USDC has not yet arrived on the destination chain. Troubleshooting should focus on this same transaction and preserve the source-chain transaction hash, message nonce, destination domain, and recipient address. If there is only an error in the interface, that is not enough to conclude that a burn has occurred. Procedures for other bridges or older versions should not be assumed to apply.
Suppose the issue is that the old attestation has expired. The technical guide says that, as long as the source-chain burn transaction still exists, a new attestation can be requested to refresh the expirationBlock. The TokenMessengerV2 source code linked in the documentation also validates nonzero expiration blocks; expired messages need to be reissued. This explains why the old attestation can no longer be used; it does not mean that USDC will automatically be returned. For this Arbitrum example, the guide says to determine the expiration field using Ethereum L1 block numbers, not L2 block numbers or an interface countdown.
Now suppose the re-attestation request returns 200. The issue is still not resolved. The API reference defines this as meaning that the process has started; you still need to obtain the new attestation and verify destination-chain execution and the actual receipt. An accepted request, issuance of a new attestation, and arrival of USDC are three different forms of evidence. Reviewing the source code also cannot replace checking the contract version actually deployed on a given chain.
Data collected at 18:16 this round showed USDCUSDT at approximately 1.00122, with full-hour spot trading volume from 17:00 to 18:00 of approximately 28.1704 million USDT. This is only market context from exchanges for the transferred asset, not evidence of CCTP usage, processing speed, or receipt.
My assessment is that an expired attestation is a processing state that needs investigation; it should not be described outright as permanent loss of funds. An incomplete transfer could also be due to source-chain confirmation, attestation processing, or destination-chain execution; the specific cause must be checked for each transaction. If network, contract, or service rules change later, check the applicable version again. This article explains how to assess the status; it is not a recovery tutorial. $USDC
For a CCTP V2 Fast transfer where USDC has already been burned on the source chain but minting has not yet completed on the destination chain, Circle’s documentation provides a re-attestation path. When investigating, check the source-chain record, attestation validity, and destination-chain execution separately; don’t rely solely on an app showing “success” or “timed out.”
For this review on October 30, I read-only checked Circle’s technical guide, the re-attestation API reference, and the fixed-version EVM contract source linked in the documentation. The webpages did not specify clear publication dates, so this article explains the current documentation. I did not initiate a transfer or request a re-attestation, and I have not verified the recovery of funds for any user.
Consider a hypothetical scenario: a Fast transfer to Arbitrum has a burn record on the source chain, but USDC has not yet arrived on the destination chain. Troubleshooting should focus on this same transaction and preserve the source-chain transaction hash, message nonce, destination domain, and recipient address. If there is only an error in the interface, that is not enough to conclude that a burn has occurred. Procedures for other bridges or older versions should not be assumed to apply.
Suppose the issue is that the old attestation has expired. The technical guide says that, as long as the source-chain burn transaction still exists, a new attestation can be requested to refresh the expirationBlock. The TokenMessengerV2 source code linked in the documentation also validates nonzero expiration blocks; expired messages need to be reissued. This explains why the old attestation can no longer be used; it does not mean that USDC will automatically be returned. For this Arbitrum example, the guide says to determine the expiration field using Ethereum L1 block numbers, not L2 block numbers or an interface countdown.
Now suppose the re-attestation request returns 200. The issue is still not resolved. The API reference defines this as meaning that the process has started; you still need to obtain the new attestation and verify destination-chain execution and the actual receipt. An accepted request, issuance of a new attestation, and arrival of USDC are three different forms of evidence. Reviewing the source code also cannot replace checking the contract version actually deployed on a given chain.
Data collected at 18:16 this round showed USDCUSDT at approximately 1.00122, with full-hour spot trading volume from 17:00 to 18:00 of approximately 28.1704 million USDT. This is only market context from exchanges for the transferred asset, not evidence of CCTP usage, processing speed, or receipt.
My assessment is that an expired attestation is a processing state that needs investigation; it should not be described outright as permanent loss of funds. An incomplete transfer could also be due to source-chain confirmation, attestation processing, or destination-chain execution; the specific cause must be checked for each transaction. If network, contract, or service rules change later, check the applicable version again. This article explains how to assess the status; it is not a recovery tutorial. $USDC