Quando um rollup deixa de funcionar: o encerramento da Polygon zkEVM explicado

3 de julho de 2026

10 min de leitura

Resumir com IA

A Polygon zkEVM entrou oficialmente na sua fase de descontinuação. Em 1 de julho de 2026, a Polygon Labs desativou o sequenciador da versão beta da Mainnet da Polygon zkEVM, tendo os saldos das carteiras sido transferidos para a L1 da Ethereum através de um processo de reclamação. Para ser justo, o encerramento foi gerido de forma impecável: os utilizadores tiveram um ano inteiro para se prepararem, a ponte permaneceu aberta até ao último dia e as reclamações continuam disponíveis até ao final de 2027.

O problema é que as blockchains não se limitam a guardar moedas nas carteiras. Quando uma rede entra em fase de encerramento, parte da liquidez já se encontra enterrada em várias camadas: em pools, cofres, mercados de crédito, posições de garantia e outros contratos que a Polygon não controla. Transferir essa liquidez de volta para a L1 já não é uma simples tarefa de ponte.

Por isso, colocámos ao nosso especialista, Andrew Nalichaev, as perguntas que muitos no setor provavelmente estão a fazer neste momento: Quem é o responsável pela liquidez bloqueada, o que acontece às stablecoins numa rede em declínio e o que devem os outros rollups aprender antes de se depararem com o mesmo problema?

Andrew Nalichaev

Especialista em cadeias de blocos e analista de DeFi

Andrew traduz conceitos descentralizados em ferramentas financeiras seguras e funcionais. Ele navega no cenário volátil de DeFi para construir infraestruturas de blockchain escaláveis que abordam a utilidade do mundo real, indo além das palavras-chave para fornecer valor técnico.

Ver perfil

- Se considerarmos a Polygon zkEVM como um caso de estudo sobre o encerramento de uma rede L2, o que foi bem gerido e o que deveria ter sido previsto desde o início?

O melhor que a Polygon fez neste caso foi dar tempo às pessoas e definir um processo claro. O fim da zkEVM foi anunciado com cerca de um ano de antecedência, a ponte permaneceu aberta até ao último dia, foi feita uma captura do saldo e foi disponibilizada aos utilizadores uma forma de reclamar os seus fundos na Ethereum L1. No que diz respeito a encerramentos, esta foi uma forma bastante organizada de lidar com a situação.

A parte que deveria ter sido prevista desde o primeiro dia é o plano de saída da DeFi. Transferir saldos de carteiras é uma coisa, porque esses saldos correspondem perfeitamente aos ativos depositados no depósito em garantia da ponte. A DeFi é um caso à parte. Os tokens LP, as participações em cofres, as posições de garantia e os créditos de dívida precisam todos das suas próprias vias de saída de emergência ao nível do protocolo. Sem isso, assim que o sequenciador parar, a liquidez depositada em contratos de terceiros pode tornar-se muito difícil, ou por vezes impossível, de aceder.

- Até que ponto é realista encerrar “de forma ordenada” uma rede L2, uma vez que esta já inclui protocolos DeFi, posições de LP, cofres, garantias e tokens derivados?

É possível realizar um encerramento ordenado, mas apenas até certo ponto. Se estivermos a falar de saldos simples de carteiras ou de ativos que correspondem diretamente ao depósito em garantia da ponte, então sim, é possível tornar o processo bastante simples. No momento em que a composibilidade da DeFi entra em jogo, as coisas tornam-se muito mais complicadas.

Considere um pool AMM básico. Em teoria, seria possível identificar quem detém os tokens LP, calcular a sua quota no pool e distribuir os ativos subjacentes. Tem de ser o detentor atual, e não quem efetuou o depósito original; caso contrário, corre-se o risco de pagar duas vezes à mesma pessoa. Mas a DeFi na prática raramente é assim tão simples. Os tokens LP podem ser colocados em cofres, staked, utilizados como garantia ou integrados noutro produto. De repente, já não se está a lidar com um único direito, mas sim com toda uma cadeia deles, e não existe uma forma universal de identificar quem é o “verdadeiro” proprietário em todos os contratos possíveis.

