Modules ERC-7579 : que reste-t-il avec l’AA native ?
Disons que votre smart account plafonne les dépenses à 100 USDC par jour. Avec le brouillon EIP-8141, une frame pourrait-elle en envoyer 500 sans que le plafond le voie ?
EN 30 SECONDES
Un module ERC-7579 est une extension d’un smart account modulaire. À mon sens, avec le brouillon EIP-8141, la plupart des modules fonctionnent toujours et les validators nécessitent un nouveau point d’entrée. Les hooks, eux, peuvent être contournés, sauf si le compte l’interdit.
À RETENIR · 3
- À mon sens, avec le brouillon 8141, les executors, les fallback handlers et les vérifications de signature ERC-1271 d’ERC-7579 passent sans changement.
- À mon sens, les validators nécessitent un nouveau point d’entrée, et leurs réglages doivent résider dans le stockage du compte.
- Les hooks ne voient que les appels qui passent par le compte. Ma règle : son contrôle y fait passer chaque frame SENDER.
Sur cette page
Ce qui reste des modules ERC-7579 avec l’AA native
EN BREF À mon sens, en partie : executors et fallback handlers passent, les validators exigent un nouveau point d’entrée, les hooks appellent à la prudence.
Le classement ci-dessous est ma lecture du brouillon EIP-8141 du 7 octobre 2026, pas la production.
LES MOTS À CONNAÎTRE
- Module
- Une extension d’un smart account modulaire selon ERC-7579. Un validator vérifie les signatures, un hook encadre les appels, un executor agit pour le compte.
- Hook
- Un module qui fait un contrôle avant et après un appel, ou un lot d’appels, passé par les fonctions execute du compte.
- Frame transaction
- Le type de transaction que propose EIP-8141 : une liste d’appels, les frames. Les frames VERIFY contrôlent, les frames SENDER agissent au nom du compte.
ERC-7579, toujours un brouillon, définit chaque Module Une extension d’un smart account modulaire selon ERC-7579. Un validator vérifie les signatures, un hook encadre les appels, un executor agit pour le compte. Voir le glossaire. Il l’avait anticipé :
« This standard has a strict dependency on ERC-4337 for the validation flow. »
Sa validation dépend donc d’ERC-4337. La voie qu’il propose : déplacer cette dépendance dans une extension séparée quand l’abstraction de compte native existera.
Native veut dire intégrée à Ethereum, comme le propose le brouillon EIP-8141 avec la Frame transaction Le type de transaction que propose EIP-8141 : une liste d’appels, les frames. Les frames VERIFY contrôlent, les frames SENDER agissent au nom du compte. Voir le glossaire. Ci-dessous, je range un compte modulaire comme Nexus face à ce brouillon.
ÉTAPE PAR ÉTAPE
Étape 1. Validators. Le contrôle principal demande un nouveau point d’entrée. Les vérifications de signature pour les autres applis restent.
- Validators Le contrôle principal demande un nouveau point d’entrée. Les vérifications de signature pour les autres applis restent.
- Hooks Ils encadrent les appels qui passent par le compte : une frame directe les contourne.
- Executors et handlers Des appels ordinaires : inchangés.
- Stockage et plomberie Le stockage à espaces de noms passe ; dépôts et caution 4337 n’ont plus de rôle.
Ce sont les validators qu’il faut réécrire : gardez la logique de signature, remplacez le point d’entrée qui l’entoure. Leur validateUserOp prend une PackedUserOperation et son hash (une empreinte courte), et une frame transaction n’a ni l’un ni l’autre. Le code VERIFY du compte lit le hash de signature via un nouvel opcode, TXPARAM, puis termine par APPROVE.
ATTENTION
Vérifiez où chaque validator garde ses réglages. Des propriétaires stockés dans une table du validator sont hors du stockage de l’émetteur, ce que refuse le mempool public du brouillon. Gardez-les dans le stockage à espaces de noms du compte, atteint par DELEGATECALL (le module agit sur le stockage du compte).
Ce stockage ERC-7201 à espaces de noms, c’est ce que nous utilisions sur Nexus, pour une autre raison : des mises à niveau sûres.
Un exemple concret : un plafond qu’une frame peut contourner
EN BREF Un hook ne s’exécute que si l’appel passe par le compte, et une frame peut viser directement le token.
UN EXEMPLE CONCRET
Chiffres illustratifs
VALIDÉUn plafond quotidien appliqué par un hook, appel routé par le compte
ENTRÉE
- Compte
- compte ERC-7579 avec un hook de plafond
- Plafond
- 100 USDC par jour
- Frame
- frame du compte vers le compte : envoyer 80 USDC
CE QUI SE PASSE
- La frame appelle la fonction execute du compte.
- Le hook contrôle d’abord : 80 USDC, sous le plafond.
SORTIE
- Résultat
- transfert exécuté, plafond respecté
CONTOURNÉMême compte, une frame envoyée directement vers le token
ENTRÉE
- Frame
- frame du compte vers le token : envoyer 500 USDC
CE QUI SE PASSE
- Le token voit le compte comme appelant.
- execute ne s’exécute pas, donc le hook non plus.
SORTIE
- Résultat
- 500 USDC partent, plafond jamais vérifié
Le brouillon nomme le problème de fond : une fois l’exécution approuvée, « every subsequent SENDER frame executes with caller set to tx.sender ».
EN CLAIR
Une fois l’exécution approuvée, chaque frame SENDER suivante agit au nom de votre compte, pas seulement celle que vous visiez.
Ma règle : soit le code VERIFY exige que chaque frame SENDER vise le compte et appelle une fonction autorisée qui déclenche les Hook Un module qui fait un contrôle avant et après un appel, ou un lot d’appels, passé par les fonctions execute du compte. Voir le glossaire, comme execute, soit il inspecte lui-même chaque frame avec FRAMEPARAM et FRAMEDATALOAD.
Vérifier l’adresse seule ne suffit pas : les données de l’appel peuvent viser une autre fonction ou un fallback handler. Dans les deux cas, le code VERIFY vérifie une signature sur le hash canonique, qui couvre toute la liste des frames.
OBJET OBTENU
Contrôler chaque frame SENDER
FAQ
Non. ERC-7579 (Minimal Modular Smart Accounts), créé en décembre 2023, est toujours un brouillon, comme EIP-8141. Les deux peuvent changer avant le statut Final.
En partie, d’après ce que j’ai trouvé. Dans le brouillon, l’échéance validUntil correspond à un contrôle d’expiration, fait dans une frame du protocole. Je n’ai pas trouvé d’équivalent pour validAfter.
Sources : ERC-7579 (brouillon), EIP-8141 (brouillon), ERC-4337.
NIVEAU TERMINÉ
Ce que vous savez maintenant
- Quels types de modules ERC-7579 passent au brouillon 8141, lesquels demandent un nouveau point d’entrée, et pourquoi.
- Pourquoi une frame qui vise directement une cible peut contourner un hook, et comment le contrôle du compte comble cette faille.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Un validator garde les propriétaires de chaque compte dans une table de son propre contrat. Le mempool public du brouillon acceptera-t-il une transaction qui la lit ?
Non. La validation ne peut lire que le stockage de l’émetteur, et cette table est dans celui du validator. Déplacez-la dans le stockage à espaces de noms du compte.
Ingénieur web3 x IA, ancien CTO d’Integra. Auteur nommé (1 sur 5) d’ERC-3643, premier auteur d’ERC-6960, co-auteur d’ERC-7410 et co-auteur d’ERC-8203, encore à l’état de brouillon.
Un projet à livrer ou un poste à pourvoir ?
Parlons de votre besoinSuivre les notes techniques
Recevez les nouveaux articles sur l’IA en production et les smart contracts par email.