Como a Polygon pretende devolver 70 milhões de POL roubados para carteiras de recuperação

Dois roubos deixaram milhões de POL em cinco endereços bloqueados. Uma proposta da Polygon moveria esses saldos para carteiras de recuperação alterando as regras da rede em um bloco específico. Levar os tokens até lá resolveria uma parte da recuperação. Devolvê-los aos clientes é uma tarefa separada.

Uma proposta de melhoria da Polygon identificou 70,49 milhões de POL em cinco endereços bloqueados que um hard fork coordenado poderia mover para carteiras de recuperação designadas para a Binance e a Polymarket.

A proposta descreve uma alteração nos saldos de POL nativo em um bloco fixo. O software zeraria os cinco saldos listados e creditaria os valores correspondentes em endereços de recuperação verificados.

A distinção é entre um saldo que a rede impediu de se mover e um que uma equipe de recuperação pode controlar. Para os clientes, há uma distinção adicional entre tokens que chegam a uma carteira de recuperação e uma plataforma que reconhece e paga uma reivindicação.

Como os dois incidentes se somam

A proposta atribui 46,63 milhões de POL em um endereço ao incidente da Binance e 23,86 milhões em quatro endereços ao incidente da Polymarket. Somando esses números arredondados, chega-se a 70,49 milhões de POL. Dividindo cada um por esse total, a participação da Binance fica em cerca de 66,2% e a da Polymarket em 33,8%.

Essas são participações da recuperação proposta, não medidas das perdas totais dos dois incidentes. Uma estimativa em dólares também depende do carimbo de data/hora e do preço utilizados. As quantidades na proposta são denominadas em POL.

Os endereços importam mais do que o valor em dólares manchete

Os saldos de referência da proposta totalizam 70.489.329,34 POL. O endereço da Binance responde por 46.626.593,27 POL, enquanto os quatro endereços da Polymarket respondem por 23.862.736,07 POL. Esses são saldos em blocos de referência escolhidos pelos autores. A transferência anterior de uma carteira quente da Binance foi ligeiramente menor do que o saldo subsequentemente registrado no endereço destinatário.

Uma diferença de quatro tokens em uma transferência de mais de 46 milhões mal mudaria a manchete. Isso importa para um implementador porque há dois números possíveis a codificar: o valor rastreado a partir do remetente e o saldo total no destino. A proposta descreve o último como o valor a ser lido do estado imediatamente antes da ativação, com um snapshot precedente a ser publicado para que as alterações sejam visíveis. O rascunho deve, portanto, ser lido como um procedimento para determinar o valor final, juntamente com uma tabela que estabelece o valor aproximado em discussão.

O número da Polymarket apresenta um problema de medição separado. A proposta situa o incidente em cerca de 28 milhões de POL e os quatro saldos selecionados em aproximadamente 23,86 milhões de POL. Em relação a essa estimativa arredondada do incidente, o valor selecionado representa cerca de 85%, deixando uma diferença de aproximadamente 4,14 milhões de POL. Essa subtração mede a lacuna entre a estimativa do incidente e os saldos selecionados. Ela não pode estabelecer para onde foram os tokens restantes ou se alguns poderiam ser recuperados por outra via.

Uma conversão em dólares acrescenta outra variável. A US$ 0,092 por POL, o saldo de referência valeria cerca de US$ 6,49 milhões. A US$ 0,096, os mesmos tokens valeriam cerca de US$ 6,77 milhões. O cálculo multiplica a quantidade de referência da proposta por dois preços ilustrativos. Ele explica como valores em dólares próximos de US$ 6,5 milhões e US$ 6,8 milhões poderiam descrever quase a mesma transferência proposta. A cobertura inicial situou o valor em torno de US$ 6,5 milhões. Uma decisão de pagamento precisaria de uma data de avaliação e de uma fonte de preço explícitas.

O que o fork proposto deixaria para trás

A recuperação proposta cobre cerca de 85% dos aproximadamente 28 milhões de POL atribuídos ao incidente da Polymarket na publicação do fórum. É tentador descrever os 15% restantes como um valor que o fork não conseguiria recuperar. A comparação mais precisa é entre um número aproximado do incidente e os saldos que os autores dizem ainda estarem mantidos em quatro endereços. Seria necessário um exercício de rastreamento separado para explicar a diferença.

