Segurança das bridges em 2026: o elo que a auditoria não vê

Setembro de 2026 entrou para a história pelas piores razões. Segundo o balanço trimestral da CertiK, o terceiro trimestre do ano custou cerca de 1,26 mil milhões de dólares em cripto roubada, em 247 incidentes, uma subida de quase 54% face aos 819,4 milhões do trimestre anterior; só setembro valeu perto de 769 milhões. No topo da tabela está a corretora Bitget, com 387,5 milhões de dólares (à volta de 344 milhões de euros) desviados, seguida da Liquid Network, com 319 milhões (cerca de 283 milhões de euros).

O detalhe mais importante não é o montante, é o como. No caso da Bitget, os atacantes não partiram nenhum smart contract; exploraram uma falha num produto de segurança de um fornecedor externo, obtiveram credenciais internas de alto nível e emitiram ordens de levantamento fraudulentas que contornaram os controlos de risco existentes. A própria CertiK resume a tendência numa frase: a ameaça deslocou-se do código para os sistemas geridos por pessoas.

Esta é a tese deste artigo, aplicada ao problema mais antigo da cripto multi-chain: as bridges. A Bitget não é uma bridge, mas a lição aplica-se com ainda mais força a quem move valor entre blockchains. O contrato que uma bridge publica na cadeia é, 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ções e páginas web que nenhuma auditoria de código chega a ver. Foi assim na Bitget e na Liquid, os dois maiores rombos de um setembro negro, e é assim na esmagadora maioria dos ataques a bridges de 2026.

O que uma bridge faz com o teu dinheiro

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

O problema estrutural nasce aqui. Todo o ETH trancado fica concentrado num único contrato, à espera. É o que a indústria chama, sem ironia, um honeypot: um pote de mel que cresce com cada depósito e que, ao contrário de um banco, não tem porta de cofre física, guarda armado nem seguro estatal. Quem conseguir convencer o contrato de que tem direito a levantar, leva tudo. E é exatamente aí que entra a segunda metade da bridge, a parte que quase ninguém vê.

Porque o contrato on-chain, sozinho, não sabe se o depósito na outra cadeia aconteceu mesmo. Alguém tem de lho dizer. Essa tarefa cabe a um conjunto off-chain: um grupo de signatários, uma rede de validadores externos, uma federação, um oráculo, um relayer. É este alguém que autoriza a cunhagem e o levantamento. A bridge tem, portanto, duas metades: o contrato que guarda o dinheiro, publicado e auditável, e a máquina off-chain que lhe diz o que fazer, muito mais difícil de inspecionar. As perdas de 2026 saíram, quase sempre, pela segunda.

Não é o código, são as chaves

Durante anos, a narrativa dominante foi a do bug de Solidity: uma linha mal escrita, um reentrancy, um overflow. Em 2026, os números contam outra história. A TRM Labs, no seu balanço do primeiro semestre, registou 207 ataques e cerca de 972 milhões de dólares roubados, e concluiu que o comprometimento de infraestrutura, chaves e operações representou apenas cerca de 15% dos incidentes, mas cerca de 76% do valor. Os bugs de código são muitos e pequenos; os roubos de chaves e de infraestrutura são poucos e gigantescos.

A CertiK chega à mesma leitura no seu balanço mais recente: a ameaça deslocou-se do código para os sistemas geridos por pessoas. É a inversão da velha máxima da indústria. Não é o código, são as chaves; não é o que foi escrito, é quem tem autoridade para o mandar executar. Para uma bridge, este deslocamento é fatal, porque a bridge é, por natureza, feita de confiança delegada.

Há ainda um segundo motivo para o risco se agravar: um ativo cunhado por uma bridge raramente fica quieto. Vai servir de garantia noutro protocolo, é emprestado, é alavancado. Quando a bridge que o emitiu é esvaziada, o colateral por trás desse ativo evapora-se e a onda de choque propaga-se a mercados que nunca tocaram na bridge original. É o contágio, e é a razão pela qual uma única falha consegue ameaçar meia dúzia de protocolos a jusante.

O que a auditoria vê, e o que nunca vê

Uma auditoria de smart contract faz uma coisa muito concreta e muito limitada: lê o código que vai ser publicado na blockchain e procura falhas na sua lógica. Verifica se a matemática fecha, se não há reentrancy, se os controlos de acesso dentro do contrato estão corretos. É trabalho essencial e, em 2026, funcionou: a maioria dos contratos de bridge comprometidos este ano comportou-se exatamente como estava escrito.

