Post-mortem cripto: o que os videojogos ensinaram primeiro

Quando a WEMIX ainda estava a escrever o seu post-mortem

A 26 de julho de 2026, às 09:17 UTC, alguém obteve privilégios de administrador sobre o contrato inteligente do WEMIX$, a stablecoin do ecossistema de jogos blockchain da Wemade, e cunhou 5.225.525 unidades do nada. Converteu-as em 30.736 WEMIX e 724.198,27 USDC.e, moveu tudo através de pontes para a Ethereum e a BNB Smart Chain, e obrigou a equipa a suspender o Chainlink CCIP, a PLAY Bridge, o mercado de NFT da WEMIX PLAY e todas as pools de liquidez afetadas. No total, cerca de 6,25 milhões de dólares, perto de 5,5 milhões de euros ao câmbio atual.

Enquanto este artigo era escrito, a WEMIX ainda estava a fazer aquilo a que a própria equipa chamou uma «inspeção completa de todos os contratos relacionados», sem uma causa raiz definitiva publicada e a avisar que os «números preliminares podem mudar» à medida que a investigação avança, segundo a CryptoTimes. Não é a primeira vez que isto acontece a esta rede: em fevereiro de 2025, a WEMIX já tinha perdido 8,65 milhões de tokens WEMIX, na altura uns 6,2 milhões de dólares, do Play Bridge Vault, depois de credenciais ligadas à plataforma Nile NFT terem sido comprometidas, com o atacante escondido dentro do sistema durante cerca de dois meses antes de levantar os fundos.

Duas falhas graves em dezassete meses, na mesma empresa de jogos, com dois mecanismos técnicos completamente distintos. É o tipo de caso que devia bastar, por si só, para perguntar de onde é que a cripto tirou o hábito de escrever a autópsia dos seus próprios desastres em público. A resposta habitual aponta para a engenharia de fiabilidade de sistemas, ou SRE, da Google. Essa resposta está certa, mas incompleta. Há uma segunda genealogia, mais antiga do que o Bitcoin, e uma empresa de jogos como a Wemade está literalmente sentada em cima dela.

Post-mortem de protocolo: uma definição rápida

Um post-mortem de protocolo é o relatório público que uma equipa, ou cada vez mais investigadores externos independentes, publica depois de um exploit, uma falha de governação ou um colapso económico num protocolo cripto. Na sua forma mais completa inclui uma linha do tempo minuto a minuto do ataque, o mecanismo técnico exato que foi explorado, o valor afetado, os passos de contenção tomados e, por vezes, uma proposta de compensação aos utilizadores. O género tornou-se tão rotineiro que existe um site inteiro, o rekt.news, dedicado a catalogar estes relatórios como uma espécie de obituário coletivo da indústria, com um tom quase editorial e uma tabela de classificação dos maiores casos.

O que raramente se discute é que este formato não nasceu do nada em 2016, quando o hack da The DAO obrigou a comunidade Ethereum a explicar publicamente o que tinha corrido mal. Nasceu do cruzamento de duas culturas de escrita muito mais antigas, com públicos, incentivos e vocabulário diferentes. A cripto não inventou o post-mortem, herdou-o, remisturou-o, e acrescentou-lhe uma coisa que nenhuma das duas tradições originais tinha: dinheiro real a mover-se em direto, num livro-razão que qualquer pessoa pode auditar enquanto o drama ainda está a acontecer.

A genealogia esquecida: o que a Game Developer inventou em 1997

A revista Game Developer nasceu em março de 1994. Em outubro de 1997 publicou a primeira edição de uma coluna que se tornaria a sua secção mais lida durante quase duas décadas: a Postmortem, escrita por Andre Vrignaud sobre o jogo Dark Sun Online, segundo o registo histórico da própria publicação. O formato era simples e implacável: a equipa que tinha acabado de lançar um jogo escrevia, com nomes, datas e decisões concretas, cinco coisas que tinham corrido bem e cinco coisas que tinham corrido mal durante o desenvolvimento. Sem relações públicas a filtrar o texto, sem anonimato a proteger quem escrevia.

