Resposta rápida: A Circle informa que seu CCTP V1, agora chamado de CCTP V1 (Legado), iniciou o desligamento em 31 de outubro de 2026 e tem previsão de pausa dos contratos em 1º de dezembro de 2026. Um desenvolvedor ou serviço que ainda envia USDC entre cadeias por meio dos contratos V1 deve migrar para os contratos e APIs do CCTP V2. Uma pessoa que simplesmente mantém USDC não precisa trocar o token por causa deste aviso. Um cliente de carteira ou exchange deve verificar se a rota específica entre cadeias que utiliza depende do V1 e seguir as instruções desse provedor. O prazo diz respeito à infraestrutura de transferência, não a todos os saldos de USDC.
O que a Circle está realmente encerrando?
CCTP é o protocolo de transferência entre cadeias da Circle. Em uma transferência típica de USDC, o USDC da cadeia de origem é queimado, uma mensagem é atestada e o USDC nativo é cunhado na cadeia de destino. Isso é diferente de enviar USDC para outro endereço na mesma cadeia. Também é diferente de mover uma representação bridged de USDC por meio de uma bridge não relacionada, cujo emissor e riscos podem ser diferentes.
O aviso de fase de encerramento da Circle afirma que os limites de queima do V1 seriam reduzidos a partir de 31 de outubro, com desempenho decrescente durante uma transição de um mês. Em 1º de dezembro, a Circle planeja pausar os contratos V1. Aplicações ainda apontando para esses contratos deixariam de realizar novas transferências entre cadeias via CCTP V1. A declaração é um plano agendado com data de 12 de novembro de 2026; um anúncio operacional posterior poderia modificá-lo.
O V2 usa contratos e interfaces de programação de aplicativos diferentes. O guia de migração chama isso de mudanças breaking (incompatíveis). Uma integração não pode simplesmente rotular um endpoint V1 como V2. É preciso atualizar endereços, interfaces, tratamento de mensagens e, quando relevante, a lógica de taxas e velocidade de transferência.
A Circle usa “CCTP” como nome do V2 desde uma mudança de nomenclatura em 2025. Isso pode confundir usuários que leem a página de ajuda de uma carteira. Um aplicativo que diz suportar CCTP pode já usar o V2, ou ainda ter uma rota legada. A pergunta útil é qual versão de contrato e API a transferência realmente usa. A versão não pode ser estabelecida apenas pelo ticker do ativo “USDC”.
Quem precisa alterar algo antes de 1º de dezembro?
Os operadores de integração têm a ação mais clara. Uma carteira, interface de bridge, exchange, sistema de tesouraria ou aplicativo de pagamento que envie queimas via CCTP V1 deve migrar esse caminho. Deve identificar cada cadeia de origem e destino suportada, verificar os endereços dos contratos V2 na documentação atual da Circle, alterar chamadas de função e polling de API, testar transferências de ponta a ponta e então deixar de oferecer a rota legada antes que ela falhe. Os operadores devem comunicar qualquer suspensão temporária ou mudança de rota aos usuários.
Para um usuário final, a resposta depende do serviço. Se o botão de transferência entre cadeias de uma carteira é mantido pelo provedor da carteira, o provedor pode implementar a atualização sem exigir que o usuário interaja com contratos. Se um aplicativo anunciou que sua rota antiga será desativada, o usuário deve aguardar uma substituição suportada ou usar outra rota verificada. Se um usuário opera um script ou chama diretamente os contratos V1, ele é efetivamente um operador de integração e deve atualizá-lo.
Um depósito ou saque em exchange é outro fluxo de trabalho distinto. O cliente deve confirmar que a exchange suporta o ativo na rede selecionada e que o endereço de depósito e a rede correspondem. Se a exchange usa CCTP internamente é uma questão operacional. O anúncio do CCTP não estabelece que uma rede específica de depósito ou saque da Phemex esteja mudando. Verifique a interface ao vivo da exchange e os avisos oficiais antes de enviar fundos; não infira suporte a partir de um artigo genérico.
Manter USDC em uma carteira não é uma integração CCTP V1. O CCTP é um mecanismo de transferência; ele não define cada saldo existente de token USDC. O guia de desenvolvedores da Circle afirma que os usuários não perderão acesso a fundos durante a fase de encerramento do V1 e que resgates pendentes permanecem disponíveis quando ela se inicia. Essa garantia é específica à transição do protocolo e não deve ser lida como uma proteção contra riscos não relacionados de carteira, emissor ou bridge.
O que muda para desenvolvedores que migram para o V2?
A migração central é uma mudança de contrato e API. A Circle lista substitutos do V2 para os contratos legados TokenMessenger, MessageTransmitter e TokenMinter em endereços diferentes. A chamada depositForBurn aceita parâmetros adicionais, incluindo um caller de destino, uma taxa máxima e um limiar de definitividade. Uma implementação que continua chamando a interface V1 não usará o V2 meramente porque sua interface de usuário diz “transferência de USDC”.
O fluxo de trabalho de atestação também muda. O guia da Circle afirma que o V2 pode retornar a mensagem, a atestação e os dados decodificados por meio de um endpoint /v2/messages/{sourceDomainId} consultado com o hash da transação de origem. O código legado frequentemente extraía uma mensagem do recibo da transação e solicitava uma atestação por um endpoint V1. Os testes devem cobrir análise do recibo, status da mensagem, tentativas repetidas e a etapa de cunhagem na cadeia de destino, não apenas a transação inicial na cadeia de origem.
O V2 oferece modos Standard e Fast Transfer. O Fast Transfer pode ter uma taxa variável com base na cadeia de origem. Desenvolvedores devem consultar as taxas atuais e expor um valor total e um valor esperado recebido antes de o usuário assinar. Uma configuração de taxa máxima pode impedir uma cobrança não intencional acima de um limite configurado, mas também pode fazer uma transferência falhar se a taxa subir. O modo Standard e o modo Fast diferem em definitividade e recursos disponíveis; o modo escolhido deve ser explícito na experiência do produto.
A disponibilidade de cadeias também exige uma checagem rota por rota. O guia de migração afirma que o V2 estava disponível em todas as cadeias do V1 exceto Noble e Sui no momento da comparação documentada, com Sui planejado antes do início do desligamento. Um desenvolvedor deve verificar as cadeias e endereços de contratos suportados pela Circle atualmente antes da implantação, pois uma lista de cadeias desatualizada pode causar transferências malsucedidas ou enviar fundos por uma bridge não intencional. Não trate o número amplo de cadeias suportadas em um post de marketing como prova de que cada par origem-destino e recurso está disponível.
O que acontece com uma transferência já em andamento?
Uma transferência CCTP tem etapas: queima na origem, atestação e cunhagem no destino. Um aplicativo pode mostrar “pendente” enquanto aguarda confirmação ou uma atestação mesmo quando a transação de origem foi bem-sucedida. Um hash da transação de origem, por si só, não mostra que a cunhagem no destino foi concluída. Antes de tentar outra transferência, inspecione o status por meio da interface oficial do provedor e dos exploradores de cadeia relevantes.
O guia de migração da Circle afirma que manterá as permissões de cunhagem do V1 acima das estações de atestação pendentes durante a fase de encerramento, para que resgates já em processamento possam ser concluídos antes que os contratos sejam totalmente pausados. Isso é mais específico do que dizer que toda transferência será concluída automaticamente. Um provedor ainda pode precisar enviar uma transação de destino ou se recuperar de um erro de aplicação. Um operador deve inventariar mensagens V1 pendentes e concluí-las ou escaloná-las usando o caminho documentado pela Circle. Os usuários devem fornecer ao suporte o hash da transação de origem, redes de origem e destino, valor, endereço de destino e horário.
Não envie uma segunda transferência meramente porque a carteira de destino não foi atualizada. Uma queima duplicada criaria uma segunda transferência separada, não “destravaria” a primeira. Da mesma forma, uma pessoa que pede uma frase de recuperação ou pagamento antecipado para liberar uma atestação não faz parte do fluxo oficial do protocolo. O aviso da Circle afirma que as transferências são irreversíveis e que não é possível recuperar ativos enviados a um endereço incorreto.
Como um usuário pode verificar se uma rota é afetada?
Primeiro, identifique que ação você executa. Um pagamento comum de USDC na mesma cadeia está fora desta migração CCTP. Uma transferência entre cadeias por meio de uma carteira ou bridge nomeada precisa de uma checagem de rota. Consulte a página de suporte atual ou o aviso de serviço do provedor sobre CCTP V1, V2, “legado” e o prazo de dezembro. Se o provedor não informar a versão, pergunte ao suporte qual protocolo e caminho de contrato ele usa para o par exato de cadeias. Não dependa de um post social de terceiros como confirmação.
Em seguida, revise a prévia da transferência. Ela deve mostrar a rede de destino, o ativo, o destinatário, a taxa e o valor esperado a chegar. Verifique o endereço e a rede do destinatário. Envie um pequeno valor de teste quando o montante em risco justificar a taxa e o tempo extras. Guarde ambos os hashes de transação se ocorrer uma cunhagem no destino. Um teste não elimina todo o risco, mas pode expor uma rede errada ou uma rota não suportada antes de uma transferência maior.
Por fim, distinga o USDC nativo de um ativo bridged com ticker semelhante. As mesmas letras em uma carteira não estabelecem o emissor ou o caminho de resgate. Verifique o contrato do token e a descrição do ativo do serviço. Mover entre duas versões do CCTP é uma mudança na infraestrutura de transferência; trocar uma representação de ativo por outra é uma decisão separada, com seus próprios custos e riscos.
Qual é o risco operacional remanescente?
O prazo está fixado no aviso atual da Circle, mas a migração de aplicações não é visível apenas pelo aviso. Provedores podem suspender rotas, alterar taxas ou suportar um par de cadeias depois do esperado. Contratos inteligentes, relayers, congestionamento de cadeia e entrada do usuário também podem causar falhas. A resposta prática é verificar a rota ao vivo e o aviso do provedor imediatamente antes de transferir e, em seguida, preservar evidências caso a transferência trave.
Para um desenvolvedor, os principais modos de falha são um endereço legado deixado na configuração, antigos parâmetros ABI, IDs de domínio incorretos, uma incompatibilidade entre a lógica de definitividade Standard e Fast e um tratamento inadequado de estações de atestação atrasadas. Um teste controlado em cada rota de produção e um inventário de mensagens V1 pendentes são mais úteis do que uma ampla afirmação de que “CCTP V2 é suportado”. A migração está completa somente quando a rota real usa o V2 de ponta a ponta e seu processo de tratamento de falhas está documentado.
Perguntas frequentes
Preciso trocar meu USDC por um novo token?
Nenhuma ação desse tipo decorre apenas do aviso do CCTP V1. O aviso trata da infraestrutura de transferência entre cadeias. Verifique um anúncio específico da carteira ou da exchange antes de agir sobre um saldo.
Uma transferência V1 iniciada antes da pausa será perdida?
A Circle afirma que os resgates pendentes permanecem disponíveis durante a fase de encerramento e descreve provisões para atestações pendentes. O usuário ou provedor ainda deve monitorar e concluir a etapa de destino. Não presuma que uma queima na origem significa que toda a transferência foi concluída.
Um aplicativo V1 pode continuar usando seus contratos antigos após 1º de dezembro?
A Circle afirma que os contratos V1 serão pausados nessa data, então um aplicativo ainda apontando para eles deixará de realizar transferências entre cadeias por esse caminho. O operador precisa implementar e testar o V2 ou fornecer outra rota suportada.