O que uma auditoria de código não vê é tudo o resto. Não vê quem guarda as chaves privadas que controlam a federação. Não vê como são operados os relayers e os nós de RPC que alimentam os validadores. Não vê o servidor onde corre o front-end, nem o registo de DNS do domínio, nem a conta de administração com poder para substituir o contrato por outro. Ronghui Gu, cofundador da CertiK, pô-lo numa frase que se tornou o lema do ano: «um protocolo pode passar numa auditoria de código impecável e ainda assim perder milhões por causa de uma chave de administração comprometida».

É útil pensar na camada off-chain de uma bridge como cinco andares, cada um com a sua forma de ruir e cada um invisível para a auditoria de código. A tabela seguinte mapeia esses andares; as secções que se seguem descem a cada um deles.

Camada 1: as chaves que assinam

O andar mais antigo e mais lucrativo. Muitas bridges exigem que um grupo de signatários aprove cada levantamento, num esquema multisig: por exemplo, 5 de 9 assinaturas. No papel é robusto; na prática, o que importa não é o número, é 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ões de dólares em março 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 única organização bastava para reunir o quórum. O vetor foi social: o Lazarus Group norte-coreano enviou uma oferta de emprego falsa, em PDF, a um engenheiro sénior.

A Harmony repetiu o guião em junho de 2022, com um limiar ainda mais frágil: bastavam 2 de 5 assinaturas para mover fundos, e cerca de 100 milhões perderam-se. O maior roubo cripto da história, os 1,5 mil milhões de dólares da Bybit em fevereiro de 2025, foi uma variação do mesmo tema: os atacantes comprometeram a estação de trabalho de um programador ligado à interface de assinatura e injetaram código que fez os executivos assinarem, às cegas, uma transação que parecia legítima. Nenhum contrato foi partido. As chaves é que foram.

O padrão repetiu-se em 2026 em versão mais pequena. A AFX Trade, um mercado de perpétuos sobre a Arbitrum, foi esvaziada em cerca de 24 milhões de dólares quando as chaves de assinatura da sua própria bridge foram comprometidas; o cofundador da Arbitrum fez questão de sublinhar que a bridge nativa da rede «não foi pirateada nem explorada de forma alguma», 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ções se desenrola e quem paga a conta quando a infraestrutura por baixo cede.

Camada 2: os verificadores que acreditam numa mentira

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

Esse caso foi o da KelpDAO, em abril de 2026: 116.500 rsETH, cerca de 292 milhões de dólares (à volta de 260 milhões de euros). Não houve bug no contrato. A configuração da KelpDAO na LayerZero usava um único verificador (1 de 1 DVN); os atacantes comprometeram dois nós de RPC internos que alimentavam esse verificador, fizeram-nos servir dados forjados e, em simultâneo, lançaram um ataque de negação de serviço contra os fornecedores de RPC externos, forçando o sistema a confiar nos nós envenenados. O verificador reportou uma queima de rsETH que nunca aconteceu, e o contrato, obediente, libertou os fundos.

Esta é a parte da bridge que mais se parece com o encanamento invisível do resto da cripto. Quem acompanha o papel dos RPC e da ordem privada na defesa contra o MEV reconhece de imediato o risco: um nó de RPC não é um detalhe técnico menor, é um ponto de confiança 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ça da Arbitrum congelou 30.766 ETH poucas horas depois. O mecanismo não é novo: em 2022, a Wormhole perdeu cerca de 325 milhões de dólares quando um atacante forjou a aprovação de um guardião que a verificação, deficiente, aceitou como válida.

O caso KelpDAO deixou ainda uma disputa reveladora sobre quem é dono da camada off-chain. A LayerZero argumentou que a Kelp reduzira manualmente a configuração para 1 de 1 e que isso ficava fora do âmbito do seu programa de recompensas; a Kelp respondeu que a configuração fora efetivamente validada pela LayerZero no momento do lançamento. Para o utilizador, a lição é desconfortável: a responsabilidade pela camada off-chain é muitas vezes uma zona cinzenta que só fica nítida depois do roubo.

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

Camada 3: quando a federação assina um erro

Há bridges em que a validação é feita por uma federação: um grupo conhecido e reputado de entidades que assinam em conjunto. A Liquid Network, a sidechain de Bitcoin da Blockstream, usa uma federação de 11 de 15 funcionários. É um limiar alto, operado por empresas sérias há oito anos. E, ainda assim, a 6 de setembro de 2026, a federação assinou a libertação de cerca de 4.000 bitcoins (perto de 319 milhões de dólares), porque o que lhe foi pedido para validar parecia, byte a byte, legítimo.

