A Polygon propôs recuperar cerca de 70 milhões de POL mantidos em cinco carteiras associadas a ataques, sem exigir assinaturas dos titulares. O plano alteraria os saldos pelas regras da rede e enviaria os valores a endereços indicados por Polymarket e Binance. Para isso, a governança aprovaria a lista de endereços e os validadores adotariam o software correspondente. Assim, a medida permitiria movimentar os recursos sem transações assinadas pelas contas de origem.

Publicada em 4 de novembro, a proposta relaciona quatro endereços ao incidente da Polymarket e um ao caso da Binance. No total, as tabelas atribuem cerca de 24 milhões de POL às contas ligadas à Polymarket. O endereço associado à Binance concentra aproximadamente 47 milhões de POL. Contudo, a recuperação consideraria os saldos existentes no momento da ativação, e não os valores históricos das tabelas.

Até 9 de novembro, a proposta não definia o nome do fork, a versão do cliente nem o bloco de ativação. A agenda de governança de 5 de novembro apenas incluiu o tema para discussão e não registrou aprovação. Já a versão Bor v2.11.0 implementa mudanças no StateReceiver da Uburu, mas não executa a recuperação. Portanto, a Polygon ainda precisa concluir várias etapas antes de aplicar a medida.

Como a Polygon pretende recuperar os POL

Segundo a proposta de recuperação, o software atualizado consultaria o saldo de cada endereço antes da ativação. Em seguida, o sistema zeraria essas contas e creditava os mesmos montantes nos endereços de recuperação. A regra entraria em vigor antes das transações comuns do bloco escolhido. Com isso, a rede executaria a alteração sem uma transferência convencional assinada.

O mecanismo manteria inalterada a oferta total de POL. A rede também preservaria todo o histórico anterior da blockchain. Ainda assim, a equipe de engenharia do Bor precisa confirmar o desenho técnico antes da implementação.

As empresas afetadas indicariam os destinatários, enquanto a Polygon Labs verificaria o controle das novas carteiras. Por exemplo, cada empresa poderia assinar uma mensagem ou confirmar uma pequena transferência de teste. Depois, o destinatário também precisaria fornecer uma confirmação escrita sobre a propriedade do endereço.

Riscos da alteração de saldos na rede

A proposta separa o rastreamento dos recursos roubados da verificação dos endereços de destino. Identificar uma carteira sob controle de um invasor pode justificar sua inclusão na lista. No entanto, uma identificação incorreta poderia deslocar o saldo legítimo de terceiros.

Qualquer POL depositado nos endereços listados antes da ativação também entraria na transferência. Por isso, os responsáveis precisariam verificar novamente os saldos e divulgar eventuais mudanças. Essas revisões mostrariam os valores abrangidos, mas não comprovariam que depósitos posteriores pertencem às vítimas.

O texto também exclui outros tokens e outra categoria de endereços bloqueados. Assim, o escopo permaneceria restrito ao POL nativo mantido nas cinco contas. A ativação ainda exigiria aprovação da governança, manutenção das listas de bloqueio e divulgação dos saldos atualizados.

Custodiantes terão de registrar um ajuste separado

Para exchanges e custodiantes, a mudança criaria uma diferença nos registros contábeis. Um nó atualizado exibiria o novo saldo, mas uma reconstrução baseada apenas em transações comuns não mostraria a alteração. Nesse caso, exploradores, indexadores e sistemas contábeis precisariam registrar um ajuste separado no bloco de ativação.

Primeiro, os desenvolvedores testariam a mudança na Amoy para confirmar a preservação da oferta e das contas não relacionadas. Depois, a equipe reproduziria o procedimento em um fork da rede principal. Posteriormente, os responsáveis publicariam o ajuste de saldo sem transação. Também disponibilizariam um script para verificar os resultados.

Reembolsos seguem separados da proposta

Enquanto isso, o reembolso dos clientes continua como um processo separado. Em seu relatório de 30 de outubro, a Polymarket informou que reembolsou integralmente 95% das carteiras afetadas naquela tarde. A empresa também anunciou a devolução de US$ 4 milhões, incluindo US$ 1 milhão por perdas relacionadas à pausa.

Esses pagamentos compensam os traders, enquanto o fork proposto devolveria os recursos a endereços corporativos de recuperação. Portanto, a governança ainda precisa tomar uma decisão e aprovar uma especificação final do software. Antes disso, as empresas devem verificar os destinatários, e os desenvolvedores precisam definir o bloco de ativação. Até lá, a recuperação permanece apenas como proposta.

	Receba nossas últimas notícias em primeira mão.   Adicione-nos como sua fonte preferida no Google    e toque em “Favorito” para priorizar nossas atualizações.