Aztec Connect: US$ 2,19 milhões roubados de um contrato morto

Um contrato que estava há mais de dois anos impossível de ser corrigido por decisão da sua própria equipe perdeu cerca de 2,19 milhões de dólares em uma única transação. Em 14 de junho de 2026, um atacante esvaziou o contrato RollupProcessor da Aztec Connect — uma ponte de privacidade sobre Ethereum que a Aztec Labs havia descontinuado (retirado de serviço). A Aztec Connect anunciou seu fechamento em março de 2023 (depósitos interrompidos em 31 de março) e renunciou às admin keys (as chaves de administração que permitem modificar ou pausar um smart contract) um ano depois, em março de 2024, ao desligar o sequenciador. Desde essa renúncia de chaves — o momento em que o contrato ficou realmente impossível de ser corrigido — até o exploit, passaram-se cerca de dois anos e três meses. A equipe fez o que a comunidade considera "o correto": permitir que ninguém, nem mesmo eles, pudesse tocá-lo. O problema é que o dinheiro continuava lá dentro. Este artigo analisa por que descontinuar um protocolo e deixá-lo imutável com fundos ativos não é segurança máxima, mas sim um bug latente transformado em bomba sem desativador, e o que deveria incluir um encerramento responsável.

O que aconteceu exatamente na Aztec Connect em 14 de junho?

Em 14 de junho de 2026, um atacante interagiu com o contrato RollupProcessor da Aztec Connect no Ethereum e extraiu, em uma única transação atômica (tudo ou nada, sem etapas intermediárias reversíveis), uma cesta de ativos avaliada em torno de 2,19 milhões de dólares. De acordo com o detalhamento publicado pela SlowMist (empresa de cibersegurança blockchain com sede na China, conhecida por suas análises forenses de hacks DeFi), o espólio incluía ETH, DAI, wstETH, LUSD e vários vaults da Yearn (yvDAI, yvWETH, yvLUSD). Os fundos passaram do contrato para um contrato-ponte intermediário e de lá para uma wallet externa controlada pelo atacante.

Um dado que convém sublinhar: ao fechamento das análises técnicas, e segundo a SlowMist, 100% dos fundos permaneciam intactos no endereço do atacante, sem que o processo de lavagem tivesse começado. Isso é relevante porque significa que não foi um roubo desesperado para movimentação rápida, mas a exploração tranquila de um alvo que estava há anos sem que ninguém o vigiasse.

A Aztec Labs e a Aztec Foundation confirmaram que o contrato explorado não tem nenhuma relação com o token AZTEC nem com os smart contracts da rede Aztec atual. O dano ficou confinado ao produto legacy. Mas o episódio não terminou aí: três dias depois, veio um segundo golpe.

Houve um segundo exploit e por que a cronologia importa?

Em 17 de junho de 2026, um segundo incidente afetou outro contrato legacy do ecossistema Aztec — descrito por várias fontes como um mecanismo de retirada de emergência (escapeHatch) de uma ponte de rollup privado também descontinuada. Os montantes relatados variam entre 2,15 e 2,21 milhões de dólares dependendo da fonte (a Coinpedia o estimou em cerca de 2,16 M$; a CryptoTimes, em cerca de 2,21 M$), ou seja, ~2,16 M$ de média entre as fontes. Somados aos 2,19 milhões do primeiro golpe, veículos como CoinJournal e NullTX estimaram as perdas em mais de 4 milhões de dólares em três dias através de dois sistemas legacy distintos.

A BlockSec (empresa de análise on-chain e auditoria de smart contracts) descreveu ambos os incidentes como ligados a "problemas de vinculação de public inputs" (como o contrato vincula os dados de entrada de uma prova criptográfica ao que realmente é liquidado), embora tenha esclarecido que os métodos de ataque não eram idênticos. A cronologia importa porque desenha um padrão: uma mesma equipe, vários contratos desligados anos atrás, todos impossíveis de corrigir, todos com saldo, caindo um após o outro em questão de dias. Não é má sorte; é o resultado previsível de uma decisão de design.

Nota de cautela: os números exatos do segundo incidente e o total agregado ainda não estavam consolidados entre todas as fontes até o fechamento deste artigo. Nós os tratamos como relatos atribuídos, não como um valor definitivo.

Por que um contrato descontinuado em 2023 ainda tinha milhões dentro?

Aqui está o paradoxo que dá sentido a todo o caso. A Aztec Connect era uma ponte que permitia aos usuários mover ativos para um ambiente privado sobre Ethereum e operar com eles. Quando a Aztec Labs decidiu pivotar para uma rede nova, anunciou o fechamento do produto em março de 2023, interrompeu os depósitos em 31 de março e abriu uma janela para que os usuários retirassem seus fundos. Apenas um ano depois, em março de 2024 — após o fechamento dessa janela —, desligou o sequenciador e renunciou às admin keys, congelando o contrato de forma definitiva.

