Comment les agents IA effectuent des trades onchain ?

Comment les agents IA exécutent des transactions onchain dépend de la plomberie, pas de la « magie IA » : l'agent produit des intentions signées que d'autres acteurs transforment en changements d'état Ethereum. La transaction ne se règle que si deux rails sont correctement câblés, le rail d'exécution (transaction EOA ou UserOperation ERC-4337) et le rail de permission de jeton (allocations ou permis de style Permit2).

Points clés

• Un agent IA ne « trade » pas tout seul sur Ethereum. Il doit contrôler ou être autorisé par un compte onchain qui peut déclencher des appels de contrat et des transferts de jetons.
• Il y a deux rails d'exécution : une transaction d'origine EOA, ou une UserOperation ERC-4337 qu'un bundler soumet au contrat EntryPoint pour vérification et exécution.
• Les échanges nécessitent une permission explicite de dépense de jetons avant le mouvement des jetons, et Permit2AllowanceTransfer ajoute des expirations et des nonces par (propriétaire, jeton, dépensier) pour lier et protéger cette autorisation contre la répétition.
• Pour une taille plus grande ou des contrôles plus stricts, un Safe peut séparer les fonctions en permettant à l'agent de proposer une transaction tandis que plusieurs propriétaires confirment avant l'exécution.

Comment un agent IA peut trader onchain

Une sortie de modèle n'est pas une action onchain. La chaîne ne réagit qu'aux messages qui passent les vérifications de signature et appellent des contrats depuis un compte qui détient desactifs.C'est la réalité fondamentale derrière le trading autonome onchain : l'« agent » est un moteur de décision offchain, et la partie onchain est un compte plus une demande signée que le réseau acceptera.

Deux rails apparaissent sur un explorateur de blocs. Le premier est le rail d'exécution, ce qui signifie comment la demande devient une transaction Ethereum. Sur Ethereum, seul un Compte Externe Peut Originer une transaction, car un EOA est contrôlé par uneclé privéeet signe la transaction directement. Uncontrat intelligentUn compte peut détenir des actifs et exécuter de la logique, mais il ne peut pas initier une transaction par lui-même. Il n'effectue du travail que lorsqu'il est appelé par autre chose.

Le deuxième rail est le mouvement des tokens. UnDEXl'échange n'est pas “juste appeler un routeur.”ERC-20les tokens ne se déplacent pas parce qu'une fonction d'échange a été appelée. Ils se déplacent parce que le propriétaire du token a accordé une autorité de dépense à un dépensier, et ensuite ce dépensier utilise cette autorité pour transférer des tokens.

Si l'agent construit une exécution d'agent onchain qui touche aux ERC-20, il doit résoudre les deux rails à chaque fois : (1) faire exécuter des appels par la chaîne, et (2) s'assurer que le bon contrat est autorisé à retirer le bon montant de tokens.

C'est ici que se regroupent les produits DeFi : exécution autonome enveloppée dans l'UX de portefeuille, avec des garde-fous autour de ce qui est signé et de ce qui est dépensé. Le modèle mental utile est le même que celui qui sous-tend ce qu'est l'exécution autonome onchain DeFi en tant que catégorie : l'agent rédige des intentions, et l'infrastructure transforme ces intentions en règlement.

Le pipeline d'exécution ERC-4337

ERC-4337 transforme "envoyer une transaction" en une chaîne d'approvisionnement avec des acteurs supplémentaires, ce qui modifie les hypothèses de fiabilité. Au lieu qu'un EOA diffuse une transaction dans le mempool public, un portefeuille ERC-4337 construit un objet UserOperation et le remet à un bundler qui soumet ensuite une transaction onchain à un contrat EntryPoint singleton.

Le flux de bout en bout est le plus facile à suivre sous forme de séquence :

1. L'agent prépare une charge utile. Pour un portefeuille d'agent qui est un compte intelligent ERC-4337, la charge utile est une UserOperation avec des champs comme l'expéditeur, le nonce, les données d'appel, les limites de gaz, les paramètres de frais et une signature.2. L'agent soumet la UserOperation à un mempool alternatif. Les portefeuilles l'envoient généralement à un point de terminaison RPC de bundler plutôt qu'au pool de transactions Ethereum standard.3. Un bundler collecte et simule. Les bundlers surveillent le alt-mempool, simulent les UserOperations candidates et décident lesquelles inclure dans un bundle.

