{"id":689,"date":"2026-10-06T16:43:18","date_gmt":"2026-10-06T16:43:18","guid":{"rendered":"https:\/\/hoge.gg\/pt\/seguranca-bridges-auditoria-off-chain-chaves-2026\/"},"modified":"2026-10-06T16:43:18","modified_gmt":"2026-10-06T16:43:18","slug":"seguranca-bridges-auditoria-off-chain-chaves-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/pt\/seguranca-bridges-auditoria-off-chain-chaves-2026\/","title":{"rendered":"Seguran\u00e7a das bridges em 2026: o elo que a auditoria n\u00e3o v\u00ea"},"content":{"rendered":"

Setembro de 2026 entrou para a hist\u00f3ria pelas piores raz\u00f5es. Segundo o balan\u00e7o trimestral da CertiK, o terceiro trimestre do ano custou cerca de 1,26 mil milh\u00f5es de d\u00f3lares em cripto roubada, em 247 incidentes<\/a>, uma subida de quase 54% face aos 819,4 milh\u00f5es do trimestre anterior; s\u00f3 setembro valeu perto de 769 milh\u00f5es. No topo da tabela est\u00e1 a corretora Bitget, com 387,5 milh\u00f5es de d\u00f3lares (\u00e0 volta de 344 milh\u00f5es de euros) desviados, seguida da Liquid Network, com 319 milh\u00f5es (cerca de 283 milh\u00f5es de euros).<\/p>

O detalhe mais importante n\u00e3o \u00e9 o montante, \u00e9 o como<\/em>. No caso da Bitget, os atacantes n\u00e3o partiram nenhum smart contract; exploraram uma falha num produto de seguran\u00e7a de um fornecedor externo<\/a>, obtiveram credenciais internas de alto n\u00edvel e emitiram ordens de levantamento fraudulentas que contornaram os controlos de risco existentes. A pr\u00f3pria CertiK resume a tend\u00eancia numa frase: a amea\u00e7a deslocou-se do c\u00f3digo para os sistemas geridos por pessoas.<\/p>

Esta \u00e9 a tese deste artigo, aplicada ao problema mais antigo da cripto multi-chain: as bridges. A Bitget n\u00e3o \u00e9 uma bridge, mas a li\u00e7\u00e3o aplica-se com ainda mais for\u00e7a a quem move valor entre blockchains. O contrato que uma bridge publica na cadeia \u00e9, hoje, a parte mais bem auditada e mais robusta de todo o sistema. O dinheiro sai por outro lado: pela camada off-chain de chaves, validadores, relayers, federa\u00e7\u00f5es e p\u00e1ginas web que nenhuma auditoria de c\u00f3digo chega a ver. Foi assim na Bitget e na Liquid, os dois maiores rombos de um setembro negro<\/a>, e \u00e9 assim na esmagadora maioria dos ataques a bridges de 2026.<\/p>

O que uma bridge faz com o teu dinheiro<\/h2>

Uma blockchain n\u00e3o sabe, por natureza, o que se passa noutra. A Ethereum n\u00e3o l\u00ea o livro-raz\u00e3o da Solana, a Solana n\u00e3o v\u00ea a Bitcoin. Uma cross-chain bridge \u00e9 a infraestrutura que preenche esse vazio: permite que um ativo ou uma mensagem passe de uma cadeia para outra. O modelo mais comum \u00e9 o de trancar-e-cunhar (lock-and-mint). Depositas 1 ETH num contrato na Ethereum, o contrato tranca esse ETH, e do outro lado \u00e9 cunhada uma representa\u00e7\u00e3o equivalente (um ETH embrulhado) na cadeia de destino. Para desfazer a opera\u00e7\u00e3o, queimas o token embrulhado e o contrato liberta o ETH original.<\/p>

O problema estrutural nasce aqui. Todo o ETH trancado fica concentrado num \u00fanico contrato, \u00e0 espera. \u00c9 o que a ind\u00fastria chama, sem ironia, um honeypot<\/em>: um pote de mel que cresce com cada dep\u00f3sito e que, ao contr\u00e1rio de um banco, n\u00e3o tem porta de cofre f\u00edsica, guarda armado nem seguro estatal. Quem conseguir convencer o contrato de que tem direito a levantar, leva tudo. E \u00e9 exatamente a\u00ed que entra a segunda metade da bridge, a parte que quase ningu\u00e9m v\u00ea.<\/p>

Porque o contrato on-chain, sozinho, n\u00e3o sabe se o dep\u00f3sito na outra cadeia aconteceu mesmo. Algu\u00e9m tem de lho dizer. Essa tarefa cabe a um conjunto off-chain: um grupo de signat\u00e1rios, uma rede de validadores externos, uma federa\u00e7\u00e3o, um or\u00e1culo, um relayer. \u00c9 este algu\u00e9m que autoriza a cunhagem e o levantamento. A bridge tem, portanto, duas metades: o contrato que guarda o dinheiro, publicado e audit\u00e1vel, e a m\u00e1quina off-chain que lhe diz o que fazer, muito mais dif\u00edcil de inspecionar. As perdas de 2026 sa\u00edram, quase sempre, pela segunda.<\/p>

N\u00e3o \u00e9 o c\u00f3digo, s\u00e3o as chaves<\/h2>

Durante anos, a narrativa dominante foi a do bug de Solidity: uma linha mal escrita, um reentrancy, um overflow. Em 2026, os n\u00fameros contam outra hist\u00f3ria. A TRM Labs, no seu balan\u00e7o do primeiro semestre, registou 207 ataques e cerca de 972 milh\u00f5es de d\u00f3lares roubados<\/a>, e concluiu que o comprometimento de infraestrutura, chaves e opera\u00e7\u00f5es representou apenas cerca de 15% dos incidentes, mas cerca de 76% do valor. Os bugs de c\u00f3digo s\u00e3o muitos e pequenos; os roubos de chaves e de infraestrutura s\u00e3o poucos e gigantescos.<\/p>

A CertiK chega \u00e0 mesma leitura no seu balan\u00e7o mais recente: a amea\u00e7a deslocou-se do c\u00f3digo para os sistemas geridos por pessoas. \u00c9 a invers\u00e3o da velha m\u00e1xima da ind\u00fastria. N\u00e3o \u00e9 o c\u00f3digo, s\u00e3o as chaves; n\u00e3o \u00e9 o que foi escrito, \u00e9 quem tem autoridade para o mandar executar. Para uma bridge, este deslocamento \u00e9 fatal, porque a bridge \u00e9, por natureza, feita de confian\u00e7a delegada.<\/p>

H\u00e1 ainda um segundo motivo para o risco se agravar: um ativo cunhado por uma bridge raramente fica quieto. Vai servir de garantia noutro protocolo, \u00e9 emprestado, \u00e9 alavancado. Quando a bridge que o emitiu \u00e9 esvaziada, o colateral por tr\u00e1s desse ativo evapora-se e a onda de choque propaga-se a mercados que nunca tocaram na bridge original. \u00c9 o cont\u00e1gio, e \u00e9 a raz\u00e3o pela qual uma \u00fanica falha consegue amea\u00e7ar meia d\u00fazia de protocolos a jusante.<\/p>

O que a auditoria v\u00ea, e o que nunca v\u00ea<\/h2>

Uma auditoria de smart contract faz uma coisa muito concreta e muito limitada: l\u00ea o c\u00f3digo que vai ser publicado na blockchain e procura falhas na sua l\u00f3gica. Verifica se a matem\u00e1tica fecha, se n\u00e3o h\u00e1 reentrancy, se os controlos de acesso dentro do contrato est\u00e3o corretos. \u00c9 trabalho essencial e, em 2026, funcionou: a maioria dos contratos de bridge comprometidos este ano comportou-se exatamente como estava escrito.<\/p>

O que uma auditoria de c\u00f3digo n\u00e3o v\u00ea \u00e9 tudo o resto. N\u00e3o v\u00ea quem guarda as chaves privadas que controlam a federa\u00e7\u00e3o. N\u00e3o v\u00ea como s\u00e3o operados os relayers e os n\u00f3s de RPC que alimentam os validadores. N\u00e3o v\u00ea o servidor onde corre o front-end, nem o registo de DNS do dom\u00ednio, nem a conta de administra\u00e7\u00e3o com poder para substituir o contrato por outro. Ronghui Gu, cofundador da CertiK, p\u00f4-lo numa frase que se tornou o lema do ano: \u00abum protocolo pode passar numa auditoria de c\u00f3digo impec\u00e1vel e ainda assim perder milh\u00f5es por causa de uma chave de administra\u00e7\u00e3o comprometida\u00bb<\/a>.<\/p>

\u00c9 \u00fatil pensar na camada off-chain de uma bridge como cinco andares, cada um com a sua forma de ruir e cada um invis\u00edvel para a auditoria de c\u00f3digo. A tabela seguinte mapeia esses andares; as sec\u00e7\u00f5es que se seguem descem a cada um deles.<\/p>

Camada off-chain<\/th>O que \u00e9<\/th>Falha t\u00edpica<\/th>O que a auditoria de c\u00f3digo n\u00e3o v\u00ea<\/th><\/tr><\/thead>
Chaves de assinatura<\/td>O multisig que autoriza levantamentos<\/td>Chaves roubadas ou phishing a signat\u00e1rios<\/td>Quem det\u00e9m as chaves e como as guarda<\/td><\/tr>
Verificadores off-chain<\/td>Relayers, DVN e n\u00f3s de RPC que reportam a outra cadeia<\/td>Infraestrutura envenenada que reporta um facto falso<\/td>Como os n\u00f3s s\u00e3o operados e protegidos<\/td><\/tr>
Federa\u00e7\u00e3o ou operador<\/td>Grupo (ou pessoa) que assina a valida\u00e7\u00e3o<\/td>Erro de consenso que o multisig assina, ou colapso do operador<\/td>O software de consenso fora do contrato<\/td><\/tr>
Administra\u00e7\u00e3o e upgrade<\/td>A chave que pode substituir o pr\u00f3prio contrato<\/td>Tomada da conta de admin, migra\u00e7\u00e3o sem timelock<\/td>Quem controla o proxy e com que atrasos<\/td><\/tr>
Front-end e dom\u00ednio<\/td>O site, o DNS e as depend\u00eancias de software<\/td>Script malicioso injetado na p\u00e1gina<\/td>Toda a infraestrutura web e cadeia de fornecimento<\/td><\/tr><\/tbody><\/table><\/figure>

Camada 1: as chaves que assinam<\/h2>

O andar mais antigo e mais lucrativo. Muitas bridges exigem que um grupo de signat\u00e1rios aprove cada levantamento, num esquema multisig: por exemplo, 5 de 9 assinaturas. No papel \u00e9 robusto; na pr\u00e1tica, o que importa n\u00e3o \u00e9 o n\u00famero, \u00e9 quem controla as chaves. O caso Ronin, da Sky Mavis (Axie Infinity), continua a ser o maior roubo de uma bridge de sempre: cerca de 625 milh\u00f5es de d\u00f3lares<\/a> em mar\u00e7o de 2022. O multisig era 5 de 9, mas a Sky Mavis controlava diretamente quatro chaves e tinha acesso delegado a uma quinta, nunca revogado. Comprometer uma \u00fanica organiza\u00e7\u00e3o bastava para reunir o qu\u00f3rum. O vetor foi social: o Lazarus Group norte-coreano enviou uma oferta de emprego falsa, em PDF, a um engenheiro s\u00e9nior.<\/p>

A Harmony repetiu o gui\u00e3o em junho de 2022, com um limiar ainda mais fr\u00e1gil: bastavam 2 de 5 assinaturas<\/a> para mover fundos, e cerca de 100 milh\u00f5es perderam-se. O maior roubo cripto da hist\u00f3ria, os 1,5 mil milh\u00f5es de d\u00f3lares da Bybit em fevereiro de 2025, foi uma varia\u00e7\u00e3o do mesmo tema: os atacantes comprometeram a esta\u00e7\u00e3o de trabalho de um programador<\/a> ligado \u00e0 interface de assinatura e injetaram c\u00f3digo que fez os executivos assinarem, \u00e0s cegas, uma transa\u00e7\u00e3o que parecia leg\u00edtima. Nenhum contrato foi partido. As chaves \u00e9 que foram.<\/p>

O padr\u00e3o repetiu-se em 2026 em vers\u00e3o mais pequena. A AFX Trade, um mercado de perp\u00e9tuos sobre a Arbitrum, foi esvaziada em cerca de 24 milh\u00f5es de d\u00f3lares quando as chaves de assinatura da sua pr\u00f3pria bridge foram comprometidas<\/a>; o cofundador da Arbitrum fez quest\u00e3o de sublinhar que a bridge nativa da rede \u00abn\u00e3o foi pirateada nem explorada de forma alguma\u00bb, a falha estava na camada que a AFX construiu por cima. Para quem opera nestes mercados, vale a pena perceber como uma cascata de liquida\u00e7\u00f5es se desenrola e quem paga a conta<\/a> quando a infraestrutura por baixo cede.<\/p>

Camada 2: os verificadores que acreditam numa mentira<\/h2>

A maioria das bridges modernas n\u00e3o guarda as chaves num multisig humano; delega a verifica\u00e7\u00e3o a uma rede off-chain de validadores, relayers ou or\u00e1culos que observam a cadeia de origem e reportam o que l\u00e1 viram. O contrato de destino confia nesse relato. O problema, como resumiu Ben Fisch, CEO da Espresso Systems, \u00e9 que \u00aba maioria das bridges n\u00e3o verifica realmente o que aconteceu noutra cadeia; em vez disso, confia num sistema mais pequeno para o reportar\u00bb<\/a>. Sobre o caso que melhor ilustra o ponto, foi lapidar: \u00aba bridge funcionou como foi desenhada; apenas acreditou na informa\u00e7\u00e3o errada\u00bb.<\/p>

Esse caso foi o da KelpDAO, em abril de 2026: 116.500 rsETH, cerca de 292 milh\u00f5es de d\u00f3lares<\/a> (\u00e0 volta de 260 milh\u00f5es de euros). N\u00e3o houve bug no contrato. A configura\u00e7\u00e3o da KelpDAO na LayerZero usava um \u00fanico verificador (1 de 1 DVN); os atacantes comprometeram dois n\u00f3s de RPC internos que alimentavam esse verificador, fizeram-nos servir dados forjados e, em simult\u00e2neo, lan\u00e7aram um ataque de nega\u00e7\u00e3o de servi\u00e7o contra os fornecedores de RPC externos, for\u00e7ando o sistema a confiar nos n\u00f3s envenenados. O verificador reportou uma queima de rsETH que nunca aconteceu, e o contrato, obediente, libertou os fundos.<\/p>

Esta \u00e9 a parte da bridge que mais se parece com o encanamento invis\u00edvel do resto da cripto. Quem acompanha o papel dos RPC e da ordem privada na defesa contra o MEV<\/a> reconhece de imediato o risco: um n\u00f3 de RPC n\u00e3o \u00e9 um detalhe t\u00e9cnico menor, \u00e9 um ponto de confian\u00e7a que, se envenenado, dita o que o resto do sistema aceita como verdade. A Chainalysis atribuiu o ataque a operadores norte-coreanos (TraderTraitor, do universo Lazarus) e notou que uma segunda tentativa, de mais 40.000 rsETH, foi travada quando a Kelp suspendeu o protocolo, e que o Conselho de Seguran\u00e7a da Arbitrum congelou 30.766 ETH poucas horas depois. O mecanismo n\u00e3o \u00e9 novo: em 2022, a Wormhole perdeu cerca de 325 milh\u00f5es de d\u00f3lares quando um atacante forjou a aprova\u00e7\u00e3o de um guardi\u00e3o<\/a> que a verifica\u00e7\u00e3o, deficiente, aceitou como v\u00e1lida.<\/p>

O caso KelpDAO deixou ainda uma disputa reveladora sobre quem \u00e9 dono da camada off-chain. A LayerZero argumentou que a Kelp reduzira manualmente a configura\u00e7\u00e3o para 1 de 1 e que isso ficava fora do \u00e2mbito do seu programa de recompensas; a Kelp respondeu que a configura\u00e7\u00e3o fora efetivamente validada pela LayerZero no momento do lan\u00e7amento<\/a>. Para o utilizador, a li\u00e7\u00e3o \u00e9 desconfort\u00e1vel: a responsabilidade pela camada off-chain \u00e9 muitas vezes uma zona cinzenta que s\u00f3 fica n\u00edtida depois do roubo.<\/p>

Um exemplo de 2026 mostra que nem um qu\u00f3rum alto salva um verificador enganado. Na bridge entre a XRP Ledger e a Coreum, em agosto, um limiar de 17 em 28 relayers n\u00e3o impediu o roubo<\/a>, porque o software validava os dep\u00f3sitos pela memo da transa\u00e7\u00e3o em vez de confirmar o destino real do pagamento; os relayers honestos assinaram, em peso, uma mentira bem formatada. Verificar muitas vezes n\u00e3o chega: \u00e9 preciso verificar a coisa certa.<\/p>

Camada 3: quando a federa\u00e7\u00e3o assina um erro<\/h2>

H\u00e1 bridges em que a valida\u00e7\u00e3o \u00e9 feita por uma federa\u00e7\u00e3o: um grupo conhecido e reputado de entidades que assinam em conjunto. A Liquid Network, a sidechain de Bitcoin da Blockstream, usa uma federa\u00e7\u00e3o de 11 de 15 funcion\u00e1rios. \u00c9 um limiar alto, operado por empresas s\u00e9rias h\u00e1 oito anos. E, ainda assim, a 6 de setembro de 2026, a federa\u00e7\u00e3o assinou a liberta\u00e7\u00e3o de cerca de 4.000 bitcoins (perto de 319 milh\u00f5es de d\u00f3lares), porque o que lhe foi pedido para validar parecia, byte a byte, leg\u00edtimo.<\/p>

A aut\u00f3psia oficial da Blockstream, publicada semanas depois, \u00e9 das leituras mais instrutivas do ano. Houve dois bugs encadeados<\/a>: um antigo, de 2018, que simplificara a chave de uma cache de verifica\u00e7\u00e3o de provas ao ponto de omitir campos essenciais; e, pior, a corre\u00e7\u00e3o<\/em> desse bug, publicada poucos dias antes do ataque, que voltou a juntar os campos em falta mas concatenou-os sem delimitadores de comprimento, abrindo colis\u00f5es. O atacante truncou uma prova e ajustou outro campo at\u00e9 a chave da cache bater, byte a byte, com uma entrada j\u00e1 marcada como v\u00e1lida. A federa\u00e7\u00e3o n\u00e3o foi comprometida; assinou uma mentira que o pr\u00f3prio software lhe apresentou como verdade. Nas palavras da Blockstream, \u00abnenhum revisor, interno ou externo, identificou este risco antes da explora\u00e7\u00e3o\u00bb. A corre\u00e7\u00e3o tornou-se o exploit.<\/p>

No extremo oposto do espetro est\u00e1 o colapso do operador. A Multichain n\u00e3o sofreu um bug de c\u00f3digo: em 2023, o seu CEO foi detido na China com as chaves da infraestrutura MPC que s\u00f3 ele controlava<\/a>, e cerca de 130 milh\u00f5es de d\u00f3lares sa\u00edram para endere\u00e7os desconhecidos antes de o protocolo fechar de vez. A auditoria do contrato n\u00e3o tinha como prever que uma \u00fanica pessoa fosse, na pr\u00e1tica, o ponto \u00fanico de falha de toda a bridge.<\/p>

Camada 4: a porta de servi\u00e7o com permiss\u00e3o<\/h2>

Quase todos os protocolos s\u00e9rios mant\u00eam uma forma de atualizar os seus contratos, para corrigir bugs ou acrescentar fun\u00e7\u00f5es. Essa capacidade (um proxy de upgrade, uma conta de administra\u00e7\u00e3o, um conselho de seguran\u00e7a) \u00e9, por desenho, uma porta de servi\u00e7o leg\u00edtima. Se um atacante a controlar, n\u00e3o precisa de furar nenhuma parede: entra pela porta, com permiss\u00e3o.<\/p>

O caso Drift, em abril de 2026, \u00e9 o exemplo perfeito. O protocolo de Solana perdeu cerca de 285 milh\u00f5es de d\u00f3lares em aproximadamente 12 minutos<\/a>. Os atacantes n\u00e3o exploraram a matem\u00e1tica dos contratos; passaram meses em engenharia social sobre os signat\u00e1rios do multisig, convenceram-nos a pr\u00e9-assinar autoriza\u00e7\u00f5es escondidas usando contas de durable nonce da Solana e, com isso, tomaram o Conselho de Seguran\u00e7a do protocolo. Uma migra\u00e7\u00e3o sem timelock eliminou a \u00faltima linha de defesa. A TRM Labs atribuiu o roubo ao Lazarus Group e classificou-o como o maior exploit de DeFi de 2026.<\/p>

A li\u00e7\u00e3o para quem avalia uma bridge: a exist\u00eancia de uma chave de administra\u00e7\u00e3o com poder para substituir o contrato \u00e9, muitas vezes, um risco maior do que qualquer linha de c\u00f3digo. Importa saber quem a det\u00e9m, se est\u00e1 protegida por um timelock que d\u00ea tempo de rea\u00e7\u00e3o, e se o pr\u00f3prio mecanismo de migra\u00e7\u00e3o pode ser desligado num instante, como aconteceu na Drift.<\/p>

Camada 5: o front-end que nunca assinaste<\/h2>

Mesmo que as chaves, os validadores, a federa\u00e7\u00e3o e a administra\u00e7\u00e3o estejam todos impec\u00e1veis, resta o andar mais mundano e, por isso, mais esquecido: o site. A maioria dos utilizadores interage com uma bridge atrav\u00e9s de uma p\u00e1gina web, que pede assinaturas \u00e0 carteira. Se essa p\u00e1gina for adulterada, o utilizador assina, de boa-f\u00e9, uma transa\u00e7\u00e3o que n\u00e3o \u00e9 a que julga estar a assinar.<\/p>

Foi o que aconteceu \u00e0 BadgerDAO em dezembro de 2021: os atacantes comprometeram uma chave de API da Cloudflare e injetaram um script malicioso no front-end<\/a>, que pedia aprova\u00e7\u00f5es de gastos ilimitadas a quem usava o site. Cerca de 120 milh\u00f5es de d\u00f3lares sa\u00edram assim, sem que um \u00fanico contrato auditado tivesse qualquer falha. O mesmo vale para a vaga de malware do tipo infostealer<\/em> que marcou 2026, capaz de roubar chaves e sess\u00f5es diretamente do computador da v\u00edtima, e para os ataques \u00e0 cadeia de fornecimento de software, em que uma depend\u00eancia comprometida contamina tudo o que a importa.<\/p>

Este andar \u00e9 um lembrete desconfort\u00e1vel: a seguran\u00e7a de uma bridge \u00e9 t\u00e3o forte quanto o mais fraco dos seus cinco andares, e o utilizador m\u00e9dio s\u00f3 v\u00ea o \u00faltimo, o site. Verificar o dom\u00ednio, desconfiar de aprova\u00e7\u00f5es ilimitadas e usar uma carteira que mostre com clareza o que est\u00e1 a ser assinado n\u00e3o s\u00e3o conselhos acess\u00f3rios; s\u00e3o, muitas vezes, a \u00fanica defesa que resta na camada que a auditoria n\u00e3o cobre.<\/p>

O mapa das perdas, camada a camada<\/h2>

Posto lado a lado, o historial dos grandes roubos de bridges desenha um padr\u00e3o n\u00edtido: quase nenhum foi um bug puro de smart contract. A esmagadora maioria saiu por uma das cinco camadas off-chain. A tabela re\u00fane os casos de refer\u00eancia, com os montantes em d\u00f3lares (a convers\u00e3o para euros usa a taxa de cerca de 1,12 d\u00f3lares por euro do in\u00edcio de outubro de 2026).<\/p>

Caso<\/th>Ano<\/th>Perda (USD)<\/th>Camada off-chain<\/th>Causa raiz<\/th><\/tr><\/thead>
Ronin (Sky Mavis)<\/td>2022<\/td>~625 milh\u00f5es<\/td>Chaves de assinatura<\/td>5 de 9 multisig, 5 chaves numa s\u00f3 organiza\u00e7\u00e3o; phishing Lazarus<\/td><\/tr>
Wormhole<\/td>2022<\/td>~325 milh\u00f5es<\/td>Verificadores<\/td>Assinatura de guardi\u00e3o forjada, verifica\u00e7\u00e3o deficiente<\/td><\/tr>
Harmony Horizon<\/td>2022<\/td>~100 milh\u00f5es<\/td>Chaves de assinatura<\/td>Limiar 2 de 5; chaves comprometidas<\/td><\/tr>
Multichain<\/td>2023<\/td>~130 milh\u00f5es<\/td>Operador<\/td>Chaves MPC controladas por uma s\u00f3 pessoa<\/td><\/tr>
Drift<\/td>2026<\/td>~285 milh\u00f5es<\/td>Administra\u00e7\u00e3o e upgrade<\/td>Tomada do Conselho de Seguran\u00e7a via durable nonce<\/td><\/tr>
KelpDAO \/ LayerZero<\/td>2026<\/td>~292 milh\u00f5es<\/td>Verificadores<\/td>DVN 1 de 1; RPC envenenado mais DDoS<\/td><\/tr>
Liquid Network<\/td>2026<\/td>~319 milh\u00f5es<\/td>Federa\u00e7\u00e3o<\/td>Colis\u00e3o de cache; a corre\u00e7\u00e3o virou exploit<\/td><\/tr>
Bitget (corretora)<\/td>2026<\/td>~387,5 milh\u00f5es<\/td>Verificadores e credenciais<\/td>Produto de terceiros; credenciais internas forjadas<\/td><\/tr><\/tbody><\/table><\/figure>

Porque este \u00e9 o andar mais dif\u00edcil de proteger<\/h2>

Se o problema \u00e9 t\u00e3o conhecido, porque persiste? Por tr\u00eas raz\u00f5es que se refor\u00e7am. A primeira \u00e9 o honeypot: uma bridge concentra, por defini\u00e7\u00e3o, todo o valor que a atravessa, o que oferece ao atacante um pr\u00e9mio gigantesco por um \u00fanico golpe bem-sucedido. A segunda \u00e9 que a camada off-chain \u00e9 feita de pessoas e de m\u00e1quinas que as pessoas operam, e as pessoas s\u00e3o o alvo mais barato: um PDF com malware, uma oferta de emprego falsa, um port\u00e1til comprometido. A terceira \u00e9 mais filos\u00f3fica.<\/p>

Vitalik Buterin avisou, j\u00e1 em 2022, que \u00abh\u00e1 limites fundamentais \u00e0 seguran\u00e7a de bridges que saltam entre m\u00faltiplas zonas de soberania\u00bb<\/a>. O argumento \u00e9 quase geom\u00e9trico: cada blockchain tem as suas pr\u00f3prias regras de consenso e a sua pr\u00f3pria no\u00e7\u00e3o de verdade; uma bridge tem de traduzir a verdade de uma cadeia para outra, e essa tradu\u00e7\u00e3o precisa sempre de algu\u00e9m, ou de alguma coisa, em que confiar. Pode reduzir-se essa confian\u00e7a, como veremos, mas n\u00e3o elimin\u00e1-la por completo. \u00c9 por isso que Buterin defende um futuro multi-chain, mas desconfia do cross-chain.<\/p>

H\u00e1 ainda um problema que escapa \u00e0 engenharia: depois de publicada, uma bridge aut\u00f3noma n\u00e3o tem dono a quem um regulador possa telefonar. A mesma propriedade que a torna dif\u00edcil de proteger torna-a dif\u00edcil de regular depois do facto, um ponto a que voltamos mais \u00e0 frente.<\/p>

A reconstru\u00e7\u00e3o: verificar em vez de confiar<\/h2>

A boa not\u00edcia \u00e9 que a ind\u00fastria aprendeu, e a resposta de 2026 tem um lema: verificar em vez de confiar. Quatro movimentos, sobretudo, atacam a camada off-chain em vez de a decorar.<\/p>

O primeiro \u00e9 apagar o honeypot. A emiss\u00e3o nativa (burn-and-mint) elimina o cofre de ativos embrulhados: em vez de trancar USDC num contrato e cunhar um IOU do outro lado, o Cross-Chain Transfer Protocol da Circle queima o USDC na origem e cunha USDC nativo no destino<\/a>, sem pool nem custodiante no meio. Se n\u00e3o h\u00e1 pote de mel trancado, n\u00e3o h\u00e1 pote para esvaziar. Na mesma linha, as bridges de liquidez (como a Across) dispensam o ativo embrulhado e usam fornecedores de liquidez dos dois lados; \u00e9 um desenho que se cruza com o debate sobre quem paga a liquidez e como os AMM a desenham<\/a>.<\/p>

O segundo movimento \u00e9 limitar o raio de explos\u00e3o. O padr\u00e3o xERC-20 (EIP-7281) deixa o emissor de um token definir limites de cunhagem por cada bridge, que se recarregam ao longo do tempo<\/a>: mesmo que uma bridge seja comprometida, s\u00f3 pode cunhar at\u00e9 ao seu teto, o que torna imposs\u00edveis os golpes de cunhar toda a oferta que vimos na Wormhole ou na Symbiosis.<\/p>

O terceiro \u00e9 empilhar verificadores independentes. Depois da KelpDAO, a LayerZero endureceu as regras, e a sua pr\u00f3pria documenta\u00e7\u00e3o passou a avisar que \u00abas implementa\u00e7\u00f5es em produ\u00e7\u00e3o devem configurar explicitamente a sua pilha de seguran\u00e7a com pelo menos um DVN que n\u00e3o seja operado pela LayerZero Labs\u00bb<\/a>. A Chainlink CCIP segue caminho semelhante com a sua Risk Management Network, uma segunda rede independente que valida as mesmas mensagens com software diferente<\/a> (a l\u00f3gica da programa\u00e7\u00e3o em N vers\u00f5es): para enganar o sistema, o atacante teria de comprometer duas redes distintas ao mesmo tempo.<\/p>

O quarto, e mais ambicioso, \u00e9 substituir o comit\u00e9 por matem\u00e1tica. Os light clients com provas de conhecimento-zero (ZK) permitem que uma cadeia verifique criptograficamente o estado de outra, sem confiar em nenhum relator: a Polyhedra e a Succinct reduziram a verifica\u00e7\u00e3o de cabe\u00e7alhos a custos de g\u00e1s vi\u00e1veis<\/a>, e protocolos como a IBC do Cosmos j\u00e1 funcionam assim. N\u00e3o \u00e9 magia: continua a haver confian\u00e7a no setup, nos circuitos e na disponibilidade do provador. Por isso se fala em bridges de confian\u00e7a minimizada, n\u00e3o de confian\u00e7a nula.<\/p>

Movimento<\/th>Exemplo<\/th>Camada off-chain que encolhe<\/th><\/tr><\/thead>
Emiss\u00e3o nativa (burn-and-mint)<\/td>Circle CCTP<\/td>Apaga o cofre honeypot<\/td><\/tr>
Limites por bridge<\/td>xERC-20 \/ EIP-7281<\/td>Limita o raio de explos\u00e3o de um verificador comprometido<\/td><\/tr>
Verificadores empilhados<\/td>LayerZero DVN, CCIP RMN<\/td>Encarece corromper os verificadores<\/td><\/tr>
Light client ZK<\/td>Polyhedra, IBC<\/td>Substitui o comit\u00e9 por prova matem\u00e1tica<\/td><\/tr><\/tbody><\/table><\/figure>

O mercado reavalia o risco, e os reguladores correm atr\u00e1s<\/h2>

Nada reavalia o risco mais depressa do que o capital a fugir. Depois de a KelpDAO ter exposto a configura\u00e7\u00e3o 1 de 1, assistiu-se a uma migra\u00e7\u00e3o not\u00e1vel: ao longo de 2026, perto de 15 mil milh\u00f5es de d\u00f3lares em ativos saltaram da LayerZero para a CCIP da Chainlink, incluindo o WBTC da BitGo e posi\u00e7\u00f5es da Lombard, da Solv e da Kraken. Johann Eid, da Chainlink Labs, descreveu o fen\u00f3meno como \u00abuma fuga cont\u00ednua para a seguran\u00e7a\u00bb<\/a>. \u00c9 o mercado a p\u00f4r pre\u00e7o na robustez da camada off-chain, n\u00e3o no marketing.<\/p>

Quando a defesa falha, a conta tem de aparecer algures, e a\u00ed entram os fundos de backstop. Foi assim que a KelpDAO sobreviveu: uma coliga\u00e7\u00e3o de protocolos recapitalizou o rsETH ao longo de cinco semanas, sem perdas para os utilizadores. No caso de uma corretora como a Bitget, o colch\u00e3o \u00e9 a reserva da casa, a mesma l\u00f3gica dos fundos de seguro e das reservas SAFU que sustentam o volume das exchanges<\/a>. Numa bridge aut\u00f3noma, muitas vezes, n\u00e3o h\u00e1 colch\u00e3o nenhum, e a perda fica, inteira, com quem l\u00e1 tinha os fundos.<\/p>

E a regula\u00e7\u00e3o? Para um leitor em Portugal, o enquadramento mudou h\u00e1 pouco. A Lei n.\u00ba 69\/2025 transp\u00f4s o MiCA para o direito portugu\u00eas, e o Banco de Portugal supervisiona os requisitos prudenciais e de governa\u00e7\u00e3o dos prestadores de servi\u00e7os de criptoativos (CASP)<\/a>, bem como as criptofichas referenciadas a ativos e de moeda eletr\u00f3nica, enquanto a CMVM assegura a supervis\u00e3o comportamental e a preven\u00e7\u00e3o do abuso de mercado. O per\u00edodo transit\u00f3rio termina a 1 de julho de 2026<\/a>: a partir dessa data, quem n\u00e3o tiver autoriza\u00e7\u00e3o MiCA deixa de poder prestar servi\u00e7os de criptoativos na Uni\u00e3o Europeia.<\/p>

O MiCA regula, por\u00e9m, prestadores de servi\u00e7os e emitentes, n\u00e3o o protocolo em si. O seu artigo 75.\u00ba imp\u00f5e deveres de cust\u00f3dia e de responsabilidade a um CASP que guarde ativos por conta de clientes, e o regulamento DORA acrescenta exig\u00eancias de resili\u00eancia operacional sobre sistemas de informa\u00e7\u00e3o e fornecedores externos, exatamente a camada off-chain que falhou na Bitget. Mas uma bridge totalmente aut\u00f3noma, sem operador, escapa a esta malha: n\u00e3o h\u00e1 entidade a quem exigir a licen\u00e7a. O mesmo dilema reapareceu com o Tornado Cash, cujas san\u00e7\u00f5es dos EUA foram levantadas em 2025 depois de um tribunal considerar que contratos imut\u00e1veis n\u00e3o t\u00eam dono sancion\u00e1vel<\/a>; o processo criminal contra o seu cofundador, esse, seguiu em frente. A conclus\u00e3o \u00e9 inc\u00f3moda: a propriedade que torna uma bridge dif\u00edcil de proteger \u00e9 a mesma que a torna dif\u00edcil de responsabilizar.<\/p>

A fronteira penal, essa, tem-se mostrado mais firme do que as san\u00e7\u00f5es. Roman Storm, cofundador do Tornado Cash, foi condenado em agosto de 2025 por conspira\u00e7\u00e3o para operar um neg\u00f3cio de transmiss\u00e3o de dinheiro sem licen\u00e7a<\/a>, com o j\u00fari dividido quanto \u00e0s acusa\u00e7\u00f5es de branqueamento; o novo julgamento ficou marcado para 2027. A mensagem para quem opera a camada off-chain de uma bridge \u00e9 n\u00edtida: o c\u00f3digo imut\u00e1vel pode escapar \u00e0 san\u00e7\u00e3o, mas as pessoas por tr\u00e1s da opera\u00e7\u00e3o n\u00e3o escapam ao direito penal.<\/p>

Como ler a camada off-chain de uma bridge<\/h2>

Nenhum utilizador vai auditar o c\u00f3digo de uma bridge, mas qualquer utilizador pode fazer as perguntas certas sobre a camada que a auditoria n\u00e3o cobre. Antes de mover fundos atrav\u00e9s de uma bridge, vale a pena correr esta lista:<\/p>

  • Quem assina?<\/strong> Procura saber quantas chaves autorizam levantamentos e quem as controla. Um multisig em que uma s\u00f3 organiza\u00e7\u00e3o det\u00e9m o qu\u00f3rum n\u00e3o \u00e9 um multisig a s\u00e9rio.<\/li>
  • Quantos verificadores independentes?<\/strong> Uma configura\u00e7\u00e3o de um \u00fanico validador (1 de 1) \u00e9 um ponto \u00fanico de falha, como na KelpDAO. Prefere pilhas com v\u00e1rios verificadores independentes.<\/li>
  • \u00c9 nativo ou embrulhado?<\/strong> Os ativos nativos (via CCTP, por exemplo) n\u00e3o dependem de um cofre trancado; os embrulhados dependem.<\/li>
  • H\u00e1 limites e timelock?<\/strong> Limites de cunhagem por bridge e um timelock na chave de administra\u00e7\u00e3o d\u00e3o tempo para travar um ataque em curso.<\/li>
  • O site \u00e9 o verdadeiro?<\/strong> Confirma o dom\u00ednio, desconfia de pedidos de aprova\u00e7\u00e3o ilimitada e usa uma carteira que mostre com clareza o que est\u00e1s a assinar.<\/li>
  • Precisas mesmo de uma bridge?<\/strong> Muitas vezes, um agregador de inten\u00e7\u00f5es ou uma corretora de confian\u00e7a movem o valor sem te exporem ao honeypot.<\/li><\/ul>

    Nenhuma destas perguntas aparece num relat\u00f3rio de auditoria de smart contract. \u00c9 esse, precisamente, o ponto.<\/p>

    Perguntas frequentes<\/h2>

    Porque \u00e9 que as bridges cripto s\u00e3o t\u00e3o atacadas?<\/h3>

    Porque concentram enormes quantidades de valor num \u00fanico ponto (um honeypot) e dependem de uma camada off-chain de chaves, validadores e relayers que vive fora do contrato auditado. Em 2026, a maioria das grandes perdas n\u00e3o veio de bugs de c\u00f3digo, mas do comprometimento dessa camada: chaves roubadas, infraestrutura envenenada ou autoridade de administra\u00e7\u00e3o tomada.<\/p>

    Se o contrato foi auditado, porque \u00e9 que a bridge foi roubada na mesma?<\/h3>

    Uma auditoria de c\u00f3digo l\u00ea o contrato que vai para a blockchain e verifica a sua l\u00f3gica, mas n\u00e3o v\u00ea quem guarda as chaves privadas, como s\u00e3o operados os relayers e os n\u00f3s de RPC, nem quem controla a conta de upgrade. Casos como o da Drift mostram que um protocolo pode passar numa auditoria impec\u00e1vel e perder centenas de milh\u00f5es por uma chave de administra\u00e7\u00e3o comprometida.<\/p>

    O que significa que n\u00e3o \u00e9 o c\u00f3digo, s\u00e3o as chaves?<\/h3>

    \u00c9 a conclus\u00e3o dos dados de 2026. Segundo a TRM Labs, o comprometimento de infraestrutura, chaves e opera\u00e7\u00f5es representou cerca de 15% dos incidentes, mas cerca de 76% do valor roubado no primeiro semestre. Os bugs de c\u00f3digo s\u00e3o muitos e pequenos; os roubos de chaves e de infraestrutura s\u00e3o poucos e gigantescos.<\/p>

    As bridges est\u00e3o a ficar mais seguras?<\/h3>

    Em desenho, sim. A emiss\u00e3o nativa (como o CCTP da Circle) apaga o cofre de ativos embrulhados, os limites por bridge (xERC-20) cont\u00eam o raio de explos\u00e3o, as pilhas de v\u00e1rios verificadores encarecem o ataque e os light clients ZK substituem comit\u00e9s por prova matem\u00e1tica. Mas persistem pontos fracos nas chaves de governa\u00e7\u00e3o e na opera\u00e7\u00e3o, pelo que se fala em confian\u00e7a minimizada, n\u00e3o em aus\u00eancia de confian\u00e7a.<\/p>

    Como est\u00e3o as bridges reguladas em Portugal?<\/h3>

    A Lei n.\u00ba 69\/2025 transp\u00f4s o MiCA, com o Banco de Portugal a supervisionar os requisitos prudenciais e de governa\u00e7\u00e3o dos CASP e a CMVM a cuidar da supervis\u00e3o comportamental e do abuso de mercado; o per\u00edodo transit\u00f3rio termina a 1 de julho de 2026. O MiCA e o DORA regulam prestadores e emitentes, mas uma bridge totalmente aut\u00f3noma, sem operador, escapa em larga medida a esta malha.<\/p>