White-hat ou roubo? O hack da Liquid e a ética da divulgação

Quando a Liquid Network, a sidechain de Bitcoin operada pela Blockstream, perdeu cerca de 4.000 BTC a 6 de setembro de 2026, o detalhe mais desconfortável não foi o tamanho do rombo, cerca de 265 milhões de euros (aproximadamente 320 milhões de dólares) drenados num punhado de minutos. Foi a data da correção. O bug que permitiu cunhar Bitcoin do nada já tinha um patch escrito e publicado no repositório público do Elements dias antes de alguém o explorar. A falha não estava escondida: estava no GitHub, com um título de commit que a descrevia em linguagem simples.

É por isso que este não é, no fundo, mais um post-mortem de código. É um post-mortem de divulgação. Em poucos dias, o caso transformou-se numa disputa pública entre figuras conhecidas do Bitcoin sobre quem sabia o quê, quando, e o que conta como comportamento responsável. O atacante assina-se white-hat; a Blockstream chama-lhe roubo; e uma equipa de segurança diz ter avisado a empresa antes do ataque. Para uma indústria que aperfeiçoou a arte da autópsia depois do desastre, a Liquid expôs a parte que a cripto continua a fazer mal: o que acontece antes.

Um bug com correção pública, e ninguém a instalou

