Post-mortem sem réu: a falha de cinco anos da Coldcard

O erro que dormiu cinco anos dentro de uma carteira de hardware

A 30 de julho de 2026, a Coinkite, fabricante canadiana das carteiras de hardware Coldcard, publicou um aviso de segurança que começou como um parágrafo técnico e terminou como um dos maiores casos de furto de bitcoin do ano. Um erro introduzido no firmware em março 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ários grupos distintos e não coordenados encontraram o erro e começaram a reconstruir chaves privadas por força bruta.

Nos primeiros 41 minutos de exploração ativa, cerca de 1.196 endereços foram esvaziados, segundo o relato da The Hacker News. No dia seguinte, a contagem subiu para cerca de 4.585 endereços e perto de 1.367 BTC. Uma semana depois, a 4 de agosto, a TechCrunch confirmava que o total já ultrapassava os 130 milhões de dólares (cerca de 112,6 milhões de euros), com Tom Robinson, cofundador da empresa de análise on-chain Elliptic, a descrever essa estimativa como «razoavelmente correta». O número continuava a subir à medida que mais endereços vulneráveis eram descobertos e esvaziados por atacantes distintos.

Este texto não é sobre a Coldcard em si, nem é mais um inventário de quem perdeu o quê. É sobre um género que a cripto construiu ao longo da última década, o post-mortem de protocolo, e sobre o que acontece quando esse género é confrontado com um tipo de falha para o qual nunca foi desenhado: não um contrato inteligente, não uma ponte, não uma exchange, mas um pedaço de firmware dentro de um dispositivo que milhares de pessoas compraram precisamente para não terem de confiar em mais ninguém.

Anatomia do post-mortem que a cripto já sabe escrever

Ao longo dos últimos dez anos, a cripto desenvolveu um género literário muito próprio: o post-mortem público. Depois de um ataque, a equipa afetada publica um documento técnico que reconstrói a linha do tempo, identifica a causa-raiz, quantifica o prejuízo e, frequentemente, negoceia em público com quem executou o ataque. A estrutura tem raízes na cultura de post-mortem sem culpa popularizada pelo livro de fiabilidade de sistemas da Google, o chamado SRE Book, mas a cripto acrescentou-lhe um ingrediente que a Google nunca precisou: o público lê estes documentos em tempo real, muitas vezes antes de a própria equipa terminar a investigação.

Ler estes documentos tornou-se, para uma parte do público cripto, quase um género de entretenimento sério: o rekt.news adotou desde cedo uma voz narrativa quase noir, catalogando cada novo caso com um tom entre o forense e o irónico, e transformando o conjunto num «hall da vergonha» coletivo que qualquer novo protocolo teme integrar. Essa dimensão pública, confessional, quase teatral, é o que distingue o post-mortem cripto do seu antepassado corporativo: uma equipa de engenharia escreve um post-mortem interno para uma audiência de colegas; uma equipa de um protocolo sabe que o seu vai ser lido, escrutinado e por vezes citado em tribunal anos depois.

O padrão-ouro deste género continua a ser a resposta da Bybit ao roubo de cerca de 1,5 mil milhões de dólares em fevereiro de 2025. O diretor-executivo Ben Zhou optou por atualizações públicas quase em direto e publicou relatórios forenses preliminares dias depois do ataque. Zhou resumiu a filosofia numa frase que se tornou referência no setor: «a nossa resposta assenta principalmente em manter a transparência», disse, segundo a Cryptonews. Já explorámos como esta retórica pode tornar-se ela própria um campo de batalha, veja-se o nosso texto sobre post-mortems a duelo, e como o género tem raízes tão antigas quanto os primeiros fóruns de videojogos que praticavam a mesma autocrítica pública, tal como descrevemos em o que os videojogos ensinaram primeiro. Mas todos estes exemplos partilham uma condição prévia: existe sempre alguém do lado de dentro capaz de escrever o documento e, mais importante, capaz de agir sobre as suas conclusões.

Dentro do post-mortem técnico da Coinkite

O documento que a Coinkite publicou é, em si mesmo, um exemplar quase perfeito do género técnico: 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ão fundo ao código.

