{"id":677,"date":"2026-10-05T04:45:23","date_gmt":"2026-10-05T04:45:23","guid":{"rendered":"https:\/\/hoge.gg\/pt\/fundo-autopsia-bitget-liquid-pior-mes-hacks-2026\/"},"modified":"2026-10-05T04:45:23","modified_gmt":"2026-10-05T04:45:23","slug":"fundo-autopsia-bitget-liquid-pior-mes-hacks-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/pt\/fundo-autopsia-bitget-liquid-pior-mes-hacks-2026\/","title":{"rendered":"O fundo ou a aut\u00f3psia: Bitget, Liquid e o pior m\u00eas de 2026"},"content":{"rendered":"

Setembro de 2026 entrou nas contas da cripto pela pior das raz\u00f5es. Entre o primeiro e o \u00faltimo dia do m\u00eas, duas empresas de an\u00e1lise forense chegaram quase ao mesmo n\u00famero: a PeckShield registou cerca de 766,5 milh\u00f5es de d\u00f3lares roubados em 55 incidentes de relevo, e a CertiK contou 768,4 milh\u00f5es em 97 incidentes. Qualquer das contas transforma setembro no m\u00eas mais caro do ano e empurra as perdas acumuladas de 2026 para perto dos 2,68 mil milh\u00f5es de d\u00f3lares, segundo a crypto.news<\/a>.<\/p>

Dois nomes explicam quase toda a fatura do m\u00eas: a corretora Bitget, com cerca de 387,5 milh\u00f5es de d\u00f3lares (uns 344 milh\u00f5es de euros), e a Liquid Network, a sidechain de Bitcoin operada pela Blockstream, com perto de 4.000 BTC. Foram, segundo a Cryptopolitan<\/a>, o primeiro e o segundo maiores ataques do ano.<\/p>

O que torna este m\u00eas relevante para quem acompanha a cultura do post-mortem na cripto n\u00e3o \u00e9 a soma, \u00e9 o contraste. Dois ataques de dimens\u00e3o parecida produziram duas respostas quase opostas. A Blockstream acabou por publicar uma aut\u00f3psia t\u00e9cnica longa e detalhada, do g\u00e9nero que a ind\u00fastria costuma elogiar. A Bitget abriu o cofre, reembolsou os clientes e falou muito pouco de c\u00f3digo. Um escreveu um relat\u00f3rio; o outro passou um cheque. E a escolha de cada um diz quase tudo sobre a diferen\u00e7a entre uma corretora e um protocolo.<\/p>

Setembro de 2026: o m\u00eas mais caro de sempre<\/h2>

Para perceber a dimens\u00e3o, conv\u00e9m recuar. No primeiro semestre de 2026, a TRM Labs tinha contado cerca de 972 milh\u00f5es de d\u00f3lares roubados em 207 incidentes, um recorde no n\u00famero de ataques mas com um valor abaixo de metade do primeiro semestre de 2025. Setembro, sozinho, ro\u00e7ou os 770 milh\u00f5es. A leitura \u00e9 simples: o dinheiro n\u00e3o saiu do crime cripto, concentrou-se.<\/p>

As duas empresas que publicaram balan\u00e7os mensais divergem no detalhe mas n\u00e3o na conclus\u00e3o. A PeckShield apontou 766,5 milh\u00f5es de d\u00f3lares; a CertiK, que usa outra metodologia e inclui mais casos pequenos, chegou a 768,4 milh\u00f5es em 97 incidentes, e a cerca de 656 incidentes e 2,68 mil milh\u00f5es no acumulado do ano. Al\u00e9m da Bitget e da Liquid, setembro trouxe perdas menores mas igualmente reveladoras: a Safe Wallet (7,8 milh\u00f5es), a carteira DCENT (uns 6 milh\u00f5es) e a casa de apostas Duelbits (cerca de 5,9 milh\u00f5es), todas no balan\u00e7o mensal<\/a> das empresas forenses.<\/p>

O padr\u00e3o de fundo n\u00e3o \u00e9 novo para quem acompanha esta s\u00e9rie. A maior parte do valor deixou de sair de erros em contratos inteligentes e passou a sair de chaves comprometidas, software de terceiros e engenharia social. Foi exatamente isso que aconteceu nos dois grandes casos do m\u00eas, em lados opostos daquilo a que podemos chamar a fronteira da cust\u00f3dia.<\/p>

Dois ataques, duas aut\u00f3psias: a corretora e o protocolo<\/h2>

A Bitget e a Liquid s\u00e3o criaturas diferentes. A primeira \u00e9 uma corretora centralizada (CEX): guarda as chaves dos clientes, tem um balan\u00e7o, uma sede, executivos com nome e cara e, cada vez mais, um regulador. A segunda \u00e9 um protocolo: a Liquid \u00e9 uma sidechain federada de Bitcoin, operada por um cons\u00f3rcio de empresas a que se chama federa\u00e7\u00e3o, sem balan\u00e7o pr\u00f3prio para cobrir perdas e sem ningu\u00e9m a quem, na pr\u00e1tica, um lesado possa apresentar queixa.<\/p>

Essa diferen\u00e7a de natureza molda a resposta ao ataque. Quando uma CEX \u00e9 esvaziada, a pergunta imediata do cliente \u00e9 se vai reaver o dinheiro. Quando um protocolo \u00e9 explorado, n\u00e3o h\u00e1 cofre para abrir: a \u00fanica coisa que a equipa pode oferecer \u00e9 a verdade sobre o que correu mal, com o m\u00e1ximo de detalhe, para que o resto do ecossistema n\u00e3o repita o erro. Dito de outro modo, a CEX responde com capital e o protocolo responde com transpar\u00eancia. Setembro de 2026 ofereceu, por acaso, a experi\u00eancia controlada quase perfeita: dois ataques de valor semelhante, um de cada lado dessa fronteira.<\/p>

Liquid: a aut\u00f3psia que a Blockstream levou semanas a entregar<\/h2>

O ataque \u00e0 Liquid aconteceu a 6 de setembro. Durante dias, por\u00e9m, n\u00e3o houve um relat\u00f3rio t\u00e9cnico oficial, e o vazio encheu-se de pol\u00e9mica. O atacante dizia-se white-hat e pedia uma recompensa; a Blockstream recusou pagar pela devolu\u00e7\u00e3o daquilo que considerava roubo; e um investigador conhecido por Calle, col\u00edder do Bitcoin Red Team, acusou a empresa de ter ignorado um aviso pr\u00e9vio, com uma frase que ficou: \u00abcusta-vos apenas 600 BTC ignorar um email do red team\u00bb. O antigo diretor de seguran\u00e7a Samson Mow respondeu que \u00abnenhum email foi ignorado\u00bb. A HOGE Wire dissecou essa guerra de narrativas quando ela estava no auge.<\/p>

O que mudou agora, e justifica voltar ao caso, \u00e9 que a Blockstream publicou finalmente a sua avalia\u00e7\u00e3o oficial do incidente, a Liquid Network Security Incident Assessment<\/a>. \u00c9 um documento invulgarmente franco para os padr\u00f5es da ind\u00fastria e \u00e9 a pe\u00e7a que faltava para fechar a aut\u00f3psia. Vale a pena l\u00ea-lo com aten\u00e7\u00e3o, porque conta uma hist\u00f3ria que nenhum dos textos anteriores podia contar: a do bug que nasceu de uma corre\u00e7\u00e3o.<\/p>

A anatomia do bug: quando a corre\u00e7\u00e3o se tornou o exploit<\/h2>

Segundo a pr\u00f3pria Blockstream, houve dois bugs encadeados. O primeiro (a que o relat\u00f3rio chama Bug A) foi introduzido em abril de 2018: a chave da cache que o Elements usa para n\u00e3o revalidar provas de intervalo (rangeproofs) foi simplificada e passou a omitir o compromisso de ativo e o scriptPubKey. Transportada para a valida\u00e7\u00e3o dos Confidential Assets em 2019, essa simplifica\u00e7\u00e3o permitia, em teoria, que um resultado de valida\u00e7\u00e3o guardado em cache fosse reutilizado num contexto onde j\u00e1 n\u00e3o era v\u00e1lido.<\/p>

Um investigador externo reportou o Bug A a 2 de agosto de 2026. A Blockstream corrigiu-o nos seus n\u00f3s no dia seguinte e validou a corre\u00e7\u00e3o em testnet a 5 de agosto. O problema nasceu quando essa corre\u00e7\u00e3o foi fundida no reposit\u00f3rio p\u00fablico do Elements, a 1 de setembro: a emenda acrescentava os campos em falta \u00e0 chave da cache, mas concatenava-os sem prefixos de comprimento. \u00c9 o Bug B. Sem delimitadores, dois conjuntos de dados diferentes podiam, por alinhamento de bytes, produzir exatamente a mesma chave.<\/p>

Foi essa a porta. A 6 de setembro, o atacante truncou uma rangeproof e ajustou o scriptPubKey at\u00e9 a chave coincidir, byte a byte, com uma entrada j\u00e1 marcada como v\u00e1lida na cache. O consenso aceitou uma transa\u00e7\u00e3o cujo valor de sa\u00edda n\u00e3o estava coberto pelas entradas e cunhou LBTC sem lastro. O mecanismo PAK, que autoriza os pedidos de peg-out, limitou-se a fazer o seu trabalho sobre um estado que o consenso j\u00e1 dera, por erro, como verdadeiro. Nas palavras do relat\u00f3rio, \u00abo mecanismo PAK autenticou um pedido de assinatura real contra LBTC que o consenso tinha, incorretamente, j\u00e1 aceitado como real\u00bb.<\/p>

A frase mais dura da aut\u00f3psia \u00e9 tamb\u00e9m a mais honesta: \u00abnenhum revisor, interno ou externo, identificou este risco antes da explora\u00e7\u00e3o\u00bb. E a li\u00e7\u00e3o que a Blockstream tira, em discurso direto, \u00e9 de engenharia: \u00abquando existe mais do que uma solu\u00e7\u00e3o para um problema cr\u00edtico de consenso, a abordagem que oferece as garantias estruturais de seguran\u00e7a mais fortes passar\u00e1 a ser a op\u00e7\u00e3o por omiss\u00e3o\u00bb. Por outras palavras, a emenda que criou o Bug B era a corre\u00e7\u00e3o r\u00e1pida; faltou escolher a corre\u00e7\u00e3o robusta. A ironia \u00e9 total, e foi o pr\u00f3prio Adam Back, presidente executivo da Blockstream, quem a resumira dias antes, ao Crypto Times<\/a>: o exploit veio \u00abde uma corre\u00e7\u00e3o incorreta, para um bug encontrado por IA que tamb\u00e9m era um bug n\u00e3o cr\u00edtico\u00bb.<\/p>

A cronologia oficial, ao minuto<\/h2>

A avalia\u00e7\u00e3o da Blockstream traz uma cronologia detalhada, que vale a pena fixar porque \u00e9 ela que transforma uma acusa\u00e7\u00e3o vaga (ignoraram o aviso) num facto verific\u00e1vel: a janela entre a corre\u00e7\u00e3o p\u00fablica e o ataque.<\/p>

Data (2026)<\/th>Evento<\/th><\/tr><\/thead>
25 abr 2018<\/td>Bug A introduzido no Elements (chave de cache simplificada)<\/td><\/tr>
2 ago<\/td>Investigador externo reporta o Bug A \u00e0 Blockstream<\/td><\/tr>
3 ago<\/td>Corre\u00e7\u00e3o aplicada aos n\u00f3s da federa\u00e7\u00e3o<\/td><\/tr>
1 set<\/td>Corre\u00e7\u00e3o fundida no reposit\u00f3rio p\u00fablico; o Bug B fica vis\u00edvel<\/td><\/tr>
6 set, 13:53 UTC<\/td>Exploit no bloco 4.050.336: cerca de 4.000 LBTC sem lastro<\/td><\/tr>
6 set, 14:29 UTC<\/td>3.996,02 BTC saem via peg-out e passam pela SideSwap<\/td><\/tr>
6 set, 18:26 UTC<\/td>N\u00f3s da ponte parados; rede suspensa<\/td><\/tr>
7 set, 01:09 UTC<\/td>Corre\u00e7\u00e3o de emerg\u00eancia aplicada<\/td><\/tr>
7 set, 16:09 UTC<\/td>Atacante devolve 3.400 BTC (cerca de 85%)<\/td><\/tr>
8 set, 19:06 UTC<\/td>Corre\u00e7\u00e3o definitiva do Bug B fundida (PR #1600)<\/td><\/tr>
9 set, 13:30 UTC<\/td>Elements v23.3.4 lan\u00e7ado para produ\u00e7\u00e3o<\/td><\/tr>
9 set, 21:05 UTC<\/td>Produ\u00e7\u00e3o de blocos retomada na cadeia corrigida<\/td><\/tr><\/tbody><\/table>
Fonte: avalia\u00e7\u00e3o oficial do incidente da Blockstream.<\/figcaption><\/figure>

O que a aut\u00f3psia faz bem, e o que fica por fechar<\/h2>

Pelos crit\u00e9rios da pr\u00f3pria cultura do post-mortem, o documento da Blockstream acerta em quase tudo o que costumamos pedir: tem cronologia ao minuto, causa-raiz ao n\u00edvel do commit, assume a falha de revis\u00e3o sem procurar um culpado individual e termina com uma mudan\u00e7a concreta de processo. \u00c9, no vocabul\u00e1rio herdado da engenharia de fiabilidade, um post-mortem sem culpados exemplar.<\/p>

Mas uma aut\u00f3psia honesta n\u00e3o resolve tudo. Ficam tr\u00eas pontas soltas. A primeira \u00e9 o dinheiro: o atacante devolveu 3.400 BTC a 7 de setembro, mas, segundo a The Hacker News<\/a>, mantinha ainda cerca de 602 BTC (uns 46 milh\u00f5es de euros), e a Blockstream recusou pagar qualquer recompensa por eles, classificando a reten\u00e7\u00e3o como roubo e n\u00e3o como divulga\u00e7\u00e3o respons\u00e1vel. A reserva da federa\u00e7\u00e3o caiu de cerca de 4.205 para 197 BTC no pico do ataque, segundo a mesma avalia\u00e7\u00e3o oficial.<\/p>

A segunda ponta \u00e9 a garantia. Quem tinha LBTC n\u00e3o ficou sem nada porque Adam Back garantiu cobrir a paridade de um para um entre LBTC e BTC. S\u00f3 que isso \u00e9 uma promessa pessoal do presidente executivo, n\u00e3o um fundo segregado nem uma obriga\u00e7\u00e3o legal; vale enquanto a palavra valer. A terceira \u00e9 a governa\u00e7\u00e3o: a Blockstream diz que a federa\u00e7\u00e3o e a empresa est\u00e3o a rever um conjunto mais amplo de altera\u00e7\u00f5es de governa\u00e7\u00e3o, seguran\u00e7a e opera\u00e7\u00f5es, mas remete os detalhes para an\u00fancios futuros. A aut\u00f3psia fecha o cap\u00edtulo t\u00e9cnico; o cap\u00edtulo institucional continua em aberto.<\/p>

Bitget: quando o cofre dispensa a aut\u00f3psia<\/h2>

Do outro lado da fronteira est\u00e1 a Bitget. O ataque come\u00e7ou a 24 de setembro e seguiu um gui\u00e3o que se tornou t\u00edpico. Segundo a presidente executiva, Gracy Chen, em declara\u00e7\u00f5es ao The Block<\/a>, o atacante come\u00e7ou por fazer transfer\u00eancias de teste abaixo dos limiares de alerta, para sondar os controlos de risco, antes de disparar uma s\u00e9rie de levantamentos grandes em v\u00e1rias redes. Quando os sistemas sinalizaram o problema, j\u00e1 tinham sa\u00eddo cerca de 361 milh\u00f5es de USDT, al\u00e9m de ETH, XRP, USDC, ZEC, BNB, AVAX e TRX. O total chegou perto dos 387,5 milh\u00f5es de d\u00f3lares.<\/p>

A causa, tal como na Bybit em 2025, n\u00e3o foi um erro no contrato nem uma chave adivinhada: foi uma falha num software de seguran\u00e7a de terceiros que deu ao atacante acesso ao ambiente das carteiras quentes e mornas da corretora. As carteiras frias ficaram intactas. A Bitget chamou a Mandiant e a SlowMist para a investiga\u00e7\u00e3o e abriu um programa de recompensas de 5% sobre fundos congelados e 5% sobre fundos recuperados.<\/p>

A resposta ao cliente, por\u00e9m, foi imediata e simples: o fundo de prote\u00e7\u00e3o do utilizador, que a Bitget diz ter ultrapassado os 465 milh\u00f5es de d\u00f3lares, absorveu a totalidade da perda, e a corretora comprometeu-se a rep\u00f4-lo acima dos 300 milh\u00f5es em pouco tempo, meta que, segundo os balan\u00e7os de fim de m\u00eas, cumpriu. Para o utilizador final, o epis\u00f3dio resumiu-se a isto: os levantamentos de BTC, ETH e USDT foram restaurados e o saldo manteve-se. \u00c9 a mesma l\u00f3gica dos fundos de seguro que sustentam o volume das grandes corretoras, um tema que a HOGE Wire j\u00e1 tinha explorado na rede de fundos SAFU por tr\u00e1s do volume<\/a>.<\/p>

O que a Bitget escolheu n\u00e3o publicar<\/h2>

Repare-se no que falta. A Bitget deu a dimens\u00e3o da perda, a causa gen\u00e9rica (software de terceiros), a atribui\u00e7\u00e3o prov\u00e1vel e o plano de reembolso. N\u00e3o publicou nada que se pare\u00e7a com a aut\u00f3psia da Blockstream: n\u00e3o h\u00e1 commit, n\u00e3o h\u00e1 cronologia ao segundo da intrus\u00e3o, n\u00e3o h\u00e1 explica\u00e7\u00e3o t\u00e9cnica de como esse software de terceiros foi comprometido nem de porque \u00e9 que os controlos internos deixaram passar 361 milh\u00f5es de USDT antes de os alarmes soarem.<\/p>

E a verdade \u00e9 que, do ponto de vista do cliente, n\u00e3o precisava. O padr\u00e3o de refer\u00eancia em transpar\u00eancia continua a ser a Bybit, que em 2025 publicou relat\u00f3rios forenses preliminares poucos dias depois do seu ataque recorde; a Bitget ficou aqu\u00e9m dessa fasquia t\u00e9cnica. Mas ambas fizeram a \u00fanica coisa que, para uma CEX, verdadeiramente importa ao utilizador: tornaram a perda invis\u00edvel no saldo. Quando h\u00e1 um balan\u00e7o por tr\u00e1s, a aut\u00f3psia \u00e9 opcional; o reembolso n\u00e3o \u00e9.<\/p>

Gracy Chen foi, de resto, pouco otimista quanto a reaver o que foi roubado. Em declara\u00e7\u00f5es recolhidas pela Cointelegraph<\/a>, lembrou que, um ano depois do ataque \u00e0 Bybit, s\u00f3 cerca de 3,5% dos fundos tinham sido congelados. A mensagem impl\u00edcita \u00e9 clara: o dinheiro provavelmente n\u00e3o volta, mas o cliente n\u00e3o vai sentir, porque o cofre paga.<\/p>

A tese: o post-mortem \u00e9 sempre um substituto<\/h2>

Postos lado a lado, os dois casos sugerem uma tese simples sobre a cultura do post-mortem: o relat\u00f3rio \u00e9 sempre um substituto de algo que a entidade n\u00e3o tem. A corretora tem capital e falta-lhe, por natureza, o c\u00f3digo aberto ao escrut\u00ednio; por isso substitui a transpar\u00eancia t\u00e9cnica por um fundo. O protocolo tem o c\u00f3digo \u00e0 vista de todos e falta-lhe um balan\u00e7o; por isso substitui o reembolso por transpar\u00eancia. Nenhum dos dois \u00e9 mais honesto por decreto; cada um paga na moeda que tem.<\/p>

Dimens\u00e3o<\/th>Bitget (corretora)<\/th>Liquid \/ Blockstream (protocolo)<\/th><\/tr><\/thead>
Tipo de entidade<\/td>CEX centralizada e custodiante<\/td>Sidechain federada de Bitcoin<\/td><\/tr>
Valor do ataque<\/td>~387,5 M$ (~344 M\u20ac)<\/td>~4.000 BTC (~300 M\u20ac)<\/td><\/tr>
Causa-raiz<\/td>Software de seguran\u00e7a de terceiros comprometido<\/td>Colis\u00e3o de chave de cache (Bug A de 2018 e a corre\u00e7\u00e3o Bug B)<\/td><\/tr>
Quem absorve a perda<\/td>Fundo de prote\u00e7\u00e3o (mais de 465 M$)<\/td>Promessa de paridade de Adam Back; 602 BTC por recuperar<\/td><\/tr>
Documento produzido<\/td>Comunicados e plano de reembolso<\/td>Aut\u00f3psia t\u00e9cnica detalhada<\/td><\/tr>
Atribui\u00e7\u00e3o<\/td>Ind\u00edcios de liga\u00e7\u00e3o \u00e0 Coreia do Norte<\/td>White-hat autoproclamado, sem atribui\u00e7\u00e3o estatal<\/td><\/tr>
Recurso do lesado<\/td>Reembolso direto (e, na UE, o regulador)<\/td>O post-mortem \u00e9 o \u00fanico recurso<\/td><\/tr><\/tbody><\/table><\/figure>

A tabela exp\u00f5e a assimetria que mais interessa a um leitor europeu, a da \u00faltima linha. Para quem perdeu dinheiro, a diferen\u00e7a entre as duas colunas n\u00e3o \u00e9 filos\u00f3fica: \u00e9 a diferen\u00e7a entre recuperar o saldo e ler um relat\u00f3rio muito bem escrito sobre a raz\u00e3o por que n\u00e3o o vai recuperar. \u00c9 uma vers\u00e3o, \u00e0 escala de um protocolo inteiro, da velha pergunta de quem fica com a conta quando uma posi\u00e7\u00e3o \u00e9 liquidada num perp DEX<\/a>.<\/p>

Coreia do Norte, mais uma vez (e as d\u00favidas da atribui\u00e7\u00e3o)<\/h2>

H\u00e1 um fio que liga a Bitget \u00e0 maioria dos grandes ataques do ano e que n\u00e3o liga a Liquid: a Coreia do Norte. No primeiro semestre de 2026, a TRM Labs<\/a> atribuiu cerca de 643 milh\u00f5es de d\u00f3lares, ou dois ter\u00e7os do valor roubado, a atores norte-coreanos, sobretudo via comprometimento de chaves e engenharia social, e n\u00e3o via erros de contrato. O caso Bitget encaixa no molde: transfer\u00eancias de teste para sondar os sistemas, software de terceiros como ponto de entrada e a pr\u00f3pria Gracy Chen a tra\u00e7ar o paralelo com a Bybit, tamb\u00e9m atribu\u00edda ao grupo Lazarus.<\/p>

Conv\u00e9m, ainda assim, calibrar a confian\u00e7a. A atribui\u00e7\u00e3o \u00e0 Coreia do Norte tornou-se um reflexo quase autom\u00e1tico sempre que h\u00e1 um grande roubo a uma corretora, e nem sempre o grau de certeza \u00e9 o mesmo. No caso Bitget, os ind\u00edcios citados publicamente passam por endere\u00e7os de IP ligados a servi\u00e7os de VPN associados a opera\u00e7\u00f5es anteriores do regime e por semelhan\u00e7as de padr\u00e3o, n\u00e3o por uma confiss\u00e3o nem por uma acusa\u00e7\u00e3o formal. J\u00e1 a Liquid \u00e9 o contraste perfeito: o atacante apresentou-se como white-hat, negociou on-chain, devolveu a maior parte do dinheiro e ningu\u00e9m lhe colou um Estado. Mover quase 400 milh\u00f5es de d\u00f3lares em ativos roubados sem passar por uma corretora regulada exige, de resto, canais discretos, do mercado de balc\u00e3o<\/a> \u00e0s pontes e aos misturadores.<\/p>

A li\u00e7\u00e3o que ningu\u00e9m aprende: o intervalo do patch<\/h2>

Se h\u00e1 um ponto em que a aut\u00f3psia da Liquid fala a toda a ind\u00fastria, \u00e9 o do intervalo do patch, o chamado problema do n-day. A corre\u00e7\u00e3o do Bug A tornou-se p\u00fablica a 1 de setembro. O ataque foi a 6. Durante cinco dias, qualquer pessoa com acesso ao reposit\u00f3rio do Elements podia ler a emenda, perceber que resolvia um problema de valida\u00e7\u00e3o de consenso e, neste caso, descobrir que a pr\u00f3pria emenda abria uma segunda porta. Uma corre\u00e7\u00e3o publicada \u00e9, para um atacante, um mapa.<\/p>

\u00c9 um padr\u00e3o que se repete com uma regularidade quase c\u00f3mica. Em 2013, uma falha no gerador de n\u00fameros aleat\u00f3rios do Android permitiu reconstruir chaves privadas de carteiras de Bitcoin a partir de dados p\u00fablicos. Em 2026, a falha de entropia da Coldcard, adormecida desde 2021, drenou carteiras durante dias e tornou-se um dos maiores desastres de hardware do ano. A forma \u00e9 sempre a mesma: um defeito latente durante anos, uma corre\u00e7\u00e3o e uma janela entre essa corre\u00e7\u00e3o e a imuniza\u00e7\u00e3o de toda a rede. A diferen\u00e7a da Liquid \u00e9 que a janela n\u00e3o foi s\u00f3 de exposi\u00e7\u00e3o; foi de introdu\u00e7\u00e3o de um novo bug.<\/p>

As boas pr\u00e1ticas existem para fechar essa janela. A divulga\u00e7\u00e3o coordenada de vulnerabilidades pede que a corre\u00e7\u00e3o s\u00f3 se torne p\u00fablica depois de os operadores cr\u00edticos estarem protegidos, e iniciativas como o Safe Harbor da Security Alliance<\/a> oferecem um enquadramento (devolu\u00e7\u00e3o em 72 horas, recompensa de 10% at\u00e9 um milh\u00e3o de d\u00f3lares) para que um verdadeiro white-hat n\u00e3o precise de reter fundos como alavanca. A federa\u00e7\u00e3o da Liquid corria, segundo v\u00e1rios relatos, uma vers\u00e3o do Elements de abril, com meses de atraso. Nenhuma aut\u00f3psia resolve o problema de quem n\u00e3o atualiza a tempo.<\/p>

MiCA, CMVM e os dois lados da fronteira<\/h2>

Para o leitor portugu\u00eas, a dist\u00e2ncia entre as duas colunas da tabela tem um nome regulat\u00f3rio. Uma corretora como a Bitget, quando serve clientes na Uni\u00e3o Europeia, cai (ou cair\u00e1) sob o regulamento MiCA como prestador de servi\u00e7os de criptoativos, um CASP na sigla inglesa. Isso traz deveres de cust\u00f3dia, de segrega\u00e7\u00e3o dos fundos dos clientes e um regime de responsabilidade, al\u00e9m de uma porta \u00e0 qual bater: em Portugal, a CMVM<\/a> supervisiona a conduta de mercado e o Banco de Portugal trata do registo e das regras das stablecoins, ao abrigo da Lei n.\u00ba 69\/2025, em vigor desde 27 de dezembro de 2025. O per\u00edodo transit\u00f3rio dos antigos VASP portugueses terminou a 1 de julho de 2026.<\/p>

A Liquid n\u00e3o tem nada disto. Uma sidechain federada n\u00e3o \u00e9 um CASP, n\u00e3o custodia fundos de clientes no sentido legal e n\u00e3o presta um servi\u00e7o regist\u00e1vel, por isso a MiCA, a CMVM e o Banco de Portugal simplesmente n\u00e3o lhe chegam. Para o DeFi e para os protocolos verdadeiramente descentralizados, as regras europeias s\u00f3 s\u00e3o esperadas para 2027 ou 2028. Entretanto, o utilizador lesado por um protocolo n\u00e3o tem fundo de garantia, n\u00e3o tem queixa poss\u00edvel e n\u00e3o tem seguro; tem, no m\u00e1ximo, o post-mortem. \u00c9 literalmente o seu \u00fanico recurso, e \u00e9 por isso que a qualidade dessa aut\u00f3psia importa tanto. A aproxima\u00e7\u00e3o do regulador europeu ao universo dos cofres e do cr\u00e9dito on-chain<\/a> \u00e9 um movimento que j\u00e1 come\u00e7ou, mas ainda vai a meio.<\/p>

H\u00e1 ainda um contraste de ritmo que a DORA<\/a>, o regulamento europeu de resili\u00eancia operacional digital em vigor desde janeiro de 2025, torna evidente. Um CASP regulado tem rel\u00f3gios obrigat\u00f3rios para reportar um incidente grave ao supervisor: uma notifica\u00e7\u00e3o inicial em horas, um relat\u00f3rio interm\u00e9dio em dias e um relat\u00f3rio final em cerca de um m\u00eas. Um protocolo n\u00e3o tem rel\u00f3gio nenhum. A Blockstream levou o tempo que entendeu a publicar a sua avalia\u00e7\u00e3o, e f\u00ea-lo porque quis, n\u00e3o porque a lei a obrigasse.<\/p>

O que isto muda para quem guarda cripto em euros<\/h2>

Que li\u00e7\u00f5es pr\u00e1ticas tira o investidor portugu\u00eas do pior m\u00eas de 2026? A primeira \u00e9 que a velha m\u00e1xima \u00abnot your keys, not your coins\u00bb tem um reverso inc\u00f3modo. A autocust\u00f3dia elimina o risco de a corretora ser esvaziada, mas transfere para o utilizador o peso de atualizar firmware, guardar sementes com entropia a s\u00e9rio e ler aut\u00f3psias como a da Coldcard. A cust\u00f3dia numa CEX cred\u00edvel troca esse peso por um risco de contraparte amortecido por um fundo, desde que o fundo exista mesmo e seja do tamanho anunciado.<\/p>

Antes de confiar o saldo a uma plataforma, vale a pena fazer tr\u00eas perguntas concretas:<\/p>