ERC-8211 vise à permettre l'exécution dynamique pour les agents IA dans DeFi

À partir de 2025, beaucoup de gens pourraient progressivement s'habituer à une nouvelle forme d'interaction : dire à GPT ou Gemini « Aide-moi à planifier mon voyage à Hong Kong la semaine prochaine et recommande des billets d'avion et des hôtels adaptés », et il effectuera en arrière-plan une série d'étapes — recherche d'informations, filtrage des critères, sélection d'itinéraires, comparaison de prix — avant de vous soumettre uniquement les résultats pour validation.

Mais apporter les mêmes attentes sur la chaîne change complètement l'histoire.

Par exemple, si vous donnez une instruction à un agent DeFi : « Échangez tous les ETH de votre portefeuille contre des USDC, transférez-les sur la chaîne Base, puis déposez le montant total sur Aave », objectivement, aujourd’hui, l’agent est peut-être capable de comprendre la demande et de planifier le parcours ; la véritable rupture se produit au niveau de l’exécution :

Vous devrez probablement encore effectuer progressivement les étapes de signature, d'autorisation, d'échange, de pont cross-chain et de dépôt, et chaque étape est exposée aux risques de variation de slippage, de fluctuation des frais Gas, de retard de pont et de changement d'état sur la chaîne. Cela signifie que si une seule étape dévie de ce qui était attendu, les actions précédentes ne peuvent pas toujours être annulées, et les actions suivantes risquent de ne pas s'enchaîner correctement, laissant finalement sur la chaîne un processus incomplet.

Le problème n’est pas que l’IA ne soit pas assez intelligente, mais que la couche d’exécution sur chaîne n’ait toujours pas de moyen véritablement adapté à l’expression des Agents.

C'est pourquoi, au début avril 2026, Biconomy et la Ethereum Foundation ont conjointement publié l'ERC-8211, visant à résoudre les « limites statiques » actuelles dans l'exécution des contrats intelligents, afin de fournir une couche d'exécution plus expressive pour les agents IA et les flux de travail DeFi complexes, en tentant de compléter cette pièce manquante du puzzle.

Au cours des deux dernières années, l'attention de l'industrie des cryptomonnaies a clairement basculé vers la question révolutionnaire de la manière dont les agents IA peuvent véritablement prendre en charge les opérations sur chaîne, après s'être concentrée sur l'extension L2 et la liquidité RWA.

Objectivement, nous avons récemment observé de nombreuses réalisations allant de « l'application de stratégies DeFi à plusieurs étapes via un langage naturel » à « la confiance d'un portefeuille d'investissement interchaînes à des agents autonomes », et la plupart de ces idées sont déjà matures au niveau des démonstrations, qu'il s'agisse de la génération de stratégies DeFi à plusieurs étapes par langage naturel, de l'exécution autonome de rééquilibrage, du transfert automatique de rendements, de l'ajustement de positions interchaînes, ou même de la gestion de portefeuilles plus complexes.

Du point de vue du raisonnement et de l'orchestration, les capacités de l'IA ont progressé très rapidement, mais lorsqu'elle est réellement intégrée dans un environnement de production, les lacunes au niveau de l'exécution deviennent de plus en plus évidentes.

Lorsqu'il s'agit de passer en production, ce point faible peut être résumé en une phrase : le DeFi est dynamique, mais la plupart des batch d'aujourd'hui restent statiques.

Le site officiel d'ERC-8211 et le fil de discussion expliquent clairement ce problème : les ERC-4337 et EIP-5792 existants ont effectivement fait passer le modèle ancien « une signature pour un appel » à une nouvelle phase où « une seule signature peut regrouper plusieurs appels », mais les paramètres de ces appels restent essentiellement figés au moment de la signature.

Autrement dit, les montants, les objectifs et les résultats attendus entrés par l'utilisateur lors de la signature ne seront pas ajustés automatiquement en fonction des changements d'état sur la chaîne lors de l'exécution réelle.

Le DeFi lui-même est précisément rempli d'incertitudes. La sortie réelle d'un Swap dépend du slippage et de la liquidité dans le bloc exécuté ; le délai de réception et le montant final d'une Bridge dépendent du mécanisme et des frais de la bridge elle-même ; le ratio share-to-asset des protocoles de prêt ou des Vault change également en permanence.

Après tout, la valeur que l'utilisateur ou l'Agent voit lors de la signature est souvent simplement une estimation au moment présent, et non le résultat réel à l'exécution.

Pour comprendre ce que résout ERC-8211, examinons d'abord un exemple typique : supposons qu'un Agent souhaite accomplir une action apparemment simple — échanger les ETH de son compte contre des USDC, puis déposer le montant intégral sur Spark pour générer des intérêts.