Ao longo dos anos seguintes, a coluna dissecou projetos de todas as escalas, do triplo A ao mobile e aos jogos sociais, e tornou-se uma referência tão citada que a própria conferência anual da indústria, a Game Developers Conference, construiu à sua volta uma tradição paralela de palestras de postmortem, hoje arquivadas aos milhares na GDC Vault. A revista impressa fechou com a edição de junho e julho de 2013, mas o formato sobreviveu, primeiro online no Gamasutra e depois no que hoje se chama Game Developer. Brandon Sheffield, que dirigiu a publicação nesse encerramento, resumiu porque é que a coluna importava: «conseguimos oferecer aos criadores a oportunidade de serem frontais e honestos sobre o seu trabalho e sobre a indústria», escreveu, acrescentando que «a indústria dos jogos tem poucos espaços onde os criadores são encorajados a ser honestos uns com os outros, e a Game Developer era um deles».

A coluna nunca escondeu números incômodos: orçamentos furados, prazos falhados, decisões de design que quase afundaram um estúdio inteiro. Esse hábito de publicar o fracasso ao lado do sucesso, décadas antes de qualquer exploit de contrato inteligente, é o que torna a ligação à cripto mais do que uma coincidência de vocabulário. Repare-se no que o formato pressupõe: o autor é a própria equipa exposta, o texto é dirigido a colegas de profissão que vão ler com espírito crítico, e o objetivo confesso é a honestidade profissional, não a gestão de crise. É uma cultura de confissão voluntária construída décadas antes de qualquer protocolo DeFi existir.

A genealogia mais citada: a cultura blameless da SRE

A segunda origem, essa sim mencionada constantemente nos textos sobre cultura de post-mortem cripto, vem da engenharia de software empresarial. O livro Site Reliability Engineering da Google, publicado em 2016, dedica um capítulo inteiro à cultura de post-mortem sem culpa, construindo sobre ideias que o engenheiro John Allspaw já defendia publicamente desde cerca de 2012, quando liderava a infraestrutura da Etsy. A ideia central: quando um sistema falha, o objetivo do relatório é perceber onde o processo, e não uma pessoa, deixou passar o erro, para que a falha não se repita.

Esta genealogia explica bem a estrutura de um post-mortem cripto típico, causa raiz, linha do tempo, ações corretivas, sem apontar o dedo a um programador individual. Mas não explica o tom. Um post-mortem de SRE é, por definição, um documento interno, escrito por engenheiros para outros engenheiros da mesma empresa, sobre a disponibilidade de um serviço que a maioria dos utilizadores nunca vai ler. Não explica porque é que os post-mortems cripto são públicos desde o primeiro rascunho, escritos a pensar numa audiência de utilizadores, investidores e concorrentes, num tom quase jornalístico. Essa parte vem da outra herança.

Duas heranças, um género: uma comparação

Colocadas lado a lado, as duas tradições explicam peças diferentes do mesmo puzzle. A tabela seguinte resume as diferenças mais relevantes.

A cripto ficou com o rigor técnico e a ambição de sistema da SRE, mas com a voz pública, confessional e dirigida à audiência da Game Developer. E acrescentou uma terceira camada que nenhuma das duas tinha: dinheiro real, muitas vezes centenas de milhões de dólares, a mover-se num livro-razão público enquanto o post-mortem ainda está a ser escrito. Nenhum programador de jogos em 1997 teve de negociar publicamente com a pessoa que lhe tinha roubado o orçamento do estúdio.

Ronin: o dia em que um jogo e um protocolo escreveram a mesma autópsia

