Auditado e hackeado: o ponto cego dos post-mortems cripto

No dia 15 de julho de 2026, a Ostium, uma exchange descentralizada de perpétuos sobre ativos do mundo real construída em Arbitrum, suspendeu as negociações depois de um atacante ter drenado entre cerca de 11,9 e 18 milhões de dólares (10 a 16 milhões de euros) do seu vault principal, quase 28% dos 63 milhões de dólares (55 milhões de euros) em valor total bloqueado que o protocolo tinha nesse momento. O mecanismo do ataque não passou por nenhuma linha do contrato inteligente que tinha sido auditado. O atacante controlava a chave privada de um dos assinantes do oráculo de preços, o suficiente para submeter relatórios com data futura e abrir e fechar posições artificialmente lucrativas cerca de vinte vezes seguidas, através de um forwarder de atualização de preços já registado no sistema.

A Ostium tinha sido auditada mais do que uma vez e contava com o apoio de fundos como General Catalyst, Jump Crypto, Coinbase Ventures, Wintermute e GSR. Ainda assim, caiu por uma porta que nenhuma dessas auditorias tinha sequer tentado fechar. Este é o ponto cego que a cultura do post-mortem cripto raramente confronta de frente: o relatório da autópsia costuma detalhar ao minuto a mecânica do ataque, mas raramente pergunta, com a mesma persistência, quem assinou a auditoria que devia ter apanhado o problema, e o que significa, na prática, um protocolo ser descrito como «auditado». Este artigo olha para essa lacuna através de cinco casos de 2025 e 2026 em que protocolos auditados, alguns deles várias vezes, foram esvaziados de qualquer forma, para o que uma auditoria de smart contracts promete legalmente, para a forma como o setor está a reorganizar-se à volta desse limite, e para o que a regulação europeia exige, ou não exige, de quem escreve estes relatórios.

Quando a auditoria não chega a tempo: o caso Ostium

A Ostium reagiu como manda o manual mais recente da cultura cripto: parou as negociações, congelou posições em aberto e publicou uma declaração a confirmar que «a equipa está a investigar ativamente com especialistas em segurança». Não houve, nas primeiras horas, qualquer menção às auditorias anteriores do protocolo nem qualquer explicação sobre porque é que nenhuma delas cobria a chave privada que acabou por ser o elo mais fraco. Isso não é incomum, é a norma.

A conta pública dos factos, entretanto, já é mais rica do que era há alguns anos: empresas de deteção de ameaças publicaram uma reconstrução técnica do ataque poucas horas depois do incidente, muito antes de a própria Ostium confirmar os números finais. Essa velocidade de resposta é, em si mesma, um produto da cultura do post-mortem, mas também mostra como a investigação forense se tornou mais rápida do que a auditoria alguma vez foi desenhada para ser.

Como acontece cada vez mais depois de um exploit, analistas independentes começaram a seguir a carteira do atacante on-chain quase em tempo real, catalogando cada troca e cada ponte usada para tentar dispersar os fundos roubados. É o mesmo tipo de vigilância que, à escala do mercado, permite interpretar os grandes movimentos das baleias muito antes de qualquer comunicado oficial confirmar o que aconteceu. A diferença é que, num exploit, essa vigilância torna-se a única fonte fiável de informação nas primeiras horas, antes de qualquer post-mortem formal.

Vale ainda notar que a Ostium, como a generalidade dos protocolos analisados neste artigo, opera como DeFi não custodiante, sem qualquer prestador de serviços sobre criptoativos (CASP) europeu formalmente no meio. Isso significa que, mesmo que tivesse utilizadores em Portugal ou noutro Estado-membro, nenhum regulador nacional teria jurisdição direta sobre a qualidade das suas auditorias ou sobre a gestão das suas chaves. Voltamos a este ponto mais à frente.

O que uma auditoria de smart contracts promete (e o que não promete)

Uma auditoria de smart contracts é, na prática, uma revisão manual e automatizada de uma base de código definida à partida, feita numa janela de tempo limitada, normalmente entre uma e quatro semanas, que termina num relatório com uma lista de falhas classificadas por gravidade. O que a generalidade dos utilizadores não lê, porque raramente aparece destacado, é a cláusula de exclusão de responsabilidade que acompanha praticamente todos estes relatórios: a empresa de auditoria não garante a ausência de vulnerabilidades, não assume responsabilidade por perdas decorrentes do código revisto e deixa expressamente fora do âmbito tudo o que não esteja listado como código «em âmbito».