A comparação com a Binance é diferente. A proposta identifica uma transferência de 46.626.589,6 POL de uma hot wallet e um saldo de 46.626.593,27 POL no destinatário quando o snapshot de referência foi tirado. O saldo de destino era aproximadamente 3,67 POL maior do que essa transferência. A diferença é pequena o suficiente para desaparecer em qualquer manchete arredondada, mas ajuda a explicar por que um snapshot tirado em um bloco especificado é mais útil do que citar um valor da transação original.

Uma segunda lição está nas unidades. A tabela de referência usa POL nativo, enquanto a transferência anterior da Binance também incluía 6.185.900,1 USDT. Um total em dólares que incluísse ambos cobriria um conjunto diferente de ativos em relação ao fork proposto. Um relatório sobre dinheiro bloqueado poderia razoavelmente discutir ambos, desde que deixe claro qual organização tomou cada ação e se os fundos se moveram posteriormente.

Os dois casos também compartilham um mecanismo de ativação sem compartilhar uma única conta. O software da Polygon creditaria endereços de recuperação separados, preservando a distinção entre os saldos atribuídos a cada incidente. Os destinatários poderiam, portanto, conciliar o que receberam com suas próprias reivindicações e registros de compensação. A publicação do fórum não combina as reivindicações decorrentes dos dois incidentes nem dá a uma plataforma autoridade sobre os proventos da outra.

O que um saldo bloqueado pode nos dizer

Um bloqueio pode impedir que um endereço listado transfira fundos enquanto o saldo ainda aparece na chain. Um observador pode ver quanto resta em um endereço sem conseguir determinar quanto qualquer cliente individual tem a receber.

Os cinco saldos definem o escopo desta proposta. Um ativo envolvido em qualquer um dos incidentes, mas fora desses saldos, precisaria de sua própria via de recuperação.

O que o registro de transferências pode estabelecer

A proposta descreve duas transferências nativas às 18:30:34 e 18:35:59 UTC de 29 de outubro. Juntas, elas moveram 3.282.275,71 POL de um endereço para outro. Dois carimbos de data e hora importam porque ajudam a estabelecer a sequência em que os saldos se espalharam pelas carteiras. O histórico de transações pode mostrar movimentação e valores mesmo quando as pessoas que controlam as chaves são mais difíceis de identificar.

A proposta vincula os endereços listados aos incidentes. Para uma verificação independente, um revisor precisaria acompanhar os registros de transação nomeados e comparar os endereços de origem com as contas identificadas pelas plataformas afetadas. Isso é mais específico do que ver várias carteiras movimentando dinheiro no mesmo dia. Também é distinto de provar uma reivindicação legal sobre cada moeda ainda em uma conta.

Um endereço que continha POL nativo e uma stablecoin pode ilustrar os limites da linguagem em nível de carteira. O emissor da stablecoin pode agir por meio do contrato da stablecoin. O POL nativo faz parte da contabilidade de saldos da rede. Os dois ativos compartilham um endereço, mas as pessoas que podem impedir transferências, e o mecanismo que podem usar, dependem do que o ativo é.

A proposta descreve outros endereços fornecidos pela Binance como Classe B. Eles pertencem à discussão de bloqueio, enquanto as mudanças de estado do rascunho estão limitadas aos endereços de Classe A especificados para recuperação. Contar cada endereço bloqueado como uma carteira que seria esvaziada superestimaria o escopo. Também obscureceria uma questão de governança importante: bloquear uma transação é uma ação, enquanto decidir que um saldo específico deve ir para um destinatário nomeado é outra.

Por que dois ativos exigiram respostas diferentes

A cronologia da proposta da Polygon rastreia 46.626.589,6 POL nativos e 6.185.900,1 USDT de uma hot wallet da Binance para o mesmo destinatário no bloco 96.406.484. A Tether congelou o USDT. O POL permaneceu como objeto da intervenção de rede proposta.

A transferência proposta aborda os diferentes controles disponíveis sobre esses dois ativos. Um emissor pode impor restrições por meio do sistema que opera para seu token. Neste caso, os produtores de bloco da Polygon usaram, em vez disso, um filtro de transações Bor para POL nativo, e a proposta descreve esse filtro como uma solução paliativa.

