Hack da Liquid Network Drena US$ 320 Milhões e Depois Devolve a Maior Parte dos Bitcoin

O hack da Liquid Network retirou quase 4.000 BTC da carteira da federação da sidechain em 6 de setembro, representando cerca de 95% de suas reservas reportadas. Os agentes não identificados se autodenominaram white hats e exigiram uma correção de software antes de devolver o dinheiro.

Inicialmente, essa alegação ofereceu pouca segurança. A retirada já havia convertido Liquid Bitcoin aparentemente sem lastro em bitcoin real por meio de um processo autorizado de peg-out. A Liquid pausou a atividade da rede, enquanto exchanges suspenderam depósitos e retiradas envolvendo seu ativo lastreado em Bitcoin.

A história então mudou. Os agentes devolveram 3.400 BTC depois que a Blockstream afirmou que os nós de ponte afetados haviam sido corrigidos. No entanto, aproximadamente 598,5 BTC, avaliados em cerca de US$ 47 milhões quando noticiados, permaneciam sob seu controle em 8 de setembro.

Não se tratou de um comprometimento da própria rede Bitcoin. Foi uma falha dentro da Liquid, uma sidechain federada que usa software e operadores designados para conectar seu ativo interno ao Bitcoin. A distinção protege a camada base do Bitcoin do incidente, mas também expõe a promessa central que a Liquid agora precisa reparar.

O Hack da Liquid Network Transformou uma Retirada Válida em Drenagem de Reserva

O fato determinante não é simplesmente que bitcoin foi movimentado, mas que a maquinaria normal de resgate da Liquid aparentemente aprovou a movimentação.

A Liquid Network divulgou que aproximadamente 4.000 BTC, então avaliados em cerca de US$ 320 milhões, haviam sido retirados de sua carteira da federação. Antes do incidente, a carteira supostamente continha cerca de 4.200 BTC.

A retirada, portanto, removeu aproximadamente 95% do saldo dessa carteira. Segundo a reportagem inicial sobre o incidente de segurança, a Liquid desativou nós de ponte e coordenou com exchanges para interromper depósitos e retiradas de L-BTC.

Liquid Bitcoin, normalmente escrito como L-BTC ou LBTC, representa bitcoin transferido para a sidechain Liquid. A documentação da Liquid afirma que cada LBTC deve ser lastreado por uma quantidade equivalente de BTC mantida pela federação.

O processo de conversão é chamado de peg bidirecional. Um peg-in bloqueia bitcoin e cria o LBTC correspondente. Um peg-out destrói LBTC e libera bitcoin da carteira da federação.

Os agentes aparentemente atacaram a contabilidade antes da retirada, em vez de roubar as chaves de assinatura da carteira. A SideSwap afirmou que 4.000 LBTC chegaram ao seu serviço de peg-out com autorização válida. O serviço queimou esses tokens, e a federação liberou cerca de 3.996 BTC para o endereço Bitcoin fornecido.

A SideSwap afirmou que seus sistemas e sua Peg-out Authorization Key não foram comprometidos. Uma Peg-out Authorization Key, ou PAK, restringe retiradas a operadores registrados e formatos de destino aprovados.

Essa distinção importa porque a transação passou pelos canais esperados. A federação não necessariamente viu uma solicitação de retirada obviamente falsificada. Em vez disso, ela teria processado tokens que jamais deveriam ter existido sem garantias correspondentes.

Os agentes não identificados posteriormente inseriram uma breve mensagem em uma transação Bitcoin. Eles afirmaram: “somos whitehats. entre em contato conosco on-chain.”

O campo OP_RETURN do Bitcoin permite que uma transação carregue uma pequena quantidade de dados arbitrários. Neste caso, ele se tornou um canal público de comunicação entre os agentes e a Blockstream.

A Blockstream respondeu com instruções de contato, seguidas de mensagens criptografadas e assinadas criptograficamente. Os agentes então disseram que devolveriam o dinheiro depois que cada nó afetado recebesse uma correção.

Essa sequência tornou o exploit da Liquid Network excepcionalmente visível. Qualquer pessoa podia inspecionar as transações e mensagens, mesmo enquanto as identidades e intenções dos agentes permaneciam desconhecidas.

A drenagem, portanto, produziu dois registros simultâneos. A Liquid e a SideSwap descreveram a resposta operacional, enquanto o Bitcoin preservou a retirada, as mensagens posteriores e a eventual devolução parcial.

