Em 16 de janeiro de 2025, o SSP Wallet v1.9.0 encerra uma revisão de segurança de várias semanas com a Halborn sobre os contratos Solidity de Account Abstraction do SSP — o Factory e o Account Implementation por trás de cada endereço de Ethereum e Sepolia. A auditoria saiu limpa no que importa, com apenas três achados Informacionais e dois de prioridade Baixa, todos em código não utilizado ou morto. Ainda assim, escolhemos tratar cada um deles, redeployar os contratos e enviar as versões mais limpas no v1.9.0. Esse redeploy é uma mudança incompatível para usuários de Ethereum e Sepolia: o seu endereço determinístico nessas duas cadeias mudará após a atualização.
TL;DR
- A Halborn auditou a parte Solidity do Account Abstraction do SSP: os contratos Factory e Account Implementation.
- Achados: 3 Informacionais, 2 Baixos, 0 Médios, 0 Altos. Todos em caminhos de código não usados ou mortos. Os contratos antes implantados eram e continuam seguros.
- Redeployamos mesmo assim para manter o código totalmente limpo — novos contratos Factory e Account Implementation chegam no v1.9.0.
- Mudança incompatível: endereços de Ethereum e Sepolia mudam após a atualização. Mova os fundos antes de atualizar ou contate o suporte do SSP para um guia de migração.
- As cadeias UTXO — Bitcoin, Zcash, Bitcoin Cash, Flux — não são afetadas.
O que a Halborn auditou
O escopo foi a parte Solidity dos contratos ERC-4337 com multisig Schnorr que entregamos no v1.6.0 e iteramos desde então. Concretamente: o repositório @runonflux/account-abstraction — o contrato Factory que implanta deterministicamente uma conta quando o usuário transaciona pela primeira vez, e o contrato Account Implementation que define como essa conta valida UserOperations, verifica as assinaturas Schnorr e segue o fluxo bundler-e-EntryPoint do ERC-4337.
A equipe técnica da Halborn executou a bateria completa de testes que reservam para contratos inteligentes em produção. O repositório, nas palavras deles, é robusto, respeita as recomendações do ERC-4337 e implementa Schnorr de forma limpa. Essa conclusão importa porque a implementação Schnorr é a parte do design com menor base de arte prévia — todas as outras peças da pilha de AA já foram auditadas muitas vezes no setor, mas assinaturas Schnorr agregadas dentro de um validador ERC-4337 são algo que nós mesmos construímos.
O que encontraram
O relatório contém 3 achados Informacionais e 2 de prioridade Baixa — nenhum Médio, nenhum Alto, nenhum Crítico. Você pode ler o relatório completo em halborn.com/audits/influx-technologies/account-abstraction-schnorr-multisig.
Todos os achados estão em código que estava sem uso nos contratos em produção ou que fazia parte de um caminho que não executava contra fundos reais de usuários — andaime defensivo, ramos residuais de uma iteração anterior, esse tipo de coisa. Nenhum descreve uma forma de um atacante tomar fundos, forjar uma assinatura ou quebrar uma conta. Os contratos implantados na Ethereum mainnet permaneceram totalmente seguros durante a janela da auditoria e depois.
Por que redeployamos mesmo assim
Dois motivos. Primeiro, uma base de código limpa é em si uma forma de segurança. Código morto que compila num contrato implantado é código morto que futuros auditores, integradores e contribuidores precisam compreender. Cortá-lo reduz a superfície que qualquer revisão futura precisará examinar — menos ramos, menos suposições, menos formas de ler errado o contrato.
Segundo, quando você tem a chance de enviar a versão que trata cada achado em vez da versão que os adia, você a envia. Foi o que fizemos. O v1.9.0 é entregue contra contratos Factory e Account Implementation recém-implantados que incorporam cada recomendação da Halborn. A branch estável do repositório @runonflux/account-abstraction agora é main (npm ^1.1.0); a branch master e o npm ~1.0.0 ficam disponíveis para quem desejar permanecer nos contratos antigos.
A MUDANÇA INCOMPATÍVEL para usuários de Ethereum e Sepolia
Como o Factory é o que deriva deterministicamente o endereço da sua conta a partir das suas chaves públicas, redeployar o Factory significa que as mesmas chaves derivam um endereço diferente. Para usuários com fundos na Ethereum mainnet ou na Sepolia, este é o impacto prático do v1.9.0: após atualizar, o endereço que o SSP mostra para Ethereum ou Sepolia é um novo. Qualquer ETH ou ERC-20 que esteja no endereço antigo não se moverá sozinho.
Há duas formas seguras de lidar com isso. O caminho direto é mover seus fundos para fora do endereço antigo antes de atualizar — envie-os para outra carteira ou exchange, depois atualize e então envie para o seu novo endereço. A outra via, para usuários que já atualizaram ou que têm posições maiores ou mais complexas, é contatar o suporte do SSP para um guia de migração para que possamos orientá-lo a recuperar os fundos antigos com os contratos antigos.
Cadeias UTXO não são afetadas. Endereços de Bitcoin, Zcash, Bitcoin Cash e Flux derivam das suas chaves sem passar por um contrato EVM, então o v1.9.0 não altera esses endereços. Apenas Ethereum e Sepolia estão envolvidos.
Mais por vir
Este artigo cobre especificamente a auditoria dos contratos de AA, em seu dia de lançamento. A história maior — o conjunto completo de revisões da Halborn sobre o SSP Wallet, os contratos e o SDK — está detalhada em Por dentro das auditorias da Halborn no SSP em 2025, que coloca esta auditoria em contexto com as outras duas.