Mas "abrir uma janela de retirada" não é o mesmo que "esvaziar o contrato". Sempre há usuários que não ficam sabendo, que perderam as chaves, que deram o dinheiro como perdido ou que simplesmente não agiram. Dois anos depois de selar a porta, esse remanescente — o dinheiro das pessoas que nunca voltaram — continuava depositado em um contrato que ninguém operava. No jargão, isso é TVL (total value locked, valor total bloqueado) órfão: capital vivo dentro de código morto.

• O produto estava morto: sem equipe designada, sem monitoramento ativo, sem novas auditorias.
• O dinheiro estava vivo: ETH, stablecoins e ativos com rendimento, perfeitamente extraíveis para quem encontrasse a falha.
• O contrato era imutável: nem a equipe nem ninguém podia retirar esse remanescente, pausá-lo ou corrigi-lo.

Essa combinação — desatenção + saldo + imutabilidade — é exatamente o que transforma um protocolo descontinuado em um alvo que melhora com o tempo. Quanto mais o tempo passa, menos olhos o vigiam e mais se esquece que o dinheiro continua lá.

Como funcionou o exploit do boundary gap?

Imagine um controle de segurança de aeroporto com 32 portões em fila, mas apenas um guarda que está fisicamente apenas no último. A regra do aeroporto diz que "todos os passageiros que passarem por estes portões ficam registrados como verificados". O sistema de registro, efetivamente, anota os 32 como verificados. Mas o guarda, na prática, só revisa quem cruza o seu portão. Os outros 31 portões ficam registrados como controlados sem que ninguém os controle de verdade.

Isso é, em essência, o que ocorreu. Em um sistema de ZK-rollup (uma tecnologia que agrupa muitas transações, gera uma prova criptográfica de que todas são válidas e a liquida no Ethereum), há duas peças que precisam coincidir:

• A prova criptográfica diz quantas operações são comprometidas ao novo estado. No contrato, esse número se relaciona com os slots de dados — 32 no total em cada lote.
• O contrato de liquidação no Ethereum (a camada L1, onde o dinheiro muda de mãos de verdade) percorre essas operações para mover os fundos e deveria verificar cada uma.

A falha, segundo a SlowMist e a BlockSec, foi uma discrepância entre ambos os intervalos: o que a prova comprometia como estado válido (o registro que diz "32 verificados") e o que o loop de liquidação da L1 verificava de verdade (o guarda que só olha um portão). O termo técnico é boundary gap: uma lacuna na fronteira entre a verificação off-chain da prova e a verificação on-chain da liquidação.

Na prática, o atacante conseguiu que 31 dos 32 slots fossem comprometidos ao estado L2 pela prova sem passar por nenhuma verificação de liquidação no contrato L1. Ele inseriu instruções de retirada por esses 31 portões "registrados, mas não controlados" e o contrato liberou os fundos acreditando que tudo estava validado. E como o contrato era imutável, não havia forma de fechar a porta uma vez descoberta.

O importante neste tipo de falha é que não é um erro grosseiro de programação, do estilo de um require esquecido ou uma função pública que deveria ser privada. É uma falha de design da fronteira: dois componentes que individualmente funcionam bem — a geração da prova e o loop de liquidação — mas cujas premissas sobre "o que conta como verificado" não coincidem exatamente. Essas lacunas nos limites são notoriamente difíceis de detectar em auditoria porque cada peça parece correta separadamente; o buraco só aparece quando são analisadas juntas e sob uma transação construída propositalmente. Por isso a SlowMist insiste em auditar a consistência lógica da borda L1/L2 e a verificação secundária on-chain dos public inputs como uma categoria de risco própria, não como um detalhe a mais do código.

Por que renunciar às admin keys pode ser um erro?

Esta é a tese incômoda do artigo. A intuição dominante em cripto é que renunciar às admin keys equivale à segurança máxima: "ninguém pode tocar no contrato, nem mesmo a equipe, então ninguém pode roubar nem censurar". Para um protocolo de privacidade, além disso, tem um apelo ideológico forte: a ausência de um administrador é a prova de que não há porta dos fundos.

O problema é que a imutabilidade é uma faca de dois gumes. Imutável também significa impossível de corrigir. Renunciar às chaves elimina o risco de um administrador malicioso (ou comprometido) roubar os fundos, mas em troca elimina também a única ferramenta para reagir quando aparece um bug. E código sem bugs não existe; existe código com bugs que ainda não foram encontrados.

Enquanto um protocolo está vivo, essa aposta pode fazer sentido: há uma equipe vigiando, uma comunidade, auditorias, bug bounties. Mas um protocolo descontinuado perde tudo isso e conserva o pior: o saldo e a impossibilidade de agir. Renunciar às chaves sem ter esvaziado primeiro os fundos não é entregar as chaves de um cofre vazio; é soldar a porta de um cofre cheio e jogar fora o maçarico. No dia em que alguém descobre como abri-lo por um lado, não há ninguém com autoridade — nem capacidade técnica — para defendê-lo.

