Le transfert d’USDC peut-il se poursuivre après l’expiration de la preuve CCTP ?
Pour un transfert CCTP V2 Fast dont l’USDC a déjà été brûlé sur la chaîne source, mais dont la frappe n’est pas encore achevée sur la chaîne cible, la documentation de Circle prévoit une procédure de nouvelle preuve. Pour localiser le problème, il faut vérifier séparément les enregistrements de la chaîne source, la validité de la preuve et l’exécution sur la chaîne cible ; il ne suffit pas de se fier à l’état « réussi » ou « expiré » affiché par l’application.
Lors de cette vérification du 30 octobre, j’ai consulté en lecture seule le guide technique de Circle, la référence de l’API de nouvelle preuve et le code source des contrats EVM dans la version figée liée depuis la documentation. La page Web n’indique pas de date de publication précise ; cet article explique donc la documentation actuelle. Aucun transfert n’a été initié, aucune nouvelle preuve n’a été demandée et je n’ai confirmé la récupération des fonds pour aucun utilisateur.
Prenons un scénario hypothétique : un transfert Fast vers Arbitrum, pour lequel un enregistrement de destruction existe déjà sur la chaîne source, mais où l’USDC n’est pas encore arrivé sur la chaîne cible. La vérification doit d’abord porter sur cet enregistrement précis ; il faut conserver le hachage de la transaction source, le nonce du message, le domaine cible et l’adresse du destinataire. Si l’on ne dispose que d’un message d’erreur dans l’interface, on ne peut toujours pas conclure que les tokens ont été brûlés. Les procédures d’autres bridges ou d’anciennes versions ne peuvent pas non plus être appliquées telles quelles.
Supposons que le problème soit dû à l’expiration de l’ancienne preuve. Le guide technique précise qu’une nouvelle preuve peut être demandée tant que la transaction de burn sur la chaîne source existe, ce qui actualise le champ expirationBlock. Le code source de TokenMessengerV2 lié dans la documentation valide également les blocs d’expiration non nuls ; un message expiré doit être émis à nouveau. Cela explique pourquoi l’ancienne preuve ne peut plus être utilisée, mais ne signifie pas que l’USDC sera automatiquement remboursé. Dans cet exemple sur Arbitrum, le guide demande de déterminer l’expiration à partir du numéro de bloc d’Ethereum L1 ; le numéro de bloc L2 ou le compte à rebours de l’interface ne peuvent pas s’y substituer directement.
Supposons ensuite que la demande de nouvelle preuve renvoie le code 200 : le processus n’est pas pour autant terminé. La référence de l’API indique que le processus a été lancé ; il faut ensuite obtenir la nouvelle preuve et vérifier l’exécution sur la chaîne cible ainsi que l’enregistrement de réception effectif. L’acceptation de la demande, l’émission d’une nouvelle preuve et l’arrivée de l’USDC constituent trois éléments de preuve distincts. La lecture du code source ne remplace pas non plus la vérification de la version du contrat effectivement déployée sur une chaîne donnée.
Lors de la collecte à 18 h 16, le cours USDCUSDT était d’environ 1.00122, et le volume total des transactions au comptant sur l’heure complète de 17 h à 18 h s’élevait à environ 28,1704 millions d’USDT. Il s’agit uniquement d’un contexte de marché sur les plateformes d’échange pour l’actif transféré, et non d’une mesure de l’utilisation de CCTP, de sa vitesse de traitement ou d’une preuve d’arrivée des fonds.
À mon avis, l’expiration d’une preuve correspond à un état de traitement à examiner ; elle ne permet pas de conclure directement à une perte définitive des fonds. L’absence d’achèvement peut aussi provenir de l’étape de confirmation sur la chaîne source, du traitement de la preuve ou de l’exécution sur la chaîne cible ; la cause précise doit être vérifiée pour chaque transfert. Si le réseau, le contrat ou les règles du service changent par la suite, il faudra consulter à nouveau la version correspondante. Cet article explique comment évaluer l’état d’un transfert ; ce n’est pas un tutoriel de récupération. $USDC
Pour un transfert CCTP V2 Fast dont l’USDC a déjà été brûlé sur la chaîne source, mais dont la frappe n’est pas encore achevée sur la chaîne cible, la documentation de Circle prévoit une procédure de nouvelle preuve. Pour localiser le problème, il faut vérifier séparément les enregistrements de la chaîne source, la validité de la preuve et l’exécution sur la chaîne cible ; il ne suffit pas de se fier à l’état « réussi » ou « expiré » affiché par l’application.
Lors de cette vérification du 30 octobre, j’ai consulté en lecture seule le guide technique de Circle, la référence de l’API de nouvelle preuve et le code source des contrats EVM dans la version figée liée depuis la documentation. La page Web n’indique pas de date de publication précise ; cet article explique donc la documentation actuelle. Aucun transfert n’a été initié, aucune nouvelle preuve n’a été demandée et je n’ai confirmé la récupération des fonds pour aucun utilisateur.
Prenons un scénario hypothétique : un transfert Fast vers Arbitrum, pour lequel un enregistrement de destruction existe déjà sur la chaîne source, mais où l’USDC n’est pas encore arrivé sur la chaîne cible. La vérification doit d’abord porter sur cet enregistrement précis ; il faut conserver le hachage de la transaction source, le nonce du message, le domaine cible et l’adresse du destinataire. Si l’on ne dispose que d’un message d’erreur dans l’interface, on ne peut toujours pas conclure que les tokens ont été brûlés. Les procédures d’autres bridges ou d’anciennes versions ne peuvent pas non plus être appliquées telles quelles.
Supposons que le problème soit dû à l’expiration de l’ancienne preuve. Le guide technique précise qu’une nouvelle preuve peut être demandée tant que la transaction de burn sur la chaîne source existe, ce qui actualise le champ expirationBlock. Le code source de TokenMessengerV2 lié dans la documentation valide également les blocs d’expiration non nuls ; un message expiré doit être émis à nouveau. Cela explique pourquoi l’ancienne preuve ne peut plus être utilisée, mais ne signifie pas que l’USDC sera automatiquement remboursé. Dans cet exemple sur Arbitrum, le guide demande de déterminer l’expiration à partir du numéro de bloc d’Ethereum L1 ; le numéro de bloc L2 ou le compte à rebours de l’interface ne peuvent pas s’y substituer directement.
Supposons ensuite que la demande de nouvelle preuve renvoie le code 200 : le processus n’est pas pour autant terminé. La référence de l’API indique que le processus a été lancé ; il faut ensuite obtenir la nouvelle preuve et vérifier l’exécution sur la chaîne cible ainsi que l’enregistrement de réception effectif. L’acceptation de la demande, l’émission d’une nouvelle preuve et l’arrivée de l’USDC constituent trois éléments de preuve distincts. La lecture du code source ne remplace pas non plus la vérification de la version du contrat effectivement déployée sur une chaîne donnée.
Lors de la collecte à 18 h 16, le cours USDCUSDT était d’environ 1.00122, et le volume total des transactions au comptant sur l’heure complète de 17 h à 18 h s’élevait à environ 28,1704 millions d’USDT. Il s’agit uniquement d’un contexte de marché sur les plateformes d’échange pour l’actif transféré, et non d’une mesure de l’utilisation de CCTP, de sa vitesse de traitement ou d’une preuve d’arrivée des fonds.
À mon avis, l’expiration d’une preuve correspond à un état de traitement à examiner ; elle ne permet pas de conclure directement à une perte définitive des fonds. L’absence d’achèvement peut aussi provenir de l’étape de confirmation sur la chaîne source, du traitement de la preuve ou de l’exécution sur la chaîne cible ; la cause précise doit être vérifiée pour chaque transfert. Si le réseau, le contrat ou les règles du service changent par la suite, il faudra consulter à nouveau la version correspondante. Cet article explique comment évaluer l’état d’un transfert ; ce n’est pas un tutoriel de récupération. $USDC