Se há um caso que fecha fisicamente a distância entre as duas genealogias, é a Ronin Network, a sidechain construída pela Sky Mavis para o jogo Axie Infinity. O ataque começou a 23 de março de 2022 e só foi descoberto a 29 de março, seis dias depois; ao todo saíram cerca de 625 milhões de dólares, perto de 548 milhões de euros, entre 173.600 ETH e 25,5 milhões de USDC, tornando-se o maior roubo de sempre em cripto até então. A causa não foi um bug de contrato inteligente clássico: dos nove validadores necessários para autorizar levantamentos, a Sky Mavis controlava diretamente quatro, e um quinto, gerido pela Axie DAO, tinha delegado a assinatura de emergência à própria Sky Mavis durante um pico de tráfego em 2021, delegação essa que nunca foi revogada. Comprometer uma única empresa chegou para reunir as cinco assinaturas. O grupo Lazarus, ligado à Coreia do Norte, usou uma oferta de emprego falsa no LinkedIn para infetar o computador de um engenheiro sénior.

O que torna a Ronin um caso único nesta genealogia é que a mesma equipa que sofreu o ataque é, literalmente, um estúdio de jogos. A Sky Mavis angariou 150 milhões de dólares numa ronda liderada pela Binance para reforçar as reservas e reembolsou os jogadores na íntegra até final de junho de 2022. Aleksander Larsen, diretor de operações da Sky Mavis, resumiu o compromisso em termos que podiam ter saído de uma coluna Postmortem da Game Developer, não de um comunicado de crise: «estamos totalmente empenhados em reembolsar os nossos jogadores assim que possível». A ponte relançou meses depois. Mais de quatro anos depois, a Ronin continua a funcionar como uma sidechain de jogos ativa, hoje associada a vários títulos além do Axie Infinity original, o que a torna um dos poucos casos desta lista em que o post-mortem não é o capítulo final da história, mas apenas o pior capítulo de uma história que continuou a ser escrita. A HOGE Wire já analisou, num levantamento sobre sobrevivência pós-hack, porque é que a Ronin acabou do lado dos protocolos que recuperam, e não do lado dos que desaparecem.

Munchables: o post-mortem sem uma única linha de código maliciosa

Se a Ronin mostra a genealogia dupla a fundir-se num só caso, a Munchables mostra o limite do que qualquer um dos dois modelos consegue explicar sozinho. A Munchables era um jogo de NFT construído sobre a rede Blast; a 26 de março de 2024 desapareceram cerca de 62,5 milhões de dólares, perto de 55 milhões de euros, em ether depositado por utilizadores. O investigador pseudónimo ZachXBT identificou rapidamente o endereço com os fundos e, ao cruzar atividade de commits no GitHub, concluiu que o responsável era um dos quatro programadores contratados pela própria equipa da Munchables, com ligações à Coreia do Norte, sob o pseudónimo Werewolves0493.

Não houve exploração de um bug de contrato. Houve um colaborador com acesso legítimo que atualizou os contratos e moveu os fundos para si próprio. Depois de cerca de uma hora de negociação envolvendo a própria Munchables e o ZachXBT, o atacante devolveu todas as chaves privadas e a totalidade dos fundos, sem pedir resgate. Não há aqui uma causa raiz técnica para documentar, no sentido em que a SRE ou a Game Developer entenderiam o termo; há uma falha de verificação de identidade na contratação, um risco que qualquer estúdio de jogos que recrute talento remoto e pseudónimo conhece bem, mas que raramente aparece nos manuais de segurança de contratos inteligentes. É também um lembrete de que a rapidez da resolução, aqui menos de 24 horas, pesa tanto na forma como um caso é lembrado quanto a causa técnica em si.

A invenção genuinamente cripto: negociar com o atacante em público