O Software Aceitou Bitcoin que Nunca Foi Depositado

A falha reportada rompeu a relação entre a oferta de LBTC e a reserva de bitcoin sem comprometer as chaves da federação.

A SideSwap afirmou que a Blockstream rastreou o incidente até um bug no Elements, o software de código aberto que sustenta a Liquid. Segundo esse relato, a vulnerabilidade permitiu que os agentes criassem LBTC sem lastro.

Esse mecanismo ataca o invariante mais importante em qualquer ponte de ativos. Um sistema jamais deve liberar mais de seu ativo de reserva do que os usuários bloquearam anteriormente.

A documentação de peg da Liquid descreve um modelo estrito de um para um. Cada LBTC deve corresponder a bitcoin mantido pela federação. A destruição de um LBTC deve liberar um BTC.

Se o software aceita uma transação inválida que aumenta a oferta da sidechain, essa garantia falha antes do início do peg-out. O atacante pode então apresentar LBTC recém-criados a um serviço legítimo de retirada.

O serviço de retirada vê tokens autorizados. Ele os queima conforme projetado e solicita que a federação libere bitcoin real. Cada componente pode aparentar cumprir sua função atribuída, embora o resultado de todo o sistema seja inválido.

Esta é a inversão central no hack da Liquid Network. Os controles de autorização aparentemente funcionaram, mas autorizaram uma reivindicação baseada em uma contabilidade de oferta corrompida.

O projeto de multisignature da carteira da federação não evitou esse resultado. Multisignature significa que vários detentores de chaves designados devem aprovar uma transação antes que a reserva possa ser movimentada.

Esse arranjo protege contra uma chave roubada ou um signatário malicioso. Ele não detecta automaticamente uma falha de consenso ou validação anterior que apresenta uma retirada como legítima.

Uma análise on-chain publicada pela Bitquery rastreou dois pequenos peg-ins antes da grande retirada. Os pesquisadores também identificaram atividade de testes e padrões criptográficos repetidos na Liquid antes da transação final.

A reconstrução da transação relatou um pagamento de 3.996 BTC pela federação às 14h28 UTC de 6 de setembro. A análise também documentou as mensagens trocadas após a retirada.

Essas descobertas sugerem preparação, e não uma transação acidental. No entanto, os agentes não se identificaram publicamente nem forneceram uma divulgação técnica completa.

Algumas reportagens associaram a falha à validação de range proofs. Uma range proof é uma evidência criptográfica de que o valor oculto de uma transação confidencial permanece válido e não cria ativos indevidamente.

A Liquid usa Confidential Transactions, que ocultam os ativos e valores transferidos enquanto permitem que os nós da rede verifiquem a validade das transações. Uma falha nesse processo de verificação pode ser especialmente grave porque os nós dependem de provas em vez de valores visíveis.

A causa raiz exata ainda exige um postmortem detalhado da Blockstream. As informações públicas sustentam a conclusão mais ampla de que LBTC sem lastro entrou na rota de peg-out, mas não estabelecem cada etapa técnica.

Essa lacuna de verificação deve permanecer explícita. Uma reconstrução plausível não equivale a uma divulgação completa do fornecedor, uma correção auditada ou uma reprodução independente.

A segurança do Liquid Bitcoin agora depende de provar mais do que a integridade das chaves. A Blockstream precisa mostrar por que os nós aceitaram o estado inválido, quais versões foram afetadas e como a correção bloqueia variantes relacionadas.

A Promessa Um-para-Um da Liquid Está Sob Pressão

O incidente pressiona a Liquid porque sua promessa de produto depende tanto da validação criptográfica quanto do julgamento operacional da federação.

A Liquid foi projetada para oferecer liquidação mais rápida e maior privacidade de transações do que a rede base do Bitcoin. Ela também oferece suporte a ativos como stablecoins e títulos tokenizados.

Esses recursos vêm de uma blockchain separada, com diferentes pressupostos de confiança. Mineradores de Bitcoin não validam transações da Liquid, e as regras de consenso do Bitcoin não impõem a oferta de LBTC.

Em vez disso, a Liquid depende de uma federação de functionaries para assinar blocos e administrar o peg bidirecional. Outros participantes da federação podem fornecer serviços, mas a segurança do sistema não espelha a mineração de Bitcoin.