4. Le bundler origine la transaction onchain. Le bundler appelle EntryPoint.handleOps avec un tableau de UserOperations, et cet appel est la transaction Ethereum réelle qui se retrouve dans un bloc.5. EntryPoint vérifie, puis exécute. EntryPoint suit un modèle en deux phases : il appelle validateUserOp sur le compte (et validatePaymasterUserOp si un paymaster est attaché) et ne lance la phase d'exécution qu'ensuite.6.

Le gaz est réglé via des préfinancements ou un paymaster. L'ERC-4337 permet à un contrat Paymaster de sponsoriser le gaz en remboursant le bundler selon des règles définies.

Pour les mécanismes de l'agent de trading AI, le point clé n'est pas le format de signature. C'est qui est responsable de l'inclusion. Avec l'ERC-4337, "exécuté par l'agent" n'est pas lorsque l'agent signe. C'est lorsque EntryPoint exécute, et cela dépend du comportement du bundler et des règles du paymaster si le gaz est sponsorisé.

Comment les agents obtiennent la permission de dépenser des tokens.

Le mouvement des tokens est là où la plupart des conceptions d'agents présentent des risques, car les permissions ont tendance à survivre au commerce. Le modèle propre est permission d'abord, exécution ensuite. L'ERC-4337 peut compresser cela en un seul règlement en regroupant plusieurs actions dans une seule UserOperation, mais la permission doit toujours être explicite et limitée.La fonction Permit2 AllowanceTransfer de Uniswap est un ensemble concret de primitives pour ce niveau. Elle prend en charge trois points d'entrée principaux : approuver (définir des permissions onchain), permettre (définir des permissions via une signature) et transferFrom (dépenser lorsque des permissions valides existent déjà). La différence importante par rapport à l'ancienne habitude "approuver max pour toujours" est que les allocations Permit2 peuvent être limitées dans le temps à l'aide d'un horodatage d'expiration.

Permit2 offre également un mécanisme pratique de protection contre les rejets que les agents peuvent réellement utiliser. Son schéma de nonce incrémente les nonces par propriétaire, par jeton et par dépensier, regroupés dans un mappage d'allocation.

Cela signifie qu'une autorisation n'est pas seulement « le propriétaire a signé une fois », mais « le propriétaire a signé cette fenêtre de dépense spécifique pour ce dépensier, et ce nonce a-t-il déjà été consommé ? » Le permis de Permit2 prend en charge les signatures EOA, les signatures compactes EIP-2098 et les signatures de contrat EIP-1271, ce qui est important lorsque le propriétaire est un compte intelligent plutôt qu'un EOA.

Pour la façon dont les agents échangent dans DeFi, voici le modèle opérationnel qui apparaît lorsque les choses sont construites avec soin :

1. L'agent demande une fenêtre de dépense étroite. Le montant est limité, l'expiration est courte, le dépensier est spécifique. 2. L'agent regroupe l'autorisation avec l'exécution. Un permis ou une approbation peut être combiné avec l'appel d'échange afin que l'allocation ne reste pas inutilisée. 3. L'agent dépense via transferFrom uniquement pendant cette fenêtre. Si la fenêtre expire, l'autorisation est morte sur la chaîne.

C'est également ici que l'exécution basée sur l'intention et un réseau de solveurs s'intègrent conceptuellement. L'agent peut signer une intention qui exprime le résultat souhaité, tandis que les solveurs rivalisent pour le router et le régler. Peu importe qui route, le rail de permission de jeton décide toujours de ce qui peut être retiré du compte du propriétaire.

Multisig et contrôles de politique avec Safe

Le modèle de contrôle le plus robuste pour l'argent réel est la séparation des politiques : laisser l'agent proposer, mais exiger un seuil Safe pour exécuter. Cela maintient l'automatisation tout en retirant l'autorité unilatérale d'une seule clé de modèle d'exécution.

Le flux documenté de Safe est explicite sur les transferts. Une transaction est créée, proposée au Service de Transaction Safe, confirmée par d'autres propriétaires, et seulement ensuite exécutée.

Dans le guide du Kit de Protocole Safe, la séquence est : créer un objet de transaction, calculer le hachage de la transaction Safe, le proposer afin que d'autres propriétaires puissent le voir, collecter des confirmations (signatures) des propriétaires, puis exécuter avec executeTransaction.

Cela a de l'importance pour l'exécution autonome car cela change ce que signifie « action de l'agent ». L'agent peut générer le calldata exact pour un appel de routeur DEX, ou pour un executeBatch d'un compte ERC-4337, mais le Safe est le bureau des risques qui décide si cette charge utile est autorisée à toucher la chaîne.

