Le 16 janvier 2025, SSP Wallet v1.9.0 conclut une revue de sécurité de plusieurs semaines menée avec Halborn sur les contrats Solidity d'Account Abstraction de SSP — le Factory et l'Account Implementation derrière chaque adresse Ethereum et Sepolia. L'audit est revenu propre sur ce qui compte, avec seulement trois constats Informatifs et deux de priorité Faible, tous dans du code inutilisé ou mort. Nous avons malgré tout choisi de traiter chacun d'eux, de redéployer les contrats et de livrer les versions plus propres dans v1.9.0. Ce redéploiement est un changement incompatible pour les utilisateurs Ethereum et Sepolia : votre adresse déterministe sur ces deux chaînes changera après la mise à jour.
TL;DR
- Halborn a audité la partie Solidity de l'Account Abstraction de SSP : les contrats Factory et Account Implementation.
- Constats : 3 Informatifs, 2 Faibles, 0 Moyen, 0 Élevé. Tous dans des chemins de code inutilisés ou morts. Les contrats déjà déployés étaient et restent sécurisés.
- Nous avons redéployé tout de même pour garder une base de code entièrement propre — de nouveaux contrats Factory et Account Implementation arrivent dans v1.9.0.
- Changement incompatible : les adresses Ethereum et Sepolia changent après la mise à jour. Déplacez vos fonds avant de mettre à jour, ou contactez le support SSP pour un guide de migration.
- Les chaînes UTXO — Bitcoin, Zcash, Bitcoin Cash, Flux — ne sont pas concernées.
Ce que Halborn a audité
Le périmètre était la partie Solidity des contrats ERC-4337 à multisig Schnorr que nous avons livrés dans v1.6.0 et itérés depuis. Concrètement : le dépôt @runonflux/account-abstraction — le contrat Factory qui déploie de manière déterministe un compte lorsqu'un utilisateur transige pour la première fois, et le contrat Account Implementation qui définit comment ce compte valide les UserOperations, vérifie les signatures Schnorr et suit le flux bundler-et-EntryPoint d'ERC-4337.
L'équipe technique de Halborn a exécuté la batterie complète de tests qu'elle réserve aux contrats intelligents de production. Le dépôt est, selon leurs termes, solide, respecte les recommandations d'ERC-4337 et implémente Schnorr proprement. Cette conclusion compte parce que l'implémentation Schnorr est la partie de la conception avec le plus petit corpus d'art antérieur — toutes les autres pièces de la pile AA ont été auditées de nombreuses fois dans l'industrie, mais des signatures Schnorr agrégées à l'intérieur d'un validateur ERC-4337, c'est quelque chose que nous avons construit nous-mêmes.
Ce qu'ils ont trouvé
Le rapport contient 3 constats Informatifs et 2 de priorité Faible — aucun Moyen, aucun Élevé, aucun Critique. Vous pouvez lire le rapport complet sur halborn.com/audits/influx-technologies/account-abstraction-schnorr-multisig.
Chaque constat se situe dans du code qui était soit inutilisé dans les contrats en production, soit dans un chemin qui ne s'exécutait pas contre de vrais fonds d'utilisateurs — échafaudage défensif, branches résiduelles d'une itération antérieure, ce genre de choses. Aucun ne décrit un moyen pour un attaquant de prendre des fonds, de falsifier une signature ou de casser un compte. Les contrats déployés sur Ethereum mainnet sont restés entièrement sécurisés pendant et après la fenêtre d'audit.
Pourquoi nous avons redéployé malgré tout
Deux raisons. D'abord, une base de code propre est en soi une forme de sécurité. Du code mort qui compile dans un contrat déployé est du code mort que les futurs auditeurs, intégrateurs et contributeurs devront comprendre. Le retirer réduit la surface que toute revue future devra examiner — moins de branches, moins d'hypothèses, moins de manières de mal lire le contrat.
Ensuite, quand on a la chance de livrer la version qui traite chaque constat plutôt que celle qui les reporte, on la livre. C'est ce que nous avons fait. v1.9.0 est livré contre des contrats Factory et Account Implementation tout juste déployés qui intègrent chaque recommandation de Halborn. La branche stable du dépôt @runonflux/account-abstraction est désormais main (npm ^1.1.0) ; la branche master et npm ~1.0.0 restent disponibles pour qui souhaite rester sur les anciens contrats déployés.
Le CHANGEMENT INCOMPATIBLE pour les utilisateurs Ethereum et Sepolia
Comme le Factory est ce qui dérive de manière déterministe l'adresse de votre compte à partir de vos clés publiques, redéployer le Factory signifie que les mêmes clés dérivent une adresse différente. Pour les utilisateurs avec des fonds sur Ethereum mainnet ou Sepolia, c'est l'impact pratique de v1.9.0 : après la mise à jour, l'adresse que SSP vous affiche pour Ethereum ou Sepolia est une nouvelle. Tout ETH ou ERC-20 présent sur l'ancienne adresse ne bougera pas tout seul.
Il y a deux façons sûres de gérer cela. La voie simple est de déplacer vos fonds hors de l'ancienne adresse avant la mise à jour — envoyez-les vers un autre portefeuille ou un exchange, mettez à jour, puis renvoyez-les vers votre nouvelle adresse. L'autre voie, pour les utilisateurs ayant déjà mis à jour ou ayant des positions plus grandes ou plus complexes, est de contacter le support SSP pour un guide de migration afin que nous vous accompagnions pour récupérer les anciens fonds avec les anciens contrats.
Les chaînes UTXO ne sont pas concernées. Les adresses Bitcoin, Zcash, Bitcoin Cash et Flux sont dérivées de vos clés sans passer par un contrat EVM, donc v1.9.0 ne change pas ces adresses. Seuls Ethereum et Sepolia sont concernés.
Et la suite
Cet article couvre spécifiquement l'audit des contrats AA, le jour de sa publication. La perspective plus large — l'ensemble des revues Halborn sur le SSP Wallet, les contrats et le SDK — est exposée dans Au cœur des audits Halborn de SSP en 2025, qui replace cet audit dans le contexte des deux autres.
Source : Notes de version SSP Wallet v1.9.0.