A origem remonta a uma migração de 2021 para a biblioteca criptográfica libsecp256k1 do próprio núcleo do Bitcoin. Nessa migração, a geração da frase-semente deixou de chamar a função interna da Coldcard e passou a chamar uma função genérica da camada de firmware MicroPython. O problema está numa única linha de código: uma verificação de compilação 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ção nunca disparava, e o firmware caía silenciosamente para um gerador de números pseudoaleatórios por software, o chamado Yasmarang, herdado do próprio MicroPython, em vez de usar o gerador de hardware dedicado do chip.

Este tipo de erro tem um nome na literatura de segurança informática: uma falha de integração entre camadas de confiança. Cada componente, isoladamente, pode ter sido revisto e testado; o gerador de hardware da Coldcard tinha sido auditado no passado, e o código do MicroPython é amplamente utilizado e escrutinado noutros contextos. O problema surgiu precisamente na fronteira entre os dois, onde a suposição de uma equipa, a de que a macro estar definida implicava estar ativada, não foi validada pela suposição da outra. É uma classe de erro particularmente difícil de apanhar em auditoria tradicional, porque nenhuma das duas partes, vista isoladamente, parece estar errada.

Segundo o próprio relato técnico da Coinkite, «não estávamos cientes do erro até hoje», e a empresa descreve a causa como «uma série complexa e subtil de erros». O impacto varia por modelo: nos Mk2 e Mk3, o espaço 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ía alguma entropia, mas essa entropia era reduzida a apenas alguns bytes antes de ser combinada com o gerador fraco, deixando um espaço efetivo de cerca de 72 bits, muito longe dos 128 bits que uma frase-semente de 12 palavras pressupõe. A diferença importa na prática: 128 bits tornam um ataque de força bruta praticamente impossível; 72 bits já é um número que clusters de GPUs conseguem varrer em dias ou semanas; 40 bits está ao alcance de um portátil comum em minutos. A Wizardsardine, empresa independente de segurança em Bitcoin, publicou uma análise técnica paralela que chega a conclusões semelhantes sobre a gravidade prática do problema em cada modelo.

Cronologia de uma fuga que ainda não parou

A cronologia pública, reconstruída a partir do aviso da Coinkite e da cobertura entretanto publicada, é a seguinte:

• Maio de 2018: o código de reserva do MicroPython que acabaria por causar o problema é introduzido no projeto upstream, anos antes de a Coldcard o adotar.
• Março de 2021: a migração para libsecp256k1 introduz a falha na geração de sementes da Coldcard, a partir do firmware 4.0.1.
• 30 de julho de 2026: a Coinkite deteta e divulga publicamente o problema; nos primeiros 41 minutos de exploração ativa, cerca de 1.196 endereços são esvaziados, segundo a The Hacker News.
• 31 de julho a 1 de agosto de 2026: a Coinkite disponibiliza firmware corrigido para todos os modelos afetados; a contagem de fundos roubados já ronda os 88,6 milhões de dólares, cerca de 76,7 milhões de euros, sobre aproximadamente 4.585 endereços.
• 4 de agosto de 2026: a TechCrunch, citando a Elliptic, confirma que o total já ultrapassa os 130 milhões de dólares, com pelo menos uma dúzia de grupos distintos a explorar o mesmo problema em paralelo, segundo dados citados da Galaxy Research.

O mais incomum nesta linha do tempo, para quem já leu dezenas de post-mortems de protocolo, é que ela não tem fim. Nos casos clássicos, mesmo os mais longos, há um momento em que o prejuízo fica fixado: os fundos foram devolvidos, o atacante desapareceu com um montante final, ou a exploração ficou tecnicamente impossível assim que o contrato foi corrigido ou pausado. Aqui não. Enquanto existirem sementes geradas em firmware vulnerável e ainda não migradas, o número pode continuar a subir, e ninguém, nem a Coinkite, nem a Elliptic, sabe hoje qual será o total final.

Porque este post-mortem não tem réu

