Dreno de US$ 600 mil na Avici: o que aconteceu e como agir

O caso Avici começou em 28 de agosto de 2026, quando transações suspeitas indicaram que mais de US$ 600 mil haviam saído de contas usadas como garantia dos cartões. À medida que os fundos eram rastreados na blockchain, algumas estimativas passaram de US$ 1 milhão. Mais tarde, a parceira de emissão de cartões da Avici, a Rain, identificou uma vulnerabilidade em uma versão antiga de um contrato de cartões na Solana e informou que os contratos afetados haviam sido atualizados. Por isso, as primeiras estimativas não devem ser tratadas automaticamente como o prejuízo final. 49 50 53

A distinção mais importante é entre as carteiras autocustodiadas comuns da Avici e os contratos separados usados para manter os saldos dos cartões. As informações divulgadas posteriormente indicaram que o incidente atingiu esses contratos de cartão, e não necessariamente a infraestrutura das carteiras usadas para guardar outros ativos em Solana ou em redes EVM. 50 53

Como a Avici transformava cripto em poder de compra na Visa

A Avici oferecia um modelo de cartão com garantia em cripto, diferente de uma conta bancária tradicional. Segundo a documentação da empresa, o fluxo funcionava assim:

1. O usuário depositava USDC em um contrato inteligente de garantia de empréstimo.
2. O depósito gerava um saldo de crédito em dólares para o cartão.
3. Cada compra reduzia esse saldo de crédito.
4. O USDC correspondente aos gastos era posteriormente liquidado a partir do contrato, em geral com atraso de um a dois dias ou, em alguns casos, de até uma semana. 35

A documentação também afirmava que o contrato de garantia era implantado em uma rede EVM, mas podia receber depósitos originados na Solana por meio de uma ponte automática operada nos bastidores. O cartão ficava separado da carteira inteligente, e a Visa só poderia retirar fundos depois de comprovar que uma compra havia sido realizada. 33

Esse desenho explica tanto o apelo quanto o risco do produto. O usuário podia gastar contra suas criptomoedas sem entregar toda a carteira a uma corretora centralizada ou a um banco. Mas, para isso, os recursos entravam em um sistema programável que envolvia contratos inteligentes, pontes entre redes, infraestrutura do emissor do cartão e mecanismos de autorização de transações.

Em outras palavras, “autocustódia” não significava que todos os componentes do fluxo de pagamento eram igualmente simples, independentes ou livres de riscos.

O que aconteceu — e o que mudou com as novas informações?

As primeiras horas: um problema de saque nos saldos dos cartões

Em 28 de agosto, a Avici reconheceu um problema que afetava saques de saldos dos cartões, enquanto observadores on-chain registravam movimentações para endereços controlados por um possível invasor. As reportagens iniciais indicaram valores entre aproximadamente US$ 600 mil e US$ 653 mil. Outros rastreamentos chegaram a apontar mais de US$ 1 milhão na carteira associada ao suspeito. Essas cifras podem corresponder a fases ou fluxos diferentes e não devem ser somadas sem uma reconciliação. 49 51 54 58

Naquele momento, as informações públicas não permitiam determinar se a causa estava:

• em uma falha no contrato de cartões ou de garantia;
• em um mecanismo comprometido de autorização, retransmissão ou registro de administradores;
• em passkeys, sessões ou abstração de contas;
• em phishing e transações maliciosas assinadas pelos próprios usuários; ou
• em outro componente da plataforma, como front-end, back-end, ponte ou parceiro emissor.

Atualização posterior: Rain apontou uma versão antiga do contrato de cartões

Uma atualização posterior atribuiu o incidente à descoberta, pela Rain, de uma vulnerabilidade em uma versão antiga do contrato de cartões na Solana usado pela Avici e por alguns outros projetos. Os contratos relevantes teriam sido atualizados, e não havia novos movimentos não autorizados detectados no momento da divulgação. A mesma atualização afirmou que o problema ficou restrito ao contrato separado da Solana que armazenava os saldos dos cartões após os depósitos, enquanto as carteiras autocustodiadas dos usuários em Solana e em redes EVM permaneciam segregadas. 50 62

Depois, foi divulgada uma perda reconciliada de US$ 500.859,22, afetando 1.685 usuários, com promessa de reembolso integral pela Avici. 53 Esse valor é mais específico do que as estimativas feitas durante o ataque, mas ainda é importante separar os números provisórios, calculados em tempo real na blockchain, da posterior reconciliação reportada.

Por que os relatos de phishing continuam relevantes

A explicação sobre o contrato não elimina o risco separado de phishing. Em 28 de agosto, relatos descreveram sites falsos que imitavam a Avici e usavam supostos airdrops ou recursos da plataforma para convencer usuários a conectar suas carteiras e autorizar transações maliciosas. Essas reportagens atribuíram mais de US$ 600 mil em perdas a um site que se passava pela Avici e disseram que, naquele momento, não havia evidência pública de uma invasão interna da plataforma. 2 4

As duas explicações não são necessariamente incompatíveis. Uma vulnerabilidade no contrato pode ter afetado contas de saldo dos cartões ao mesmo tempo que uma campanha independente de falsificação drenava carteiras de pessoas que assinaram transações maliciosas.