Dans le modèle actuel de traitement par lot statique, l'Agent doit estimer avant la signature combien d'USDC il recevra après le Swap, ce qui oblige souvent à fixer à l'avance le montant d'entrée pour la deuxième étape. Si l'estimation est trop élevée, le montant réel reçu est insuffisant et l'ensemble du lot est annulé ; si elle est trop faible, une partie des fonds reste inutilisée dans le portefeuille.

Autrement dit, on se retrouve dans ce qu'on appelle un dilemme : soit on assume le risque d'échec, soit on assume le coût d'opportunité. C'est pourquoi de nombreux processus sur chaîne qui semblent simples deviennent rapidement fragiles dès qu'ils s'étendent à 5, 8 étapes, voire traversent deux chaînes : ce n'est pas parce que la stratégie est trop complexe pour être décrite, mais parce que le modèle d'exécution actuel dépend trop fortement de paramètres prédéfinis.

En résumé, la capacité maximale du batch statique détermine en fait la limite supérieure des stratégies que l'Agent peut exécuter en toute sécurité.

Du point de vue de cette perspective, ERC-8211 ne vise pas à résoudre la question de la prise de décision des AI Agent, mais à offrir, une fois la décision prise, une manière plus naturelle, stable et sécurisée de l'exécuter sur la chaîne. Ainsi, l'exécution sur la chaîne acquiert pour la première fois une forme native conçue spécifiquement pour les AI Agent.

La percée fondamentale d'ERC-8211 ne réside pas dans l'ajout de davantage d'étapes à une seule signature, mais dans la transformation du traitement par lot, d'une séquence de transactions à paramètres statiques, en un « programme dont les paramètres sont évalués dynamiquement au moment de l'exécution ».

Cela semble effectivement abstrait, mais pas difficile à comprendre ; l'équipe officielle l'a décrit en une phrase : From transactions to programs.

Cela signifie que ERC-8211 ne considère plus le batch comme une liste d'actions exécutées séquentiellement, mais comme un programme d'exécution évalué à l'exécution avec des conditions de sécurité, et plus précisément, il réalise cela grâce à trois primitives composites :

• Fetchers : définit d'où ce paramètre extrait sa valeur ; il peut s'agir d'une requête en temps réel du solde actuel d'une adresse, permettant ainsi que le paramètre ne soit plus un instantané au moment de la signature, mais une lecture en temps réel issue de l'état de la chaîne au moment de l'exécution ;
• Contraintes : après extraction des paramètres, une vérification des contraintes intégrées est effectuée — par exemple, « les USDC reçus doivent être ≥ 2500 » ou « le slippage ne doit pas dépasser 0,5 % » — ces contraintes sont vérifiées avant que les valeurs ne soient transmises à l’appel suivant ; si l’une d’entre elles échoue, l’ensemble du lot est immédiatement annulé ;
• Prédictions (conditions de déclenchement) : à comprendre comme des gardiens entre les étapes, qui ne produisent pas de valeur, mais déterminent si l'exécution doit se poursuivre ; par exemple, dans un scénario cross-chain, le lot côté Ethereum peut rester bloqué par une prédiction jusqu'à ce que le WETH transféré via cross-chain soit bien reçu, et ne soit soumis qu'après réception.

Dans ce système de conception, chaque paramètre doit répondre à deux questions : premièrement, d’où provient cette valeur lors de son exécution ; deuxièmement, quelles conditions doivent être remplies avant qu’elle soit effectivement utilisée dans l’appel. Ainsi, combinés, ces trois éléments transforment un lot non seulement en une séquence de transactions, mais en un programme intégrant des vérifications de sécurité.

Au final, le modèle mental du traitement par lot statique est une liste de vérification — exécuter les étapes A, B et C dans l'ordre ; tandis que le modèle mental d'ERC-8211 est un programme conditionnel — après l'exécution de A, utiliser la sortie réelle de A comme entrée pour B ; B ne passe à C que si les contraintes sont satisfaites ; si une étape quelconque ne répond pas aux attentes, l'ensemble du lot est annulé.

Nous pouvons en fait le comprendre simplement comme un mécanisme de « traitement par lots intelligent » conçu spécifiquement pour les AI Agent et les opérations DeFi complexes, car dans les opérations chainées traditionnelles, la réalisation 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 : Encyclopédie des protocoles crypto AI : comment construire un nouvel système d'exploitation pour les AI Agent à partir du champ de bataille principal d'Ethereum ?).

Chaque étape nécessite une signature et une confirmation séparées, ce qui est déjà fastidieux pour les utilisateurs humains et constitue un goulot d'étranglement pour les agents IA nécessitant des opérations autonomes à haute fréquence. La solution d'ERC-8211 permet de regrouper plusieurs opérations blockchain dans une seule transaction, en résolvant dynamiquement les valeurs réelles à chaque étape, et en exigeant que les conditions prédéfinies soient remplies avant de passer à l'étape suivante.

