Levaram 320 milhões em bitcoin e dizem ser os bons da história: o que falhou na Liquid

Uma única transação bastou para esvaziar quase toda a reserva de bitcoin que garante a Liquid Network, a sidechain desenvolvida pela Blockstream e usada por exchanges para liquidar operações mais depressa do que na cadeia principal do Bitcoin. A rede confirmou a 6 de setembro que atores por ela descritos como «purported white-hat hackers» retiraram cerca de 4.000 dos aproximadamente 4.200 BTC guardados na carteira da federação, o que levou à desativação dos nós-ponte, à pausa da rede e a instruções às exchanges para suspenderem depósitos e retiradas de L-BTC. O caso é atípico por dois motivos: não houve roubo de chaves criptográficas e a negociação entre a empresa e quem controla os fundos está a decorrer publicamente, escrita dentro de transações Bitcoin.

Como se esvaziou 95% da reserva numa só transação

A Liquid é uma sidechain do Bitcoin: BTC real é bloqueado na cadeia principal por uma federação de exchanges e empresas, que emite Liquid Bitcoin (L-BTC) contra esse colateral. O mecanismo inverso chama-se peg-out: o L-BTC é queimado na sidechain e a federação liberta o bitcoin equivalente. Em condições normais, essa saída exige autorização por uma multisig de 11 em 15 e o envio dos fundos para uma lista de endereços aprovada.

Foi exatamente esse processo que correu de forma «normal» — e é aí que reside o problema. Segundo a SideSwap, a transação envolveu 4.000 L-BTC enviados para o seu serviço de peg-out; o serviço queimou os tokens com uma autorização válida e, em seguida, a Liquid Federation pagou 3.996 BTC para o endereço Bitcoin do cliente. A plataforma afirmou que não tinha forma de distinguir aquelas moedas de quaisquer outros L-BTC.

O impacto na garantia foi drástico. O explorador da Liquid mostrou a carteira da federação a cair de cerca de 4.200 BTC para 207,275 BTC, valores próximos dos referidos noutras análises que apontam para um saldo residual em torno dos 197 BTC. A queda de cerca de 95% ocorreu numa transação processada por volta das 14:28 UTC.

Cronologia verificável do incidente

A sequência de mensagens foi reconstruída publicamente por Alex Thorn, responsável de investigação da Galaxy Research: a Blockstream iniciou o contacto no bloco 965.822 com 1.000 satoshis e uma mensagem a encaminhar para a sua equipa de segurança; seguiu-se material cifrado com assinatura verificável contra a chave PGP publicada pela empresa; no bloco 965.869 os atores perguntaram se podiam devolver «a maior parte» dos fundos ao endereço da federação e, seis blocos depois, apresentaram a exigência de correção. A Blockstream respondeu com uma mensagem on-chain assinada com PGP a indicar que os nós-ponte estavam corrigidos e que era seguro devolver os fundos, com assinatura verificável contra a chave de segurança publicada no seu site.

Um bug no Elements, não uma chave roubada

Este ponto distingue o caso da maioria dos incidentes em ativos digitais. A Liquid afirmou que os fundos foram retirados através da PAK (Peg-out Authorization Key) da SideSwap, mas que essa chave não foi comprometida, nem qualquer outra. A SideSwap acrescentou que a Blockstream determinou que o L-BTC daquela ordem tinha sido criado através de um bug no software Elements, e que nem os seus sistemas nem a sua chave de autorização foram comprometidos. Em termos práticos, o problema não esteve na custódia das chaves, mas na validação: uma falha no código do Elements permitiu a criação de tokens L-BTC sem lastro.

Importa sublinhar o que ainda não está estabelecido. Até 7 de setembro não havia devolução publicamente confirmada nem análise técnica de causa raiz publicada pela Liquid ou pela Blockstream, não há identificador CVE público associado à falha e as descrições técnicas que circulam sobre a natureza exata do erro permanecem, por isso, não confirmadas. Uma reportagem noticiou ainda que uma correção para a falha teria sido adicionada ao software subjacente cinco semanas antes, sem explicação pública da empresa sobre o bug — um detalhe que só um relatório pós-incidente poderá esclarecer.

O perímetro do impacto também está delimitado: a camada base do Bitcoin continuou a operar normalmente e outros ativos emitidos na Liquid, incluindo USDT, DePix e ativos do mundo real tokenizados, foram descritos como não afetados. A SideSwap indicou que as carteiras existentes são não-custodiais e não foram afetadas, mas que peg-ins, peg-outs e swaps ficariam offline até a rede retomar.

«White hat» ou resgate com melhor comunicação?