Nem a cultura blameless da SRE nem a coluna Postmortem da Game Developer alguma vez precisaram de incluir uma negociação pública com a pessoa que causou o incidente. A cripto acrescentou isso ao género, e o caso mais citado continua a ser o da Euler Finance, explorada em março de 2023 por um empréstimo relâmpago que retirou cerca de 197 milhões de dólares, perto de 173 milhões de euros. O atacante deixou uma mensagem on-chain, visível a qualquer pessoa com um explorador de blocos: «no intention of keeping what is not ours», sem intenção de ficar com o que não é nosso. Seguiu-se uma negociação pública, feita através de mensagens anexadas a transações, que terminou com uma recompensa de 10% para o atacante e a devolução de praticamente a totalidade dos fundos. Um padrão semelhante tinha aparecido um ano antes na Poly Network, cujo atacante devolveu quase 611 milhões de dólares depois de ser publicamente tratado como Mr. White Hat.

Este ritual, atacante e vítima a negociar em público, num livro-razão que qualquer jornalista pode seguir ao vivo, não tem equivalente nem nos jogos nem na SRE. E como a HOGE Wire já documentou num artigo sobre post-mortems que acabam em tribunal, o acordo alcançado on-chain não é sempre o fim da história: processos penais e civis podem reabrir o caso anos depois, mesmo quando a comunidade já tinha considerado o assunto encerrado.

Quem assina a autópsia: a profissão que os videojogos nunca tiveram

Na Game Developer, o autor de uma Postmortem era sempre alguém de dentro do estúdio, a escrever sobre o próprio trabalho. Na cripto, cada vez mais, o autor é outra pessoa. Firmas de análise on-chain como a Chainalysis e a TRM Labs, investigadores pseudónimos como o já mencionado ZachXBT, e coligações de resposta rápida como a Security Alliance, com o seu programa SEAL 911 e o enquadramento de Safe Harbor para whitehats, formam hoje uma camada profissional inteira dedicada a reconstruir o que aconteceu, muitas vezes antes mesmo de a equipa afetada publicar a sua própria versão. A Safe Harbor funciona como uma espécie de porto seguro pré-negociado: um whitehat que devolva fundos dentro de 72 horas, com verificação de identidade e sem ligação a jurisdições sancionadas, pode reclamar uma recompensa de até 10%, com um teto de um milhão de dólares, sem risco de ser processado pelo protocolo afetado. É a formalização, em regras escritas antecipadamente, do mesmo instinto que já se via nas negociações informais da Euler e da Poly Network.

Isto resolve um problema óbvio, o de confiar apenas na palavra de quem foi hackeado, mas cria outro que a HOGE Wire já explorou em profundidade: quem audita as próprias auditoras? Um post-mortem pode nomear a firma forense envolvida e ainda assim deixar por responder porque é que um contrato auditado múltiplas vezes continuou vulnerável. Esse é precisamente o ponto cego descrito num artigo anterior sobre protocolos auditados e mesmo assim hackeados: não existe, nem na União Europeia nem nos Estados Unidos, um equivalente ao PCAOB para auditores de contratos inteligentes, pelo que a reputação, não a regulação, continua a ser o único tribunal real destas firmas.

WEMIX, outra vez: o género a fechar o círculo em tempo real

Vale a pena voltar à WEMIX com mais detalhe, porque o caso resume tudo o que este artigo tenta mostrar. Em fevereiro de 2025, o vetor foi credenciais de autenticação ligadas à plataforma Nile NFT, exploradas para drenar 8,65 milhões de WEMIX do Play Bridge Vault, com o atacante escondido no sistema durante cerca de dois meses. Em julho de 2026, o vetor foi completamente diferente: privilégios de administrador sobre o contrato do WEMIX$, a stablecoin da rede, usados para cunhar tokens do nada. Duas causas técnicas distintas, mas o mesmo resultado, uma rede de jogos obrigada a suspender pontes e mercados enquanto tenta perceber o que aconteceu.