Esse modelo não é inerentemente defeituoso. Toda sidechain ou ponte introduz pressupostos adicionais de software, governança e custódia. Os usuários aceitam esses pressupostos em troca de capacidades indisponíveis na camada base.

O incidente expôs como esses pressupostos interagem durante uma falha. A Liquid pôde pausar sua rede, desativar nós de ponte, coordenar com exchanges, distribuir uma correção e negociar com os agentes.

Essas ações limitaram danos adicionais. Elas também demonstraram que a resposta de emergência da Liquid depende de operadores identificáveis que podem interromper a infraestrutura e influenciar a movimentação de ativos.

O próprio Bitcoin não foi pausado. Seus mineradores continuaram processando blocos, incluindo as transações que carregavam as mensagens dos agentes e os fundos devolvidos.

Esse contraste não significa que toda aplicação deva operar diretamente no Bitcoin. Significa que os usuários devem separar a segurança do Bitcoin da segurança de ativos que representam bitcoin em outros ambientes.

A própria visão técnica geral da Liquid descreve nós de ponte, hardware de functionaries, controles de assinatura e mecanismos de recuperação de emergência. A arquitetura combina criptografia com coordenação institucional.

A pressão agora recai sobre a Blockstream e a federação para explicar como essas camadas falharam em conjunto. Dizer que nenhuma chave privada foi comprometida responde apenas a uma parte da questão.

Os usuários também precisam saber por que os signatários liberaram bitcoin para LBTC criados indevidamente. As exchanges precisam de evidências de que a retomada dos depósitos não pode expô-las a uma discrepância de oferta não resolvida.

Os emissores de ativos enfrentam uma preocupação relacionada. A Liquid afirmou que outros ativos emitidos não foram afetados, mas a pausa na rede ainda interrompeu a infraestrutura compartilhada que os transporta.

Um ativo pode permanecer tecnicamente intacto enquanto se torna temporariamente difícil de transferir ou resgatar. A disponibilidade operacional, portanto, passa a fazer parte da avaliação de segurança.

A recuperação parcial melhorou a posição da reserva, mas não apagou o evento. Um sistema anunciado como lastreado um para um perdeu brevemente a maior parte do bitcoin que sustentava essa alegação.

Os 598,5 BTC restantes também deixam uma questão contábil. A Blockstream deve explicar como o montante pendente afeta o lastro de LBTC, os passivos e qualquer compromisso de recuperação.

Um ativo devolvido não reverte a disponibilidade perdida, a incerteza de mercado ou a necessidade de controles em exchanges. Tampouco prova que nenhuma vulnerabilidade relacionada permanece em outro lugar.

Os operadores da Liquid enfrentam tanto uma auditoria técnica quanto um teste de credibilidade. A primeira pergunta se o bug foi corrigido. A segunda pergunta se os usuários podem verificar essa resposta de forma independente.

Uma Devolução Parcial Não Resolve a Questão do White Hat

Devolver 3.400 BTC apoia a intenção declarada dos agentes, mas reter quase 600 BTC impede uma conclusão clara de white hat.

Depois que a Blockstream afirmou que seus nós de ponte haviam sido corrigidos, os agentes transferiram 3.400 BTC de volta para o endereço da federação. A transação restaurou aproximadamente 85% do montante retirado.

Uma atualização sobre a recuperação de 8 de setembro informou que quase US$ 47 milhões em bitcoin continuavam pendentes. As negociações sobre o saldo prosseguiam.

Os responsáveis haviam instruído anteriormente a Blockstream a corrigir primeiro a falha. Disseram que todos os nós precisavam aplicar o patch antes que devolvessem os fundos em segurança.

Essa mensagem se alinha a um aspecto do trabalho de segurança white hat. Publicar ou demonstrar uma vulnerabilidade antes da correção pode expor outros usuários a ataques imitadores.

No entanto, a divulgação responsável convencional normalmente começa com um relatório privado e testes coordenados. Ela não começa com a retirada de 95% da reserva de um sistema sem autorização documentada.

Portanto, o rótulo adotado pelos responsáveis é uma alegação, não uma condição profissional verificada. O uso inicial de “supostos hackers white hat” pela Liquid preservou adequadamente essa incerteza.

Os fundos restantes tornam a questão mais aguda. Nenhuma evidência pública analisada para este artigo estabelece que a Blockstream aprovou uma recompensa de 598,5 BTC.

