Na semana passada, um investigador de segurança revelou um caso alarmante: numa atualização de carteira em 24 de dezembro, foi inserido um backdoor que levou à exposição de dados de privacidade dos utilizadores (incluindo a frase-semente), resultando em perdas superiores a 2 milhões de dólares.

Este incidente pareceu inicialmente novo, mas, ao pensar bem, reflete um problema antigo das carteiras de uma geração — os utilizadores não têm controlo real sobre os limites de segurança.

**Qual é o verdadeiro risco das carteiras plugin**

Muitas pessoas, ao discutir este tipo de incidente, tendem a culpar os utilizadores: "Será que importaram a frase-semente? Foi um erro de clique?" Mas, do ponto de vista do design do produto, o problema não está aí. O risco principal está no próprio mecanismo de atualização automática.

As carteiras plugin têm uma realidade inescapável:

Cada atualização automática é, na prática, uma autorização total para os seus ativos.

Contanto que o código na atualização seja comprometido — seja por um problema interno ou, mais frequentemente, por um ataque à cadeia de fornecimento (injeção no processo CI/CD, ambiente de build, canais de distribuição invadidos) — uma lógica maliciosa pode ser executada sem que o utilizador perceba. E o utilizador nem sequer consegue detectar.

Mais preocupante ainda: esse risco não se limita ao cenário de carteiras quentes. Mesmo que utilize apenas um plugin para conectar uma carteira de hardware, o risco permanece. Porque o plugin controla:

- O conteúdo das transações que vê
- Os endereços de receção que confirma
- Todas as informações exibidas antes e depois de assinar

A carteira de hardware garante que a "chave privada nunca sai do chip", mas não garante que a transação que assina seja a que pensa estar a assinar. Se o plugin tiver intenções maliciosas, pode fazer com que assine uma coisa, enquanto na blockchain executa outra.

**Por que isto se tornou um problema sistémico**

A raiz do problema está na centralização do controlo de atualizações. Depois de instalar um plugin, o utilizador entrega toda a segurança ao equipa de desenvolvimento. Essa equipa pode ser confiável, mas qualquer falha na infraestrutura, no processo de publicação ou nos computadores dos funcionários pode levar a uma perda massiva de ativos.

E o utilizador fica completamente passivo — não consegue ver o que foi atualizado nem recusar uma versão específica.

Por isso, toda a comunidade Web3 começou a reavaliar o design da arquitetura das carteiras. Alguns projetos estão a explorar mecanismos de atualização baseados em separação de chaves, verificáveis pelo utilizador, ou até arquiteturas com prioridade local — com o objetivo de dar ao utilizador controlo real sobre a segurança dos seus ativos, em vez de confiar cegamente.