Cada produtor de bloco lê a lista na inicialização, de acordo com a proposta. Alterações exigem implantação e uma reinicialização ou rotação, e o filtro cobre remetentes externos e autoridades EIP-7702. A proposta afirma que o snapshot será relido antes da ativação, de modo que sua tabela publicada é uma referência e não uma garantia dos valores finais de débito.

Por que um filtro de transações pode durar dias e ainda assim ser temporário

A lista dos produtores de bloco depende de configuração de software. A proposta afirma que a lista é lida na inicialização. Uma nova entrada, portanto, exige uma mudança operacional, e os operadores precisam aplicar a mesma configuração para que as restrições funcionem conforme o pretendido. O esforço envolvido pode ser justificado durante um incidente em andamento, quando cada hora dá a uma pessoa que detém as chaves outra chance de mover fundos.

Uma restrição na camada do produtor também precisa corresponder à forma como uma transação pode ser autorizada. A proposta afirma que o filtro cobre remetentes externos e autoridades EIP-7702. Essa é uma afirmação mais restrita do que dizer que os fundos foram tornados impossíveis de mover sob qualquer caminho de transação concebível. O que os autores relatam é que os fundos foram detidos e que não encontraram nenhuma forma de contorno. Eles identificam limitações na abordagem como parte de seu argumento para uma mudança mais duradoura.

Os autores descrevem uma transação pendente carregando uma taxa proposta excepcionalmente alta e tentativas de obter assistência de validadores. Uma transação tentada é evidência de um esforço para alterar o status do saldo. Ela carrega um peso probatório diferente de uma transferência executada. A proposta também descreve um canal de recuperação onchain sem resposta. Um retorno negociado teria dependido de uma resposta de uma parte capaz de autorizar o pagamento, enquanto a proposta de fork funcionaria por meio de participantes adotando novas regras.

Uma lista indefinida tem consequências práticas para as pessoas que a administram. Elas precisariam saber quais entradas ainda servem a um propósito, como novos operadores obtêm a configuração correta e quem é responsável por revisar entradas antigas. A proposta do fórum prevê uma revisão após a recuperação, incluindo tratamento distinto para os endereços adicionais. Isso significa que a proposta diz respeito tanto a uma mudança única de saldo quanto ao que acontece com os controles temporários em torno dela.

O que muda no bloco do fork

Normalmente, uma transferência altera os saldos das contas após uma transação válida ser aceita sob as regras da rede. A proposta, em vez disso, pede que o software que segue as regras atualizadas aplique os débitos e créditos listados como parte do processamento de um bloco especificado.

Os créditos correspondentes importam. A operação conforme descrita retira o mesmo número de tokens nativos dos endereços listados que concede aos endereços de recuperação designados. O escopo não se estende a tokens arbitrários nas carteiras.

O bloco que registraria a recuperação

A mudança de estado proposta é ordenada em torno do bloco de ativação, que o rascunho chama de F. O valor relevante é o saldo após F menos um. Nós atualizados aplicariam os ajustes de saldo prescritos antes das transações ordinárias em F. Essa sequência importa porque identifica o limite exato que um revisor usaria para verificar o resultado.

Uma transferência normal geralmente fornece a um explorador uma entrada de transação para exibir. Uma alteração aplicada diretamente sob as regras da cadeia pode, em vez disso, ser visível comparando saldos entre blocos adjacentes. Alguém que olhe apenas para a lista de transferências ordinárias do destinatário pode não percebê-la. A publicação proposta de um script de verificação ajudaria a conectar o estado anterior e posterior com a lista de destinatários pretendidos.

A verificação precisa cobrir ambos os lados do livro-razão. Ela procuraria um débito e crédito correspondentes para cada saldo. Se um endereço de recuperação também recebeu transações ordinárias no mesmo bloco, a diferença bruta entre dois instantâneos poderia incluir esses movimentos. Um revisor precisaria então separá-los da alteração de estado especial, em vez de tratar cada incremento como fundos recuperados.

O bloco de ativação é um prazo de coordenação. Um operador executando software que calcula o estado antigo e um operador aplicando a regra especial de saldo poderiam calcular resultados diferentes a partir do mesmo bloco. O trabalho prático, portanto, inclui publicar a alteração, dar aos operadores tempo para revisá-la e deixar claro o ponto de ativação. A tabela da proposta ainda rotula o bloco como uma decisão a ser tomada uma vez que a aprovação esteja em vigor. Uma discussão de governança é uma oportunidade para resolver esse plano, enquanto o estado da cadeia estabeleceria a execução.