Dan Guido, cofundador e diretor executivo da Trail of Bits, uma das auditoras mais citadas do setor, resumiu uma vez o objetivo de todo este trabalho numa frase simples: «nunca quero encontrar o mesmo bug duas vezes». Não foi dito sobre a WEMIX especificamente, mas descreve bem o problema de fundo: não foi o mesmo bug, mas foi a segunda vez, em dezassete meses, que a mesma organização teve de suspender a sua própria infraestrutura para conter um ataque. Se e quando a WEMIX publicar um post-mortem completo sobre o incidente de 26 de julho, valerá a pena verificar se o relatório explica porque é que os privilégios de administrador do contrato do WEMIX$ estavam expostos da forma que permitiu este ataque, e não apenas o que foi drenado.

Uma década de post-mortems: dos jogos aos protocolos

Colocados em sequência, os casos discutidos neste artigo desenham uma linha razoavelmente clara de como o género amadureceu.

O padrão mais interessante não é o valor perdido, é a velocidade e a transparência da resposta. A Ronin e a Euler, apesar de perdas muito maiores, tornaram-se casos de referência positiva porque publicaram linhas do tempo detalhadas e agiram rapidamente. A WEMIX de 2025 nunca chegou a publicar um post-mortem público detalhado sobre o incidente do Play Bridge Vault, o que ajuda a explicar porque é que o incidente de 2026 foi recebido com mais ceticismo do que talvez merecesse só pelo valor envolvido.

O que a MiCA cobre, e o que deixa de fora

Em Portugal, e na União Europeia em geral, o Regulamento dos Mercados de Criptoativos, a MiCA, regula prestadores de serviços de criptoativos, os CASP, com a CMVM a supervisionar a conduta de mercado e o Banco de Portugal a tratar do registo de CASP e da supervisão de stablecoins. A Lei n.º 69/2025, em vigor desde 27 de dezembro de 2025, transpõe estas regras para o direito português, e o período transitório para os antigos VASP terminou a 1 de julho de 2026. Nada disto, porém, obriga um protocolo a publicar um post-mortem depois de um incidente, e protocolos totalmente descentralizados ficam fora do âmbito da MiCA por completo. A isto soma-se o Regulamento da Resiliência Operacional Digital, o DORA, em vigor desde 17 de janeiro de 2025, que impõe requisitos de resiliência de sistemas informáticos aos CASP mas, tal como a MiCA, não obriga à divulgação pública de um post-mortem técnico nem exige auditorias de código a protocolos descentralizados.

Isto é especialmente relevante para casos como o da WEMIX ou da Munchables, onde o incidente atinge uma rede de jogos com utilizadores espalhados por várias jurisdições, sem um único CASP claramente identificável a responder perante a CMVM. Para um utilizador português afetado por um exploit num jogo blockchain descentralizado, o post-mortem voluntário, escrito ou não, continua a ser, na prática, o único mecanismo de prestação de contas disponível.

Seguro on-chain e a velocidade da IA: o que vem a seguir

Duas tendências estão a mudar a forma como este género vai continuar a evoluir. A primeira é o seguro on-chain: plataformas como a Nexus Mutual, ativa desde 2019, ou a Chainproof, incubada pela Quantstamp, oferecem cobertura contra exploits de contratos inteligentes, com alguns sinistros pagos em poucas semanas a partir de dados on-chain. É ainda um mercado pequeno face à escala das perdas do setor, mas representa uma tentativa de formalizar, através de um contrato, a promessa implícita que um post-mortem faz ao prometer reparação. A HOGE Wire já olhou para um problema paralelo no mundo do restaking, onde o seguro contra slashing em cascata enfrenta o mesmo desafio de escala.

A segunda tendência é a velocidade. Auditoras como a Trail of Bits descrevem publicamente uma transição interna para fluxos de trabalho assistidos por inteligência artificial que, segundo o próprio Guido, permitiram passar de cerca de 15 bugs encontrados por semana em certos projetos para perto de 200, com cerca de um quinto de todos os problemas reportados a serem inicialmente sinalizados por ferramentas de IA, sempre com verificação humana antes de qualquer publicação. Isso está a mudar a expectativa dos leitores: um post-mortem que demore semanas a sair começa a parecer tão desatualizado quanto uma revista impressa depois do fecho da edição. A própria WEMIX publicou os primeiros detalhes do incidente de julho de 2026 dentro de horas, ainda que sem causa raiz confirmada, precisamente porque essa é agora a norma esperada.