Os post-mortems de protocolo que este site já analisou, do roubo da Ronin ao da Euler, passando pela Bybit, têm quase sempre uma estrutura de responsabilização reconhecível: existe uma equipa ou empresa do lado da vítima, e existe, do lado oposto, ou um atacante identificável com quem negociar, ou um agente estatal, tipicamente ligado à Coreia do Norte, a quem atribuir o ataque sem esperar devolução. O caso Coldcard não encaixa em nenhum dos dois moldes.

Não há um único atacante. Segundo a TechCrunch, a Galaxy Research identificou pelo menos uma dúzia de grupos distintos, não coordenados entre si, a competir pelos mesmos endereços vulneráveis. Não é uma operação, é uma corrida: assim que a falha se tornou pública, qualquer pessoa com conhecimento técnico suficiente podia calcular quais endereços tinham maior probabilidade de ter sido gerados com pouca entropia e tentar chegar lá primeiro. Não há, portanto, ninguém com quem a Coinkite ou as vítimas 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.

Também não há um DAO. Nos protocolos DeFi, mesmo quando o ataque é irreversível, existe frequentemente um mecanismo de governação, uma votação, um fundo comunitário, capaz de decidir compensar vítimas com reservas de tesouraria. A Coldcard não tem token, não tem DAO, não tem tesouraria comunitária. É uma empresa privada canadiana que vende um dispositivo físico; depois da venda, as chaves geradas dentro desse dispositivo nunca tocaram nos servidores da Coinkite, o que é, 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 é a que torna impossível à empresa saber, sem que o utilizador o diga, se uma determinada semente está ou não em risco.

E não há, por fim, uma empresa com bolso suficientemente fundo. Comparar com o nosso texto sobre quem sobrevive ao hack e quem desaparece é instrutivo: a Sky Mavis absorveu os 625 milhões de dólares do ataque à Ronin com uma ronda de financiamento liderada pela Binance; a Bybit, com milhares de milhões em reservas, cobriu o prejuízo do seu próprio bolso. A Coinkite é uma empresa pequena, sem financiamento de capital de risco conhecido, que fabrica um produto de nicho. Não tem, nem nunca teve, capacidade financeira para reembolsar 130 milhões de dólares a terceiros.

O paradoxo do patch: corrigir o código não repara a chave

Talvez o aspeto mais contraintuitivo deste caso, e o que mais o distingue de um post-mortem de contrato inteligente, é que a correção do erro não resolve nada para quem já foi afetado. Num contrato inteligente, corrigir e reimplementar o código, ou pausar e migrar para uma versão nova, normalmente fecha a janela de exploração: o erro deixa de existir, ponto final. Numa carteira de hardware, a lógica é inversa.

A própria Coinkite é explícita sobre isto no seu aviso: atualizar o firmware não repara uma frase-semente que já foi gerada em firmware vulnerável. A aleatoriedade fraca não é um problema que o dispositivo possa corrigir remotamente nem que a próxima atualização apague; a chave privada resultante desse processo já existe, já é potencialmente calculável, e vai continuar em risco para sempre, mesmo depois de o firmware estar impecável. A única forma de resolver é gerar uma frase-semente inteiramente nova, num dispositivo já corrigido, e mover todos os fundos para essa nova semente antes que outra pessoa o faça.

Isto transforma o post-mortem num objeto estranho: não é uma explicação retrospetiva de um problema resolvido, é uma instrução de sobrevivência para um problema que continua ativo em cada dispositivo ainda não 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çamentos de dado privados e independentes não dependem do gerador de números aleatórios do dispositivo e não estão em risco só por causa deste problema, uma salvaguarda que só faz sentido porque, nesta categoria de falha, a responsabilidade final pela entropia pode, e talvez deva, sair do dispositivo e passar para o utilizador.

Não é a primeira vez: da SecureRandom de 2013 ao RNG da Coldcard