Isto não é uma prática de uma empresa específica, é o padrão do setor. Um relatório de auditoria é, formalmente, uma opinião técnica sobre um snapshot do código numa determinada data, não uma apólice de seguro nem uma certificação regulatória. Costuma ficar de fora do âmbito, por exemplo:

• A lógica económica e a teoria de jogos por trás de incentivos e tokens;
• Infraestrutura fora do próprio contrato, como oráculos, chaves privadas, servidores e interfaces;
• Qualquer alteração ao código feita depois da data em que o relatório foi fechado;
• Interações entre vários protocolos que nenhum deles, isoladamente, cobre na sua própria auditoria.

A título de exemplo do tipo de linguagem que é norma no setor, guias especializados em como ler relatórios de segurança, como o publicado pela Cantina, sublinham que um relatório deve ser lido como uma opinião informada num determinado momento, não como uma certificação permanente, e que código fora do âmbito definido é, por convenção, assumido como correto para efeitos da análise, mesmo quando esse código interage diretamente com o que foi revisto.

É exatamente aqui que se encaixam os cinco casos seguintes. A chave de oráculo da Ostium, o patch da GMX, a biblioteca de terceiros da Cetus, ficam todos, tecnicamente, fora do que um relatório «limpo» certifica, ainda que os utilizadores tratem a palavra «auditado» como sinónimo de «seguro».

Balancer: dez auditorias, o mesmo aviso ignorado

A 3 de novembro de 2025, um atacante drenou cerca de 129 milhões de dólares (113 milhões de euros) da Balancer v2, espalhados por várias redes. O mecanismo combinou uma falha de controlo de acesso na função manageUserBalance, que permitia manipular o valor do remetente de uma operação, com um erro de arredondamento nos Composable Stable Pools que essa falha tornou possível explorar em escala. A Balancer não era um protocolo pouco escrutinado: tinha sido auditada mais de dez vezes ao longo da sua vida, incluindo pela OpenZeppelin e pela Trail of Bits.

É aqui que o caso se torna incomum. A Trail of Bits publicou a sua própria retrospetiva a assumir o erro: já em 2021 tinha identificado o risco subjacente, catalogado como TOB-BALANCER-004, relativo à forma como os Linear Pools consumiam a biblioteca de matemática estável, mas classificou a gravidade como «indeterminada» na altura, porque a equipa não conseguiu confirmar se era explorável na configuração real das pools. Em vez de ficar em silêncio depois do exploit de 2025, a empresa reconheceu publicamente que os modelos de ameaça de 2021 e 2022 estavam dominados por preocupações de controlo de acesso e roubo de chaves, não por casos limite de aritmética.

Suhail Kakar, responsável de relações com programadores na TAC Blockchain, resumiu o problema de forma direta: «a Balancer passou por mais de dez auditorias. O vault foi auditado três vezes separadas por empresas diferentes e mesmo assim foi hackeado em 110 milhões de dólares. Este setor precisa de aceitar que ‘auditado pela empresa X’ não significa quase nada. Código é difícil, DeFi é ainda mais difícil.»

Bunni e o problema da correção incompleta

A Bunni, uma exchange descentralizada construída sobre o Uniswap v4, sofreu um exploit a 2 de setembro de 2025 que lhe custou cerca de 8,4 milhões de dólares (7,4 milhões de euros), repartidos entre Ethereum e Unichain. O atacante usou um empréstimo relâmpago (flash loan) para executar 44 levantamentos consecutivos de valores muito pequenos, cada um acumulando um erro de arredondamento minúsculo, até o saldo ativo de USDC de uma pool cair 85,7%, apesar de praticamente não terem sido queimadas unidades de liquidez.

O que torna este caso relevante para a questão da responsabilização é que a falha não era desconhecida. A Trail of Bits tinha sinalizado, numa auditoria anterior, um problema catalogado como TOB-BUNNI-13: a falta de uma abordagem sistemática ao arredondamento e à aritmética de precisão. A Bunni corrigiu o que foi identificado nessa auditoria, mas a correção não cobriu o caso limite específico que acabou por ser explorado. Passar por uma auditoria e corrigir o que ela encontra não é, por si só, garantia de que o problema desapareceu, pode apenas significar que a versão seguinte do mesmo problema ainda não tinha sido imaginada.