A auto-atribuição do rótulo de investigação ética é contestada dentro do próprio setor. Charles Guillemet, CTO da Ledger, questionou publicamente o rótulo de whitehat, argumentando que os investigadores normalmente divulgam a falha antes de mover uma reserva de grande dimensão. A caracterização como white hat continua a ser uma alegação, e não algo verificado, e as mensagens on-chain provam apenas que quem controla os bitcoins consegue responder à Blockstream, não os seus motivos.

Do ponto de vista da gestão de risco, a diferença é relevante: cerca de 3.998,5 BTC continuavam sem se mover do endereço de destino, sendo a pequena diferença face aos 4.000 BTC iniciais atribuída a taxas de transação. Enquanto não houver movimento para um endereço controlado pela federação, o valor não está recuperado — está apenas prometido.

O que fazer se tem exposição a L-BTC

• Não tente forçar operações: os nós-ponte foram desativados e as exchanges receberam instrução para suspender depósitos e retiradas de L-BTC.
• Verifique os anúncios individuais da sua exchange antes de assumir que um saque está disponível ou bloqueado.
• Desconfie de mensagens, «suportes técnicos» e formulários de «recuperação de fundos» que apareçam nas próximas semanas: incidentes mediáticos são sempre seguidos de vagas de phishing oportunista.
• Acompanhe os três sinais que realmente contam: publicação da análise técnica, confirmação de retorno de BTC à carteira da federação e reabertura coordenada dos bridge nodes.
• Registe o seu próprio inventário de exposição (saldos, plataformas, datas) — será útil se houver processos de reconciliação.

Porque é que isto importa a quem gere risco em Portugal

Ainda que a Liquid não tenha operações centradas em Portugal, o padrão técnico é diretamente transponível para qualquer organização nacional. Primeiro, porque demonstra que uma arquitetura com distribuição robusta de chaves não protege contra um erro de lógica no software que valida as transações: na leitura de Alex Thorn, da Galaxy Digital, o caso expõe o risco sistémico do bitcoin embrulhado e transferido por pontes, já que uma falha de lógica no software torna irrelevante a distribuição física das chaves. Segundo, porque reforça que a segurança da cadeia de fornecimento de software — neste caso um componente open-source partilhado por todos os participantes — é um controlo de primeira linha, e não um detalhe de engenharia.

Para entidades abrangidas em Portugal, esta lógica está agora inscrita na lei. O Regime Jurídico da Cibersegurança, aprovado pelo Decreto-Lei n.º 125/2025 que transpõe a diretiva NIS2, exige medidas de gestão de risco que incluem gestão de vulnerabilidades, segurança na aquisição e desenvolvimento de software e notificação de incidentes significativos ao CNCS/CERT.PT, dentro de prazos escalonados. No setor financeiro, o Regulamento DORA impõe requisitos equivalentes de resiliência operacional digital e de gestão do risco de terceiros em TIC, aplicáveis também a prestadores de serviços de criptoativos autorizados ao abrigo do MiCA. E quando um incidente envolve dados pessoais de clientes — o que não é o caso central aqui, mas é frequente em plataformas de negociação —, acresce o dever de avaliação e eventual notificação à CNPD ao abrigo do RGPD.

Há uma terceira lição, mais transversal: a resposta ao incidente foi, na prática, uma negociação com um interlocutor anónimo cuja boa-fé não é verificável. Para PME e organizações portuguesas, isso equivale ao cenário de ter de decidir sob pressão, sem informação completa e com o negócio parado. É precisamente para esse momento que servem um plano de resposta testado, cópias de segurança verificadas, canais de comunicação alternativos com assinatura criptográfica e uma política clara sobre quem decide e o que se comunica.

Perguntas frequentes

O Bitcoin foi comprometido neste ataque?

Não. A camada base do Bitcoin continuou a operar normalmente e o incidente ficou circunscrito à infraestrutura da sidechain Liquid que emite e resgata L-BTC. As regras de consenso do Bitcoin não foram alteradas.

Alguma chave criptográfica foi roubada?

Segundo os comunicados públicos, não. A Liquid afirmou que os fundos saíram através da PAK da SideSwap, mas que essa chave não foi comprometida, nem qualquer outra. A origem apontada é uma falha de software no Elements.

Os bitcoins já foram devolvidos?

Não à data desta publicação. A 7 de setembro a Blockstream confirmou on-chain que as correções estavam aplicadas e incentivou a devolução rápida, mas cerca de 3.998,5 BTC continuavam sem se mover do endereço de destino.

Existe um CVE atribuído a esta vulnerabilidade?

Não há, publicamente, um identificador CVE associado a esta falha. Até 7 de setembro, nem a Liquid nem a Blockstream tinham publicado uma análise técnica de causa raiz, pelo que qualquer descrição detalhada do erro deve ser tratada como não confirmada.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Liquid Network, pela SideSwap, pela Blockstream e em análises on-chain atribuídas a investigadores e analistas do setor.