Como distinguir um post-mortem credível de um exercício de relações públicas

Depois de rever dezenas de casos ao longo desta série, alguns critérios práticos ajudam a separar um relatório honesto de uma peça de gestão de imagem:

• Granularidade da linha do tempo: um bom post-mortem tem horas e minutos, não apenas uma referência vaga a atividade suspeita detetada algures num certo dia.
• Especificidade técnica da causa: nomeia a função, o contrato ou o vetor exato explorado, em vez de se esconder atrás da expressão acesso não autorizado.
• Verificação independente: nomeia a firma forense ou o investigador externo envolvido, permitindo que terceiros confirmem os factos.
• Atualização contínua: continua a ser corrigido e ampliado à medida que a investigação avança, como está a acontecer com a WEMIX em julho de 2026, em vez de ser um único comunicado definitivo.
• Tratamento dos utilizadores: explica claramente se, como e quando os fundos afetados serão cobertos, e não apenas o que vai mudar no código.

Nenhum destes critérios garante, por si só, que um protocolo sobreviva ao incidente. Mas a ausência de vários deles ao mesmo tempo é, historicamente, um bom sinal de alerta.

Perguntas Frequentes

O que é um post-mortem de protocolo cripto?

É o relatório público que uma equipa, ou cada vez mais investigadores externos, publica depois de um protocolo cripto ser explorado ou falhar, normalmente com a linha do tempo do ataque, a causa técnica exata, os fundos afetados e os passos seguintes. Sites como o rekt.news catalogam estes relatórios como um género próprio, quase jornalístico, e não apenas como comunicados de imprensa corporativos.

Porque é que a cultura dos post-mortems cripto se parece com a dos videojogos?

Porque partilha uma genealogia direta com a coluna Postmortem da revista Game Developer, que desde outubro de 1997 pedia às equipas de jogos que descrevessem, com nomes e números, o que tinha corrido bem e o que tinha corrido mal num projeto. Essa vontade de confissão pública e voltada para a audiência aproxima-se mais da autópsia cripto do que a cultura interna e sem culpa da SRE da Google, muitas vezes apontada como a única origem do género.

Os post-mortems cripto são sempre fiáveis?

Não por defeito. Um post-mortem escrito pela própria equipa afetada tem incentivo para minimizar erros próprios, e nem todos são atualizados à medida que a investigação avança. Os mais credíveis costumam nomear a firma forense independente envolvida, manter a linha do tempo a ser atualizada, como a WEMIX está a fazer após o incidente de 26 de julho de 2026, e explicar o mecanismo técnico exato, não apenas uma referência vaga a acesso não autorizado.

Um protocolo hackeado recupera sempre depois de publicar um post-mortem?

Não. Casos como o da Ronin mostram recuperação quase total, com reembolso completo, ponte relançada e estúdio ainda ativo em 2026; outros nunca mais recuperam a confiança dos utilizadores apesar de um post-mortem detalhado. Publicar a autópsia é necessário para manter alguma credibilidade, mas não garante, por si só, a sobrevivência do protocolo.

A MiCA obriga os protocolos cripto a publicar um post-mortem depois de um hack?

Não diretamente. A MiCA regula prestadores de serviços de criptoativos centralizados, supervisionados em Portugal pela CMVM e pelo Banco de Portugal, mas não impõe a divulgação de um relatório pós-incidente e exclui protocolos totalmente descentralizados do seu âmbito. Para os utilizadores de DeFi, o post-mortem voluntário continua a ser, na prática, o único mecanismo de prestação de contas disponível.

Marcus Okafor é editor da secção Culture and Long-reads da HOGE Wire, focado em segurança de protocolos e na cultura de resposta a incidentes em cripto.