A 30 de julho de 2026, a Coinkite, fabricante canadiana das carteiras de hardware Coldcard, publicou um aviso de seguran\u00e7a que come\u00e7ou como um par\u00e1grafo t\u00e9cnico e terminou como um dos maiores casos de furto de bitcoin do ano. Um erro introduzido no firmware em mar\u00e7o de 2021, nunca detetado internamente, fazia com que algumas unidades gerassem frases-semente com muito menos aleatoriedade do que o protocolo Bitcoin exige. Cinco anos depois, v\u00e1rios grupos distintos e n\u00e3o coordenados encontraram o erro e come\u00e7aram a reconstruir chaves privadas por for\u00e7a bruta.<\/p>
Nos primeiros 41 minutos de explora\u00e7\u00e3o ativa, cerca de 1.196 endere\u00e7os foram esvaziados, segundo o relato da The Hacker News<\/a>. No dia seguinte, a contagem subiu para cerca de 4.585 endere\u00e7os e perto de 1.367 BTC. Uma semana depois, a 4 de agosto, a TechCrunch<\/a> confirmava que o total j\u00e1 ultrapassava os 130 milh\u00f5es de d\u00f3lares (cerca de 112,6 milh\u00f5es de euros), com Tom Robinson, cofundador da empresa de an\u00e1lise on-chain Elliptic, a descrever essa estimativa como \u00abrazoavelmente correta\u00bb. O n\u00famero continuava a subir \u00e0 medida que mais endere\u00e7os vulner\u00e1veis eram descobertos e esvaziados por atacantes distintos.<\/p> Este texto n\u00e3o \u00e9 sobre a Coldcard em si, nem \u00e9 mais um invent\u00e1rio de quem perdeu o qu\u00ea. \u00c9 sobre um g\u00e9nero que a cripto construiu ao longo da \u00faltima d\u00e9cada, o post-mortem de protocolo, e sobre o que acontece quando esse g\u00e9nero \u00e9 confrontado com um tipo de falha para o qual nunca foi desenhado: n\u00e3o um contrato inteligente, n\u00e3o uma ponte, n\u00e3o uma exchange, mas um peda\u00e7o de firmware dentro de um dispositivo que milhares de pessoas compraram precisamente para n\u00e3o terem de confiar em mais ningu\u00e9m.<\/p> Ao longo dos \u00faltimos dez anos, a cripto desenvolveu um g\u00e9nero liter\u00e1rio muito pr\u00f3prio: o post-mortem p\u00fablico. Depois de um ataque, a equipa afetada publica um documento t\u00e9cnico que reconstr\u00f3i a linha do tempo, identifica a causa-raiz, quantifica o preju\u00edzo e, frequentemente, negoceia em p\u00fablico com quem executou o ataque. A estrutura tem ra\u00edzes na cultura de post-mortem sem culpa popularizada pelo livro de fiabilidade de sistemas da Google, o chamado SRE Book<\/a>, mas a cripto acrescentou-lhe um ingrediente que a Google nunca precisou: o p\u00fablico l\u00ea estes documentos em tempo real, muitas vezes antes de a pr\u00f3pria equipa terminar a investiga\u00e7\u00e3o.<\/p> Ler estes documentos tornou-se, para uma parte do p\u00fablico cripto, quase um g\u00e9nero de entretenimento s\u00e9rio: o rekt.news<\/a> adotou desde cedo uma voz narrativa quase noir, catalogando cada novo caso com um tom entre o forense e o ir\u00f3nico, e transformando o conjunto num \u00abhall da vergonha\u00bb coletivo que qualquer novo protocolo teme integrar. Essa dimens\u00e3o p\u00fablica, confessional, quase teatral, \u00e9 o que distingue o post-mortem cripto do seu antepassado corporativo: uma equipa de engenharia escreve um post-mortem interno para uma audi\u00eancia de colegas; uma equipa de um protocolo sabe que o seu vai ser lido, escrutinado e por vezes citado em tribunal anos depois.<\/p> O padr\u00e3o-ouro deste g\u00e9nero continua a ser a resposta da Bybit ao roubo de cerca de 1,5 mil milh\u00f5es de d\u00f3lares em fevereiro de 2025. O diretor-executivo Ben Zhou optou por atualiza\u00e7\u00f5es p\u00fablicas quase em direto e publicou relat\u00f3rios forenses preliminares dias depois do ataque. Zhou resumiu a filosofia numa frase que se tornou refer\u00eancia no setor: \u00aba nossa resposta assenta principalmente em manter a transpar\u00eancia\u00bb, disse, segundo a Cryptonews<\/a>. J\u00e1 explor\u00e1mos como esta ret\u00f3rica pode tornar-se ela pr\u00f3pria um campo de batalha, veja-se o nosso texto sobre post-mortems a duelo<\/a>, e como o g\u00e9nero tem ra\u00edzes t\u00e3o antigas quanto os primeiros f\u00f3runs de videojogos que praticavam a mesma autocr\u00edtica p\u00fablica, tal como descrevemos em o que os videojogos ensinaram primeiro<\/a>. Mas todos estes exemplos partilham uma condi\u00e7\u00e3o pr\u00e9via: existe sempre algu\u00e9m do lado de dentro capaz de escrever o documento e, mais importante, capaz de agir sobre as suas conclus\u00f5es.<\/p> O documento que a Coinkite publicou \u00e9, em si mesmo, um exemplar quase perfeito do g\u00e9nero t\u00e9cnico: direto, sem floreados, e surpreendentemente honesto sobre o mecanismo exato da falha. Vale a pena olhar para dentro dele, porque poucos post-mortems de 2026 descem t\u00e3o fundo ao c\u00f3digo.<\/p> A origem remonta a uma migra\u00e7\u00e3o de 2021 para a biblioteca criptogr\u00e1fica libsecp256k1 do pr\u00f3prio n\u00facleo do Bitcoin. Nessa migra\u00e7\u00e3o, a gera\u00e7\u00e3o da frase-semente deixou de chamar a fun\u00e7\u00e3o interna da Coldcard e passou a chamar uma fun\u00e7\u00e3o gen\u00e9rica da camada de firmware MicroPython. O problema est\u00e1 numa \u00fanica linha de c\u00f3digo: uma verifica\u00e7\u00e3o de compila\u00e7\u00e3o usava a diretiva ifndef para testar se a macro MICROPY_HW_ENABLE_RNG estava definida, em vez de testar se o seu valor era diferente de zero. Como a macro estava definida, mas com valor zero, a verifica\u00e7\u00e3o nunca disparava, e o firmware ca\u00eda silenciosamente para um gerador de n\u00fameros pseudoaleat\u00f3rios por software, o chamado Yasmarang, herdado do pr\u00f3prio MicroPython, em vez de usar o gerador de hardware dedicado do chip.<\/p> Este tipo de erro tem um nome na literatura de seguran\u00e7a inform\u00e1tica: uma falha de integra\u00e7\u00e3o entre camadas de confian\u00e7a. Cada componente, isoladamente, pode ter sido revisto e testado; o gerador de hardware da Coldcard tinha sido auditado no passado, e o c\u00f3digo do MicroPython \u00e9 amplamente utilizado e escrutinado noutros contextos. O problema surgiu precisamente na fronteira entre os dois, onde a suposi\u00e7\u00e3o de uma equipa, a de que a macro estar definida implicava estar ativada, n\u00e3o foi validada pela suposi\u00e7\u00e3o da outra. \u00c9 uma classe de erro particularmente dif\u00edcil de apanhar em auditoria tradicional, porque nenhuma das duas partes, vista isoladamente, parece estar errada.<\/p> Segundo o pr\u00f3prio relato t\u00e9cnico da Coinkite<\/a>, \u00abn\u00e3o est\u00e1vamos cientes do erro at\u00e9 hoje\u00bb, e a empresa descreve a causa como \u00abuma s\u00e9rie complexa e subtil de erros\u00bb. O impacto varia por modelo: nos Mk2 e Mk3, o espa\u00e7o de procura efetivo caiu para cerca de 40 bits, derivados sobretudo do identificador do dispositivo e de um temporizador interno; nos Mk4, Mk5 e Q, o elemento seguro do chip ainda contribu\u00eda alguma entropia, mas essa entropia era reduzida a apenas alguns bytes antes de ser combinada com o gerador fraco, deixando um espa\u00e7o efetivo de cerca de 72 bits, muito longe dos 128 bits que uma frase-semente de 12 palavras pressup\u00f5e. A diferen\u00e7a importa na pr\u00e1tica: 128 bits tornam um ataque de for\u00e7a bruta praticamente imposs\u00edvel; 72 bits j\u00e1 \u00e9 um n\u00famero que clusters de GPUs conseguem varrer em dias ou semanas; 40 bits est\u00e1 ao alcance de um port\u00e1til comum em minutos. A Wizardsardine<\/a>, empresa independente de seguran\u00e7a em Bitcoin, publicou uma an\u00e1lise t\u00e9cnica paralela que chega a conclus\u00f5es semelhantes sobre a gravidade pr\u00e1tica do problema em cada modelo.<\/p> A cronologia p\u00fablica, reconstru\u00edda a partir do aviso da Coinkite e da cobertura entretanto publicada, \u00e9 a seguinte:<\/p> O mais incomum nesta linha do tempo, para quem j\u00e1 leu dezenas de post-mortems de protocolo, \u00e9 que ela n\u00e3o tem fim. Nos casos cl\u00e1ssicos, mesmo os mais longos, h\u00e1 um momento em que o preju\u00edzo fica fixado: os fundos foram devolvidos, o atacante desapareceu com um montante final, ou a explora\u00e7\u00e3o ficou tecnicamente imposs\u00edvel assim que o contrato foi corrigido ou pausado. Aqui n\u00e3o. Enquanto existirem sementes geradas em firmware vulner\u00e1vel e ainda n\u00e3o migradas, o n\u00famero pode continuar a subir, e ningu\u00e9m, nem a Coinkite, nem a Elliptic, sabe hoje qual ser\u00e1 o total final.<\/p> Os post-mortems de protocolo que este site j\u00e1 analisou, do roubo da Ronin ao da Euler, passando pela Bybit, t\u00eam quase sempre uma estrutura de responsabiliza\u00e7\u00e3o reconhec\u00edvel: existe uma equipa ou empresa do lado da v\u00edtima, e existe, do lado oposto, ou um atacante identific\u00e1vel com quem negociar, ou um agente estatal, tipicamente ligado \u00e0 Coreia do Norte, a quem atribuir o ataque sem esperar devolu\u00e7\u00e3o. O caso Coldcard n\u00e3o encaixa em nenhum dos dois moldes.<\/p> N\u00e3o h\u00e1 um \u00fanico atacante. Segundo a TechCrunch, a Galaxy Research identificou pelo menos uma d\u00fazia de grupos distintos, n\u00e3o coordenados entre si, a competir pelos mesmos endere\u00e7os vulner\u00e1veis. N\u00e3o \u00e9 uma opera\u00e7\u00e3o, \u00e9 uma corrida: assim que a falha se tornou p\u00fablica, qualquer pessoa com conhecimento t\u00e9cnico suficiente podia calcular quais endere\u00e7os tinham maior probabilidade de ter sido gerados com pouca entropia e tentar chegar l\u00e1 primeiro. N\u00e3o h\u00e1, portanto, ningu\u00e9m com quem a Coinkite ou as v\u00edtimas possam negociar, ao estilo da troca que devolveu a maior parte dos fundos e deixou uma pequena percentagem como recompensa, como aconteceu com a Euler Finance.<\/p> Tamb\u00e9m n\u00e3o h\u00e1 um DAO. Nos protocolos DeFi, mesmo quando o ataque \u00e9 irrevers\u00edvel, existe frequentemente um mecanismo de governa\u00e7\u00e3o, uma vota\u00e7\u00e3o, um fundo comunit\u00e1rio, capaz de decidir compensar v\u00edtimas com reservas de tesouraria. A Coldcard n\u00e3o tem token, n\u00e3o tem DAO, n\u00e3o tem tesouraria comunit\u00e1ria. \u00c9 uma empresa privada canadiana que vende um dispositivo f\u00edsico; depois da venda, as chaves geradas dentro desse dispositivo nunca tocaram nos servidores da Coinkite, o que \u00e9, ironicamente, exatamente o ponto de venda de uma carteira de hardware isolada da rede. A mesma arquitetura que torna o dispositivo resistente a um ataque remoto \u00e9 a que torna imposs\u00edvel \u00e0 empresa saber, sem que o utilizador o diga, se uma determinada semente est\u00e1 ou n\u00e3o em risco.<\/p> E n\u00e3o h\u00e1, por fim, uma empresa com bolso suficientemente fundo. Comparar com o nosso texto sobre quem sobrevive ao hack e quem desaparece<\/a> \u00e9 instrutivo: a Sky Mavis absorveu os 625 milh\u00f5es de d\u00f3lares do ataque \u00e0 Ronin com uma ronda de financiamento liderada pela Binance; a Bybit, com milhares de milh\u00f5es em reservas, cobriu o preju\u00edzo do seu pr\u00f3prio bolso. A Coinkite \u00e9 uma empresa pequena, sem financiamento de capital de risco conhecido, que fabrica um produto de nicho. N\u00e3o tem, nem nunca teve, capacidade financeira para reembolsar 130 milh\u00f5es de d\u00f3lares a terceiros.<\/p> Talvez o aspeto mais contraintuitivo deste caso, e o que mais o distingue de um post-mortem de contrato inteligente, \u00e9 que a corre\u00e7\u00e3o do erro n\u00e3o resolve nada para quem j\u00e1 foi afetado. Num contrato inteligente, corrigir e reimplementar o c\u00f3digo, ou pausar e migrar para uma vers\u00e3o nova, normalmente fecha a janela de explora\u00e7\u00e3o: o erro deixa de existir, ponto final. Numa carteira de hardware, a l\u00f3gica \u00e9 inversa.<\/p> A pr\u00f3pria Coinkite \u00e9 expl\u00edcita sobre isto no seu aviso: atualizar o firmware n\u00e3o repara uma frase-semente que j\u00e1 foi gerada em firmware vulner\u00e1vel. A aleatoriedade fraca n\u00e3o \u00e9 um problema que o dispositivo possa corrigir remotamente nem que a pr\u00f3xima atualiza\u00e7\u00e3o apague; a chave privada resultante desse processo j\u00e1 existe, j\u00e1 \u00e9 potencialmente calcul\u00e1vel, e vai continuar em risco para sempre, mesmo depois de o firmware estar impec\u00e1vel. A \u00fanica forma de resolver \u00e9 gerar uma frase-semente inteiramente nova, num dispositivo j\u00e1 corrigido, e mover todos os fundos para essa nova semente antes que outra pessoa o fa\u00e7a.<\/p> Isto transforma o post-mortem num objeto estranho: n\u00e3o \u00e9 uma explica\u00e7\u00e3o retrospetiva de um problema resolvido, \u00e9 uma instru\u00e7\u00e3o de sobreviv\u00eancia para um problema que continua ativo em cada dispositivo ainda n\u00e3o atualizado e migrado. A Coinkite acrescenta uma nota que poucos post-mortems de protocolo precisam de incluir: sementes geradas a partir de, pelo menos, 50 lan\u00e7amentos de dado privados e independentes n\u00e3o dependem do gerador de n\u00fameros aleat\u00f3rios do dispositivo e n\u00e3o est\u00e3o em risco s\u00f3 por causa deste problema, uma salvaguarda que s\u00f3 faz sentido porque, nesta categoria de falha, a responsabilidade final pela entropia pode, e talvez deva, sair do dispositivo e passar para o utilizador.<\/p> A cripto j\u00e1 passou por isto antes, quase treze anos antes, quase ao dia. Em agosto de 2013, descobriu-se que a implementa\u00e7\u00e3o do gerador SecureRandom no Android continha falhas que a tornavam inadequada para uso criptogr\u00e1fico, afetando qualquer carteira Bitcoin gerada atrav\u00e9s de uma aplica\u00e7\u00e3o Android, incluindo nomes conhecidos da \u00e9poca. O resultado foi a assinatura de transa\u00e7\u00f5es diferentes com o mesmo n\u00famero supostamente aleat\u00f3rio, um erro que, tal como no caso Coldcard, permitia a quem soubesse procurar reconstruir a chave privada a partir de dados publicados na pr\u00f3pria blockchain. O alerta oficial<\/a> da \u00e9poca recomendava exatamente o mesmo rem\u00e9dio que a Coinkite recomenda hoje: gerar um endere\u00e7o novo com um gerador de aleatoriedade reparado e mover para l\u00e1 todos os fundos.<\/p> O paralelo \u00e9 \u00fatil por dois motivos. Primeiro, mostra que este tipo de falha n\u00e3o \u00e9 uma novidade ex\u00f3tica trazida pela era da intelig\u00eancia artificial, \u00e9 um erro estrutural que a ind\u00fastria j\u00e1 cometeu antes e voltou a cometer, desta vez num dispositivo cuja fun\u00e7\u00e3o declarada era precisamente eliminar depend\u00eancias deste tipo. Segundo, mostra como o g\u00e9nero do post-mortem evoluiu: em 2013, a resposta coube em larga medida \u00e0 comunidade de programadores que descobriu o problema e a um alerta t\u00e9cnico sucinto; em 2026, o mesmo tipo de falha gera cobertura em tempo real de m\u00faltiplos meios especializados, an\u00e1lises forenses de empresas como a Elliptic, e um documento t\u00e9cnico de v\u00e1rias p\u00e1ginas publicado pela pr\u00f3pria fabricante horas depois da descoberta. A cultura do post-mortem amadureceu; o tipo de erro que a motiva, nem sempre.<\/p> Um dos \u00e2ngulos mais discutidos do caso Coldcard nas semanas seguintes ao an\u00fancio foi o papel, ainda por confirmar em detalhe mas amplamente sugerido pela cobertura especializada, de ferramentas de intelig\u00eancia artificial na descoberta do problema. Rodolfo Novak, cofundador da Coinkite e conhecido no setor pelo pseud\u00f3nimo NVK, foi direto sobre o que isto significa para qualquer fabricante de hardware ou equipa de protocolo: \u00abacreditamos que esta \u00e9 uma realidade s\u00f3bria do novo paradigma da IA. A revis\u00e3o de c\u00f3digo assistida por IA j\u00e1 consegue encontrar erros latentes a uma velocidade que ultrapassa at\u00e9 os profissionais mais experientes do setor\u00bb, disse, segundo a Bitcoin Magazine<\/a>.<\/p> Novak foi ainda mais longe numa segunda declara\u00e7\u00e3o, que resume talvez a mudan\u00e7a mais profunda na cultura de seguran\u00e7a de 2026: \u00abse o seu firmware \u00e9 de c\u00f3digo aberto, ou alguma vez foi p\u00fablico, assuma que j\u00e1 est\u00e1 a ser lido por atacantes e por defensores em simult\u00e2neo\u00bb. A frase inverte uma pressuposi\u00e7\u00e3o antiga da seguran\u00e7a de c\u00f3digo aberto, a de que mais olhos a examinar o c\u00f3digo o tornam mais seguro com o tempo; com modelos de IA capazes de auditar milhares de linhas de firmware em minutos, esses olhos adicionais j\u00e1 n\u00e3o pertencem exclusivamente \u00e0 comunidade de programadores volunt\u00e1rios, podem pertencer a quem procura explorar, n\u00e3o corrigir.<\/p> Para o g\u00e9nero do post-mortem, isto tem uma implica\u00e7\u00e3o pr\u00e1tica inc\u00f3moda: se ferramentas de IA conseguem encontrar erros de cinco anos mais depressa do que as equipas internas os encontram por revis\u00e3o manual, a janela entre a exist\u00eancia do erro e a sua explora\u00e7\u00e3o pode estar a encolher mais depressa do que a janela entre a descoberta interna e a disponibiliza\u00e7\u00e3o de um patch. Um post-mortem tradicionalmente documenta o que j\u00e1 aconteceu; nesta vers\u00e3o do futuro, pode ter de come\u00e7ar a antecipar quanto tempo, exatamente, uma equipa tem antes de uma ferramenta p\u00fablica encontrar o mesmo erro que os seus pr\u00f3prios auditores ainda n\u00e3o viram.<\/p> Para tornar a compara\u00e7\u00e3o concreta, vale a pena colocar o caso Coldcard lado a lado com quatro post-mortems de protocolo j\u00e1 bem documentados e ler as diferen\u00e7as coluna a coluna.<\/p>Anatomia do post-mortem que a cripto j\u00e1 sabe escrever<\/h2>
Dentro do post-mortem t\u00e9cnico da Coinkite<\/h2>
Cronologia de uma fuga que ainda n\u00e3o parou<\/h2>
Porque este post-mortem n\u00e3o tem r\u00e9u<\/h2>
O paradoxo do patch: corrigir o c\u00f3digo n\u00e3o repara a chave<\/h2>
N\u00e3o \u00e9 a primeira vez: da SecureRandom de 2013 ao RNG da Coldcard<\/h2>
Intelig\u00eancia artificial: quem encontra o erro primeiro?<\/h2>
Como este post-mortem difere dos post-mortems de protocolo<\/h2>