Quem faz a alteração entrar em vigor

A proposta do fórum descreve a alteração solicitada. Um marco separado seria uma versão que a implementa e identifica o bloco de ativação. Os operadores teriam então que adotar software compatível para que a alteração entre em vigor na cadeia que utilizam.

Um usuário que acompanha a proposta deve, portanto, distinguir uma postagem no fórum, uma implementação e um bloco que realmente reflita os novos saldos. Cada um responde a uma pergunta diferente sobre a recuperação.

O trabalho por trás da escolha de um bloco de ativação

Um número de bloco pode parecer um detalhe administrativo. Na prática, é onde o novo software e o software antigo começam a divergir sobre os saldos das contas afetadas. Escolhê-lo dá aos operadores um prazo compartilhado para instalar a atualização, e dá aos exploradores, provedores de infraestrutura e às empresas afetadas um ponto comum a partir do qual verificar o resultado.

A preparação proposta na postagem do fórum envolve confirmar os destinos, manter os arranjos de bloqueio em vigor até a ativação e publicar um novo instantâneo de saldo. Essas etapas abordam diferentes maneiras pelas quais uma recuperação pode dar errado. Um endereço registrado incorretamente poderia enviar ativos para algum lugar não intencional. Uma alteração inexplicada em um saldo poderia deixar os leitores comparando o resultado com um número desatualizado. Uma atualização atrasada poderia deixar um operador calculando o estado usando as regras antigas.

Cada uma dessas questões exige uma verificação diferente. Para o destino, a evidência importante é como o destinatário demonstra controle e como o endereço publicado é revisado. Para o valor, é o saldo no ponto de referência final. Para a rede, é quais versões de software realmente processam blocos após o ponto de ativação. Uma declaração de que os operadores apoiam a recuperação não responderia a nenhuma dessas questões de implementação por si só.

Há também uma verificação útil após o evento. A alteração de estado afetaria diretamente os saldos nativos, enquanto um pagamento ordinário feito no mesmo bloco poderia afetar o mesmo destinatário. Uma diferença de saldo, portanto, precisa ser reconciliada com as transações ordinárias naquele bloco. É aí que o script de verificação proposto pelos autores seria útil, particularmente se identificar tanto o débito quanto o crédito correspondente para cada conta.

Onde os clientes entram no processo

O destinatário da transferência proposta é um endereço de recuperação, não uma lista de contas de clientes. Uma vez que um operador controla os fundos, a próxima pergunta é como seu próprio processo de recuperação e reembolso os contabiliza.

Evidências relevantes incluiriam um cronograma de reivindicações, instruções para comprovar uma perda e uma política sobre a data de avaliação. Uma plataforma pode já ter reembolsado alguns usuários com outros fundos. Sua contabilidade precisaria estabelecer para onde vai o POL recuperado nesses casos.

O que conta como um retorno aos clientes

Uma carteira receptora é onde a capacidade da rede de mover os fundos encontra a responsabilidade de uma organização de contabilizá-los. Se os clientes afetados já foram reembolsados com os próprios recursos de uma exchange, a recuperação poderia reabastecer esses recursos sob os termos aplicáveis. Se eles têm reivindicações pendentes, uma distribuição poderia, em vez disso, reduzir o valor que lhes é devido. Ambos os cenários envolvem dinheiro chegando a um endereço de recuperação, com consequências diferentes para os usuários.

Também pode haver uma divergência entre o ativo recuperado e o ativo que um cliente perdeu. Um usuário cujo saldo original era denominado em dólares ou em outro token precisaria saber se a compensação é calculada em unidades desse ativo original, em POL ou em dinheiro a um preço declarado. Um token volátil pode produzir resultados materialmente diferentes dependendo de quando a conversão é medida.

A distinção entre saldos de clientes e perdas da plataforma é especialmente importante quando incidentes separados são combinados em uma única proposta. A tabela de referência aloca os saldos da Polygon por incidente. Ela não contém um pool conjunto de reivindicações nem um cálculo dos valores devidos a usuários individuais. Mesmo que ambos os conjuntos de saldos se movam no mesmo bloco de ativação, as plataformas podem enfrentar obrigações diferentes e podem anunciar arranjos de pagamento diferentes.