Portanto, a resposta sincera é: uma L2 só pode ser encerrada de forma ordenada se os protocolos que funcionam sobre ela tiverem previsto esse cenário desde o início. Caso contrário, o encerramento ao nível da rede pode parecer organizado, mas a camada DeFi pode continuar a ser um caos.

- Como avaliaria o risco de duplo gasto ao tentar encerrar manualmente posições de DeFi após uma interrupção da rede? Trata-se principalmente de um problema técnico, jurídico ou económico?

É uma combinação dos três, mas, no fundo, trata-se de um problema económico.

A conta de garantia da ponte na L1 contém apenas os ativos reais que foram introduzidos no sistema. A DeFi constrói, então, camadas adicionais sobre essa base: tokens LP, participações em cofres, posições de empréstimo, tokens de dívida e outros direitos. Num mercado de empréstimos, por exemplo, pode rapidamente acabar por ter mais direitos de crédito do que os ativos que se encontram no depósito em garantia, pelo menos se tentar satisfazer todos ao mesmo tempo.

É aí que surge o problema do duplo gasto. Não é possível pagar ao depositante, ao mutuário e a todos os detentores de derivados a partir do mesmo conjunto de ativos subjacentes, se esse conjunto não for suficientemente grande para cobrir todos esses créditos.

Há também uma armadilha relacionada com o momento certo. Algumas posições nem sequer têm um valor definido no momento em que são congeladas: um empréstimo em perda requer uma liquidação, os juros têm de acumular-se, um oráculo tem de ser atualizado. Se interrompermos a cadeia a meio do processo, a parte “justa” dessas posições torna-se indefinida, e não apenas difícil de calcular.

Do ponto de vista técnico, pode tentar esclarecer quem é o proprietário de cada bem. Do ponto de vista jurídico, poderá ter de decidir qual das reivindicações tem prioridade. Mas, do ponto de vista económico, o limite é muito simples: não é possível distribuir mais ativos do que aqueles que realmente existem.

- Será que as equipas da L2 devem exigir que os protocolos disponham de uma «saída de emergência» antes de lhes permitirem disponibilizar liquidez na rede?

Sim, especialmente se um protocolo vai guardar o dinheiro das pessoas. Não se pode aceitar depósitos, criar liquidez e só depois começar a perguntar “como é que vamos fazer com que toda a gente saia?” quando a rede já está a ser desativada.

A própria L2 só pode ajudar na parte clara e simples: saldos que correspondam ao que se encontra no depósito de garantia da ponte. Não é realista esperar que ela analise cada protocolo DeFi e desemaranhe os registos contabilísticos. Nessa altura, a equipa da L2 teria de decidir quem é o proprietário de cada ativo, como as posições devem ser avaliadas e quem deve ser pago em primeiro lugar. Isso é uma grande responsabilidade e, na verdade, não é função deles.

Portanto, sim, os protocolos DeFi precisam de ter as suas próprias vias de levantamento de emergência, lógica de liquidação ou planos de encerramento antes de os utilizadores começarem a investir quantidades significativas de liquidez neles.

- De que forma o encerramento de um sequenciador altera o modelo de confiança para os L2? Os utilizadores devem agora avaliar não só o risco de ponte, mas também o risco de encerramento?

É aqui que toda a ideia de “basta fazer o bridge” começa a falhar. Funciona se os teus fundos estiverem simplesmente depositados numa carteira. Não funciona tão bem se estiverem retidos num mercado de empréstimos, numa posição de LP, num cofre ou num contrato que ainda necessite de mais uma transação para que possas sair.

Quando o sequenciador pára, a cadeia deixa de receber instruções. Pode ainda ter uma reivindicação válida algures, mas talvez já não tenha um caminho viável para a concretizar. É essa a parte incómoda: o ativo pode não ter desaparecido, mas o caminho para o alcançar pode desaparecer.

Os utilizadores têm de olhar para além da segurança das pontes. No caso das L2 mais pequenas, especialmente aquelas com pouca liquidez ou ecossistemas experimentais, a questão também deve ser: o que acontece se esta rede entrar em declínio e será que consigo sair antes que isso aconteça?