Sem essa aprovação, reter as moedas pode se assemelhar a uma taxa unilateral, uma ferramenta de pressão nas negociações ou posse continuada de ativos apropriados indevidamente. A devolução parcial, por si só, não determina a motivação ou a responsabilidade legal.

Também não há uma identidade pública pela qual os leitores possam avaliar experiência, autorização ou conduta anterior. Uma assinatura on-chain prova o controle sobre um endereço, não o caráter ético de quem o controla.

Essa ambiguidade tem um precedente histórico. Em 2021, um invasor retirou mais de US$ 600 milhões da Poly Network e depois devolveu a maior parte dos ativos.

A Poly Network chamou esse invasor de white hat e ofereceu uma recompensa. A cobertura contemporânea da Poly Network mostrou como uma grande devolução pode alterar a narrativa pública sem eliminar questões legais ou de governança.

O caso da Liquid não é idêntico. O mecanismo relatado, os ativos, os operadores e as comunicações são diferentes. Ainda assim, ambos os incidentes mostram quão rapidamente “hacker” se torna “white hat” quando a recuperação depende de cooperação.

Essa linguagem pode servir a um propósito prático durante negociações. Atacar publicamente uma contraparte cooperativa pode reduzir a chance de recuperar os fundos.

Ainda assim, a diplomacia operacional não deve substituir a classificação de segurança. Um pesquisador autorizado, um explorador oportunista e um extorsionário podem todos devolver fundos por motivos diferentes.

A evidência útil virá da destinação final dos BTC restantes e de qualquer acordo divulgado. Um relatório técnico completo também poderia esclarecer se os responsáveis tentaram contato privado anteriormente.

Até lá, a descrição mais precisa continua sendo white hats autoidentificados ou supostos. Chamar a operação de teste de segurança aprovado iria além das evidências disponíveis.

O Exploit Reaviva um Problema Antigo para Pontes de Bitcoin

A arquitetura da Liquid difere da de muitas pontes cripto, mas a falha segue um padrão conhecido: uma reivindicação falsa chegou a uma reserva que detinha ativos reais.

Sistemas cross-chain concentram riscos porque traduzem atividade entre ambientes com regras de segurança diferentes. Um sistema precisa decidir se um evento em outro sistema justifica a liberação de valor.

No caso da Liquid, essa decisão conecta LBTC na sidechain com BTC mantidos no Bitcoin. A carteira da federação é a reserva, enquanto as regras de validação da Liquid governam as reivindicações sobre ela.

A falha relatada criou uma divergência entre esses dois livros-razão. A sidechain aceitou LBTC sem bitcoin correspondente, e então o processo de peg-out honrou a reivindicação falsa.

Um padrão econômico semelhante apareceu em outros incidentes envolvendo pontes. O exploit da Wormhole em 2022 permitiu que um invasor criasse ativos encapsulados sem o depósito que deveria sustentá-los.

A ponte da Ronin falhou por uma rota diferente. Os invasores obtiveram chaves de validadores suficientes para autorizar retiradas de sua reserva.

Esses mecanismos diferem tecnicamente, mas chegam ao mesmo ponto de pressão. A ponte precisa preservar uma relação estrita entre reivindicações emitidas e garantias bloqueadas.

Dados históricos mostram por que esse limite recebe escrutínio contínuo. A Chainalysis estimou que invasores roubaram US$ 2 bilhões em 13 hacks de pontes durante parte de 2022.

Sua análise de risco de pontes afirmou que esses incidentes representavam 69% das criptomoedas roubadas naquele ano no momento da publicação. Os números descrevem 2022, não o mercado atual, mas a lição arquitetural continua relevante.

Pontes acumulam ativos em locais previsíveis. Seu código de validação e suas políticas de assinantes também criam caminhos estreitos pelos quais grandes reservas podem se movimentar.

A federação da Liquid oferece um conjunto de operadores mais estruturado do que uma ponte de contratos inteligentes anônima. Ela pode coordenar atualizações, interromper serviços e se comunicar diretamente com exchanges.

Essas vantagens ajudaram na resposta. Elas não impediram o esvaziamento inicial da reserva porque a vulnerabilidade relatada estava na lógica que determinava quais transações eram válidas.

Essa distinção deve orientar auditorias futuras. Testar apenas a custódia de chaves e os controles de acesso deixará de detectar falhas de inflação, validação de provas e consistência de estado.