O caso espelhado demonstra isso pelo outro extremo. No final de maio de 2026, os lockers legacy da DxSale (plataforma de lançamento de tokens e bloqueio de liquidez na BNB Chain) perderam cerca de 7,3 milhões de dólares, mas pelo motivo oposto: as admin keys não haviam sido renunciadas, foram transferidas silenciosamente meses antes e houve abuso delas para esvaziar mais de 1.400 pools. A Aztec renunciou às chaves e foi roubada por um bug; a DxSale conservou as chaves e foi roubada pelas chaves. O fator comum não são as chaves: é o dinheiro que ficou dentro de um sistema que ninguém mais cuidava. O vetor muda; a causa raiz é a mesma.

Como se compara com outros casos de "código morto"?

A Aztec Connect não é o primeiro protocolo legacy que sangra anos depois de morrer. A tabela resume três episódios recentes de 2026 onde o denominador comum é capital vivo em infraestrutura desatendida, com vetores distintos.

A leitura cruzada é a que dá a manchete: tanto renunciar às chaves (Aztec) quanto conservá-las mal custodiadas (DxSale) terminam no mesmo resultado quando há saldo em um sistema que ninguém opera. A governança das chaves é secundária; o erro primário é não ter retirado os fundos ao encerrar. Um contrato descontinuado e vazio não aparece em nenhuma lista de alvos.

Há também um viés temporal que agrava o caso dos contratos imutáveis frente ao dos administradores comprometidos. Um contrato com administrador vivo recebe correções, rotações de chaves e vigilância enquanto alguém o opera; sua superfície de ataque pode diminuir com o tempo. Um contrato imutável e descontinuado faz o contrário: sua superfície de ataque só cresce, porque o código é congelado no dia do fechamento enquanto as técnicas de análise e as ferramentas dos atacantes continuam melhorando ano após ano. O contrato da Aztec Connect era, em 2026, exatamente tão seguro quanto quando foi congelado em março de 2024 — mas o mundo ao seu redor era muito melhor em encontrar falhas. O tempo joga contra o código que não pode mudar.

Como um protocolo deveria ser descontinuado de forma responsável?

O setor trata o "descontinuar e esquecer" como uma operação neutra: anuncia-se o fechamento, abre-se uma janela de retirada e dá-se por encerrado. Mas enquanto houver saldo, o protocolo continua sendo um passivo de segurança. Um encerramento responsável — um sunset bem feito — deveria tratar o remanescente como o problema central, não como um detalhe.

• Retirada forçada do remanescente: conservar a capacidade técnica de varrer os fundos não reclamados (para um contrato de custódia, para um multisig da fundação — um contrato que exige várias assinaturas para mover fundos, sem ponto único de falha — ou para um mecanismo de reclamação posterior) antes de selar a porta. Um contrato vazio é imune por definição.
• Renúncia às chaves depois, não antes: a imutabilidade como último passo, uma vez que o TVL esteja em zero ou em um mínimo aceitável, não como gesto simbólico no dia do anúncio.
• Botão de pausa conservado durante a transição: manter um botão de pausa (pause button: uma função que congela o contrato sem permitir mover fundos) com time-lock (um atraso público antes que qualquer ação surta efeito) enquanto durar a janela, para poder congelar o contrato se aparecer uma falha sem poder mover fundos arbitrariamente.
• Auditoria do estado de fechamento: auditar especificamente o caminho de retirada de emergência e as bordas L1/L2, que foi exatamente onde ambos os contratos da Aztec falharam.
• Monitoramento post-mortem: se por design não for possível agir, ao menos vigiar o contrato morto e avisar publicamente sobre o saldo residual, para que o risco seja explícito e não uma mina enterrada.

A SlowMist, em sua própria análise, recomenda exatamente isso para contratos descontinuados que ainda custodiam ativos: migração ordenada ou destruição dos fundos para eliminar a exposição contínua. A lição não é "não renuncie às chaves"; é "não deixe dinheiro atrás de uma porta que você decide não poder mais abrir".

Quais lições ficam para o leitor?

Para quem usa DeFi, o episódio deixa uma diretriz concreta: quando um protocolo anuncia que vai fechar, a janela de retirada é o único momento em que o sistema ainda tem quem cuide dele, e um saldo esquecido em um contrato descontinuado não está "guardado", mas sim exposto e sem ninguém capaz de defendê-lo. A intuição a ser corrigida é equiparar "imutável" com "seguro": a imutabilidade protege contra o administrador malicioso, mas te deixa indefeso perante o bug sem correção, e em um protocolo morto — sem vigilância e com dinheiro dentro — ocorre a pior combinação possível. Por isso, a recomendação que a SlowMist extrai do caso não é "não renuncie às chaves", mas sim migrar ou destruir os ativos dos contratos legacy que ainda custodiam fundos antes de selar a porta: "protocolo morto, dinheiro vivo" continua sendo uma das superfícies de ataque pior gerenciadas de DeFi precisamente porque se disfarça de boa prática.

Fontes e links: SlowMist — análise técnica do exploit · NewsBTC — risco de cauda longa dos contratos descontinuados · Cryptopolitan · CoinJournal — segundo incidente · Crypto Briefing · Rekt News — DxSale