A consequência mais reveladora não foi o valor roubado, relativamente modesto para os padrões do setor, mas o desfecho: a equipa da Bunni encerrou o protocolo de forma permanente no outono de 2025, alegando não ter capacidade para financiar um programa de segurança de seis ou sete dígitos necessário para relançar em segurança. A Trail of Bits, entretanto, continuou a operar como uma das auditoras mais procuradas do mercado. A assimetria é reveladora: o protocolo pagou com a própria existência, a auditora pagou, na pior das hipóteses, com um parágrafo de constrangimento.

GMX V1: o patch que ninguém auditou

A GMX é uma das maiores exchanges de perpétuos on-chain, com um mecanismo de funding que ancora o preço dos contratos ao mercado à vista e que já foi explicado em detalhe nesta publicação. A 9 de julho de 2025, a versão V1 do protocolo perdeu cerca de 42 milhões de dólares (37 milhões de euros) através de um ataque de reentrância (reentrancy) na função executeDecreaseOrder. O código assumia, de forma implícita, que o parâmetro de conta era sempre uma carteira externa comum, quando na realidade podia ser um contrato inteligente malicioso. O atacante usou isso para distorcer o preço médio de uma posição curta em Bitcoin, arrastando-o de cerca de 109.515 dólares para cerca de 1.914 dólares dentro da contabilidade interna do protocolo.

Os fundos foram recuperados na quase totalidade dentro de 48 horas, depois de a equipa negociar com o atacante e pagar um bounty de 5 milhões de dólares, uma versão mais recente do mesmo ritual de negociação on-chain que tornou o caso Euler Finance famoso em 2023. Mas o detalhe mais relevante para este artigo está a montante do ataque: a vulnerabilidade explorada em 2025 tinha sido introduzida por uma correção a um problema totalmente diferente, identificado em 2022 através de um bug bounty de 1 milhão de dólares sobre atualizações não atómicas do tamanho global de posições curtas. Essa correção de 2022, a que acabou por abrir a porta ao exploit de 2025, nunca foi submetida a uma auditoria independente própria.

É um padrão fácil de ignorar quando se fala de auditorias como um selo único: o rótulo «auditado» refere-se quase sempre a uma versão específica do código, não a tudo o que vem depois. Cada patch, cada atualização, cada correção de um problema anterior é, por definição, código novo e não auditado até prova em contrário.

Cetus: quando a auditoria confia demais na linguagem

O maior dos cinco casos aconteceu a 22 de maio de 2025, quando a Cetus, a maior exchange descentralizada da rede Sui, perdeu cerca de 223 milhões de dólares (196 milhões de euros). A causa não estava no código da própria Cetus, mas numa biblioteca de terceiros, a integer-mate, usada para verificar overflows aritméticos. A função checked_shlw comparava o valor fornecido com o limite errado, o que permitia que certos valores capazes de gerar overflow passassem despercebidos pela verificação. O atacante combinou isto com um empréstimo relâmpago e uma posição de liquidez com um intervalo de tick extremamente estreito para forçar o cálculo do número de tokens necessários a resultar em apenas uma unidade, enquanto lhe era atribuída liquidez muito maior do que a que efetivamente depositou.

Cerca de 162 milhões de dólares ficaram retidos na própria rede Sui e acabaram por ser recuperados através de uma votação dos validadores para reverter o estado da cadeia, apoiada por um empréstimo da Sui Foundation e por reservas de tesouraria da própria Cetus; os restantes 60 milhões de dólares, que já tinham sido transferidos para a Ethereum através de pontes, permanecem em grande parte fora de alcance.

O que distingue este caso dos anteriores é o tipo de suposição que falhou. Não foi um erro de arredondamento silenciosamente ignorado, foi a confiança excessiva na ideia de que uma linguagem desenhada para segurança de memória, como o Move, torna verificações de overflow uma preocupação menor. Auditorias tendem a concentrar o escrutínio mais apertado onde a experiência coletiva do setor diz que os bugs costumam viver; quando a suposição de partida está errada, mesmo um código revisto várias vezes pode esconder um erro deste tipo durante meses.

Cinco casos, um padrão

Colocados lado a lado, cronologicamente, os cinco casos não parecem aleatórios. Todos envolveram protocolos com auditorias formais em dia, todos envolveram um tipo de falha que ficava, de alguma forma, fora do que essa auditoria certificava, e em nenhum dos post-mortems publicados a auditora envolvida foi tratada como parte central da história.

Quem fiscaliza os fiscalizadores?