Os auditores também devem testar toda a rota de resgate. Esse caminho inclui criação de ativos, validação, autorização, queima, assinatura da federação e pagamento final no Bitcoin.

O exploit da Liquid Network demonstra por que a correção local é insuficiente. A SideSwap afirma que sua chave de autorização permaneceu segura, mas seu serviço válido ainda se tornou parte de um resultado inválido do sistema.

Os signatários da federação também parecem ter seguido as regras esperadas. A falha teria alterado as informações que essas regras recebiam.

Portanto, os operadores precisam de controles que comparem múltiplas fontes de verdade. Alterações na oferta, histórico de peg-in, volume de peg-out e movimentação de reservas devem ser reconciliados antes que uma retirada extraordinária seja concluída.

Uma única solicitação envolvendo a maior parte das reservas também deve receber revisão excepcional, mesmo que as regras do protocolo a considerem válida. Validade de software e plausibilidade operacional são verificações diferentes.

Essa abordagem introduz atrito, que a Liquid foi projetada em parte para reduzir. O trade-off de segurança é inevitável quando uma liquidação mais rápida pode movimentar quase toda uma reserva por um único caminho.

Três Sinais Decidirão se a Liquid Conteve os Danos

A próxima etapa depende do bitcoin pendente, de uma explicação técnica reproduzível e de um retorno controlado às operações normais.

O primeiro sinal são os 598,5 BTC restantes. Uma devolução integral reforçaria a versão white hat dos responsáveis, embora não estabelecesse retroativamente a autorização.

Uma recompensa negociada também poderia resolver o saldo, mas apenas se a Blockstream divulgar informação suficiente para distinguir um acordo de uma retenção unilateral. Silêncio contínuo ou movimentação para endereços não relacionados enfraqueceriam a interpretação white hat.

O segundo sinal é a análise técnica pós-incidente da Blockstream. Ela deve identificar as versões vulneráveis do Elements, a regra de validação que falhou, o caminho de transação afetado e a proteção precisa oferecida pelo patch.

Uma divulgação útil também deve explicar se desenvolvedores independentes reproduziram a falha. A reprodução importa porque uma descrição fechada deixa os usuários dependentes da mesma organização cujo software falhou.

O relatório deve abordar o momento da detecção. A análise pública de transações sugere que atividade preparatória precedeu o principal peg-out, levantando questões sobre monitoramento e limites de anomalias.

O terceiro sinal é o processo de reinicialização da Liquid. Exchanges e usuários precisam de um caminho definido para depósitos, retiradas e verificação de reservas antes que a atividade rotineira seja retomada.

Reiniciar nós da ponte não equivale a restaurar a confiança. Os operadores precisam reconciliar a oferta de LBTC com o bitcoin detido pela federação após a devolução parcial.

Eles também devem explicar como a diferença restante será coberta. Essa resposta determina se os detentores arcarão com alguma exposição residual ou se outra parte a absorverá.

Uma reinicialização cuidadosa incluiria verificações de versão entre functionaries e nós da ponte. Ela também forneceria confirmação visível de que software desatualizado não pode se reconectar à rede de produção.

A questão mais ampla da segurança do Bitcoin na Liquid permanecerá após a retomada dos serviços. A federação deve mostrar que adicionou defesas tanto contra a falha divulgada quanto contra falhas comparáveis de validação.

Para desenvolvedores, a lição é rastrear garantias de segurança através dos limites entre componentes. Uma chave protegida não pode salvar um sistema que autoriza a transação errada.

Para exchanges, a lição é monitorar as garantias de forma independente. A aparência normal de um token não garante que sua relação com a reserva permaneça intacta.

Para detentores de ativos, a questão imediata é mais simples. Eles devem acompanhar comunicados oficiais de serviço, dados de reserva e o status de retiradas nas exchanges antes de considerar o incidente encerrado.

A devolução parcial transformou uma perda catastrófica em uma crise recuperável. Ela não restaurou, por si só, a promessa de paridade um a um.

O hack da Liquid Network estará contido apenas quando o saldo restante for resolvido, a falha for compreendida de forma independente e as retiradas normais forem retomadas com reservas reconciliadas. Até que essas condições estejam visíveis, “a maior parte dos fundos foi devolvida” é uma atualização, não um desfecho.