Quase 4.000 BTC, avaliados em cerca de US$ 320 milhões, foram drenados da sidechain Bitcoin Liquid. Mas isso não foi um simples hack de chave privada — e as pessoas que agora detêm o Bitcoin dizem que querem devolver a maior parte.
Em 6 de setembro, a Liquid Network sofreu um dos maiores incidentes de segurança cripto de 2026.
Aproximadamente 4.000 BTC foram retirados da carteira de reserva do Bitcoin da Liquid Federation, no valor de cerca de US$ 320 milhões na época. A Liquid posteriormente pausou a atividade de ponte, enquanto exchanges suspenderam ou se prepararam para suspender depósitos e retiradas de L-BTC.
Então a história tomou uma direção inesperada.
Os atacantes se identificaram on-chain como "whitehats" e disseram à Blockstream que devolveriam a maior parte do Bitcoin — mas apenas depois que a vulnerabilidade subjacente fosse corrigida e os nós da rede fossem atualizados.
Na época da redação, aproximadamente 4.000 BTC continuavam sob o controle dos atacantes.
Então, o que realmente aconteceu?
Este não foi um hack do Bitcoin
A primeira distinção importante: o próprio Bitcoin não foi hackeado.
O incidente aconteceu no Liquid, um sidechain do Bitcoin operado através da Federação Liquid.
O modelo do Liquid foi construído em torno de um peg bidirecional. Os usuários movem BTC para o reserve de Bitcoin da federação e recebem uma quantidade equivalente de Bitcoin do Liquid, ou LBTC, no sidechain.
Em operação normal:
BTC → Federação Liquid → LBTC
E quando os usuários querem sair do Liquid:
LBTC → queimado → BTC liberado
A própria documentação do Liquid descreve o LBTC como lastreado 1:1 por Bitcoin mantido na carteira de multisignatura da Federação.
O modelo de segurança foi deliberadamente desenhado para que a federação não dependa de uma única chave privada.
A Federação usa uma estrutura de multisig 11-de-15, com chaves mantidas por funções separadas. Os peg-outs também usam uma Peg-out Authorization Key (PAK) para restringir para onde o Bitcoin pode ser enviado.
E, ainda assim, aproximadamente 4.000 BTC permaneceram no reserve.
É isso que torna esse incidente tão interessante.
As chaves aparentemente não foram roubadas
De acordo com o Liquid e com a apuração da SideSwap, o incidente não envolveu o roubo das credenciais de assinatura da federação.
Em vez disso, a transação seguiu o mecanismo normal de peg-out.
O problema parece ter estado em algum lugar mais profundo na pilha de software.
A SideSwap disse que o L-BTC envolvido na transação foi criado por meio de um bug no Elements, o software de blockchain open-source por trás do Liquid.
Em outras palavras, o atacante parece ter explorado uma falha que permitiu que aproximadamente 4.000 LBTC existissem mesmo sem o Bitcoin correspondente ter sido depositado na federação.
Esses tokens foram apresentados para resgate.
A infraestrutura da federação processou efetivamente a solicitação como um peg-out válido e liberou Bitcoin real.
O resultado foi uma conversão extraordinária:
LBTC falso/ilegítimo → peg-out legítimo → BTC real
No fim, os atacantes ficaram com aproximadamente 3.996 BTC em um endereço do Bitcoin após a transação.
O problema dos US$ 320 milhões
Isso expõe um risco fundamental em qualquer sistema de ativo tokenizado, ponteado ou envolvido.
A segurança da ponte não é determinada apenas por quão bem o Bitcoin subjacente é protegido.
Ele também depende de o sistema conseguir responder corretamente a uma pergunta muito mais simples:
"Esse token existe de fato legitimamente?"
O peg completo do Liquid depende de uma relação 1:1 entre o LBTC em circulação no sidechain e o BTC mantido pela federação.
Se o software permitir que um atacante fabrique LBTC fora desse modelo de contabilidade, o atacante pode conseguir resgatar esses tokens artificiais por Bitcoin real.
O cofre pode permanecer seguro.
As chaves privadas podem permanecer seguras.
O multisig pode permanecer intacto.
E o sistema ainda pode perder centenas de milhões de dólares.
Essa é a lição crítica deste incidente.
Por que o multisig de 11-de-15 não impediu isso?
À primeira vista, isso parece exatamente o tipo de ataque que um multisig de 11-de-15 deveria impedir.
Mas o multisig protege contra gastos não autorizados.
Isso não protege automaticamente contra uma transação que o próprio sistema considera válida.
O processo documentado de peg-out do Liquid exige que os membros da federação verifiquem a solicitação de peg-out e então assinem a transação de Bitcoin correspondente.
Se o software subjacente determinar incorretamente que um resgate de LBTC é legítimo, os participantes do multisig podem acabar fazendo exatamente o que foram projetados para fazer:
assine uma transação válida.
Essa distinção é crucial.
Isso não era necessariamente:
"O atacante roubou 11 chaves privadas."
Era mais perto de:
"O atacante encontrou uma forma de fazer o sistema acreditar que o saque era legítimo."
Isso é, fundamentalmente, outra classe de vulnerabilidade.
Então, os hackers fizeram algo estranho
Depois de mover o Bitcoin, os atacantes não desapareceram imediatamente.
Em vez disso, eles deixaram uma mensagem on-chain identificando-se como "whitehats" e pedindo que a Blockstream entrasse em contato.
A Blockstream respondeu posteriormente por meio de transações do Bitcoin e comunicação criptografada.
Os atacantes então teriam oferecido devolver a maior parte do Bitcoin — com uma grande condição:
Corrija o bug primeiro.
Eles queriam confirmação de que a vulnerabilidade tinha sido corrigida nos nós relevantes antes de devolver os fundos.
Mais tarde, a Blockstream enviou uma mensagem assinada na cadeia indicando que os nós da ponte haviam sido corrigidos e que os fundos poderiam ser devolvidos.
Mas o Bitcoin ainda não tinha sido movido no momento da reportagem.
Então, a maior história de roubo de cripto do dia, de forma incomum, acabou virando uma negociação entre os desenvolvedores do protocolo e as pessoas que exploraram isso.
Liquid pausou a ponte
Após o incidente, o Liquid desabilitou nós de ponte e as exchanges passaram a suspender depósitos e saques de L-BTC.
Isso faz sentido: se a vulnerabilidade de contabilidade subjacente não for corrigida, simplesmente devolver o BTC roubado não resolve o problema.
A rede precisa estabelecer que o mesmo exploit não pode ser repetido.
O Liquid pode continuar existindo como uma blockchain, mas a ponte entre o Liquid e o Bitcoin é o ponto crítico que está sendo protegido.
Essa distinção importa porque Liquid não é Bitcoin.
A própria documentação da Blockstream descreve o Liquid como um sidechain do Bitcoin que opera independentemente da camada base do Bitcoin. O Bitcoin não depende do Liquid para funcionar.
Então não há indicação de que o mecanismo de consenso do Bitcoin, nem a prova de trabalho subjacente do Bitcoin, tenha sido comprometida.
A falha ocorreu na camada de sidechain e peg.
A grande lição para a cripto
Este incidente é maior do que o Liquid.
É mais um lembrete de que a infraestrutura cripto tem várias camadas de segurança — e proteger uma camada não protege automaticamente as outras.
Você pode ter:
Chaves privadas protegidas por hardware
Carteiras de multisig
Validadores distribuídos geograficamente
Endereços de saque na lista branca
Timelocks e procedimentos de recuperação de emergência
…e ainda assim ter uma falha catastrófica se o software que valida os ativos contiver um bug de consenso.
A arquitetura do Liquid na verdade inclui várias salvaguardas adicionais. A documentação descreve um mecanismo de recuperação de emergência e timelocks projetados para proteger os fundos da federação durante falhas prolongadas da rede.
Mas essas proteções foram projetadas principalmente para cenários de falha diferentes.
A lição não é que o multisig não funciona.
A lição é que o multisig não pode compensar uma lógica de validação quebrada.
A parte mais interessante pode ser o que acontece a seguir
O Bitcoin ainda é a peça central do quebra-cabeça.
Se os atacantes realmente devolverem a maior parte dos ~4.000 BTC após a correção, o incidente pode se tornar um exemplo incomum de uma intervenção massiva de white-hat: uma vulnerabilidade foi explorada por dinheiro de verdade, os fundos foram temporariamente protegidos pelos pesquisadores e o protocolo foi forçado a corrigir a fraqueza subjacente.
Mas, até que o Bitcoin realmente volte a se mover, isso permanece como uma reivindicação — não uma recuperação concluída.
E ainda há grandes perguntas a responder:
Exatamente qual bug do Elements habilitou a criação não autorizada de LBTC?
Como o atacante descobriu isso?
Por que o processo de validação da federação aceitou o peg-out resultante?
A vulnerabilidade poderia ter sido explorada antes?
Quantos nós e sistemas foram afetados?
E talvez o mais importante:
Quanta confiança os usuários devem depositar em um ativo ponteado cuja segurança, no fim, depende de software validando uma relação de lastro 1:1?
Portanto, o incidente do Liquid não é simplesmente uma história sobre US$ 320 milhões roubados.
É um estudo de caso sobre a diferença entre proteger chaves e proteger as regras que essas chaves estão programadas para aplicar.
E, em cripto, às vezes o segundo problema é o maior.
#bitcoin #liquidnetwork #CryptoSecurity #BTC