A cripto já passou por isto antes, quase treze anos antes, quase ao dia. Em agosto de 2013, descobriu-se que a implementação do gerador SecureRandom no Android continha falhas que a tornavam inadequada para uso criptográfico, afetando qualquer carteira Bitcoin gerada através de uma aplicação Android, incluindo nomes conhecidos da época. O resultado foi a assinatura de transações diferentes com o mesmo número supostamente aleatório, um erro que, tal como no caso Coldcard, permitia a quem soubesse procurar reconstruir a chave privada a partir de dados publicados na própria blockchain. O alerta oficial da época recomendava exatamente o mesmo remédio que a Coinkite recomenda hoje: gerar um endereço novo com um gerador de aleatoriedade reparado e mover para lá todos os fundos.

O paralelo é útil por dois motivos. Primeiro, mostra que este tipo de falha não é uma novidade exótica trazida pela era da inteligência artificial, é um erro estrutural que a indústria já cometeu antes e voltou a cometer, desta vez num dispositivo cuja função declarada era precisamente eliminar dependências deste tipo. Segundo, mostra como o género do post-mortem evoluiu: em 2013, a resposta coube em larga medida à comunidade de programadores que descobriu o problema e a um alerta técnico sucinto; em 2026, o mesmo tipo de falha gera cobertura em tempo real de múltiplos meios especializados, análises forenses de empresas como a Elliptic, e um documento técnico de várias páginas publicado pela própria fabricante horas depois da descoberta. A cultura do post-mortem amadureceu; o tipo de erro que a motiva, nem sempre.

Inteligência artificial: quem encontra o erro primeiro?

Um dos ângulos mais discutidos do caso Coldcard nas semanas seguintes ao anúncio foi o papel, ainda por confirmar em detalhe mas amplamente sugerido pela cobertura especializada, de ferramentas de inteligência artificial na descoberta do problema. Rodolfo Novak, cofundador da Coinkite e conhecido no setor pelo pseudónimo NVK, foi direto sobre o que isto significa para qualquer fabricante de hardware ou equipa de protocolo: «acreditamos que esta é uma realidade sóbria do novo paradigma da IA. A revisão de código assistida por IA já consegue encontrar erros latentes a uma velocidade que ultrapassa até os profissionais mais experientes do setor», disse, segundo a Bitcoin Magazine.

Novak foi ainda mais longe numa segunda declaração, que resume talvez a mudança mais profunda na cultura de segurança de 2026: «se o seu firmware é de código aberto, ou alguma vez foi público, assuma que já está a ser lido por atacantes e por defensores em simultâneo». A frase inverte uma pressuposição antiga da segurança de código aberto, a de que mais olhos a examinar o código 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á não pertencem exclusivamente à comunidade de programadores voluntários, podem pertencer a quem procura explorar, não corrigir.

Para o género do post-mortem, isto tem uma implicação prática incómoda: se ferramentas de IA conseguem encontrar erros de cinco anos mais depressa do que as equipas internas os encontram por revisão manual, a janela entre a existência do erro e a sua exploração pode estar a encolher mais depressa do que a janela entre a descoberta interna e a disponibilização de um patch. Um post-mortem tradicionalmente documenta o que já aconteceu; nesta versão do futuro, pode ter de começar a antecipar quanto tempo, exatamente, uma equipa tem antes de uma ferramenta pública encontrar o mesmo erro que os seus próprios auditores ainda não viram.

Como este post-mortem difere dos post-mortems de protocolo

Para tornar a comparação concreta, vale a pena colocar o caso Coldcard lado a lado com quatro post-mortems de protocolo já bem documentados e ler as diferenças coluna a coluna.

A última coluna é a que mais interessa a quem lê estes documentos à procura de uma lição prática. Em todos os outros quatro casos, existe uma entidade central, empresa, protocolo, ou o próprio atacante, que acaba por absorver, total ou parcialmente, o prejuízo. No caso Coldcard, essa entidade central simplesmente não existe. A Coinkite pode publicar o post-mortem mais honesto do ano, pode lançar firmware corrigido em 48 horas, e mesmo assim não tem qualquer mecanismo, contratual ou financeiro, para tornar as vítimas novamente inteiras. É a definição mais literal possível da máxima «não são as suas chaves, não são as suas moedas», aplicada ao contrário: se são mesmo as suas chaves, o prejuízo também é inteiramente seu.

A lacuna regulatória: onde ficam as carteiras de hardware nas regras europeias