A autópsia oficial da Blockstream, publicada semanas depois, é das leituras mais instrutivas do ano. Houve dois bugs encadeados: um antigo, de 2018, que simplificara a chave de uma cache de verificação de provas ao ponto de omitir campos essenciais; e, pior, a correção 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ões. O atacante truncou uma prova e ajustou outro campo até a chave da cache bater, byte a byte, com uma entrada já marcada como válida. A federação não foi comprometida; assinou uma mentira que o próprio software lhe apresentou como verdade. Nas palavras da Blockstream, «nenhum revisor, interno ou externo, identificou este risco antes da exploração». A correção tornou-se o exploit.

No extremo oposto do espetro está o colapso do operador. A Multichain não sofreu um bug de código: em 2023, o seu CEO foi detido na China com as chaves da infraestrutura MPC que só ele controlava, e cerca de 130 milhões de dólares saíram para endereços desconhecidos antes de o protocolo fechar de vez. A auditoria do contrato não tinha como prever que uma única pessoa fosse, na prática, o ponto único de falha de toda a bridge.

Camada 4: a porta de serviço com permissão

Quase todos os protocolos sérios mantêm uma forma de atualizar os seus contratos, para corrigir bugs ou acrescentar funções. Essa capacidade (um proxy de upgrade, uma conta de administração, um conselho de segurança) é, por desenho, uma porta de serviço legítima. Se um atacante a controlar, não precisa de furar nenhuma parede: entra pela porta, com permissão.

O caso Drift, em abril de 2026, é o exemplo perfeito. O protocolo de Solana perdeu cerca de 285 milhões de dólares em aproximadamente 12 minutos. Os atacantes não exploraram a matemática dos contratos; passaram meses em engenharia social sobre os signatários do multisig, convenceram-nos a pré-assinar autorizações escondidas usando contas de durable nonce da Solana e, com isso, tomaram o Conselho de Segurança do protocolo. Uma migração sem timelock eliminou a última linha de defesa. A TRM Labs atribuiu o roubo ao Lazarus Group e classificou-o como o maior exploit de DeFi de 2026.

A lição para quem avalia uma bridge: a existência de uma chave de administração com poder para substituir o contrato é, muitas vezes, um risco maior do que qualquer linha de código. Importa saber quem a detém, se está protegida por um timelock que dê tempo de reação, e se o próprio mecanismo de migração pode ser desligado num instante, como aconteceu na Drift.

Camada 5: o front-end que nunca assinaste

Mesmo que as chaves, os validadores, a federação e a administração estejam todos impecáveis, resta o andar mais mundano e, por isso, mais esquecido: o site. A maioria dos utilizadores interage com uma bridge através de uma página web, que pede assinaturas à carteira. Se essa página for adulterada, o utilizador assina, de boa-fé, uma transação que não é a que julga estar a assinar.

Foi o que aconteceu à BadgerDAO em dezembro de 2021: os atacantes comprometeram uma chave de API da Cloudflare e injetaram um script malicioso no front-end, que pedia aprovações de gastos ilimitadas a quem usava o site. Cerca de 120 milhões de dólares saíram assim, sem que um único contrato auditado tivesse qualquer falha. O mesmo vale para a vaga de malware do tipo infostealer que marcou 2026, capaz de roubar chaves e sessões diretamente do computador da vítima, e para os ataques à cadeia de fornecimento de software, em que uma dependência comprometida contamina tudo o que a importa.

Este andar é um lembrete desconfortável: a segurança de uma bridge é tão forte quanto o mais fraco dos seus cinco andares, e o utilizador médio só vê o último, o site. Verificar o domínio, desconfiar de aprovações ilimitadas e usar uma carteira que mostre com clareza o que está a ser assinado não são conselhos acessórios; são, muitas vezes, a única defesa que resta na camada que a auditoria não cobre.

O mapa das perdas, camada a camada

Posto lado a lado, o historial dos grandes roubos de bridges desenha um padrão nítido: quase nenhum foi um bug puro de smart contract. A esmagadora maioria saiu por uma das cinco camadas off-chain. A tabela reúne os casos de referência, com os montantes em dólares (a conversão para euros usa a taxa de cerca de 1,12 dólares por euro do início de outubro de 2026).