C'est un endroit propre pour faire respecter des politiques que les sources ne standardisent pas pour les agents, comme limiter les nouveaux dépensiers, exiger des confirmations supplémentaires pour de nouveaux jetons, ou contrôler la taille.

Safe fonctionne également bien avec les modèles de clé de session au niveau du compte. Les comptes ERC-4337 peuvent valider différents schémas de signature à l'intérieur de validateUserOp, et une clé de session peut être l'un de ces schémas. Le point n'est pas le mot à la mode. Le point est qu'une clé à courte durée de vie peut être autorisée pour des actions étroites tandis que les propriétaires à long terme conservent le contrôle ultime.

Pour les équipes construisant des systèmes DeFi, c'est la différence entre « l'agent peut échanger » et « l'agent peut rédiger des échanges ». Rédiger est peu coûteux. L'exécution est là où se produisent des changements d'état irréversibles.

Compromis de conception et modes de défaillance

Le premier mode de défaillance est la confusion des types de messages. Une UserOperation n'est pas une transaction Ethereum. C'est des données dans un mempool alternatif jusqu'à ce qu'un bundler les encapsule dans un appel EntryPoint.handleOps. C'est pourquoi les comptes de contrats intelligents ne peuvent pas "simplement envoyer des transactions comme les EOAs." Seules les EOAs initient des transactions, et les comptes intelligents agissent lorsqu'ils sont appelés.

Le deuxième mode de défaillance consiste à traiter le bundler comme une infrastructure invisible. L'ERC-4337 déplace les hypothèses de « mon portefeuille diffuse » à « un bundler va-t-il m'inclure ». La description d'Eco est explicite : les bundlers surveillent l'alt-mempool, simulent et soumettent des bundles, payant le gaz L1 et étant remboursés par des préfinancements ou des paymasters.

Si un point de terminaison de bundler est hors service, limité en taux, ou refuse certaines opérations, l'agent peut continuer à signer et rien ne sera réglé.

Le troisième mode de défaillance est l'étalement des autorisations. Des approbations illimitées ne sont pas une fonctionnalité de trading. Ce sont une surface de perte permanente. Les horodatages d'expiration de Permit2 et les nonces par (propriétaire, jeton, dépensier) sont les contrôles onchain qui peuvent limiter cette surface, mais seulement si l'intégration les utilise.

Une erreur d'intégration courante consiste à autoriser le mauvais dépensier ou à passer le mauvais from.adressedans un appel de transfert, que Uniswap signale comme une considération de sécurité pour l'intégration des contrats.

Le quatrième mode de défaillance est le surcréditage de l'IA. La plupart des explosions dans l'exécution des agents onchain proviennent du câblage, et non du modèle choisissant le mauvais côté. Si le portefeuille de l'agent peut signer un large permis, ou si les règles du paymaster sont trop laxistes, le système peut faire exactement ce qu'il était autorisé à faire, tout en restant inacceptable.

Le résumé des compromis est simple. Les EOAs sont simples et directs mais mettent tout le système derrière une seule clé. L'ERC-4337 ajoute le regroupement, la validation personnalisée et le gaz sponsorisé, mais introduit une chaîne d'approvisionnement de transactions avec des agrégateurs, EntryPoint et des payeurs optionnels. Safe ajoute de la friction par conception, et cette friction est le point où la taille compte.

Près du bas de tout document d'architecture sérieux, le sujet plus large reste l'exécution autonome onchain, et la question est de savoir quel rail et quel niveau de politique le système peut réellement supporter sous pression.

L'Analyse

J'ai vu des équipes s'obséder sur la partie "IA" et ensuite expédier l'erreur coûteuse : une approbation de jeton large et de longue durée associée à une infrastructure fragile. Quand quelque chose ne va pas, ce n'est que rarement parce que le modèle a halluciné un échange.

C'est parce que la couche de permission a laissé un dépensier retirer plus que prévu, ou parce que la chaîne d'approvisionnement ERC-4337 s'est bloquée au niveau du regroupement et que personne ne surveillait l'inclusion.

La posture claire est de traiter cela comme un diagramme à deux clés à chaque fois : autorité d'exécution et autorité de dépense. Si le design ne peut pas répondre, en une phrase, qui originaire la transaction (EOA vs bundler via EntryPoint) et exactement ce que le dépensier peut retirer (montant, expiration, portée de nonce), alors le système n'est pas « autonome ». Il est juste non surveillé.

Sources

• QuickNode
• Éco
• Uniswap
• Safe