À partir de 2025, beaucoup commenceront peut-être à s'habituer à une nouvelle façon d'interagir : dire à GPT ou Gemini « Aide-moi à planifier mon voyage à Hong Kong la semaine prochaine et recommande des billets d'avion et des hôtels appropriés », et il effectuera en arrière-plan une série d'étapes comme la recherche d'informations, le filtrage des conditions, le choix de l'itinéraire, la comparaison des prix, etc., pour finalement ne vous présenter que les résultats à confirmer.
Cependant, si on transpose la même attente sur la blockchain, l'histoire change complètement.
Par exemple, si vous donnez l'instruction à un Agent DeFi : « Convertis l'ETH de mon portefeuille en USDC, transfère-le sur la chaîne Base, puis dépose-le intégralement sur Aave », objectivement parlant, en termes de « compréhension des besoins » et de « planification du chemin », les Agents d'aujourd'hui pourraient potentiellement le faire. La vraie rupture se situe au niveau de l'exécution :
Vous devrez probablement encore effectuer étape par étape les opérations de signature, d'autorisation, d'échange, de跨链 (bridging) et de dépôt, chaque étape étant exposée aux risques de variation du slippage, des fluctuations du Gas, des délais de bridge et des changements d'état sur la blockchain. Cela signifie que si un maillon du processus s'écarte des attentes, les actions précédentes ne pourront pas nécessairement être annulées, et les actions suivantes pourraient ne pas pouvoir être enchaînées, laissant finalement sur la blockchain un flux de travail semi-fini.
Le problème ne vient pas du fait que l'IA ne soit pas assez intelligente, mais du fait que la couche d'exécution on-chain manque encore d'un mode d'expression véritablement adapté aux Agents.
C'est précisément pour cette raison que début avril 2026, Biconomy et la Fondation Ethereum ont共同publié l'ERC-8211, visant à résoudre le problème des « limitations statiques » dans l'exécution actuelle des smart contracts, en fournissant une couche d'exécution plus expressive pour les agents IA et les workflows DeFi complexes, tentant de combler cette pièce manquante du puzzle.
一、La « dernière fracture » pour l'intégration des agents IA sur la blockchain
Au cours de la dernière année ou des deux dernières années, le point focal de l'attention dans l'industrie crypto s'est progressivement déplacé de la scalabilité des L2, de la liquidité des RWA, vers la question très disruptive de savoir comment les agents IA peuvent véritablement prendre en charge les opérations on-chain.
Objectivement parlant, de « l'utilisation du langage naturel pour formuler des stratégies DeFi multi-étapes » à « la confiance d'un agent autonome pour gérer un portefeuille d'investissement跨链 entier », nous avons récemment vu de nombreuses pratiques, et la plupart des concepts sont déjà matures au niveau de la démonstration, qu'il s'agisse de la génération en langage naturel de stratégies DeFi multi-étapes, de la réexécution autonome de rééquilibrage, de la migration automatique des rendements, de l'ajustement de positions跨链, ou même de la gestion de portefeuille combinée plus complexe.
Du point de vue du raisonnement et de l'orchestration, les capacités de l'IA ont progressé très rapidement, mais lorsqu'il s'agit de la mettre en environnement de production, les lacunes de la couche d'exécution deviennent de plus en plus évidentes.
Pour vraiment l'appliquer en environnement de production, cette lacune peut se résumer en une phrase : Le DeFi est dynamique, mais la plupart des batchs (traitements par lots) d'aujourd'hui sont encore statiques.
Le site officiel d'ERC-8211 et les posts de discussion expliquent clairement ce problème, à savoir que les ERC-4337 et EIP-5792 existants ont effectivement fait passer l'ancien modèle « une signature correspond à un appel » à une nouvelle étape « une signature peut regrouper plusieurs appels », mais les paramètres de ces appels sont, pour l'essentiel, encore figés au moment de la signature.
Cela signifie que le montant, la valeur cible, le résultat attendu que l'utilisateur saisit au moment de la signature, ne s'ajusteront pas automatiquement en fonction des changements d'état de la blockchain au moment de l'exécution réelle.
Or, le DeFi lui-même est justement plein d'incertitudes. Le résultat réel d'un Swap dépend du slippage et de la liquidité dans le bloc où il est exécuté ; le temps de livraison et le montant final d'un Bridge dépendent du mécanisme du bridge lui-même et des frais ; le ratio share-to-asset d'un protocole de prêt ou d'un Vault évolue également constamment.
Après tout, la valeur que l'utilisateur ou l'Agent voit au moment de la signature n'est souvent qu'une estimation instantanée, et non le résultat réel au moment de l'exécution.
Pour comprendre ce que résout ERC-8211, prenons un exemple typique : supposons qu'un Agent veuille faire une chose qui semble très ordinaire – convertir l'ETH du compte en USDC, puis le déposer intégralement sur Spark pour gagner des intérêts.
Dans le modèle de traitement par lots statique actuel, l'Agent doit estimer à l'avance combien d'USDC il obtiendra après le Swap, ce qui vous oblige souvent à figer à l'avance le montant d'entrée de la deuxième étape lors de la signature. Si vous surestimez, le montant réel reçu est insuffisant et tout le lot est annulé (revert) ; si vous sous-estimez, une partie des fonds reste inactive dans le portefeuille, incapable d'être utilisée.
En d'autres termes, vous êtes essentiellement confronté à un dilemme : soit assumer le risque d'échec, soit assumer le coût d'opportunité. C'est pourquoi de nombreux flux on-chain qui ne semblent pas complexes, une fois que les étapes s'étendent à 5, 8 étapes, voire跨越deux chaînes, deviennent rapidement fragiles. Ce n'est pas parce que la stratégie elle-même est trop complexe à décrire, mais parce que le paradigme d'exécution actuel dépend trop de paramètres prédéfinis et figés.
En bref, la limite supérieure de capacité du traitement par lots statique détermine en fait la limite supérieure des stratégies qu'un Agent peut exécuter en toute sécurité.
Sous cet angle, ce qu'ERC-8211 cherche à résoudre, ce n'est pas comment l'Agent IA prend des décisions, mais une fois que l'Agent a pris une décision, existe-t-il une manière plus naturelle, plus stable et plus sûre de l'exécuter sur la blockchain. Ainsi, l'exécution on-chain possède pour la première fois une forme d'expression conçue nativement pour les agents IA.
二、Qu'est-ce que l'ERC-8211 change vraiment ?
La percée核心de l'ERC-8211 ne réside pas dans le fait de mettre plus d'étapes dans une seule signature, mais dans la mise à niveau du traitement par lots d'une séquence de transactions aux paramètres figés vers un « programme dont les paramètres sont évalués dynamiquement sur le site d'exécution ».
Cela semble très abstrait, mais ce n'est pas difficile à comprendre. Les auteurs officiels utilisent une phrase pour le décrire : Des transactions aux programmes (From transactions to programs).
Cela signifie que l'ERC-8211 ne considère plus le lot comme une liste d'actions à exécuter séquentiellement, mais comme un programme d'exécution évalué à l'exécution et doté de conditions de sécurité. Pour le décomposer concrètement, il réalise cela grâce à trois primitives combinables :
- Fetchers (extracteurs de valeur) : Définissent d'où ce paramètre tire sa valeur. Il peut s'agir d'une requête sur le solde actuel d'une certaine adresse, faisant que le paramètre n'est plus un instantané au moment de la signature, mais une lecture en temps réel extraite de l'état de la blockchain au moment de l'exécution.
- Constraints (contraintes) : Une fois le paramètre résolu, il doit passer des vérifications de contraintes inline – par exemple « les USDC obtenus doivent être ≥ 2500 » ou « le slippage ne doit pas dépasser 0,5 % ». Ces contraintes sont validées avant que la valeur ne soit acheminée vers le prochain appel. Si l'une d'elles n'est pas satisfaite, l'ensemble du lot est immédiatement annulé (revert).
- Predicates (conditions déclenchantes) : Peuvent être compris comme des gardiens entre les étapes. Ils ne sont pas responsables de produire une valeur, mais de juger si l'exécution doit continuer. Par exemple, dans un scénario跨链, le lot côté Ethereum peut utiliser un predicate pour attendre la condition « les WETH跨链sont bien arrivés » et ne pas soumettre la suite tant que cette condition n'est pas remplie.
Dans cette conception, chaque paramètre doit répondre à deux questions : Premièrement, d'où cette valeur doit-elle venir au moment de l'exécution ? Deuxièmement, quelles conditions doit-elle satisfaire avant d'être réellement utilisée dans l'appel ? Une fois ces trois éléments combinés, un lot n'est plus seulement une séquence de transactions, mais un programme intégrant des contrôles de sécurité.
En fin de compte, le modèle mental du traitement par lots statique est une liste – exécuter séquentiellement les étapes A, B, C ; tandis que le modèle mental de l'ERC-8211 est un programme conditionnel – après l'exécution de A, prendre la sortie réelle de A comme entrée de B ; B doit satisfaire les contraintes pour passer à C ; si une étape ne répond pas aux attentes, tout le lot est annulé.
On peut simplement le comprendre comme un mécanisme de « traitement par lots intelligent » conçu spécifiquement pour les agents IA et les opérations DeFi complexes. En effet, dans les opérations on-chain traditionnelles, l'exécution d'une stratégie DeFi complexe nécessite souvent plusieurs transactions indépendantes : retirer des fonds d'un protocole de prêt, échanger des jetons, puis les déposer dans un autre protocole (lecture complémentaire《Panorama des protocoles Crypto IA : En partant du champ de bataille principal d'Ethereum, comment construire un nouveau système d'exploitation pour les agents IA ?》).
Chaque étape nécessite une signature et une confirmation séparées, ce qui est déjà fastidieux pour un utilisateur humain, et constitue un goulot d'étranglement encore plus important pour un agent IA devant opérer de manière autonome et à haute fréquence. La solution de l'ERC-8211 est de permettre à plusieurs opérations blockchain de s'exécuter de manière combinée dans une seule transaction, chaque étape解析dynamiquement la valeur réelle au moment de l'exécution, et ne pouvant passer à l'étape suivante que si des conditions prédéfinies sont remplies.
Par exemple, un Agent peut, dans une seule transaction signée, accomplir : retirer des fonds d'Aave → échanger le montant réellement reçu sur Uniswap → déposer le résultat de l'échange sur Compound – le tout exécuté de manière atomique, sans avoir à écrire de nouveau smart contract.
三、Pourquoi est-ce que cela concerne davantage les portefeuilles, et particulièrement les smart wallets
La raison pour laquelle l'ERC-8211 mérite l'attention de l'industrie des portefeuilles n'est pas seulement parce qu'il convient aux Agents, mais aussi parce qu'il redéfinit la position du portefeuille dans la chaîne d'interaction.
Autrefois, le portefeuille ressemblait plus à un signataire sécurisé. Sa responsabilité était de garder la clé privée, d'afficher la transaction, de laisser l'utilisateur confirmer, puis d'envoyer la signature. Ce rôle était déjà suffisamment important à l'ère des EOA, et il reste valable à l'ère de l'abstraction de compte. Mais si à l'avenir, de plus en plus d'opérations on-chain sont effectuées par des Agents, le rôle du portefeuille deviendra plus central et plus important.
La raison est simple : lorsque l'utilisateur ne contrôle plus les actions on-chain transaction par transaction, mais commence à autoriser un Agent à exécuter un ensemble complet d'objectifs, le portefeuille doit être capable de prendre en charge cet objet d'interaction de plus haut niveau. Ce qu'il doit afficher n'est plus seulement une adresse de contrat et un calldata, mais un programme d'exécution entier « intention – logique d'extraction de valeur – jugement conditionnel – résultat final ».
Par conséquent, le portefeuille de demain doit comprendre, non plus des transactions, mais des programmes. L'ERC-8211 fournit justement à ce niveau une prise plus claire pour les portefeuilles, car il écrit explicitement ces sémantiques d'exécution dans la structure de codage, incluant d'où viennent les paramètres, quelles conditions ils doivent satisfaire, quand continuer, quand annuler. Ce ne sont pas des boîtes noires cachées dans la logique backend, mais des objets que le portefeuille peut interpréter, simuler et afficher.
Du point de vue du portefeuille, l'ensemble de ce mécanisme pointe finalement vers la même chose : l'utilisateur ne signe plus une série d'appels bas niveau qu'il a du mal à comprendre complètement, mais signe un programme d'exécution orienté résultat, aux limites claires et aux conditions vérifiables :
- L'Agent IA peut être responsable de comprendre l'intention de l'utilisateur et de générer le chemin ;
- Le portefeuille est responsable de présenter ce chemin de manière plus claire à l'utilisateur pour examen ;
- Et le relayer (relais) est seulement responsable de soumettre lorsque les conditions sont remplies, sans avoir le droit de falsifier les résultats ;
C'est précisément la raison pour laquelle l'exécution non custodiale (non gardée) est considérée comme un prérequis pour le DeFi Agentic, car l'agent peut participer, mais la souveraineté, les contraintes et le règlement final restent sur la blockchain. C'est aussi là que l'ERC-8211 et les smart wallets convergent vraiment : il écrit la chose « exprimer en toute sécurité des intentions complexes » dans une norme de couche protocolaire.
Il est worth noting que l'ERC-8211 est entièrement compatible avec les frameworks d'abstraction de compte comme ERC-4337, EIP-7702, ERC-7579, etc. Il ne remplace pas l'abstraction de compte, mais ajoute une couche de sémantique d'exécution programmatique pour les Agents par-dessus l'abstraction de compte.
Si l'ERC-4337 résout « qui peut me représenter pour initier une transaction », et l'EIP-7702 résout « comment un EOA peut temporairement avoir des capacités de smart contract », alors l'ERC-8211 résout une fois que l'Agent commence à opérer pour moi, peut-il terminer une chaîne de décision entière en une seule signature.
En regardant l'évolution du paradigme d'interaction on-chain d'Ethereum sur les 10 dernières années :
- Première phase : une signature = un appel de fonction (ère EOA)
- Deuxième phase : une signature = un groupe d'appels打包statiques (ère ERC-4337, EIP-5792)
- Troisième phase : une signature = un programme d'intention à évaluation dynamique (ère ERC-8211)
Chaque transition signifie que l'utilisateur (ou l'Agent qui le représente) peut exprimer des objectifs plus complexes avec moins de friction.
Bien que l'ERC-8211 soit actuellement encore au stade de draft, que les discussions techniques se poursuivent et que l'intégration massive des protocoles prenne encore du temps, la direction qu'il indique est déjà suffisamment claire : lorsque les agents IA commenceront véritablement à prendre des décisions on-chain pour les humains, la blockchain aura besoin d'une syntaxe d'exécution native qui leur corresponde.
