Circle réduit les limites de brûlage du CCTP legacy sur Noble à partir du 31 octobre

Circle a lancé la réduction programmée des limites de brûlage pour son infrastructure legacy du protocole de transfert inter-chaînes (CCTP), un processus qui commence le 31 octobre. Cet événement marque le début d’une réduction progressive de CCTP V1, que Circle indique n’être pas rétrocompatible avec le nouveau système V2. Pour les utilisateurs et intégrateurs détenant des USDC sur la chaîne Noble, cette phase de réduction précède une date de suspension spécifique du 12 janvier 2027 pour le contrat USDC de Noble et les routes CCTP restantes.

Distinction entre les délais généraux et ceux de Noble

L’avis de dépréciation de CCTP V1 par Circle détaille un calendrier où les limites de brûlage commencent à diminuer le 31 octobre, menant à une suspension générale des contrats legacy le 1er décembre. L’entreprise souligne que CCTP V2 utilise des contrats et des API distincts, ce qui signifie qu’il ne prend pas en charge la rétrocompatibilité avec V1. Les intégrateurs passant de V1 à V2 doivent modifier les systèmes qu’ils appellent et ajuster leurs hypothèses concernant les données de réponse. Se contenter de mettre à jour un logo ou d’afficher un nouveau nom de route est insuffisant pour une migration fonctionnelle.

Noble dispose d’un calendrier distinct, séparé de la suspension générale legacy. Selon l’avis spécifique à Noble de Circle, la nouvelle émission (minting) sur Noble devait s’arrêter le 13 octobre. La date de suspension du contrat USDC de Noble et de ses routes CCTP restantes est fixée au 12 janvier 2027. Noble ne bénéficiera pas du support de CCTP V2. Circle avertit qu’après la suspension générale du 1er décembre, les sorties de Noble pourraient être limitées aux destinations qui prennent encore en charge V1. Par conséquent, la date du 12 janvier ne garantit pas que chaque route restera ouverte jusqu’à ce jour précis.

Exigences opérationnelles pour la migration

La transition de CCTP V1 à V2 nécessite plus que des mises à jour d’interface. Étant donné que les versions du protocole utilisent des contrats différents, les applications doivent prendre en compte les transferts déjà en cours. Un transfert implique une action sur la chaîne source, une attestation et une complétion sur la chaîne de destination. Le statut d’une étape ne confirme pas que l’ensemble du processus est terminé. L’objectif opérationnel est de prévenir les lacunes où les utilisateurs initient un transfert que l’application ne peut plus compléter. La clarté sur la disponibilité des routes et la gestion des transferts en attente sont des composants essentiels de ce travail de migration.

L’identité du jeton et le support des chaînes sont des facteurs critiques pendant cette période de fin de vie. Les USDC émis sur une blockchain ne sont pas interchangeables au niveau de l’interface avec les actifs portant le même ticker sur d’autres réseaux. Un service de réception doit prendre en charge le réseau spécifique et la forme du jeton envoyé. Un lieu de transaction peut prendre en charge une chaîne de destination tout en n’acceptant plus les dépôts depuis une route plus ancienne, ou il peut exiger une étape de conversion avec des conditions et des exigences de liquidité spécifiques. La proposition de migration du pool communautaire de Cosmos illustre cela au niveau du trésor, décrivant un déplacement prévu des USDC émis par Noble vers des USDC émis par Injective. Cependant, la publication d’une proposition ne prouve pas que la migration a été achevée.

Circle indique que les soldes restants sur Noble seront figés (snapshot) à la date de suspension du 12 janvier 2027. Un processus de rachat manuel commencera le lendemain, le 13 janvier 2027. Ce processus est soumis à des exigences d’éligibilité et de conformité et sert de solution de repli plutôt que de transfert automatisé ordinaire. Pour les détenteurs et les services, la préparation implique de déterminer quelle route prise en charge s’applique, de comprendre les conditions régissant et de vérifier l’achèvement. Un réseau peut continuer à fonctionner alors qu’un émetteur de stablecoin retire des contrats ou infrastructures spécifiques dessus, ce qui signifie que la disponibilité du réseau et le support de l’émetteur ont des cycles de vie distincts.