Nos Estados Unidos, na União Europeia ou em qualquer outra jurisdição relevante, não existe hoje um regulador que exija ou credencie auditorias de smart contracts. Não há equivalente ao PCAOB norte-americano, que supervisiona os auditores de contas de empresas cotadas, nem a nenhum organismo semelhante para quem revê código Solidity, Rust ou Move. Qualquer empresa pode anunciar-se como auditora de segurança cripto sem licença, sem exame de admissão e sem obrigação de seguro de responsabilidade civil profissional equivalente ao que se exige, por exemplo, a um revisor oficial de contas na União Europeia.

A qualidade é policiada quase inteiramente pela reputação. Um relatório mal feito, ou um caso sonado de «auditado e mesmo assim hackeado», custa clientes futuros, não custa uma licença, porque não existe licença para perder. Isto cria um incentivo estranho: as auditoras mais visadas em post-mortems públicos são, quase sempre, as mais conhecidas, precisamente porque são as mais contratadas, o que significa que o mesmo nome aparece repetidamente associado a exploits sem que isso, por si só, afete de forma mensurável o seu volume de contratos seguintes.

Isto contrasta com o mundo da auditoria financeira tradicional, onde revisores de contas estão sujeitos a regimes de supervisão pública, obrigações de seguro e, em casos extremos, processos judiciais e perda de licença. Nenhum desses mecanismos existe, para já, no lado dos smart contracts.

Mesmo nos Estados Unidos, onde a Securities and Exchange Commission adotou, sob a liderança do atual presidente Paul Atkins, uma postura muito mais permissiva para a cripto, com a agência a declarar publicamente em 2026 que «a maioria dos criptoativos não são, em si mesmos, valores mobiliários», o foco regulatório continua a ser a classificação de tokens e as regras de oferta, não os padrões de revisão de código. Nenhuma das reformas do chamado Project Crypto toca, em qualquer momento, na questão de quem pode chamar-se auditor de smart contracts.

O que isto significa para Portugal e a União Europeia

A MiCA (Markets in Crypto-Assets Regulation) regula prestadores de serviços sobre criptoativos (CASP) que operam na União Europeia, obrigando a autorização, capital mínimo, regras de conduta e, nalguns casos, custódia segregada. Em Portugal, a Lei n.º 69/2025, em vigor desde 27 de dezembro de 2025, transpõe esse quadro, e o período transitório que permitia a antigos VASP continuarem a operar apenas com o registo anterior terminou a 1 de julho de 2026. A partir dessa data, qualquer prestador que sirva utilizadores portugueses precisa de autorização MiCA completa, supervisionada pela CMVM no plano da conduta de mercado e pelo Banco de Portugal no registo de CASP e na supervisão de stablecoins.

O que a MiCA não faz, em nenhuma das suas partes, é exigir uma auditoria de smart contracts como condição de autorização, nem credenciar quem as realiza. O DORA (Digital Operational Resilience Act), em aplicação desde 17 de janeiro de 2025, acrescenta obrigações de resiliência operacional digital, gestão de risco de TIC e testes de penetração avançados às entidades financeiras, CASP incluídos, mas o seu foco é a robustez dos processos internos e dos fornecedores críticos de tecnologia, não a revisão do código-fonte de contratos inteligentes.

Para os CASP centralizados que ficam dentro do âmbito da MiCA, como exchanges ou custodiantes que sirvam clientes europeus, a regulação exige governação robusta, salvaguarda de ativos de clientes, planos de continuidade de negócio e comunicação de incidentes às autoridades competentes. São exigências reais e, em muitos casos, mais rigorosas do que tudo o que existia antes. Mas nenhuma delas equivale a certificar que o código por trás de um contrato inteligente foi revisto com um padrão mínimo de qualidade, porque a MiCA foi desenhada para regular intermediários, não para regular código.

Mais importante ainda para os cinco casos descritos neste artigo: nenhum deles teria, com toda a probabilidade, sequer entrado no âmbito da MiCA como CASP. São protocolos DeFi não custodiantes, sem entidade emissora central identificável a pedir autorização junto da CMVM. Para um utilizador português que use este tipo de protocolo, o post-mortem publicado a seguir a um exploit continua a ser, na prática, o único mecanismo de responsabilização disponível, não existe reclamação a apresentar a um regulador nacional nem fundo de garantia a acionar.

O setor de auditoria cripto em 2026

Apesar dos casos descritos acima, o setor da auditoria não parou de crescer, nem deixou de ser, para a esmagadora maioria dos protocolos, o único filtro de segurança que existe antes do lançamento. Eis um retrato de algumas das empresas mais citadas em 2026, com as suas especialidades e faixas de preço típicas.