Comecemos pelo facto que reordena tudo o resto. A correção para o bug explorado na Liquid não apareceu depois do ataque; apareceu antes. Segundo o registo do repositório Elements, o commit que corrige a falha na cache de verificação de range proofs (intitulado, sem ambiguidade, «Fix caching bug in rangeproof caching», identificado como PR #1561) foi escrito a 3 de agosto de 2026 e fundido no ramo público principal a 2 de setembro, quatro dias antes da exploração de 6 de setembro, conforme reconstituído pela crypto.news e visível na própria página de versões do Elements no GitHub. Os nós da federação, entretanto, corriam a versão v23.3.3, lançada a 13 de abril de 2026. Estavam quase cinco meses atrasados.

Este intervalo tem um nome na segurança informática: patch-gap, a janela entre o momento em que uma correção fica disponível e o momento em que os sistemas afetados a instalam de facto. E tem uma consequência bem documentada. Quando a equipa Project Zero da Google estudou o problema no Android, concluiu que uma vulnerabilidade n-day (já corrigida algures, mas ainda por aplicar noutro lado) pode ser tão perigosa como uma zero-day, e por vezes mais, precisamente porque os detalhes técnicos, e às vezes até uma prova de conceito, já foram publicados, como resumiu o BleepingComputer. Uma correção pública de segurança não é só um remédio. É também um mapa.

No caso da Liquid, esse mapa esteve à vista de todos durante dias, com uma legenda a dizer exatamente onde escavar. Quem lê o Elements (e num software de código aberto isso inclui defensores e atacantes) tinha um commit que anunciava um problema na cache de range proofs. Faltava apenas que os operadores da rede aplicassem a versão que já continha o remédio. Não aplicaram.

O que é a Liquid e o que aconteceu a 6 de setembro

A Liquid é uma sidechain federada de Bitcoin, construída sobre o Elements e coordenada pela Blockstream em conjunto com um grupo de cerca de quinze membros (as chamadas functionaries, entre elas várias exchanges e empresas de Bitcoin) que operam os nós que validam a rede e guardam as chaves da reserva. Quem quer usá-la faz um peg-in, tranca BTC na mainchain e recebe L-BTC em circulação na Liquid, uma ficha lastreada 1 para 1 pensada para liquidações mais rápidas e transações confidenciais; quem quer sair faz um peg-out e recupera o BTC. É, na prática, um cofre coletivo de Bitcoin com regras próprias de contabilidade, e não uma rede sem confiança como a mainchain.

A 6 de setembro de 2026, por volta das 15h53 UTC (bloco 4.050.336 da Liquid), esse cofre foi esvaziado. A raiz, confirmada pela análise da CertiK e pela própria Blockstream, não foram chaves roubadas nem hardware comprometido: foi uma colisão de chave de cache no Elements. Para poupar trabalho, o software guarda em cache o veredicto «esta range proof é válida», para não recalcular a mesma prova duas vezes. Só que a chave dessa cache era construída de forma ambígua, a partir dos bytes da prova e do compromisso de valor, mas omitindo o gerador do ativo e o scriptPubKey, segundo o detalhe técnico reunido pela crypto.news. O resultado: duas transações diferentes podiam gerar a mesma chave de cache, e uma prova falsa passava a reutilizar um veredicto «válido» que pertencia a outra. Com isso, o atacante cunhou L-BTC sem lastro e fez o peg-out de cerca de 4.000 dos aproximadamente 4.200 BTC da reserva, movendo-os através da SideSwap. A reserva caiu de cerca de 4.205 BTC para perto de 200, como noticiou o Crypto Times. Tudo em cerca de 23 minutos.

Porque uma multisig de 11 em 15 assinou o assalto

Numa federação, uma multisig de 11 em 15 devia ser uma barreira. Onze dos quinze membros tiveram de assinar o peg-out que tirou os 4.000 BTC. Assinaram. E é aqui que está o mal-entendido mais comum sobre este caso: a multisig não falhou por ter sido enganada ou coagida; falhou porque não tinha como saber. Uma multisig valida assinaturas, não valida as regras de consenso da cadeia. Do ponto de vista dos signatários, aquele peg-out parecia uma saída perfeitamente normal, lastreada por L-BTC que o software lhes garantia ser legítimo. O bug estava uma camada abaixo, na verificação que dizia «esta prova é válida».

O programador Mononaut, do mempool.space, apontou o sintoma mais revelador: os nós da federação aceitaram as transações da exploração enquanto outros nós, a correr código diferente, as rejeitavam, segundo a crypto.news. Por outras palavras, a rede esteve dividida entre quem já tinha o entendimento correto das regras e quem não tinha, e foram os guardiões da reserva que ficaram do lado errado dessa linha.

Isto contraria a narrativa dominante de 2026. Foi o ano em que a mensagem da indústria passou a ser que as chaves batem o código: mais de 1,3 mil milhões de dólares perdidos em oito meses, com a maior fatia a vir de chaves comprometidas e engenharia social, não de bugs de contrato, como documentou a Forbes a partir dos dados da CertiK. Ronghui Gu, presidente executivo da CertiK, resumiu-o assim: «Um protocolo pode passar numa auditoria de código impecável e ainda assim perder milhões por causa de uma chave de administração comprometida.» A Liquid é o contraexemplo perfeito: nem chave, nem administração, nem contrato. Um bug de consenso puro, do tipo que se dizia estar em vias de extinção. E, mesmo assim, o problema profundo não foi o bug. Foi tudo o que o rodeou. Quem decide, afinal, quando e como se aplica uma correção a uma infraestrutura de Bitcoin partilhada por tanta gente e governada por tão poucos? É a mesma pergunta incómoda que atravessa a governação sem voto do Bitcoin e do Ethereum.

O patch-gap: quando a correção é o mapa do assalto

Chegamos ao coração do assunto. Em software proprietário, uma empresa pode corrigir uma falha em silêncio e distribuir a atualização antes de o mundo saber que ela existiu. Em código aberto, não há silêncio possível: a correção é um evento público. E quando essa correção é fundida no ramo principal com um título que descreve o problema, sem uma versão empacotada e instalada nos sistemas críticos ao mesmo tempo, o que se cria não é segurança. É uma contagem decrescente.

O padrão tem nome duplo. Há o patch-gap simples (a correção existe, mas o utilizador ainda não a aplicou) e há o patch-gap a montante, mais traiçoeiro, em que o fornecedor de origem já tem o remédio mas os projetos que dependem dele ainda não o integraram. A Liquid viveu exatamente o segundo: o Elements a montante tinha a correção; a federação a jusante corria uma versão de abril. É o mesmo desenho que a Project Zero descreveu no Android, onde os fabricantes podem demorar meses a fazer chegar uma correção já disponível.

A resposta da comunidade de segurança a este dilema tem sido gerir a divulgação, não fingir que ela não acontece. A própria Project Zero, depois de anos a lutar com o problema, passou em 2025 a anunciar cedo a existência de uma falha comunicada a um fornecedor, mas a manter privados os detalhes técnicos e a prova de conceito até ao fim do prazo, como explicou o CyberScoop. A lógica é simples: separar o «existe um problema aqui» do «aqui está exatamente como o explorar». No Elements, os dois vieram no mesmo commit.

Há uma ironia adicional específica da Liquid. Numa rede permissionless como a mainchain do Bitcoin, ninguém consegue obrigar milhares de nós anónimos a atualizar em coordenação, e o patch-gap é, até certo ponto, inevitável. A Liquid não é isso: é uma federação de cerca de quinze membros identificados, com contactos conhecidos e obrigações contratuais entre si. Era precisamente o tipo de rede em que uma atualização coordenada e privada, antes de a correção se tornar pública, seria possível. A janela existiu não porque fosse impossível fechá-la, mas porque ninguém a fechou a tempo.

White-hat ou roubo? A fronteira que a cripto nunca fixou

Enquanto os 4.000 BTC saíam, o atacante fez algo que se tornou um ritual da cripto: deixou uma mensagem on-chain. «Please fix the bug first. The chain is under risk at latest commit right now. Make sure every node is patched. Then we will transfer the money back safely after confirming the fix», escreveu, ou seja, corrijam primeiro o bug, a cadeia está em risco no commit mais recente, garantam que todos os nós estão atualizados, e depois devolveremos o dinheiro em segurança, como reportou a CoinDesk. É a pose do white-hat: eu não sou um ladrão, sou o vosso teste de intrusão não solicitado.

A Blockstream não aceitou o enquadramento. Ao recusar pagar qualquer recompensa pelos cerca de 598,5 BTC ainda retidos, a empresa foi taxativa, segundo o The Block: «Tirar ativos sem autorização e reter a sua devolução é um crime, não divulgação responsável. Não é atividade white-hat. É roubo.» Charles Guillemet, diretor de tecnologia da Ledger, foi na mesma direção, questionando o rótulo de white-hat com o argumento de que um investigador genuíno divulga a falha antes de mover somas enormes de garantia, não depois.

O problema é que a cripto nunca fixou bem esta fronteira, e a diferença entre herói e vilão pode resumir-se a quem devolve o dinheiro e com que rapidez. A tentativa mais séria de a codificar é o Safe Harbor da Security Alliance (SEAL): uma oferta pública e juridicamente vinculativa que dá imunidade a quem devolver os fundos em até 72 horas, com uma recompensa de 10% limitada a um milhão de dólares e verificação de identidade, e que já cobre dezenas de milhares de milhões em protocolos, como descreve a própria SEAL. O modelo de referência continua a ser a Euler, cujo atacante devolveu quase tudo em 2023 depois de negociar on-chain e escrever «No intention of keeping what is not ours», sem intenção de ficar com o que não é nosso, como noticiou o The Block. A diferença face à Liquid é subtil mas decisiva: na Euler não havia um patch público ignorado, e a devolução não vinha embrulhada numa exigência. O debate sobre onde acaba a legítima defesa da rede e começa o crime é, no fundo, o mesmo que a HOGE Wire explorou a propósito do drama das DAO e do vilão que falta.

600 BTC para ignorar um email: a disputa da divulgação

Se o caso ficasse pela mecânica, seria um post-mortem técnico. O que o tornou um caso de cultura foi a segunda frente, aberta poucos dias depois. Calle, colíder do Bitcoin Red Team, um grupo de investigação de segurança, veio a público afirmar que tinha avisado a Blockstream sobre a vulnerabilidade antes do ataque. O seu comentário, dirigido às explicações da empresa, foi cortante: «Afinal, só custa 600 BTC ignorar um email da red team», atirou, segundo a news.bitcoin.com. Calle acrescentou que a Blockstream tinha mencionado os patches «de forma seletiva e imprecisa, sem um histórico completo e muito claro de reconhecimento».

A Blockstream contesta. Samson Mow, antigo diretor de segurança da empresa, respondeu que «nenhum email foi ignorado» e sugeriu que as insinuações diminuíam a seriedade do próprio Red Team. Calle, por seu lado, disse que daria tempo à Blockstream para restaurar as operações e publicar o seu post-mortem antes de divulgar o relato completo do processo de divulgação, deixando no ar a existência de versões conflituantes sobre a mesma cronologia.

Retire-se o ruído e fica uma pergunta de responsabilidade que a cripto raramente enfrenta: quando uma equipa externa avisa, de quem é o dever de agir, e em que prazo? Num software mantido por poucos e usado por muitos, receber um aviso e não empacotar e distribuir a correção a tempo é uma falha operacional tão grave como o bug original. É a mesma tensão que percorre a profissionalização da governação cripto, onde gerir uma infraestrutura comum se tornou um emprego com deveres, e não apenas um passatempo de voluntários.

A divulgação coordenada que a cripto importou pela metade

Fora da cripto, este problema não é novo, e há décadas de prática acumulada em como o resolver. Chama-se divulgação coordenada de vulnerabilidades (CVD). A ideia é dar ao fornecedor uma janela para corrigir antes de os detalhes se tornarem públicos, com regras claras: prazos, proteção legal para quem reporta de boa-fé, e a promessa de não deixar correções em silêncio. Em julho de 2026, a agência norte-americana CISA publicou orientações que recomendam precisamente linguagem de safe harbor para investigadores, evitar acordos de confidencialidade cegos e correções silenciosas, e coordenar a publicação após a remediação, tipicamente num prazo de 90 dias, como resumiu a Help Net Security. Do lado legal, a política do Departamento de Justiça dos EUA desde 2022 desencoraja processar investigação de boa-fé, e a diretiva NIS2 da UE incentiva a CVD ao nível dos Estados-membros.

A cripto importou este mundo pela metade. Copiou a autópsia (o post-mortem detalhado, com cronologia ao minuto e causa raiz, publicado depois do desastre) e saltou a sala de emergência (o processo disciplinado de divulgação que devia impedir o desastre, ou pelo menos encurtar a janela). Temos rekt.news, temos dashboards de transparência, temos investigadores forenses de reputação. Não temos um padrão partilhado sobre como se comunica uma falha, quem tem de agir, em quanto tempo, e o que se torna público quando. O caso Liquid é o que acontece quando a parte de trás do manual está bem escrita e a parte da frente não existe.

A inteligência artificial acelera os dois lados

Há um fio que liga a Liquid ao outro grande caso de 2026, o da carteira física Coldcard, e esse fio é a inteligência artificial. Sobre a origem do bug, o fundador da Blockstream, Adam Back, ofereceu uma explicação que é quase uma boneca russa: a falha crítica terá sido introduzida «devido a uma correção de bug incorreta, para um bug encontrado por IA que também era um bug não crítico», segundo o Crypto Times. Ou seja: a IA encontrou um problema pequeno, a correção desse problema pequeno criou um problema enorme, e a correção do problema enorme ficou dias exposta antes de alguém a instalar.

Do lado da Coldcard, Rodolfo Novak, cofundador da Coinkite, tinha avisado semanas antes que «a revisão de código assistida por IA consegue agora encontrar bugs latentes a uma velocidade que ultrapassa até os especialistas mais experientes da indústria», como citou a Bitcoin Magazine. As duas afirmações, juntas, descrevem um problema desconfortável para a era do patch-gap: se a IA acelera a descoberta de falhas nos dois lados, então a janela entre uma correção pública e a sua exploração encolhe. O commit deixa de ser um mapa que um atacante humano leva dias a decifrar e passa a ser algo que uma ferramenta automatizada transforma em exploit em horas. A resposta não pode continuar a ser a velocidade humana de abril.

O peg, o resgate e a conta por pagar

Nem tudo correu mal. Menos de um dia depois, a 7 de setembro às 16h09 UTC, o atacante devolveu 3.400 BTC, cerca de 85% do total, deixando por devolver aproximadamente 598,5 BTC, à volta de 40 milhões de euros (perto de 47 milhões de dólares). A Blockstream traçou a linha: «Não pagaremos pela devolução de propriedade roubada», declarou, recusando também servir de precedente para que software de código aberto feito para o bem do Bitcoin sujeite os seus programadores a pagar um resgate, nas palavras reproduzidas pelo The Block.

Quanto ao lastro, o cofundador Adam Back garantiu que a paridade 1 para 1 entre L-BTC e BTC seria coberta, o que na prática significa que a Blockstream absorve o buraco. Durante os dias seguintes, o L-BTC ficou temporariamente sub-colateralizado, com um rácio de cobertura na casa dos 85%, exatamente o tipo de problema de reserva que também assombra as stablecoins e o seu rendimento: uma ficha só vale a paridade que alguém garante. A empresa lançou o Elements v23.3.4 a 9 de setembro, os blocos foram retomados a 10 de setembro (com os peg-outs ainda desativados por precaução) e comprometeu-se a trabalhar com autoridades e peritos forenses para recuperar o resto. Quem no fim suporta a perda é a Blockstream, uma disciplina de balanço que ecoa a nova era das tesourarias cripto, onde já não se compra (nem se cobre) a qualquer preço sem regras.

Essa cobertura resolve o problema imediato dos utilizadores, mas levanta outro. Um lastro que depende de uma empresa privada aceitar absorver 40 milhões de euros de prejuízo é, por definição, um ponto de confiança. Funcionou desta vez porque a Blockstream quis e pôde; a pergunta que fica para a Liquid, e para qualquer sidechain federada, é o que acontece no dia em que o buraco for grande demais para o balanço de quem o tem de tapar. É a diferença entre uma rede que não precisa de confiar em ninguém e uma que precisa de confiar em alguém solvente.

Corrigido no repositório, explorado na rede: o padrão de 2026

Visto de longe, 2026 tem um padrão: a falha existe algures antes de explodir noutro lado, e a diferença entre um desastre e um susto está quase toda na resposta. Vale a pena colocar a Liquid ao lado dos casos que definiram os anos anteriores.

A comparação mais desconfortável é com a Wormhole, que em 2022 perdeu também cerca de 320 milhões de dólares numa falha de verificação de assinatura. A diferença é que a Jump Crypto repôs o valor total em cerca de um dia, como noticiou a Fortune, transformando uma catástrofe potencial num episódio de contabilidade. A Bybit, em 2025, respondeu ao maior roubo de sempre com transparência radical e um programa de recompensas para rastrear os fundos, como reportou a TechCrunch. E a Coldcard mostrou o pior cenário: um bug latente desde 2021, sem réu único e sem tesouraria que cobrisse os utilizadores. A Liquid encaixa algures no meio, com um traço só seu: foi a única em que a correção já era pública quando o ataque aconteceu.

O que a MiCA e a CMVM alcançam (e o que não)

E a regulação, onde entra? Para um leitor português, a resposta é frustrante mas clarificadora. A MiCA regula os prestadores de serviços de criptoativos (os CASP) e os emitentes, não o software de consenso de uma sidechain. A Blockstream não é um CASP e o Elements não é um produto financeiro; várias das functionaries da federação, essas sim, são exchanges que podem estar abrangidas pela MiCA nas suas próprias jurisdições, mas nenhuma delas «opera» sozinha o bug que era partilhado por todas. O regime alcança as bordas, não o centro.

Há um instrumento que se aproxima do tema: o regulamento DORA, em vigor desde janeiro de 2025, obriga os CASP e outras entidades financeiras a reportar incidentes graves de TIC num relógio apertado (notificação inicial em poucas horas, relatório intermédio em 72 horas, relatório final em um mês), como detalha a documentação europeia sobre a DORA. Mas a DORA governa como uma entidade regulada reporta um incidente que a afeta, não como se coordena a divulgação de uma falha num software de código aberto que ninguém individualmente controla, e não fixa qualquer norma de auditoria de código nem de divulgação coordenada. Nenhum regulador, nem a CMVM, nem o Banco de Portugal, nem a ESMA ao nível europeu, certifica investigadores de segurança ou define um padrão probatório de divulgação para infraestrutura cripto, como se pode confirmar na página da CMVM sobre fintech e criptoativos.

Na prática, para uma vítima portuguesa, a via não seria a CMVM mas o Código Penal e a Lei do Cibercrime, através da Polícia Judiciária, com todas as dificuldades de perseguir um atacante anónimo através de fronteiras. O post-mortem, mais uma vez, é o único tribunal com jurisdição garantida.

Como ler o post-mortem que aí vem

A Blockstream prometeu um post-mortem, e o Bitcoin Red Team prometeu o seu próprio relato do processo de divulgação. Quando chegarem, vale a pena lê-los com uma grelha específica, porque é na cronologia da divulgação, e não na descrição do bug, que este caso se joga.

• Quando é que a correção foi escrita, quando foi fundida no ramo público, e quando (se alguma vez) foi empacotada numa versão instalada nos nós da federação?
• Houve um aviso externo? Em que data chegou, a quem, e que ação concreta se seguiu nas horas seguintes?
• Porque é que os nós críticos corriam uma versão de abril quando a correção estava disponível desde o início de setembro?
• Que processo de divulgação coordenada passa a existir a partir de agora, com que prazos e que proteção para quem reporta de boa-fé?

Um bom post-mortem responde a todas estas perguntas mesmo quando as respostas envergonham quem o escreve. Um mau post-mortem descreve o bug ao milímetro e deixa a cronologia da divulgação na sombra. A cripto já domina a primeira metade desse exercício. O caso Liquid é o convite (mais um) para dominar a segunda: tratar a divulgação com o mesmo rigor forense com que já trata a autópsia. Porque, como este setembro deixou claro, uma falha pode estar corrigida no papel e continuar a valer 320 milhões para quem chegar primeiro.

Perguntas frequentes

O que é a Liquid Network e quem a controla?

A Liquid é uma sidechain federada de Bitcoin, construída sobre o software Elements e coordenada pela Blockstream em conjunto com cerca de quinze membros, várias delas exchanges, que operam os nós e guardam a reserva. Os utilizadores trancam BTC na mainchain e recebem L-BTC lastreado 1 para 1 na Liquid, pensado para liquidações rápidas e transações confidenciais. Não é uma rede sem confiança como a mainchain do Bitcoin: depende da honestidade e da segurança operacional dessa federação.

Quanto foi roubado no hack da Liquid de setembro de 2026?

Saíram da reserva da federação cerca de 4.000 dos aproximadamente 4.200 BTC lastreados, algo como 265 milhões de euros (perto de 320 milhões de dólares) ao câmbio da altura. O atacante devolveu 3.400 BTC (85%) no dia seguinte e ficou com cerca de 598,5 BTC, à volta de 40 milhões de euros, que a Blockstream se recusou a pagar como recompensa.

O ataque à Liquid foi um roubo de chaves privadas?

Não. Ao contrário da maioria dos grandes casos de 2026, não houve chaves roubadas nem hardware comprometido. A falha foi um bug de consenso no Elements, uma colisão de chave de cache na verificação de range proofs que permitiu reutilizar um veredicto «válido» e cunhar L-BTC sem lastro. A multisig de 11 em 15 assinou um peg-out que lhe parecia perfeitamente normal.

O que é o patch-gap e porque é que importa neste caso?

O patch-gap é o intervalo entre o momento em que uma correção de segurança fica disponível e o momento em que os sistemas afetados a instalam. No caso da Liquid, a correção estava pública no repositório Elements quatro dias antes do ataque, mas os nós da federação corriam uma versão de abril. Em software de código aberto, uma correção publicada funciona como um mapa da vulnerabilidade para quem ainda não atualizou.

O atacante da Liquid foi um white-hat?

É exatamente isso que está em disputa. O atacante deixou uma mensagem on-chain a dizer-se investigador de segurança e a pedir que a rede fosse corrigida antes de devolver os fundos, mas a Blockstream classificou a retenção dos restantes 598 BTC como roubo, não como divulgação responsável. A fronteira depende de detalhes como a intenção, o momento da divulgação e o facto de os fundos terem sido movidos primeiro.

Marcus Okafor cobre cultura, segurança e long-reads na HOGE Wire.