Em qualquer um dos quatro primeiros casos da tabela acima, sobretudo se a vítima fosse residente na União Europeia, existiria pelo menos um caminho regulatório a explorar. Uma exchange como a Bybit, se estivesse registada como prestador de serviços de criptoativos ao abrigo do MiCA, responderia perante um supervisor nacional, em Portugal a CMVM, que fiscaliza a conduta de mercado dos prestadores de serviços de criptoativos, com o Banco de Portugal a acompanhar o registo e os aspetos ligados a moeda eletrónica e stablecoins. O DORA, o Regulamento sobre a Resiliência Operacional Digital, em vigor desde janeiro de 2025, obriga esses mesmos prestadores a reportar incidentes graves de tecnologias de informação dentro de prazos apertados: notificação inicial poucas horas após a classificação do incidente, relatório intermédio, relatório final dentro de um mês, segundo o texto oficial publicado pela EIOPA.

Nenhuma destas regras se aplica à Coinkite. Um fabricante de carteiras de hardware não é um prestador de serviços de criptoativos: não custodia fundos, não executa ordens, não presta serviços de câmbio. Cai completamente fora do perímetro do MiCA, tal como cai fora do perímetro do DORA, que regula a resiliência operacional de entidades financeiras, não a qualidade do código de um fabricante de eletrónica de consumo. Não existe, em lado nenhum da regulação europeia atual, uma norma que obrigue um fabricante de carteiras de hardware a divulgar uma vulnerabilidade dentro de um prazo determinado, a submeter o seu firmware a auditoria independente obrigatória, ou a manter um fundo de compensação para utilizadores afetados por um erro de fabrico.

Na ausência de um regime específico, o caminho jurídico disponível a uma vítima na União Europeia recai sobre regras gerais, nomeadamente as diretivas de responsabilidade do produtor e de proteção do consumidor, que permitem, em teoria, responsabilizar um fabricante por um defeito de fabrico que cause dano. Na prática, provar esse dano perante um tribunal civil, quantificar a perda de bitcoin roubado através de um erro de entropia, e fazê-lo contra uma empresa sediada fora da jurisdição europeia, é um processo lento, caro e sem qualquer precedente conhecido neste setor específico. A CMVM, tal como qualquer outro supervisor nacional de mercados na União Europeia, simplesmente não tem competência sobre este tipo de produto. O post-mortem de um contrato inteligente já vive, como temos vindo a explorar nesta série, numa zona cinzenta regulatória; o post-mortem de um dispositivo físico vive uma zona ainda mais vazia.

Quem investiga um crime sem contrato inteligente

Nos post-mortems de protocolo mais comuns, a investigação forense segue fundos on-chain: uma transação suspeita é sinalizada, uma empresa de análise on-chain traça o percurso dos tokens através de várias carteiras e pontes até uma exchange onde, com sorte, podem ser congelados. Já dedicámos um texto inteiro a explicar como funciona essa indústria, veja-se quem investiga os hacks cripto, mas o caso Coldcard testa os limites desse modelo de duas formas distintas.

Por um lado, a parte on-chain do trabalho continua a aplicar-se sem grandes alterações: assim que os bitcoins saem dos endereços comprometidos, tornam-se rastreáveis pelas mesmas ferramentas de sempre, e foi precisamente esse rasto que permitiu à Elliptic confirmar a ordem de grandeza dos 130 milhões de dólares. Por outro lado, a parte mais interessante do trabalho forense neste caso não acontece na blockchain, acontece antes dela: perceber quais endereços foram gerados com firmware vulnerável exige combinar metadados do dispositivo, datas de compra e versões de firmware. Não há um contrato inteligente a auditar, não há uma transação maliciosa isolada a dissecar linha a linha; há um padrão estatístico de fraqueza espalhado por milhares de dispositivos vendidos ao longo de cinco anos.