Segundo dados publicados pela Sherlock, o custo de uma auditoria em 2026 varia entre cerca de 5.000 dólares para um token simples e mais de 150.000 dólares para sistemas complexos, com plataformas de concurso a chegar aos 200.000 dólares em modelos de prize pool. É uma despesa real, mas continua a ser uma fração pequena do valor tipicamente em risco num protocolo DeFi de grande escala, o que ajuda a explicar porque é que tantos projetos preferem somar várias auditorias relativamente baratas a investir num único programa de segurança contínuo.

O tabuleiro está a mudar: concursos, bounties e consolidação

A inteligência artificial está também a mudar a forma como estas empresas trabalham. A própria Trail of Bits descreveu publicamente, em 2026, uma transição interna de cerca de 5% para mais de 90% de adoção de ferramentas de IA em determinados projetos, com um aumento reportado de cerca de 15 para 200 bugs encontrados por semana em certos contratos, sempre com verificação humana antes de qualquer publicação. O objetivo declarado não é substituir o auditor humano, mas reduzir o tempo entre a introdução de um erro e a sua deteção, precisamente a janela que os cinco casos analisados neste artigo exploraram.

Em maio de 2026, a Code4rena, uma das plataformas pioneiras no modelo de auditoria por concurso (onde investigadores independentes, os «wardens», competem para encontrar vulnerabilidades em troca de prémios), anunciou o encerramento das suas operações. A Immunefi, a maior plataforma de bug bounty do setor, absorveu os seus programas, prémios e investigadores, prometendo dar continuidade aos concursos já em curso. O encerramento aconteceu menos de dois anos depois de a própria Code4rena ter sido adquirida pela Zellic, noutra fase de consolidação do setor.

A Cantina, entretanto, resultou da fusão do braço público da Spearbit, e a Sherlock combina concursos com cobertura financeira ao estilo de um seguro para os protocolos participantes. A Immunefi mantém os maiores bounties do setor, incluindo um programa da Uniswap v4 com um teto de 15,5 milhões de dólares e um da LayerZero perto dos 15 milhões, embora o maior pagamento individual alguma vez feito continue a ser os 10 milhões de dólares pagos ao investigador satya0x pela descoberta de uma falha crítica na Wormhole, em 2022.

Esta reorganização é, em si mesma, um reconhecimento implícito de que uma auditoria pontual não chega. As plataformas que sobrevivem são as que combinam revisão inicial de código com vigilância contínua e recompensas permanentes por encontrar problemas depois do lançamento, uma admissão silenciosa de que o momento em que o código é «auditado» é só o início do risco, não o fim.

Quando o problema sai do código: o fator humano

Alargando a lente para todo o primeiro semestre de 2026, os dados compilados pela CertiK e reportados pela Forbes mostram 1,315 mil milhões de dólares (1,153 mil milhões de euros) perdidos em 344 incidentes. Segundo Ronghui Gu, CEO da CertiK, o comprometimento de carteiras tornou-se a categoria mais cara do período, responsável por mais de 444 milhões de dólares (389 milhões de euros), uma média de cerca de 13 milhões de dólares por evento, de longe a mais alta de qualquer categoria. Os bugs de código continuaram a ser os mais frequentes, 204 incidentes, mas responsáveis por apenas 151,6 milhões de dólares (133 milhões de euros) no total.

Dois dos maiores casos do semestre ilustram bem esta deslocação. O roubo à Bybit em fevereiro de 2025, o maior da história da cripto, não teve origem num bug de contrato, mas numa interface comprometida da Safe usada pelos assinantes da carteira multisig da exchange, um ataque à cadeia de fornecimento de software, não ao código on-chain. A KelpDAO perdeu cerca de 291 milhões de dólares (255 milhões de euros) em abril de 2026 através de uma mensagem falsificada na ponte LayerZero, na sequência de uma manipulação de engenharia social a um programador da própria LayerZero Labs, um episódio que marcou de forma decisiva o ano do restaking. Nenhuma auditoria de smart contracts, por mais rigorosa que fosse, teria impedido qualquer um dos dois.

A questão de quem acaba, na prática, por cobrir este tipo de perdas, seja a própria empresa a absorver o prejuízo, seja o preço do token a socializar a perda entre todos os detentores, seja um seguro on-chain a pagar uma fração do valor, é tratada em detalhe numa análise anterior sobre a economia dos post-mortems. O que interessa aqui é o deslocamento da pergunta: já não se trata de saber se um auditor apanhou ou não um bug, trata-se de saber se a segurança de chaves, de oráculos e de interfaces alguma vez foi, de forma explícita, da responsabilidade de alguém.

