Como avaliar uma bridge L2 antes de a atravessar

O que uma ponte L2 faz na verdade e porque é que isso importa para o teu dinheiro

Uma ponte é um software que te permite mover um ativo de uma cadeia para outra. Quando depositas ETH na ponte da Arbitrum, o teu ETH fica bloqueado num contrato inteligente na mainnet da Ethereum e é criada uma quantidade equivalente de ETH wrapped na Arbitrum. Quando fazes o levantamento, o ETH wrapped na Arbitrum é queimado e o ETH original é libertado na mainnet. Em ambas as direções, algures na stack existe um contrato que detém o teu ativo real, e esse contrato é o alvo dos atacantes.

É por isso que cada ponte, independentemente do aspeto cuidado do front end, funciona como um custodiante de último recurso. Enquanto as tuas tokens estiverem no contrato da ponte, não as controlas da mesma forma que um utilizador de hardware wallet controla as suas moedas. Se o contrato for explorado, drenado ou congelado pela governança, os teus fundos vão com ele. A história das pontes é, em grande medida, a história destes contratos a serem quebrados: Ronin (mais de $600 milhões, 2022), Wormhole (mais de $300 milhões, 2022), Multichain (estimativa de $125 a $265 milhões consoante a fonte, 2023), ponte Horizon da Harmony (cerca de $100 milhões, 2022) e a ponte Nomad (cerca de $190 milhões, 2022). Milhares de milhões foram retirados de pontes; quase nenhuma dessas perdas veio das próprias L1 ou L2.

Esse historial é o ponto de partida para qualquer diligência devida. Não estás a escolher entre dois caminhos técnicos igualmente seguros. Estás a escolher entre diferentes custodiantes com diferentes superfícies de ataque, e o teu trabalho é perceber quais fizeram o trabalho pouco glamoroso de se reforçar e quais estão a um relatório de bug de distância de um título de jornal.

Sinais de alerta a detetar antes de assinares qualquer transação de ponte

Antes de passares pela checklist de 7 pontos, ajuda saber do que te deves afastar à primeira vista. Pontes com um ou mais destes sinais de alerta já perderam dinheiro dos utilizadores no passado ou são estruturalmente semelhantes a pontes que o perderam.

• Sem auditoria de terceiros, ou apenas uma auditoria auto-publicada por uma empresa desconhecida. Trata a ponte como não auditada.
• Equipa anónima sem histórico e sem entidade legal. Não há ninguém a quem recorrer e nenhuma forma de verificar que os operadores já não estão dentro do sistema.
• TVL reportado no próprio dashboard do projeto que não corresponde aos dados on-chain. TVL falso é uma tática frequente para atrair depósitos antes de uma saída.
• Sem programa de recompensas por bugs, ou um programa condicionado por tokens tão pequeno que não atrai investigadores a sério. Se pagar $50.000 permite drenar $200 milhões, os atacantes não vão reportar o bug.
• Contratos atualizáveis controlados por uma multisig com um limiar baixo. Uma multisig 2-de-5 a governar todos os fundos da ponte está a uma campanha de phishing de distância de uma perda.
• Base de código copiada de uma ponte sabidamente explorada. Forks herdam os bugs do progenitor, a menos que cada linha tenha sido reauditada.
• Wrapper com rendimento sem uma fonte de rendimento clara. Se a ponte promete 4% nas tuas stablecoins e a página não consegue explicar de onde vem o rendimento, o rendimento é provavelmente o teu capital.

Se vires dois ou mais destes sinais na mesma ponte, a única jogada segura é não depositar. A checklist que se segue é o que verificar quando nenhum dos pontos acima está a gritar, mas mesmo assim queres confirmar antes de comprometeres capital.

Ponto 1 da checklist: bridge canónica versus bridge de terceiros

A pergunta mais importante é se a bridge que vai usar é a bridge canónica gerida pela própria equipa do rollup (a bridge oficial da Arbitrum, a bridge padrão do OP Stack, a bridge incluída num zk-rollup como zkSync) ou uma bridge de terceiros operada por um protocolo externo (Across, Stargate, Hop, Wormhole, Synapse, Rhino.fi, entre outros).

Uma bridge canónica herda o modelo de segurança do rollup. Se confia que a Arbitrum é uma execução fiel de um rollup otimista, estende essa confiança à sua bridge canónica. Uma bridge de terceiros acrescenta mais um pressuposto de confiança ao rollup, porque o terceiro opera os seus próprios contratos, a sua própria infraestrutura de nodes e, normalmente, a sua própria lógica de passagem de mensagens. Algumas bridges de terceiros, como a Across, evoluíram para designs com poucos validadores, com relayers cauçãoados e provas de fraude na camada de relayers, o que reduz a diferença de confiança. Outras continuam a depender de multisigs ou conjuntos externos de validadores.

Para um utilizador que só precisa de mover fundos entre a Ethereum e a Arbitrum ou a OP, a bridge canónica costuma ser a resposta certa por defeito. Recorra a uma bridge de terceiros quando precisar especificamente daquilo que ela oferece: levantamentos mais rápidos em rollups otimistas, envios multichain num só clique ou rotas que a bridge canónica não suporta. Nesses casos, os pontos seguintes da checklist são ainda mais importantes.