- O que acontece às reservas de stablecoins numa rede em declínio, especialmente quando se compara o USDC.e transferido através de uma ponte com a emissão nativa através de um modelo semelhante ao CCTP?

No caso das stablecoins em ponte, como o USDC.e, o USDC real encontra-se em custódia na camada 1 da Ethereum. Se o seu USDC.e estiver simplesmente na sua carteira, pode ser migrado ou reclamado. Se estiver retido num contrato com o qual já ninguém pode interagir, o USDC subjacente continua lá, mas o utilizador não tem qualquer forma prática de aceder ao mesmo. O emitente não recebe qualquer dinheiro “extra” com isto. A garantia continua lá, mas o valor está, basicamente, retido.

As stablecoins nativas funcionam de forma diferente. Numa configuração do tipo CCTP, o token é cunhado diretamente na L2 e a reserva fiduciária fica na posse do emitente. Para sair de forma limpa, é necessário queimar o token na L2 antes do encerramento e cunhá-lo noutro local. Se o token ficar retido num contrato inativo, já não é possível queimá-lo na cadeia. Assim, o emitente fica com reservas reais para tokens que ainda existem, mas numa rede que já não funciona.

Nessa altura, o emissor tem de decidir o que fazer a seguir: manter as reservas, aceitar reclamações fora da cadeia com comprovativos ou, eventualmente, considerar esses tokens como abandonados.

Não deixe que o risco de infraestrutura se transforme num risco de produto

O Innowise ajuda a conceber infraestruturas Web3 com menos pontos cegos

- Que lições devem as equipas que estão a desenvolver novos ecossistemas de rollup retirar do encerramento do Polygon zkEVM?

O Polygon zkEVM serve para nos lembrar que cada rollup precisa de dois planos de ação: um para o crescimento e outro para o encerramento seguro. Atrair liquidez é apenas metade do trabalho. As equipas também precisam de uma forma clara de retirar essa liquidez, caso a rede venha a ser encerrada.

Isso significa alertar os utilizadores com antecedência, manter a ponte aberta durante o máximo de tempo possível, proporcionar às pessoas um processo simples de reclamação relativamente aos saldos das carteiras e entrar em contacto com os protocolos DeFi muito antes da data de encerramento. Significa também explicar claramente o que acontece aos ativos transferidos através da ponte, aos ativos nativos e às stablecoins.

Acima de tudo, as equipas devem deixar de tratar o TVL como algo que pode simplesmente ser empacotado e transferido mais tarde. Assim que o sequenciador ficar inativo, a verdadeira questão passa a ser: quanta liquidez ainda é necessária para que uma transação seja concluída?

Há também uma lição de conceção subjacente a tudo isto. Se desativar um sistema é assim tão complicado, vale a pena perguntar-se honestamente, antes do lançamento, se a carga de trabalho precisava mesmo da sua própria cadeia. Muitos casos de utilização que exigem “evidência de adulteração” são melhor atendidos por uma base de dados verificável ou por um registo de transparência com uma referência externa. Nesses casos, não há nenhum sequenciador para desligar.

- O que deve incluir o plano de contingência mínimo para qualquer L2 antes do lançamento da mainnet: comunicação, reivindicações de ponte, coordenação de DeFi, política de stablecoins ou algo mais?

Um manual de encerramento adequado da L2 deve descrever todo o processo, desde o primeiro aviso até ao prazo final para a apresentação de reclamações. As equipas têm de decidir atempadamente quando os utilizadores serão notificados, durante quanto tempo a ponte permanecerá aberta, quando será efetuado o instantâneo final, como funcionarão as reclamações da L1 e o que acontecerá aos fundos que não forem reclamados.

A DeFi merece um plano específico. Os protocolos devem explicar se os utilizadores podem efetuar levantamentos em caso de emergência, como as posições podem ser liquidadas e o que acontece aos tokens LP, às participações no cofre, às garantias e à dívida caso a rede deixe de processar transações.