Par exemple, un Agent peut accomplir cela en une seule transaction signée : retirer des fonds depuis Aave → échanger le montant reçu sur Uniswap → déposer le résultat sur Compound — le tout exécuté de manière atomique, sans nécessiter d'écrire un nouveau contrat intelligent.

ERC-8211 mérite l'attention de l'industrie des portefeuilles non seulement parce qu'il convient aux agents, mais aussi parce qu'il redéfinira le rôle des portefeuilles dans les chaînes d'interaction.

Les portefeuilles passés ressemblaient davantage à des signataires sécurisés : leur rôle consistait à stocker les clés privées, afficher les transactions, permettre à l'utilisateur de les confirmer, puis d'envoyer la signature. Ce rôle était déjà essentiel à l'ère des EOA, et il reste valable à l'ère de l'abstraction de compte ; toutefois, si de plus en plus d'opérations sur chaîne sont désormais effectuées par des agents, le rôle du portefeuille deviendra encore plus central et crucial.

La raison est simple : lorsque les utilisateurs ne manipulent plus chaque action sur la chaîne individuellement, mais commencent à autoriser un Agent à exécuter un ensemble complet d'objectifs, le portefeuille doit être capable de prendre en charge ce type d'interaction de niveau supérieur. Il ne doit plus simplement afficher une adresse de contrat et une chaîne de calldata, mais un programme d'exécution complet comprenant « intention — logique de récupération — évaluation conditionnelle — résultat final ».

Ainsi, les portefeuilles du futur devront comprendre non seulement les transactions, mais aussi les programmes. ERC-8211 fournit à ce niveau un point d'ancrage plus clair pour les portefeuilles, car il intègre explicitement ces sémantiques d'exécution dans la structure du code : l'origine des paramètres, les conditions requises, les moments pour continuer ou pour annuler, ne sont plus des boîtes noires cachées derrière la logique backend, mais des objets que le portefeuille peut interpréter, simuler et afficher.

Du point de vue du portefeuille, ce mécanisme global conduit finalement à une même chose : l'utilisateur ne signe plus une série d'appels sous-jacents qu'il peine à comprendre entièrement, mais un programme d'exécution orienté résultat, aux limites claires et aux conditions vérifiables :

• L'agent IA peut être chargé de comprendre l'intention de l'utilisateur et de générer le parcours ;
• Le portefeuille présente ce chemin à l'utilisateur pour validation, de manière plus claire ;
• Le relayer n'est responsable que de la soumission lorsque les conditions sont remplies et n'a pas le pouvoir de modifier les résultats ;

C'est précisément pour cette raison que l'exécution non custodiale est considérée comme une condition préalable à l'Agentic DeFi, car les agents peuvent participer, mais la souveraineté, les contraintes et le règlement final restent sur la chaîne — c'est exactement là où ERC-8211 s'aligne parfaitement avec les portefeuilles intelligents : il intègre la capacité à « exprimer de manière sécurisée des intentions complexes » au niveau du protocole.

Il est à noter que ERC-8211 est entièrement compatible avec les cadres d'abstraction de compte tels qu'ERC-4337, EIP-7702 et ERC-7579 ; il ne remplace pas l'abstraction de compte, mais ajoute une couche supplémentaire de sémantique d'exécution programmatique pour les agents.

Si ERC-4337 résout la question « Qui peut agir en mon nom pour lancer une transaction ? », et EIP-7702 résout « Comment un EOA peut temporairement acquérir des capacités de contrat intelligent ? », alors ERC-8211 résout la question suivante : une fois qu'un Agent commence à agir en mon nom, peut-il accomplir toute une chaîne de décisions en une seule signature ?

Revue de l'évolution des modèles d'interaction sur la chaîne d'Ethereum au cours des 10 dernières années :

• Phase 1 : Une signature = Un appel de fonction (ère EOA)
• Phase 2 : Une signature = un ensemble d'appels packagés statiques (ère ERC-4337, EIP-5792)
• Phase 3 : Une signature = Un programme d'intention évalué dynamiquement (ère ERC-8211)

Chaque saut signifie que l'utilisateur (ou l'agent qui le représente) peut exprimer des objectifs plus complexes avec moins de friction.

Bien que ERC-8211 soit encore en phase de projet et que les discussions techniques soient en cours, avec un intégration à grande échelle du protocole qui nécessitera encore du temps, la direction qu'il indique est déjà suffisamment claire : lorsque les AI Agent commenceront réellement à prendre des décisions sur chaîne à la place des humains, la chaîne aura besoin d'une syntaxe d'exécution native correspondante.