Porque este é o andar mais difícil de proteger

Se o problema é tão conhecido, porque persiste? Por três razões que se reforçam. A primeira é o honeypot: uma bridge concentra, por definição, todo o valor que a atravessa, o que oferece ao atacante um prémio gigantesco por um único golpe bem-sucedido. A segunda é que a camada off-chain é feita de pessoas e de máquinas que as pessoas operam, e as pessoas são o alvo mais barato: um PDF com malware, uma oferta de emprego falsa, um portátil comprometido. A terceira é mais filosófica.

Vitalik Buterin avisou, já em 2022, que «há limites fundamentais à segurança de bridges que saltam entre múltiplas zonas de soberania». O argumento é quase geométrico: cada blockchain tem as suas próprias regras de consenso e a sua própria noção de verdade; uma bridge tem de traduzir a verdade de uma cadeia para outra, e essa tradução precisa sempre de alguém, ou de alguma coisa, em que confiar. Pode reduzir-se essa confiança, como veremos, mas não eliminá-la por completo. É por isso que Buterin defende um futuro multi-chain, mas desconfia do cross-chain.

Há ainda um problema que escapa à engenharia: depois de publicada, uma bridge autónoma não tem dono a quem um regulador possa telefonar. A mesma propriedade que a torna difícil de proteger torna-a difícil de regular depois do facto, um ponto a que voltamos mais à frente.

A reconstrução: verificar em vez de confiar

A boa notícia é que a indústria 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.

O primeiro é apagar o honeypot. A emissão 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, sem pool nem custodiante no meio. Se não há pote de mel trancado, não há 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; é um desenho que se cruza com o debate sobre quem paga a liquidez e como os AMM a desenham.

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

O terceiro é empilhar verificadores independentes. Depois da KelpDAO, a LayerZero endureceu as regras, e a sua própria documentação passou a avisar que «as implementações em produção devem configurar explicitamente a sua pilha de segurança com pelo menos um DVN que não seja operado pela LayerZero Labs». 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 lógica da programação em N versões): para enganar o sistema, o atacante teria de comprometer duas redes distintas ao mesmo tempo.

O quarto, e mais ambicioso, é substituir o comité por matemática. 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ção de cabeçalhos a custos de gás viáveis, e protocolos como a IBC do Cosmos já funcionam assim. Não é magia: continua a haver confiança no setup, nos circuitos e na disponibilidade do provador. Por isso se fala em bridges de confiança minimizada, não de confiança nula.

O mercado reavalia o risco, e os reguladores correm atrás

Nada reavalia o risco mais depressa do que o capital a fugir. Depois de a KelpDAO ter exposto a configuração 1 de 1, assistiu-se a uma migração notável: ao longo de 2026, perto de 15 mil milhões de dólares em ativos saltaram da LayerZero para a CCIP da Chainlink, incluindo o WBTC da BitGo e posições da Lombard, da Solv e da Kraken. Johann Eid, da Chainlink Labs, descreveu o fenómeno como «uma fuga contínua para a segurança». É o mercado a pôr preço na robustez da camada off-chain, não no marketing.

Quando a defesa falha, a conta tem de aparecer algures, e aí entram os fundos de backstop. Foi assim que a KelpDAO sobreviveu: uma coligação 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ão é a reserva da casa, a mesma lógica dos fundos de seguro e das reservas SAFU que sustentam o volume das exchanges. Numa bridge autónoma, muitas vezes, não há colchão nenhum, e a perda fica, inteira, com quem lá tinha os fundos.

E a regulação? Para um leitor em Portugal, o enquadramento mudou há pouco. A Lei n.º 69/2025 transpôs o MiCA para o direito português, e o Banco de Portugal supervisiona os requisitos prudenciais e de governação dos prestadores de serviços de criptoativos (CASP), bem como as criptofichas referenciadas a ativos e de moeda eletrónica, enquanto a CMVM assegura a supervisão comportamental e a prevenção do abuso de mercado. O período transitório termina a 1 de julho de 2026: a partir dessa data, quem não tiver autorização MiCA deixa de poder prestar serviços de criptoativos na União Europeia.

