Il 16 gennaio 2025, SSP Wallet v1.9.0 chiude una revisione di sicurezza durata diverse settimane con Halborn sui contratti Solidity di Account Abstraction di SSP — il Factory e l'Account Implementation dietro ogni indirizzo Ethereum e Sepolia. L'audit è risultato pulito sulle cose che contano, con solo tre risultati Informativi e due di priorità Bassa, tutti in codice inutilizzato o morto. Abbiamo comunque scelto di trattarli tutti, redeployare i contratti e rilasciare le versioni più pulite in v1.9.0. Quel redeploy è un cambiamento incompatibile per gli utenti Ethereum e Sepolia: il vostro indirizzo deterministico su queste due catene cambierà dopo l'aggiornamento.
TL;DR
- Halborn ha auditato la parte Solidity di Account Abstraction di SSP: i contratti Factory e Account Implementation.
- Risultati: 3 Informativi, 2 Bassi, 0 Medi, 0 Alti. Tutti in percorsi di codice inutilizzati o morti. I contratti precedentemente distribuiti erano e restano sicuri.
- Abbiamo redeployato comunque per mantenere una codebase del tutto pulita — nuovi contratti Factory e Account Implementation arrivano in v1.9.0.
- Cambiamento incompatibile: gli indirizzi Ethereum e Sepolia cambiano dopo l'aggiornamento. Spostate i fondi prima di aggiornare o contattate il supporto SSP per una guida di migrazione.
- Le catene UTXO — Bitcoin, Zcash, Bitcoin Cash, Flux — non sono interessate.
Cosa ha auditato Halborn
L'ambito era la parte Solidity dei contratti ERC-4337 con multisig Schnorr che abbiamo rilasciato in v1.6.0 e iterato da allora. Concretamente: il repository @runonflux/account-abstraction — il contratto Factory che distribuisce in modo deterministico un account quando un utente effettua la prima transazione, e il contratto Account Implementation che definisce come quell'account convalida le UserOperations, verifica le firme Schnorr e segue il flusso bundler-e-EntryPoint di ERC-4337.
Il team tecnico di Halborn ha eseguito la batteria completa di test che riserva ai contratti intelligenti di produzione. Il repository, nelle loro parole, è robusto, rispetta le raccomandazioni ERC-4337 e implementa Schnorr in modo pulito. Quella conclusione conta perché l'implementazione Schnorr è la parte del design con il minor corpus di arte precedente — ogni altra parte dello stack AA è stata auditata molte volte nell'industria, ma le firme Schnorr aggregate dentro un validatore ERC-4337 sono qualcosa che abbiamo costruito noi.
Cosa hanno trovato
Il report contiene 3 risultati Informativi e 2 di priorità Bassa — nessun Medio, nessun Alto, nessun Critico. Potete leggere il report completo su halborn.com/audits/influx-technologies/account-abstraction-schnorr-multisig.
Ogni risultato si trova in codice che era inutilizzato sui contratti in produzione o faceva parte di un percorso che non veniva eseguito contro fondi reali degli utenti — impalcatura difensiva, rami residui di un'iterazione precedente, quel tipo di cose. Nessuno descrive un modo per un attaccante di prelevare fondi, falsificare una firma o rompere un account. I contratti distribuiti su Ethereum mainnet sono rimasti pienamente sicuri durante e dopo la finestra di audit.
Perché abbiamo redeployato comunque
Due motivi. Primo, una codebase pulita è di per sé una forma di sicurezza. Codice morto che compila in un contratto distribuito è codice morto su cui futuri auditor, integratori e contributori devono ragionare. Tagliarlo riduce la superficie che ogni revisione futura dovrà esaminare — meno rami, meno assunzioni, meno modi di leggere male il contratto.
Secondo, quando hai l'occasione di rilasciare la versione che tratta ogni risultato invece di quella che li rimanda, lo fai. E così è stato. v1.9.0 viene rilasciato contro contratti Factory e Account Implementation appena distribuiti che incorporano ogni raccomandazione di Halborn. Il ramo stabile del repository @runonflux/account-abstraction è ora main (npm ^1.1.0); il ramo master e npm ~1.0.0 restano disponibili per chi desidera restare sui vecchi contratti distribuiti.
Il CAMBIAMENTO INCOMPATIBILE per gli utenti Ethereum e Sepolia
Poiché il Factory è ciò che deriva in modo deterministico l'indirizzo del vostro account dalle vostre chiavi pubbliche, redeployare il Factory significa che le stesse chiavi derivano un indirizzo diverso. Per gli utenti con fondi su Ethereum mainnet o Sepolia, questo è l'impatto pratico di v1.9.0: dopo l'aggiornamento, l'indirizzo che SSP mostra per Ethereum o Sepolia è nuovo. Eventuali ETH o ERC-20 presenti sul vecchio indirizzo non si sposteranno da soli.
Ci sono due modi sicuri di gestirlo. La via diretta è spostare i fondi fuori dal vecchio indirizzo prima di aggiornare — inviateli a un altro wallet o exchange, poi aggiornate e poi inviateli al vostro nuovo indirizzo. L'altra via, per utenti che hanno già aggiornato o che hanno posizioni più grandi o complesse, è contattare il supporto SSP per una guida di migrazione così possiamo accompagnarvi nel recupero dei vecchi fondi con i vecchi contratti.
Le catene UTXO non sono interessate. Gli indirizzi Bitcoin, Zcash, Bitcoin Cash e Flux derivano dalle vostre chiavi senza passare attraverso un contratto EVM, quindi v1.9.0 non cambia quegli indirizzi. Sono coinvolti solo Ethereum e Sepolia.
Cosa arriverà
Questo articolo copre specificamente l'audit dei contratti AA, nel giorno del rilascio. La storia più ampia — l'insieme completo delle revisioni Halborn su SSP Wallet, contratti e SDK — è raccontata in Dentro gli audit Halborn di SSP nel 2025, che inquadra questo audit nel contesto degli altri due.