Sem um relatório completo que relacione endereços, contratos, instruções de transação e horários, é arriscado afirmar que todas as perdas divulgadas tiveram a mesma causa.

O que ainda precisa ser documentado

O registro público disponível ainda deixa perguntas técnicas importantes em aberto, entre elas:

• qual era exatamente a versão vulnerável do contrato e quais eram seus endereços de implantação;
• qual instrução ou sequência de transações permitiu o ataque;
• se houve obtenção indevida de privilégios administrativos ou abuso de outro mecanismo de autorização;
• quais contas e saldos foram afetados;
• como a atividade foi detectada e quanto tempo levou para os contratos serem atualizados;
• como funcionará o reembolso e qual será seu alcance; e
• se algum usuário precisa trocar passkeys, sessões, autoridades delegadas ou credenciais de carteira.

A atribuição posterior feita pela Rain é uma explicação relevante para o incidente dos saldos dos cartões. Ela, porém, não autoriza concluir que todos os drenos relacionados à Avici tenham sido causados pela mesma vulnerabilidade. Para resolver essa questão, seria necessário um relatório técnico detalhado, verificável e idealmente revisado por terceiros.

O que usuários afetados devem fazer agora

1. Pare de usar links e contratos suspeitos

Não interaja com a Avici nem com contratos relacionados aos cartões por meio de links recebidos em mensagens diretas, anúncios, respostas em redes sociais ou supostos airdrops. Enquanto os detalhes da correção são confirmados, use um domínio oficial salvo nos favoritos ou um canal de suporte verificado de forma independente.

2. Diferencie um problema de autorização de uma exposição da chave

Se você informou uma frase de recuperação, expôs uma chave privada, instalou uma extensão de carteira não confiável ou assinou uma transação desconhecida, transfira os ativos restantes para uma carteira recém-criada, usando um dispositivo ou ambiente de carteira limpo.

Revogar permissões não corrige uma frase-semente ou uma chave de assinatura comprometida.

3. Revise as permissões em cada rede

Em carteiras EVM, verifique as permissões de tokens e remova aprovações desconhecidas ou ilimitadas. Também procure chaves de sessão, autoridades delegadas ou permissões suspeitas de abstração de contas, quando a carteira oferecer esses recursos.

Em carteiras Solana, revise transações assinadas recentemente, aplicativos conectados, delegações desconhecidas e sessões ativas. A Solana não usa exatamente o mesmo modelo de aprovações das redes EVM; portanto, uma ferramenta genérica de “revogação de aprovações” pode não localizar todas as autorizações relevantes.

4. Preserve as evidências

Guarde endereços de carteira, assinaturas de transação, URLs suspeitas, capturas de tela, horários e a mensagem ou anúncio que levou à interação. Esses dados podem ajudar a equipe autenticada de suporte da Avici, o provedor da carteira ou investigadores a diferenciar phishing de um evento no nível do contrato.

5. Espere golpes de segunda etapa

Não assine uma transação de “verificação”, “reembolso” ou “recuperação” enviada por uma conta não solicitada. Pessoas que já foram identificadas como vítimas costumam ser alvos de impostores que prometem devolver os fundos roubados.

O que o caso revela sobre a autocustódia

A autocustódia muda o modelo de risco — não elimina o risco. O usuário pode evitar que uma instituição centralizada tenha controle unilateral dos ativos, mas ainda fica exposto a software de carteira, lógica de contratos inteligentes, pontes, retransmissores, passkeys, permissões delegadas, interfaces, emissores de cartões e processos de liquidação.

O roubo envolvendo a Coldcard em 2026 ajuda a mostrar a diferença entre esses cenários. Naquele caso, reportagens descreveram aproximadamente 594 BTC retirados de cerca de 500 carteiras em aproximadamente 25 minutos, depois que um problema de firmware enfraqueceu a aleatoriedade usada na geração das sementes das carteiras. A falha estava no dispositivo e no firmware, não na criptografia subjacente do Bitcoin. 30

A Avici representa uma classe diferente de falha: um produto de pagamentos pode manter a carteira geral sob controle do usuário e, ainda assim, colocar a garantia do cartão em um sistema especializado de contratos, com dependências próprias. A Coldcard destaca riscos de hardware e geração de chaves; a Avici destaca riscos de contratos, autorizações, interfaces e infraestrutura de parceiros.

Relatos sobre vulnerabilidades no Core Lightning também lembram que softwares de protocolo ou de nós podem introduzir riscos mesmo quando as chaves privadas continuam sob controle do usuário. No material disponível, porém, não há evidência suficiente para ligar tecnicamente ou operacionalmente qualquer problema do Core Lightning ao incidente da Avici.

A lição prática não é que a autocustódia seja necessariamente insegura, nem que a custódia centralizada seja automaticamente mais segura. É que a segurança de um produto de pagamentos autocustodiado depende de todo o caminho da transação.

Antes de usar um serviço desse tipo, o usuário deve saber quais ativos permanecem na carteira comum, quais são transferidos para um contrato de cartão ou garantia, quem pode autorizar saques, como as atualizações são governadas e o que acontece quando um parceiro ou contrato falha.