A Galaxy Research, braço de investigação da gestora de ativos digitais Galaxy Digital, desempenhou neste caso um papel que raramente vemos num post-mortem de protocolo: não confirmar uma atribuição única, mas documentar publicamente a existência de múltiplos atores em competição pelo mesmo conjunto de endereços vulneráveis. Isto explica também porque é que, ao contrário de casos como a Bybit, onde diferentes equipas forenses convergiram rapidamente numa atribuição de alta confiança à Coreia do Norte, o caso Coldcard não tem, até à data, uma atribuição clara. Num post-mortem de protocolo, saber quem atacou costuma ser o primeiro passo para decidir o que fazer a seguir; aqui, é quase irrelevante, porque a resposta correta, migrar para uma semente nova o mais depressa possível, é exatamente a mesma independentemente de quem esteja do outro lado.

O que um bom post-mortem de firmware precisa de ter

Se o setor já desenvolveu, ao longo de dezenas de casos, um consenso implícito sobre o que torna um post-mortem de contrato inteligente credível, linha do tempo precisa ao minuto, causa-raiz ao nível do código, quantificação honesta mesmo quando o número é embaraçoso, e alguma forma de compensação ou plano de recuperação, o caso Coldcard sugere que um post-mortem de firmware ou de hardware precisa de responder a perguntas ligeiramente diferentes.

Primeiro, precisa de explicar não apenas o que correu mal, mas há quanto tempo está a correr mal, porque a janela de exposição, neste caso mais de cinco anos, determina quantos dispositivos, potencialmente, estão em risco, um número muito mais difícil de estimar do que o valor bloqueado num contrato no momento do ataque. Segundo, precisa de ser explícito sobre o que a correção não resolve, uma secção que a maioria dos post-mortems de contratos inteligentes nem sequer precisa de escrever, mas que aqui é a informação mais importante de todo o documento. Terceiro, precisa de dar ao utilizador um critério objetivo para decidir se está ou não em risco, como a regra dos 50 lançamentos de dado independentes da Coinkite, um teste que qualquer pessoa pode aplicar à sua própria situação sem depender de mais nenhuma informação da empresa.

Quarto, e talvez mais difícil de aceitar para uma cultura habituada a fechar o ciclo com uma compensação, um post-mortem deste tipo pode ter de admitir, com honestidade, que não existe reparação financeira possível, e que a única forma de encerrar o incidente é cada utilizador individual concluir a migração para uma semente segura. Não é um final tão satisfatório como uma recompensa devolvida ou um fundo de reembolso, mas é o final honesto que este tipo de falha permite.

Modelos afetados e janela de exposição

Para quem possui um dispositivo Coldcard e ainda não confirmou o seu estado, a tabela seguinte resume a informação essencial publicada pela Coinkite.

Sementes geradas a partir de, no mínimo, 50 lançamentos de dado privados e independentes escapam ao problema, porque nesse caso a aleatoriedade nunca dependeu do gerador interno do dispositivo. Para todos os outros casos, a única forma prudente de agir, segundo a própria Coinkite, é atualizar o firmware, gerar uma frase-semente completamente nova, confirmar a nova impressão digital e o endereço de receção depois de reiniciar o dispositivo, fazer uma transação de teste antes de mover o saldo principal, e só depois concluir a migração total.

O que isto significa para quem guarda as próprias chaves

O caso Coldcard chega numa altura em que a mensagem dominante do setor, sobretudo depois de casos de fraude e comprometimento de custodiantes centralizados, tem sido incentivar cada vez mais utilizadores a assumir a custódia das suas próprias chaves. A ironia é que a falha mais recente e mais cara em bitcoin não veio de uma exchange centralizada nem de uma ponte DeFi, veio precisamente da categoria de produto que a indústria recomenda como a alternativa mais segura a essas duas coisas.