Ponto 2 da checklist: sistema de provas e o que implica no tempo de levantamento

As bridges não são todas igualmente rápidas, e a diferença de velocidade não é cosmética. É uma consequência direta do sistema de provas que o rollup utiliza.

Rollups otimistas (Arbitrum, OP Mainnet, Base) partem do princípio de que as transações são válidas a menos que sejam contestadas durante uma janela de disputa. O período de contestação é atualmente de cerca de 7 dias na Arbitrum e na OP, com janelas mais curtas em configurações mais recentes. Quando levanta de volta para a mainnet através da bridge canónica, tem de esperar aproximadamente esse tempo até os fundos poderem ser reclamados, porque a bridge só liberta o ativo bloqueado depois de a janela de prova de fraude fechar sem uma contestação bem-sucedida. A contrapartida são taxas mais baixas e um design amplamente testado.

Rollups de validade (zkSync, Starknet, Linea, Polygon zkEVM e cadeias mais recentes do OP Stack a avançar para fault proofs com janelas mais curtas) geram uma prova criptográfica de que cada lote de transações L2 está correto. Assim que essa prova de validade é verificada na L1, a bridge pode libertar os fundos. Os levantamentos costumam concluir-se em dezenas de minutos a algumas horas, consoante o prover e a congestão da L1, e não em dias.

O que isto significa na prática: se uma bridge de terceiros oferece um "levantamento rápido" num rollup otimista, está a fazer algo nos bastidores para lhe dar liquidez imediata (tipicamente adianta-lhe o ativo a partir de um pool de liquidez e depois recolhe o levantamento canónico mais tarde). Esse produto é razoável se a bridge for reputada, mas acrescenta uma contraparte que deve compreender. A bridge canónica lenta é a opção com menor confiança exigida; a bridge rápida é a opção conveniente, mas com risco adicional.

Ponto 3 da checklist: auditorias, programa de recompensas por bugs e a diferença entre "auditado" e "seguro"

Uma auditoria é uma revisão pontual do código dos contratos inteligentes por uma empresa externa. Não cobre todas as falhas possíveis, não cobre riscos de governação ou económicos, e não cobre atualizações introduzidas após a publicação da auditoria. Bridges podem ser auditadas e ainda assim ser exploradas, da mesma forma que bridges podem não ser auditadas e funcionar durante anos sem incidentes. A postura de auditoria é um sinal de probabilidade, não uma garantia.

O que procurar: auditorias de empresas reputadas (OpenZeppelin, Trail of Bits, Spearbit, ChainSecurity, Zellic, Cantina, revisores associados à Code4rena, Certora para trabalho mais formal) publicadas com âmbito, datas e versão do código revisto bem claros. Várias auditorias ao longo do tempo. Um programa de recompensas por bugs numa plataforma como a Immunefi ou a Code4rena com um montante relevante (uma recompensa de $50.000 numa bridge que detém $10 milhões é teatro; uma recompensa de $2 milhões numa bridge que detém $500 milhões já está, no mínimo, na ordem de grandeza correta).

Igualmente importante: um processo de resposta a incidentes documentado, post-mortems públicos de quaisquer problemas passados e uma multisig com um limiar elevado e signatários publicamente conhecidos. A exploração da Wormhole em 2022 aconteceu em parte porque o caminho de atualização da rede de guardiões contornou uma revisão adequada; a equipa corrigiu e reembolsou os utilizadores, mas a lição é que o processo é tão importante quanto o código.

Consegue verificar a maior parte disto numa tarde. Consulte a documentação do projeto, procure relatórios de auditoria no GitHub, verifique a página do programa de recompensas na Immunefi, veja as permissões de atualização no Etherscan (ler o contrato, verificar owners, verificar padrões de proxy) e leia o último ano de publicações no fórum de governação.

Ponto 4 da checklist: concentração de TVL, histórico de hacks e pressão da janela de saída

TVL, ou total value locked, é o valor em dólares depositado nos contratos de uma bridge. Dois riscos opostos convivem neste único número.

Primeiro, o risco de concentração. Se uma bridge detém $3 mil milhões num único contrato, é um alvo maior do que uma bridge com a mesma TVL distribuída por muitos pools mais pequenos. Alvos maiores atraem atacantes mais sofisticados e o raio de destruição de uma única falha é maior. Se uma bridge detém $3 mil milhões e uma multisig 2-de-5 a pode atualizar, isso é um problema estrutural independentemente de quão agradável seja a interface.

Segundo, a questão da sustentabilidade da própria bridge. As bridges ganham taxas sobre o fluxo, mas as maiores também precisam de continuar a pagar auditorias, monitorização e resposta a incidentes. Bridges com dificuldade em financiar-se por vezes cortam despesas, e os cortes nas ferramentas de segurança acabam por surgir como falhas dois anos mais tarde. Verifique se a bridge tem um modelo de receita sustentável e se a equipa já existe há tempo suficiente para ter atravessado pelo menos uma grande crise de mercado.