As evidências públicas podem ser ordenadas pelo que cada etapa provaria. Uma altura de liberação e ativação mostraria que uma implementação está pronta. O estado do bloco mostraria se o livro-razão mudou. Registros da plataforma estabeleceriam se os ativos recuperados foram distribuídos, retidos contra compensações anteriores ou contabilizados de outra forma. O rascunho do fórum torna seus destinos pretendidos no nível da cadeia específicos para cada incidente e prevê verificação pública das mudanças de saldo.

Quem pode decidir quanto vale um token recuperado?

Suponha, a título de ilustração, que uma plataforma deva a um usuário o valor em dinheiro de um saldo e receba POL depois que o preço mudou. Há pelo menos três datas às quais a plataforma pode se referir: o momento do roubo, o momento em que obtém os tokens recuperados e o momento em que faz uma distribuição. O valor em dinheiro representado pela mesma quantidade de POL pode diferir em cada um desses pontos.

Uma política de reivindicações poderia, em vez disso, prever o pagamento em unidades do ativo que foi perdido. Isso evita escolher um preço de mercado para uma reivindicação denominada no mesmo ativo, mas ainda deixa questões sobre elegibilidade e reembolsos anteriores. Um cliente que já havia sido reembolsado poderia ter uma posição diferente da de alguém cuja reivindicação permanece pendente. A rede não tem papel na tomada dessas determinações.

O que um cliente precisa é de uma declaração do que a plataforma deve, em qual unidade e como ela contabiliza qualquer coisa paga anteriormente. A cadeia pode estabelecer que um endereço de recuperação recebeu um saldo, e a plataforma pode reconciliá-lo com seus registros. Nenhum documento faz o trabalho do outro. Essa é uma das razões pelas quais uma recuperação confirmada pode ser notícia mesmo que ainda haja uma espera separada por detalhes de uma distribuição.

Uma comparação de relatórios pode manter os números lado a lado. O primeiro seria o POL nativo recuperado sob a mudança de estado. O segundo seria o valor atribuído a reivindicações de clientes ou a reembolsos já feitos. O terceiro seria qualquer saldo que permaneça sob custódia enquanto a plataforma resolve casos individuais. Um único número em dólares retirado da primeira etapa diria pouco aos leitores sobre os outros dois.

Por que o escopo restrito importa

Um fork que altera saldos levanta uma questão que uma atualização normal de software não levanta. Quais fatos teriam de estar presentes para que os participantes apoiassem essa intervenção novamente?

A própria proposta descreve a ação como extrema e a limita aos saldos listados de POL nativo. O argumento a favor da proposta e a questão do precedente podem ambos ser avaliados com base nos mesmos detalhes concretos: os endereços identificados, o destino proposto e o bloco no qual os saldos mudariam.

O que tornaria este caso um precedente?

Outro projeto poderia apontar para a abordagem da Polygon após um roubo, mas as circunstâncias neste rascunho são incomumente específicas. Os autores identificam os incidentes, as contas listadas, os ativos sujeitos à mudança proposta e para onde iriam. Eles também descrevem por que a restrição já em uso era apenas uma medida temporária. Uma proposta sem esses elementos apresentaria um caso diferente para alterar saldos.

A questão importante é quem precisa ser persuadido e quais informações recebem. Uma exchange pode saber quais saldos de clientes foram afetados, enquanto os operadores precisam de evidências sobre a mudança proposta na cadeia. Um usuário cujos fundos são recuperados está interessado no resultado. Um operador que avalia a proposta também precisa pensar em como avaliaria uma solicitação futura de uma parte diferente.

A comparação mais segura é entre os fatos que outra solicitação poderia demonstrar. Ela consegue identificar o valor em um bloco específico? Consegue vincular esses fundos a um incidente reconhecido? Consegue verificar um destinatário e especificar o que acontece com endereços já bloqueados? Essas perguntas decorrem diretamente do rascunho publicado e são mais úteis do que descrever cada mudança de estado incomum como equivalente.