As stablecoins precisam da mesma clareza. Os ativos transferidos através de pontes e os ativos emitidos nativamente comportam-se de forma muito diferente quando uma rede é desativada, pelo que os utilizadores devem saber exatamente quais as regras que se aplicam a cada token.

- Nestas situações, qual é normalmente a parte mais difícil: interromper tecnicamente a rede, atribuir legalmente a responsabilidade ou resolver economicamente a questão da liquidez congelada?

Desligar a rede é provavelmente a parte mais simples de todo o processo. Os verdadeiros problemas começam quando se analisa quem ainda tem dinheiro investido, onde esse dinheiro se encontra e quem tem o direito de tomar decisões a esse respeito.

Do ponto de vista jurídico, a responsabilidade torna-se muito rapidamente difusa. A equipa da L2 gere a infraestrutura, mas não é proprietária de todos os protocolos DeFi construídos sobre ela. Do ponto de vista económico, a situação torna-se ainda mais complexa, porque a DeFi pode criar várias camadas de direitos sobre a mesma liquidez subjacente. Se essa liquidez for limitada, estiver bloqueada ou já tiver sido comprometida de diferentes formas, alguns direitos simplesmente não podem ser honrados na totalidade.

Assim, a tarefa mais difícil é encontrar uma forma justa de lidar com a liquidez congelada sem pagar duas vezes pelo mesmo ativo subjacente, sem criar novos passivos e sem obrigar a equipa de infraestruturas a agir como um juiz para cada protocolo do ecossistema.

- Como achas que este caso irá afetar a confiança nos L2 de menor dimensão e nos ecossistemas de zk-rollup com baixo TVL?

Este caso fará com que as L2 mais pequenas pareçam muito menos “seguras por defeito”. Um TVL baixo já suscita dúvidas. Agora, os utilizadores têm outra questão a colocar: se esta rede entrar em declínio, será que consigo realmente sair dela?

No caso dos zk-rollups, a confiança não se resumirá apenas à tecnologia, às taxas e à velocidade. A dependência do sequenciador, os pedidos de reembolso das pontes, as vias de saída da DeFi e a gestão das stablecoins passam a fazer parte da lista de verificação. Um rollup tem agora de provar que as pessoas podem sair da mesma forma simples com que entraram.

A experiência do Andrew em ação

Mais sobre este tema

Blogue

Como transferir USDT de Tron para EVM sem ficar preso pela liquidez

Blogue

Cadeias de bloqueio da camada 2 de topo: encontre a solução ideal para o seu projeto

Blogue

O que é um DID? Um guia sobre a identidade digital

Contactar-nos

Marcar uma chamada ou preencha o formulário abaixo e entraremos em contacto consigo assim que tivermos processado o seu pedido.

Nome

Empresa

Correio electrónico

Telefone

Mensagem

Envie-nos uma mensagem de voz

Anexar documentos

Enviar ficheiro

Pode anexar um ficheiro com um máximo de 2MB. Formatos de ficheiro válidos: pdf, jpg, jpeg, png.

Ao clicar em Enviar, o utilizador autoriza a Innowise a processar os seus dados pessoais de acordo com a nossa Política de privacidade para lhe fornecer informações relevantes. Ao enviar o seu número de telefone, o utilizador aceita que o possamos contactar através de chamadas de voz, SMS e aplicações de mensagens. Poderão ser aplicadas tarifas de chamadas, mensagens e dados.

Pode também enviar-nos o seu pedido
para contact@innowise.com

O que é que acontece a seguir?

Assim que recebermos e processarmos o seu pedido, entraremos em contacto consigo para necessidades do seu projeto e assinar um NDA para garantir a confidencialidade.

Depois de analisarmos os seus desejos, necessidades e expectativas, a nossa equipa elaborará uma proposta de projeto proposta de projeto com o âmbito do trabalho, dimensão da equipa, tempo e estimativas de custos.

Marcaremos uma reunião consigo para discutir a oferta e acertar os pormenores.

Por fim, assinaremos um contrato e começaremos a trabalhar no seu projeto imediatamente.