Secret Network Perde US$ 4,67 Milhões em Exploração Cross-Chain da Axelar — Não Detectada por Sete Dias
Secret Network Perde US$ 4,67 Milhões em Exploração Cross-Chain da Axelar — Não Detectada por Sete Dias
Em 21 de junho de 2026, pesquisadores da Common Prefix publicaram descobertas sobre um incidente de ponte cross-chain envolvendo a Secret Network e um contrato conectado à Axelar. O atacante supostamente explorou uma falha em um contrato de ponte ICS-20 do lado da Secret, forjou "depósitos", cunhou tokens sem lastro e retirou liquidez, totalizando um valor estimado de US$ 4,67 milhões.
O que torna este evento especialmente instrutivo não é apenas o montante da perda — é a cronologia: a exploração persistiu por cerca de uma semana antes que alguém percebesse, e o primeiro sinal claro não foi um alerta, mas uma falha operacional quando uma transferência legítima não pôde ser concluída.
Este post detalha o que aconteceu, por que o modo de falha é comum em sistemas cross-chain e o que usuários e desenvolvedores podem fazer para reduzir a exposição à medida que a interoperabilidade se torna um padrão no design de produtos cripto em 2025-2026.
O que supostamente aconteceu: uma linha do tempo clara, um alarme tardio
Com base na investigação divulgada:
- 10 de junho de 2026: o atacante começou a abusar de uma vulnerabilidade em um contrato de ponte cross-chain Secret Network ↔ Axelar ao fabricar o estado de transferência de entrada e cunhar tokens sem lastro.
- 10 a 17 de junho de 2026: o atacante converteu repetidamente os ativos cunhados em tokens mais líquidos e roteou os lucros para fora.
- 17 de junho de 2026: uma transferência cross-chain normal falhou porque a conta de custódia/depósito em garantia da ponte não tinha mais fundos suficientes — expondo a anomalia.
Este padrão de "drenagem silenciosa até que um usuário esbarre na parede" é um risco operacional recorrente para pontes: se o monitoramento se concentra na disponibilidade e no volume de mensagens (em vez de invariantes econômicas), as explorações podem se esconder à vista de todos.
Para leitores que desejam uma revisão de como as transferências de tokens no estilo IBC são tipicamente modeladas (depósito em um lado, representação cunhada no outro), a documentação da Secret Network sobre ferramentas relacionadas a IBC e ICS-20 é um bom ponto de partida.
Causa raiz (conforme descrito): quando um modelo de depósito em garantia se torna um modelo de cunhagem
A análise divulgada atribui o bug principal a um refactor de contrato: uma mudança de um fluxo de custódia / depósito em garantia para um fluxo de cunhagem — removendo verificações críticas que comprovavam a origem da transferência.
Em linguagem simples:
- Um contrato de ponte recebe uma mensagem cross-chain alegando: "X tokens foram depositados na Cadeia A para o usuário Y".
- O contrato de destino deve verificar se essa mensagem veio realmente do canal / gateway / remetente esperado.
- Só então ele deve cunhar ou liberar os ativos.
De acordo com a divulgação, o contrato vulnerável removeu duas funções-chave responsáveis pela validação da origem das transferências, permitindo que um atacante submetesse dados que pareciam ser uma transferência de entrada válida e acionasse a cunhagem sem lastro real.
Pior ainda, o relatório afirma que o contrato estava implantado desde início de 2023 e nunca passou por uma auditoria externa — uma lacuna de governança e processo difícil de justificar para qualquer contrato que controle a autoridade de cunhagem cross-chain.
Para contexto sobre o quão sérias são as auditorias de pontes esperadas na camada de infraestrutura, você pode revisar os recursos públicos de auditoria da Axelar no repositório de auditorias da Axelar Network e a própria perspectiva da Axelar em seu post sobre segurança no núcleo da Axelar.
Por que passou despercebido: "sem sirenes" antes que o cofre estivesse vazio
Uma alegação principal do lado da Secret Network é que a infraestrutura de ponte da Axelar não ativou uma detecção de anomalia eficaz ou um mecanismo de pausa de emergência antes que um valor significativo já tivesse saído do sistema.
Se a responsabilidade recai sobre o contrato da aplicação, o provedor da ponte ou operações compartilhadas, a lição é mais ampla:
Sistemas cross-chain precisam de monitoramento econômico, não apenas técnico
Pontes não são apenas "tubos de mensagem". São sistemas financeiros com invariantes:
- Suprimento cunhado vs. lastro depositado em garantia
- Limites diários de cunhagem
- Limites de exposição por rota
- Padrões anormais de resgate / swap
- Pico de transferências falhas (frequentemente um sintoma tardio)
Em 2026, a indústria já está reavaliando esse risco. Por exemplo, após um evento separado impulsionado por pontes, a Aave apertou os padrões de listagem e de risco — destacando como a fragilidade das pontes pode se espalhar para mercados de dinheiro DeFi (cobertura do CoinDesk).
Para onde foram os fundos: roteamento via Osmosis, liquidação em Ethereum, após saídas em CEX
O rastreamento divulgado indica um caminho de lavagem familiar:
- Os ativos foram roteados através de trilhos de liquidez Cosmos, supostamente via Osmosis, que funciona como um grande hub DEX cross-chain (ver documentação da Osmosis).
- Os lucros foram então pontuados para Ethereum e trocados por ETH usando o CoW Protocol (ver documentação do CoW Protocol), antes de serem fragmentados em múltiplos endereços.
- Alguns fundos foram relatados como tendo chegado a locais centralizados, incluindo KuCoin, ChangeNow e HitBTC.
O relatório também afirma que aproximadamente US$ 672.000 permaneceram em uma carteira Axelar controlada pelo atacante no momento da publicação, e que pedidos para congelar esse endereço foram negados — enquanto a Axelar enfatizou que o contrato explorado não foi desenvolvido ou mantido pela Axelar, e que o protocolo principal da Axelar não foi comprometido.
O que este incidente diz sobre o risco de pontes em 2025-2026
A interoperabilidade está acelerando — a experiência do usuário (UX) das carteiras tende para "cross-chain com um clique", e os aplicativos assumem cada vez mais a abstração de cadeia por padrão. Mas essa conveniência expande a superfície de ataque de três maneiras:
- Mais contratos ganham autoridade de cunhagem em algum lugar (e autoridade de cunhagem é o privilégio mais alto no design de tokens).
- Refactors são frequentes à medida que as equipes buscam rotas mais rápidas, taxas mais baixas e melhor UX — introduzindo frequentemente risco de regressão.
- A responsabilidade se torna ambígua entre equipes de aplicativos, provedores de pontes, retransmissores e pilhas de monitoramento.
O resultado: mesmo que uma rede de ponte seja robusta, um único contrato de integração fraco pode se tornar o ponto de falha.
Lições práticas
Para desenvolvedores: reduzir o "raio de explosão da autoridade de cunhagem"
- Trate qualquer contrato de cunhagem cross-chain como um componente sistemicamente importante: auditorias externas obrigatórias, portões de revisão formal e monitoramento contínuo.
- Adicione disjuntores: limites de taxa, limites por ativo e gatilhos de pausa automática vinculados a violações de invariantes.
- Monitore lastro vs. suprimento cunhado em todas as rotas; alerte sobre desvios, não apenas sobre tempo de inatividade.
- Evite remover a lógica de validação durante "mudanças de modelo" (depósito em garantia → cunhagem, ou vice-versa) sem revisão adversarial e testes de regressão.
Para usuários: assuma que as pontes são de maior risco do que swaps à vista
- Mantenha apenas o que você precisa em representações pontuadas; não trate ativos embrulhados como armazenamento a frio de longo prazo.
- Após a ponte, considere mover fundos para custódia própria e verificar o ativo que você recebeu (cadeia, denominação, contrato) antes de interagir mais.
- Prefira fluxos de trabalho onde você possa verificar independentemente o que assina e para onde vai — especialmente ao fazer ponte e trocar através de múltiplos saltos.
Onde a OneKey se encaixa: custódia própria em um mundo cross-chain
Incidentes de ponte são um lembrete de que "não suas chaves, não suas moedas" é apenas metade da história — a outra metade é minimizar o tempo e o valor que você deixa dentro de rotas complexas de contratos inteligentes.
Uma carteira de hardware como a OneKey ajuda mantendo as chaves privadas offline e facilitando a revisão e confirmação de endereços de destino e intenção de transação antes de assinar — um hábito importante quando a UX cross-chain pode obscurecer o que está acontecendo nos bastidores.
Na realidade multichain de 2026, o padrão mais seguro é: faça ponte apenas quando necessário, verifique cada assinatura e retorne à custódia própria quando terminar.
