À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.
Réponse directe
Un module activé constitue une voie d’autorisation distincte. Dans un compte intelligent de type Safe, un module approuvé peut appeler execTransactionFromModule et exécuter un CALL ou DELEGATECALL sans recueillir, pour cette action, les signatures M-sur-N habituelles des propriétaires. Le seuil affiché ne décrit donc qu’une voie d’exécution, pas toute la frontière de sécurité du compte.
Les modules permettent des automatisations utiles comme les plafonds de dépense, paiements périodiques, récupérations et opérations de protocole. Leur pouvoir peut néanmoins être vaste : le contrat Safe officiel indique que les modules activés peuvent exécuter des transactions arbitraires et avertit qu’un module malveillant peut prendre le contrôle d’un Safe. Examinez chaque module activé, et pas seulement les propriétaires et le seuil.
Fonctionnement
Les propriétaires autorisent d’abord enableModule par une transaction Safe normale. Le compte inscrit le module dans son registre des modules activés. Ensuite, le module valide lui-même l’appelant et ses règles, puis appelle execTransactionFromModule ; le compte vérifie que l’appelant est activé et exécute l’opération demandée. La sécurité dépend alors aussi du code, de la configuration, des administrateurs, des clés de mise à niveau et des dépendances externes du module.
Un Guard de transaction et un Module Guard sont des contrôles distincts. Le premier vérifie les appels execTransaction ordinaires, le second les appels initiés par les modules. Un Guard peut refuser une exécution, mais un Guard défectueux ou trop restrictif peut aussi provoquer un déni de service. Vérifiez le type installé, ce qu’il contrôle et comment le récupérer ou le retirer.
Un Fallback Handler est un autre point d’extension. Lorsque calldata ne correspond à aucune fonction centrale du compte, celui-ci transmet l’appel au Handler configuré et ajoute l’adresse de l’appelant initial. Les Handlers peuvent ajouter la validation des signatures et les callbacks de jetons, mais une logique ou configuration dangereuse crée une surface supplémentaire d’autorisation et d’interprétation.
Exemple
Une trésorerie utilise un seuil de propriétaires 3-of-5 et active un module d’allocation pour les paiements courants. Ce module est évolutif et son administrateur de mise à niveau est un seul portefeuille chaud. Si cette clé est compromise, un attaquant peut mettre le module à niveau, emprunter la voie d’exécution du module et transférer les actifs sans obtenir 3 signatures. Le seuil 3-of-5 reste intact, mais ne régit pas cette voie.
L’examen doit relever l’adresse du module et son implémentation vérifiée, le proxy et l’administrateur, les plafonds, les cibles et sélecteurs autorisés, l’autorisation de DELEGATECALL, le Module Guard installé, le Fallback Handler et la transaction exacte nécessaire pour désactiver le module. Vérifiez ces valeurs dans les contrats du compte et des proxys sur chaque chaîne, et non uniquement dans une interface de portefeuille.
Risques
- Risque d’autorité : Un module vulnérable ou malveillant peut transférer des actifs, approuver des dépensiers, modifier l’état par
DELEGATECALLou appeler d’autres contrats privilégiés. Une interface limitée ne prouve pas que le pouvoir on-chain l’est aussi. - Risque de contrôle et de mise à niveau : Un proxy, administrateur, oracle, exécuteur d’automatisation ou clé de récupération peut réduire une structure apparente 3-of-5 à un ensemble de contrôle effectif plus petit. Suivez chaque voie de mise à niveau et de configuration jusqu’aux signataires finaux et aux délais.
- Risque de disponibilité : Un Guard défectueux peut bloquer des transactions valides, tandis qu’un module compromis peut agir avant que les propriétaires coordonnent son retrait. Testez désactivation et récupération, surveillez les changements de module, Guard et Handler, et conservez une voie de réponse indépendante du composant à retirer.
Idées fausses courantes
- Idée fausse 1 : « Le compte est 3-of-5, donc chaque transfert exige 3 signatures. » Le seuil s’applique à la voie normale autorisée par les propriétaires ; les modules activés peuvent suivre une autre politique.
- Idée fausse 2 : « Un Guard protège toutes les voies d’exécution. » Guards de transaction et Module Guards couvrent des points d’entrée différents ; la couverture dépend du contrat installé et de ses règles.
- Idée fausse 3 : « Retirer le module dans l’interface supprime le risque. » Vérifiez sur chaque chaîne le registre des modules activés, le stockage du Handler et du Guard, l’implémentation du proxy et les transactions de modification exécutées.
Sujets connexes
- Risque de stockage lié à delegatecall
- Gestion des clés privées
- Portefeuille multisignature
- Surveillance des mises à niveau de proxy
- Signature de portefeuille
Sources
- Modules Safe - Safe Ecosystem Foundation (consulté le 2026-08-21)
- Guards Safe - Safe Ecosystem Foundation (consulté le 2026-08-21)
- Fallback Handler Safe - Safe Ecosystem Foundation (consulté le 2026-08-21)
- ModuleManager.sol - Safe Ecosystem Foundation (consulté le 2026-08-21)