Isto não invalida o argumento da autocustódia, mas complica-o de uma forma que qualquer post-mortem sério sobre o tema tem de admitir: guardar as próprias chaves elimina o risco de um terceiro perder ou desviar os seus fundos, mas não elimina o risco de o próprio hardware que gera essas chaves ter uma falha oculta durante anos. Nos dias seguintes ao anúncio, várias vozes do setor, entre elas o diretor de tecnologia da Ledger, Charles Guillemet, vieram publicamente moderar a tentação de reagir ao caso Coldcard adotando de imediato uma configuração multiassinatura mais complexa: mais dispositivos, mais frases de recuperação para gerir e mais passos de coordenação introduzem, eles próprios, novos pontos de falha, segundo o relato do Cryptonomist. Já analisámos como esta mesma lógica de complexidade acrescida está a moldar o debate sobre seguros em sistemas de restaking, onde a corrida ao seguro depois de um slashing em cascata enfrenta um problema estrutural parecido: quanto mais camadas de proteção se empilham, mais difícil se torna garantir que cada camada, isoladamente, não introduz uma fragilidade nova.

Para os leitores que seguem esta série de post-mortems, o padrão que emerge ao longo de 2026 é cada vez mais claro: a cripto já sabe escrever a autópsia de um contrato inteligente com bastante competência, sabe negociar em público com um atacante, sabe, às vezes, reconstruir a confiança depois de um DAO votar uma compensação. O que ainda não sabe fazer, porque o problema é estruturalmente diferente, é escrever um post-mortem para uma falha que não tem dono, não tem prazo de resolução e não tem, no fim de contas, um final.

Perguntas Frequentes

O que é um post-mortem de protocolo em cripto?

Um post-mortem de protocolo é um documento técnico público, publicado por uma equipa ou empresa depois de um ataque ou falha grave, que reconstrói a linha do tempo do incidente, identifica a causa-raiz técnica, quantifica o prejuízo e, frequentemente, descreve os passos seguintes, seja uma correção de código, uma negociação com o atacante ou um plano de compensação. O género tem raízes na cultura de post-mortem sem culpa da engenharia de fiabilidade de sistemas, mas na cripto tornou-se um documento público lido em tempo real por toda a indústria.

O que aconteceu exatamente com a carteira Coldcard em 2026?

A Coinkite, fabricante da Coldcard, descobriu e divulgou a 30 de julho de 2026 que um erro de firmware introduzido em março de 2021 fazia com que algumas unidades gerassem frases-semente com muito menos aleatoriedade do que o exigido, entre cerca de 40 e 72 bits de entropia efetiva em vez dos 128 bits esperados. Vários grupos distintos exploraram o problema para reconstruir chaves privadas por força bruta, com o total roubado a ultrapassar os 130 milhões de dólares até 4 de agosto de 2026, segundo dados citados pela Elliptic.

Atualizar o firmware da Coldcard resolve o problema?

Só parcialmente. Atualizar para o firmware corrigido impede que o dispositivo continue a gerar novas sementes fracas, mas não repara uma frase-semente que já tenha sido criada em firmware vulnerável antes da atualização. Quem esteve exposto precisa de gerar uma frase-semente completamente nova, num dispositivo já atualizado, e mover todos os fundos para essa nova semente; a chave antiga permanece em risco para sempre, independentemente da atualização.

Quem regula a segurança das carteiras de hardware na União Europeia?

Atualmente, nenhum regime específico. O MiCA e o DORA aplicam-se a prestadores de serviços de criptoativos, como exchanges ou custodiantes, supervisionados em Portugal pela CMVM e pelo Banco de Portugal, mas um fabricante de carteiras de hardware não presta esse tipo de serviço e cai fora do perímetro de ambos os regulamentos. Não existe, por isso, uma obrigação legal europeia de divulgação de vulnerabilidades, auditoria de firmware ou compensação de utilizadores para este tipo de produto.

Como sei se a minha carteira Coldcard foi afetada?

Segundo a Coinkite, o risco depende do modelo e da versão de firmware ativa quando a frase-semente foi gerada: Mk2 e Mk3 em firmware 4.0.1 a 4.1.9, e versões de Mk4, Mk5 e Q anteriores ao patch de 31 de julho de 2026, estão potencialmente expostos. A exceção é qualquer semente gerada a partir de, no mínimo, 50 lançamentos de dado privados e independentes, que nunca dependeu do gerador interno do dispositivo. Na dúvida, a recomendação é atualizar o firmware e migrar para uma semente nova por precaução.

Marcus Okafor é jornalista da HOGE Wire, especializado em segurança, protocolos e cultura cripto.