O MiCA regula, porém, prestadores de serviços e emitentes, não o protocolo em si. O seu artigo 75.º impõe deveres de custódia e de responsabilidade a um CASP que guarde ativos por conta de clientes, e o regulamento DORA acrescenta exigências de resiliência operacional sobre sistemas de informação e fornecedores externos, exatamente a camada off-chain que falhou na Bitget. Mas uma bridge totalmente autónoma, sem operador, escapa a esta malha: não há entidade a quem exigir a licença. O mesmo dilema reapareceu com o Tornado Cash, cujas sanções dos EUA foram levantadas em 2025 depois de um tribunal considerar que contratos imutáveis não têm dono sancionável; o processo criminal contra o seu cofundador, esse, seguiu em frente. A conclusão é incómoda: a propriedade que torna uma bridge difícil de proteger é a mesma que a torna difícil de responsabilizar.

A fronteira penal, essa, tem-se mostrado mais firme do que as sanções. Roman Storm, cofundador do Tornado Cash, foi condenado em agosto de 2025 por conspiração para operar um negócio de transmissão de dinheiro sem licença, com o júri dividido quanto às acusações de branqueamento; o novo julgamento ficou marcado para 2027. A mensagem para quem opera a camada off-chain de uma bridge é nítida: o código imutável pode escapar à sanção, mas as pessoas por trás da operação não escapam ao direito penal.

Como ler a camada off-chain de uma bridge

Nenhum utilizador vai auditar o código de uma bridge, mas qualquer utilizador pode fazer as perguntas certas sobre a camada que a auditoria não cobre. Antes de mover fundos através de uma bridge, vale a pena correr esta lista:

• Quem assina? Procura saber quantas chaves autorizam levantamentos e quem as controla. Um multisig em que uma só organização detém o quórum não é um multisig a sério.
• Quantos verificadores independentes? Uma configuração de um único validador (1 de 1) é um ponto único de falha, como na KelpDAO. Prefere pilhas com vários verificadores independentes.
• É nativo ou embrulhado? Os ativos nativos (via CCTP, por exemplo) não dependem de um cofre trancado; os embrulhados dependem.
• Há limites e timelock? Limites de cunhagem por bridge e um timelock na chave de administração dão tempo para travar um ataque em curso.
• O site é o verdadeiro? Confirma o domínio, desconfia de pedidos de aprovação ilimitada e usa uma carteira que mostre com clareza o que estás a assinar.
• Precisas mesmo de uma bridge? Muitas vezes, um agregador de intenções ou uma corretora de confiança movem o valor sem te exporem ao honeypot.

Nenhuma destas perguntas aparece num relatório de auditoria de smart contract. É esse, precisamente, o ponto.

Perguntas frequentes

Porque é que as bridges cripto são tão atacadas?

Porque concentram enormes quantidades de valor num único 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ão veio de bugs de código, mas do comprometimento dessa camada: chaves roubadas, infraestrutura envenenada ou autoridade de administração tomada.

Se o contrato foi auditado, porque é que a bridge foi roubada na mesma?

Uma auditoria de código lê o contrato que vai para a blockchain e verifica a sua lógica, mas não vê quem guarda as chaves privadas, como são operados os relayers e os nós de RPC, nem quem controla a conta de upgrade. Casos como o da Drift mostram que um protocolo pode passar numa auditoria impecável e perder centenas de milhões por uma chave de administração comprometida.

O que significa que não é o código, são as chaves?

É a conclusão dos dados de 2026. Segundo a TRM Labs, o comprometimento de infraestrutura, chaves e operações representou cerca de 15% dos incidentes, mas cerca de 76% do valor roubado no primeiro semestre. Os bugs de código são muitos e pequenos; os roubos de chaves e de infraestrutura são poucos e gigantescos.

As bridges estão a ficar mais seguras?

Em desenho, sim. A emissão nativa (como o CCTP da Circle) apaga o cofre de ativos embrulhados, os limites por bridge (xERC-20) contêm o raio de explosão, as pilhas de vários verificadores encarecem o ataque e os light clients ZK substituem comités por prova matemática. Mas persistem pontos fracos nas chaves de governação e na operação, pelo que se fala em confiança minimizada, não em ausência de confiança.

Como estão as bridges reguladas em Portugal?

A Lei n.º 69/2025 transpôs o MiCA, com o Banco de Portugal a supervisionar os requisitos prudenciais e de governação dos CASP e a CMVM a cuidar da supervisão comportamental e do abuso de mercado; o período transitório termina a 1 de julho de 2026. O MiCA e o DORA regulam prestadores e emitentes, mas uma bridge totalmente autónoma, sem operador, escapa em larga medida a esta malha.

Por Yuki Tanaka, redação da HOGE Wire, cluster DeFi e On-Chain.