O histórico de hacks é a terceira perna deste ponto. Uma bridge que foi explorada e reconstruída com a causa da perda anterior tratada (post-mortem e nova auditoria da Nomad, reformulação da rede de guardiões da Wormhole) é diferente de uma bridge sem qualquer histórico. Uma bridge que foi explorada e relançada silenciosamente sem resolver a causa deve ser tratada como comprometida.

Cruze a TVL on-chain com aquilo que a bridge anuncia. Os painéis da DefiLlama, L2Beat e Dune para a bridge em causa permitem-lhe comparar os saldos reais nos contratos com a comunicação do projeto. Um projeto que declara $400 milhões em TVL quando os contratos detêm $40 milhões está a fazer algo em que não vai querer participar.

Ponto 5 da checklist: que ativo recebe efetivamente

Este é o ponto que a maioria dos utilizadores ignora, e é o que lhes sai mais caro. Quando faz a ponte de USDC de Ethereum para Arbitrum, o que chega à sua carteira depende inteiramente da bridge que usou e do contrato que está do lado recetor.

O USDC nativo é emitido diretamente pela Circle em cada cadeia que a Circle suporta. Em 2025, a Circle emite USDC nativo em Ethereum, Arbitrum, OP Mainnet, Base, Polygon, Avalanche e numa lista crescente de outras, através de um Cross-Chain Transfer Protocol (CCTP) que queima USDC na cadeia de origem e cunha USDC nativo na cadeia de destino. Quando recebe USDC nativo, o ativo em Arbitrum tem o mesmo emissor que o de Ethereum, e as atestações da Circle aplicam-se.

O USDC em ponte é um token diferente. É uma versão embrulhada cunhada por uma bridge de terceiros (USDC.e em Arbitrum, por exemplo, ou USDC em cadeias onde a Circle ainda não emite). O emissor é a bridge, não a Circle. A Circle não atesta esse token embrulhado. Se a bridge for explorada, o USDC embrulhado torna-se sem valor; o USDC nativo na mesma cadeia não é afetado.

Porque é que isto importa na prática: muitos protocolos DeFi em Arbitrum ainda listam USDC.e em vez de USDC nativo, por vezes ambos, outras vezes só um. Antes de fazer a ponte, verifique que token o protocolo de destino aceita e que token irá efetivamente receber. Receber USDC nativo através do CCTP da Circle está mais próximo de uma bridge de confiança minimizada do que de uma bridge genérica de terceiros, porque o mecanismo de cunhar/queimar da Circle significa que não há liquidez agrupada detida por terceiros; o USDC é destruído na origem e recriado no destino.

Pontos 6 e 7 da checklist: atualizações, governança e pequenos sinais operacionais

Os dois últimos pontos são mais pequenos por si só, mas apanham problemas que os primeiros cinco podem deixar passar.

O ponto 6 da checklist é a atualizabilidade e a governança. O contrato da bridge está atrás de um proxy? Pode ser atualizado, e por quem, e com que rapidez? Bridges com timelocks nas atualizações (um atraso de 24 a 72 horas antes de as mudanças produzirem efeito) dão à comunidade tempo para reagir a uma ação de governança hostil. Bridges sem timelock, ou com um único proprietário EOA, não são adequadas para depósitos sérios. Para uma posição do tamanho de ETH, a governança de atualizações da bridge é uma decisão de maior alavancagem do que a L2 onde acaba por estacionar os fundos.

O ponto 7 da checklist é a camada humana. A equipa é pública, tem um historial comprovado, já entregou atualizações dentro do prazo, tem uma página de estado funcional, publica relatórios de incidentes em inglês num fórum público? Uma equipa de bridge que responde durante um incidente pode evitar que uma perda se torne num wipeout. Uma equipa de bridge que se cala durante incidentes só piora o pânico. A bridge Harmony Horizon foi explorada em junho de 2022 em parte porque a monitorização falhou a intrusão inicial; uma monitorização melhor poderia ter reduzido a perda.

Pode montar tudo isto numa checklist de uma página antes de cada transação de bridge: canónica ou de terceiros, sistema de prova, auditorias e bounty, TVL e historial, ativo recebido, governança de atualizações, qualidade da equipa. A maior parte disto leva trinta minutos de leitura da primeira vez que avalia uma bridge e cinco minutos numa visita de retorno. O custo de saltar este passo é pago por quem pensou que a sua bridge era problema de outra pessoa.

Como seguir as L2 bridges da forma inteligente

As L2 bridges movem-se depressa e as notícias à volta delas também. Acompanhar qual bridge acabou de ser auditada, qual passou a suportar USDC nativo, qual teve uma votação de governança que enfraqueceu o seu caminho de atualização, é um trabalho por si só, e a maioria dos utilizadores não tem tempo para monitorizar isto manualmente. A Zippfeed destaca manchetes de L2 e bridges com pontuação de sentimento (bullish, neutral ou bearish) e uma classificação de importância, para que possa detetar alterações nas bridges que já utiliza, ouvir falar de novas cedo, e evitar as que estão prestes a dar que falar pelos piores motivos.