A proposta deixaria algumas dessas perguntas testáveis em público. Uma altura de ativação permitiria aos observadores identificar a transição de estado exata. Destinos nomeados permitiriam rastrear o que aconteceu depois dela. Os autores também propõem revisar as entradas na lista de bloqueio temporária após a ativação, incluindo tratamento diferente para os endereços adicionais relacionados à Binance. Essa revisão final ajudaria a estabelecer quais restrições emergenciais permanecem em uso após a conclusão da recuperação.

O que o ledger poderia confirmar

Se a proposta for implementada, a primeira verificação compararia os saldos dos endereços listados em ambos os lados do bloco de fork. Créditos correspondentes mostrariam que o ledger aplicou a transferência conforme especificado. As distribuições aos clientes precisariam de evidências dos operadores de recuperação.

A proposta atual especifica cinco endereços de origem e endereços de recuperação designados para os dois incidentes.

Quais registros respondem a qual pergunta de recuperação

Um incidente pode percorrer esses estágios em velocidades diferentes. O congelamento do USDT, por exemplo, diz respeito a um ativo e a um mecanismo diferentes do fork POL proposto. Um anúncio posterior sobre fundos protegidos ou recuperados precisaria especificar qual ativo foi contabilizado e o que aconteceu com ele.

Os saldos também podem mudar entre as datas usadas no relatório. Uma proposta que cita um snapshot anterior deve preservar o número do bloco para que os leitores possam reproduzir o valor mesmo que o saldo atual mude. Quando o resultado for conhecido, comparar o bloco de execução com o snapshot publicado estabeleceria se o valor devolvido difere do valor discutido na proposta.

A reconciliação mais importante para os leitores é entre o valor debitado e o valor creditado. Publicar essa verificação separadamente para os dois incidentes permitiria comparar o relato posterior de cada plataforma sobre os proventos com o valor sobre o qual ela efetivamente obteve controle. Um único total combinado tornaria mais difícil acompanhar quais proventos estavam disponíveis para atender a quais reivindicações.

Uma recuperação restrita também dá às plataformas uma forma de comunicar o que aconteceu com ativos fora do fork. O valor da Polymarket no post do fórum inclui mais POL do que está listado na mudança de estado proposta. A transferência da Binance incluiu USDT, que a Tether tratou separadamente. Uma atualização de recuperação que identifique o ativo relevante, o endereço e a ação tomada permitiria aos leitores reconciliar ambos os incidentes sem presumir que todos os fundos roubados seguiram uma única rota.

A cronologia apresenta três datas com significados diferentes. A data do incidente estabelece quando os fundos se moveram. O bloco de referência estabelece o que foi observado nos endereços quando os autores compilaram a proposta. A data de ativação, se acordada, estabeleceria quando a rede aplica a regra de recuperação. Um token pode ser protegido contra certas transferências entre essas datas sem ter sido devolvido nesse meio-tempo.

Os registros de endereços também podem servir como verificação das declarações feitas após uma atualização. Se um operador afirmar que os fundos foram enviados ao destino publicado, a blockchain deve mostrar a mudança de saldo correspondente na altura de ativação. Se disser que os clientes foram reembolsados, a evidência mais útil é um registro de distribuição ou um relato claro dos reembolsos. Um é uma declaração sobre a rede, o outro sobre as obrigações da plataforma.

É por isso que a evidência do livro-razão é especialmente valiosa quando a conversa pública se volta para saber se o fork funcionou. Ela oferece aos observadores uma questão restrita que podem verificar sem esperar que cada empresa afetada conclua sua própria contabilidade. A proposta estabelece um procedimento para publicar os saldos usados na mudança de estado e para verificar os créditos dos destinatários depois dela. Esses registros também dariam aos usuários um ponto de partida para rastrear o que cada plataforma fez depois de ter o controle do dinheiro.

O que observar

• Proposta de liberação: As quantidades específicas do incidente, os endereços destinatários propostos e as instruções executáveis submetidas à governança.
• Bloco de ativação: A altura de bloco confirmada e a versão de software que os operadores da Polygon precisariam instalar antes dele.
• Créditos de recuperação: O POL nativo debitado de cada endereço bloqueado e o crédito correspondente registrado em seu destinatário designado.
• Reivindicações de clientes: As instruções de cada plataforma sobre elegibilidade, avaliação e como contabilizará reembolsos anteriores.

Perguntas frequentes