A reputação como único tribunal

Na ausência de qualquer regime de responsabilidade civil ou supervisão regulatória equivalente ao que existe para auditores financeiros tradicionais, o único custo real que uma auditora de smart contracts paga por um erro é reputacional, e mesmo esse custo é surpreendentemente difícil de medir. A retrospetiva pública da Trail of Bits sobre o caso Balancer continua a ser a exceção, não a regra: a norma é o silêncio, ou uma nota discreta a atualizar a versão do relatório, sem qualquer reconhecimento público de que a avaliação original ficou aquém.

Dan Guido, cofundador e diretor executivo da Trail of Bits, resumiu numa entrevista o incentivo que, na prática, disciplina o setor mais do que qualquer lei: «nunca quero encontrar o mesmo erro duas vezes». É uma frase sobre reputação profissional, não sobre obrigação legal, e essa distinção é exatamente o que este artigo tentou mostrar. O post-mortem cripto nasceu como um substituto do recurso judicial para as vítimas de um exploit, mas raramente se estende à própria cadeia de responsabilidade que devia ter impedido o exploit à partida.

Isso pode estar a começar a mudar, ainda que lentamente, à medida que mais auditoras incorporam ferramentas de inteligência artificial nos seus próprios processos internos para encontrar mais bugs, mais depressa, sempre com verificação humana antes de qualquer publicação. Mas nenhuma ferramenta nova resolve o problema estrutural descrito ao longo deste artigo: enquanto a cláusula de exclusão de responsabilidade continuar a ser a norma em qualquer relatório de auditoria, a palavra «auditado» vai continuar a significar, sobretudo, que alguém olhou para o código antes de o problema acontecer, não que o problema não vai acontecer.

Perguntas frequentes

O que é um post-mortem de protocolo cripto?

É um relatório público, publicado pela equipa de um protocolo ou por investigadores independentes depois de um exploit, que reconstrói a cronologia do ataque, identifica a causa técnica, quantifica o valor perdido e descreve as medidas tomadas a seguir. Nasceu adaptado das práticas de post-mortem sem culpa da engenharia de software e tornou-se, na cripto, o principal substituto público para processos judiciais ou intervenção regulatória, sobretudo em protocolos DeFi que não têm qualquer entidade central responsável perante um regulador.

Uma auditoria de smart contracts garante que um protocolo não vai ser hackeado?

Não. Uma auditoria é uma revisão de um código específico, numa data específica, com um âmbito definido à partida, e quase todos os relatórios incluem uma cláusula que exclui expressamente qualquer garantia de segurança. Os casos da Balancer, da Bunni, da Cetus, da GMX V1 e da Ostium descritos neste artigo foram todos auditados, alguns várias vezes, e mesmo assim perderam, em conjunto, mais de 400 milhões de dólares entre 2025 e 2026.

Quem é responsabilizado quando um protocolo auditado é hackeado?

Na prática, quase ninguém, no sentido legal do termo. Não existe regulador, nos Estados Unidos ou na União Europeia, que credencie auditores de smart contracts ou que os responsabilize formalmente por erros de avaliação. O custo mais comum é reputacional para a auditora e existencial para o protocolo, que pode perder utilizadores, capital ou, como aconteceu com a Bunni, a própria viabilidade do negócio.

Porque é que a Trail of Bits aparece nos post-mortems da Balancer e da Bunni?

Porque foi uma das auditoras envolvidas em ambos os casos e, no caso da Balancer, uma das poucas empresas do setor a publicar uma retrospetiva pública a assumir que tinha subestimado, em 2021, a gravidade de um risco que viria a ser explorado em 2025. Essa transparência é suficientemente rara para se tornar, ela própria, parte da notícia, o que diz muito sobre o padrão habitual do setor.

A MiCA ou a DORA obrigam a auditorias de smart contracts na União Europeia?

Não. A MiCA regula a autorização e a conduta de prestadores de serviços sobre criptoativos (CASP) e a DORA regula a resiliência operacional digital de entidades financeiras, incluindo CASP, mas nenhuma das duas exige uma auditoria de código a contratos inteligentes nem credencia quem as realiza. Protocolos DeFi totalmente descentralizados, como os cinco analisados neste artigo, ficam também fora do âmbito de autorização da MiCA.

Por Marcus Okafor, HOGE Wire.