Virtuals en partenariat avec la Fondation Ethereum publie l'ERC-8183 : un protocole commercial on-chain sans confiance

Auteur : Virtuals Protocol

Traduction : Deep潮 TechFlow

Deep潮 Introduction : Virtuals Protocol, en collaboration avec l’équipe dAI de la Fondation Ethereum, a publié la proposition de standard ERC-8183. L’idée centrale est de créer un protocole commercial on-chain sans confiance pour les interactions économiques entre AI Agents. Ce n’est pas un simple protocole de paiement, mais une infrastructure commerciale complète couvrant la spécification des tâches, la garde, la validation de livraison et la certification d’évaluation. En complément du ERC-8004 (identité et réputation des Agents), ces deux standards forment une boucle fermée : découverte, transaction, accumulation de réputation, meilleure découverte, davantage de transactions sans confiance. Si vous vous intéressez à la mise en œuvre de l’économie des AI Agents sur la blockchain, cet article mérite une lecture attentive.

Voici le contenu intégral :

Développé conjointement par Virtuals Protocol et l’équipe dAI de la Fondation Ethereum

Normes et spécifications :

Forum de discussion : ethereum-magicians.org/t/erc-8183-agentic-commerce/27902

Rejoignez la communauté Builder :

Les enjeux commerciaux : les prérequis pour une IA décentralisée

Si nous voulons que les AI Agents soient accessibles, décentralisés, non contrôlés par une plateforme unique, indépendants d’un fournisseur unique, sans point de défaillance unique, alors le commerce devient indispensable. Le commerce ne peut pas être une réflexion après coup ; il doit constituer une infrastructure fondamentale. Et cette infrastructure doit toujours être ouverte, sans permission. C’est précisément ce que @ethereum a été créé pour construire : un « espace numérique partagé sans propriétaire ».

Pourquoi ? Parce que la décentralisation au niveau des AI et des Agents nécessite un grand nombre d’Agents et de services indépendants. Par exemple, si un seul Agent peut générer des images, et qu’il cesse de fonctionner, peu importe le protocole utilisé, la génération d’images devient centralisée. Si un seul fournisseur contrôle l’exécution des transactions, la gestion des fonds dépend de sa volonté. Si une seule plateforme contrôle l’infrastructure de règlement, chaque fournisseur et client est soumis à ses règles, même s’il y a mille Agents sur cette plateforme.

Il faut donc ouvrir le commerce : tout Agent doit pouvoir acheter des services, tout Agent doit pouvoir en fournir. Pas de gardiens, pas de jardins clos, pas d’intermédiaires obligatoires.

Pourquoi la blockchain ?

L’essentiel est que le commerce ne peut fonctionner que si toutes les parties ont confiance dans l’exécution des transactions. Si le client paie d’avance, comment savoir si le fournisseur livrera ? Si le fournisseur livre d’abord, comment savoir si le client paiera ? Il faut quelqu’un qui détient les fonds, qui suit l’avancement du travail, et qui exécute le résultat : libérer le paiement à la fin, rembourser en cas d’échec. C’est cette confiance (ou son absence) qui, fondamentalement, a engendré des entités centralisées ou des gardiens.

Dans l’architecture traditionnelle, cette « personne » est la plateforme. Une entreprise détient les fonds en garde, contrôle la machine à états, décide qui doit être payé et quand. Ce modèle fonctionne — jusqu’à ce qu’il ne fonctionne plus. La plateforme peut changer ses règles, geler des fonds, retirer des fournisseurs, couper l’accès. Chaque participant dépend de la bonne volonté continue de la plateforme. C’est une centralisation, non pas au niveau du protocole, mais dans l’exécution. Ce n’est pas forcément une erreur, mais dans un système sans confiance, c’est nécessaire. Notre objectif est la « dé-totalisation » : empêcher qu’une seule entité ait un contrôle total sur la façon dont un Agent effectue ses transactions. Nous avons vu de nos propres yeux que les développeurs veulent une infrastructure fiable, dont ils peuvent dépendre, mais sans dépendre de la bonne volonté d’une plateforme unique.

Les contrats intelligents décentralisés sur la blockchain sont une tentative de solution à cela. La garde, la machine à états et la certification des évaluateurs existent dans un code public, immuable, appartenant à personne. Le contrat est un exécuteur neutre, produisant des signaux de réputation significatifs pour toutes les parties.

Le règlement on-chain peut aussi produire quelque chose qu’une plateforme centralisée ne peut pas fournir : des enregistrements portables, vérifiables, immuables. Chaque tâche complétée, chaque certification d’évaluateur, chaque hash de livraison est enregistré sur la blockchain, visible par tout Agent, toute plateforme, toute interface. Ces enregistrements alimentent le système de réputation et l’identité des Agents. Sans règlement on-chain, il n’y a pas d’historique vérifiable. Sans historique vérifiable, il n’y a pas de réputation portable. Sans réputation portable, chaque interaction avec un Agent recommence à zéro, en partant d’une confiance nulle.

C’est pourquoi un standard on-chain est nécessaire. La garde, la transition d’état, la certification — ces éléments doivent être neutres, sécurisés, exécutables.

La découverte, la négociation et la communication peuvent se faire on-chain ou off-chain, via n’importe quelle interface naturelle. L’Agent peut utiliser HTTP avec le protocole x402, comme s’il s’agissait d’une API standard ou d’une requête HTTPS. L’Agent n’a pas forcément besoin d’interagir directement avec la blockchain. Il signe un message, qui est traité par un facilitateur pour le règlement on-chain et la conformité. Ou bien l’Agent peut interagir directement via MCP ou A2A. L’interface est flexible, mais le règlement principal doit être sans confiance, programmatique, on-chain. C’est une infrastructure que les systèmes centralisés ne fourniront pas, car elle affaiblirait leur contrôle.

L’économie des Agents

Les modèles et Agents d’IA progressent rapidement chaque mois, devenant plus puissants. Des tâches qui nécessitaient il y a un an une expertise humaine — écrire du code de production, générer du contenu média spécialisé, analyser des données financières, coordonner des workflows complexes — peuvent aujourd’hui être accomplies par des Agents avec une qualité équivalente ou supérieure. Et cette capacité continue de s’accroître à un rythme accéléré. La trajectoire de l’IA rend cette nouvelle économie inévitable.

Plus les Agents deviennent puissants, plus leur travail a de la valeur. Un Agent capable de générer des images indiscernables de celles d’un photographe professionnel est une ressource payante. Un Agent qui analyse un portefeuille et exécute des trades optimisés gère de l’argent réel. Un Agent qui révise des documents juridiques et signale des risques effectue un travail facturé plusieurs centaines de dollars de l’heure par des humains.

C’est la grande transformation : l’IA et les Agents deviennent des acteurs économiques créant de la valeur et fournissant des services.

Lorsque l’IA devient accessible à tous, chaque personne, organisation ou appareil peut opérer via un Agent. L’économie va changer. Les Agents ne se contentent pas d’interagir avec les humains ou de leur fournir des services ; ils interagiront aussi entre eux, se fourniront mutuellement. Par exemple, un Agent coordonnant une campagne marketing pourrait signer avec un Agent de contenu, un Agent de distribution, un Agent d’analyse. L’économie devient un réseau d’échanges entre Agents, fonctionnant à la vitesse machine, à l’échelle mondiale.

Lorsque chaque Agent peut réaliser un travail à valeur ajoutée, et que tout le monde a un Agent, cela crée une économie où la majorité des activités commerciales transitent par des systèmes autonomes. C’est le futur que nous construisons.

Problème : le commerce sans confiance entre Agents

L’économie des Agents nécessite un commerce entre Agents. Et ce commerce, entre Agents qui ne se sont jamais rencontrés ni interagi, doit être sans confiance.

Chez l’humain, la confiance est au cœur des échanges, des embauches ou de l’utilisation de services. Dans ces cas, la confiance est médiée par la plateforme, les évaluations, le cadre juridique et les normes sociales. Lorsqu’un Agent embauche un autre Agent, ces mécanismes ne s’appliquent pas. Il n’y a pas de réputation sociale vérifiable, pas de lois ou de recours en temps réel, pas de plateforme ou de régulateur pour faire respecter l’accord.

La question devient donc : comment faire du commerce entre Agents sans confiance ?

On ne peut pas simplement transférer des tokens et espérer que tout se passe bien. Un transfert de tokens n’est pas un commerce, c’est un paiement sans garantie. Il n’y a pas d’enregistrement des accords, pas de mécanisme pour détenir des fonds avant la satisfaction du travail, pas de signal d’évaluation pour que d’autres Agents puissent juger, pas de recours si le fournisseur ne livre pas.

Ce qu’il faut, c’est un mécanisme structuré de collaboration : des fonds détenus par un contrat décentralisé, programmable, sans biais ; un travail soumis sous forme de livrables vérifiables ; une évaluation qui prouve que le livrable respecte les termes ; un résultat déterministe. Les fonds sont libérés à l’achèvement, remboursés en cas de rejet, récupérables en cas d’expiration. Tout cela doit contribuer à l’identité et à la réputation des parties.

ERC-8183 : Primitive Job

En collaboration étroite avec l’équipe dAI de @ethereumfndn, nous avons formalisé cela en un standard. ERC-8183 : Agentic Commerce, est un standard ouvert, sans permission, pour les applications commerciales d’Agents, implémenté sous forme de contrats intelligents on-chain pour la garde et la certification des évaluateurs.

ERC-8183 définit une unité centrale : le Job. Chaque Job implique trois parties — le client (Client), le fournisseur (Provider) et l’évaluateur (Evaluator). Chaque partie est simplement définie par son adresse de portefeuille, ce qui permet une large application.

Les composants et principes clés derrière le primitive Job incluent : (i) la spécification et la description de la tâche — une claire documentation de la tâche, du service ou du travail lié au paiement ; (ii) le paiement lui-même — conservé dans la garde jusqu’à l’état final, puis libéré de façon programmée ; (iii) la soumission de livrables enregistrés, vérifiables, traçables, protégeant à la fois le client et le fournisseur ; (iv) la certification par l’évaluateur — produisant des signaux de confiance sur l’identité et la réputation, pour un règlement sans confiance.

Ce processus fait évoluer le Job à travers quatre états clés, garantissant un commerce sans confiance :

Open → Funded → Submitted → Terminal (Completed / Rejected / Expired)

En résumé : le client crée un Job avec le fournisseur, y injecte des fonds, et bloque le paiement en garde. Après exécution, le fournisseur appelle submit, en déposant le livrable (ou sa référence) sur la blockchain. L’évaluateur examine le contenu, puis appelle complete (libérant les fonds au fournisseur) ou reject (remboursant le client). Si ni le fournisseur ni l’évaluateur n’agissent avant la date limite, le Job expire, et le client récupère ses fonds.

Ce standard reste volontairement minimaliste, formant une primitive atomique. Il ne prescrit pas le processus de négociation, la structure des frais, la résolution des litiges, la communication ou la découverte. Il définit uniquement le cycle de vie central du Job — la surface minimale pour un commerce d’Agents sans confiance.

L’évaluateur

Un concept clé et une décision de conception dans ERC-8183 est celui de l’évaluateur (Evaluator), défini simplement comme une adresse. C’est toujours un Agent, dans la définition la plus large.

Pour des tâches subjectives comme la rédaction, la conception ou l’analyse, l’évaluateur peut être un Agent IA, qui lit le contenu soumis, le compare à la requête, et juge. Pour des tâches déterministes comme le calcul, la génération de preuves ou la transformation de données, l’évaluateur peut être un contrat intelligent intégrant un vérificateur ZK. Le fournisseur soumet une preuve, que l’évaluateur vérifie on-chain, puis appelle automatiquement complete ou reject. Pour des scénarios à haut risque, l’évaluateur peut être multi-signature, DAO ou un vérificateur avec mise en jeu de fonds.

Le standard ne fait pas de distinction. Une adresse appelle complete ou reject. Que cette adresse soit un Agent LLM ou un circuit ZK, le protocole ne s’en soucie pas. Cela permet d’utiliser la même interface pour une tâche à 0,1 dollar d’image générée ou pour une gestion de fonds à 100 000 dollars.

Hooks : modularité et extensibilité

Le primitive Job est volontairement minimaliste. Mais le commerce ne l’est pas. Les applications réelles nécessitent des vérifications personnalisées, la mise à jour de la réputation, la répartition des frais, le transfert de fonds, des mécanismes d’enchères, et des logiques spécifiques à chaque cas d’usage. Une tâche d’évaluation de contenu, un échange de tokens ou une position sur un marché prédictif nécessitent des logiques très différentes.

ERC-8183 résout cela avec des Hooks. Un Hook est un contrat intelligent optionnel, attaché lors de la création du Job. Il reçoit des callbacks avant et après chaque opération, permettant d’exécuter une logique personnalisée sans modifier le cycle de vie principal. Un Hook est identifié par un seul sélecteur de fonction (quelle transition se produit), et reçoit les paramètres pertinents. Il peut vérifier des préconditions, bloquer des opérations invalides, déclencher des effets secondaires ou effectuer des transferts de tokens supplémentaires, le tout dans la même transaction que la modification principale.

Sans Hook, le contrat fonctionne normalement. La version sans Hook est conforme à ERC-8183. Les Hooks sont optionnels, non obligatoires. Cette conception maintient le contrat central simple, l’interface stable. De nouveaux cas d’usage peuvent être supportés par de nouveaux contrats Hook, en étendant la logique sur la chaîne, de façon programmatique et sans confiance — tout comme le cœur du standard.

Exemples d’applications commerciales

Le cœur du Job gère directement le commerce de services : paiement, livraison, évaluation. Mais l’économie pilotée par Agent n’est pas simple. Certains Jobs impliquent la gestion de capital client, pas seulement la facturation. D’autres nécessitent une enchère avant la distribution. D’autres encore requièrent une vérification de réputation externe. Ce sont des modèles économiques très différents, et les Hooks permettent à une même interface de Job de supporter cette diversité, faisant d’ERC-8183 une primitive commerciale universelle.

Les Jobs de service sont la base, sans Hook. Le client paie pour la génération de contenu, l’analyse de données ou la revue de code. Le processus de garde et d’évaluation est entièrement géré par le cœur.

Les Jobs liés au transfert de fonds dépassent la simple facturation. Le client fournit du capital (tokens à échanger, fonds à investir), le fournisseur le transforme, et le résultat doit revenir. Un Hook peut gérer ce flux de capital bidirectionnel en dehors de la garde principale, en s’assurant que le fournisseur dépose les tokens de sortie avant la fin du Job. Cela couvre de nombreux cas d’usage, comme le yield farming, l’échange de tokens, le rééquilibrage de portefeuille — tout Job où le fournisseur doit gérer des fonds clients ou disposer de capital initial pour exécuter la tâche, pas seulement pour facturer.

Les Jobs d’enchères inversées modifient le modèle de distribution. Ce n’est plus le client qui choisit à l’avance le fournisseur, mais le fournisseur qui fait concurrence sur le prix. Un Hook vérifie lors de la distribution que l’offre signée cryptographiquement correspond à la promesse du fournisseur. Personne ne peut falsifier ou nier les termes.

Les Jobs avec contrôle de réputation appliquent la confiance au niveau du protocole. Le Hook peut interroger ERC-8004 avant toute opération, empêchant les fournisseurs à faible réputation ou exigeant des conditions plus strictes pour des Agents non vérifiés.

Les Jobs protégeant la vie privée utilisent des Hooks pour une commercialisation sans divulgation de données. Un Hook de confidentialité peut exiger que le champ « submit » contienne une preuve ZKP ou une référence à un environnement sécurisé (TEE), plutôt que de publier des données sensibles sur la chaîne. Cela garantit que le paiement reste sans confiance et public, tandis que la propriété intellectuelle ou les données personnelles restent dans un « havre de paix », accessibles uniquement aux Agents autorisés.

Les Jobs d’évaluation des risques ou de souscription peuvent utiliser des Hooks pour une souscription transparente. Le Hook peut exiger que le fournisseur ou le souscripteur dépose une garantie, vérifier le score de réputation ERC-8004 ou d’autres indicateurs, appliquer une pénalité en cas d’échec, ou consulter des oracles de risque externes. Ces processus auparavant opaques deviennent transparents, programmables et compétitifs.

Chacune de ces applications peut être implémentée par un contrat Hook distinct, tout en conservant le cœur et la norme de Job inchangés. De nouvelles variantes économiques, applications commerciales ou logiques personnalisées sont autant de Hooks. Nous avons introduit quelques Hooks initiaux, illustrant la faisabilité, mais nous sommes encore au début. Les futurs Hooks pourraient concerner l’assurance, la collaboration créative, la coordination de la chaîne d’approvisionnement… Nous ne savons pas encore, et c’est justement le point. L’économie des Agents évoluera de manières que nous ne pouvons pas prévoir — nouveaux modèles économiques, nouveaux mécanismes de confiance, nouvelles formes de collaboration machine-à-machine. La norme est conçue pour évoluer avec cette évolution, pas pour la contraindre. Elle doit être construite dans l’ouverture, car les meilleures idées viendront de l’écosystème. Nous espérons la découvrir ensemble.

Synergie avec ERC-8004

ERC-8183 n’est pas isolé. Il est en synergie avec ERC-8004 (« Trustless Agents »), la norme d’identité, de réputation et de vérification des Agents d’Ethereum.

ERC-8004 résout la découverte et la confiance : comment un Agent trouve-t-il un autre, et évalue-t-il sa fiabilité ? Mais la valeur de son registre dépend de ses activités enregistrées. Une identité sans interaction commerciale ou comportement réel est un vide. La réputation doit reposer sur de véritables interactions. La vérification nécessite des livrables définis pour la validation.

ERC-8183 fournit la couche commerciale alimentant la confiance dans ERC-8004. Chaque Job est un signal de réputation. Chaque soumission est un livrable vérifiable. Chaque évaluation est une certification que d’autres Agents peuvent référencer.

Les deux standards forment une boucle, permettant aux Agents d’auto-organiser via des interactions sans confiance :

Découverte (8004) → Commerce (8183) → Réputation (8004) → Meilleure découverte → Plus de commerce sans confiance

Les deux sont indispensables. Ensemble, ils constituent la base du commerce et des interactions sans confiance entre Agents.

Au-delà du paiement

ERC-8183 n’est pas un protocole de paiement, mais une norme commerciale.

Le paiement déplace de l’argent. Mais le commerce nécessite bien plus. Il s’agit de tout ce qui entoure le paiement pour le rendre fiable et opérationnel : ce qui a été convenu, si le travail est terminé, qui l’a vérifié, que faire en cas d’échec. Dans le monde traditionnel, le commerce fonctionne grâce à un écosystème autour du paiement : évaluation et souscription du risque avant acceptation, extension de crédit pour permettre la transaction avant que les fonds soient disponibles, détection en temps réel de la fraude, mécanismes de protection contre les retards ou litiges, et un système de réputation basé sur la confiance accumulée par l’interaction. Ce sont ces fonctions qui donnent de la valeur aux processeurs de paiement, aux réseaux de cartes, et aux plateformes — pas seulement le transfert d’argent, mais l’infrastructure de confiance qui l’entoure.

Lorsque le commerce migre sur la blockchain, ces fonctions ne disparaissent pas. Elles doivent être reconstruites de façon sans confiance, programmable, ouverte. C’est ce que fait ERC-8183.

Le modèle de garde et de certification des évaluateurs du primitive Job ressemble à un mécanisme de « chargeback » avec des termes de règlement programmables. En intégrant la réputation on-chain d’ERC-8004 et d’autres indicateurs, on obtient une forme de souscription portable et vérifiable. Les Hooks remplacent la gestion centralisée du risque par une logique modulaire, compétitive, auditable, déployée par n’importe quel facilitateur. Le résultat n’est pas seulement une façon de transférer des fonds sur la chaîne, mais une reconstruction complète de l’infrastructure de confiance commerciale — ouverte, sans permission.

Les protocoles et interfaces de paiement existants, qu’il s’agisse de processeurs traditionnels ou de protocoles comme x402 pour les transferts de stablecoins, offrent une expérience fluide, native à Internet, pour le transfert de fonds. ERC-8183 gère tout le cycle de vie du paiement sans confiance : spécification, garde, soumission de livrables, certification par évaluateur, règlement déterministe. Les Agents peuvent interagir via x402 ou HTTP à l’interface, tandis que le règlement sous-jacent circule sur la chaîne via ERC-8183. Les deux sont complémentaires.

Immuabilité, non-réversibilité et problèmes de chargeback

Une autre préoccupation concernant le paiement indépendant est l’irréversibilité. Lorsqu’une carte de crédit est débitée et que le service est insatisfaisant, le consommateur peut contester et faire annuler la charge. Une fois l’argent transféré, il est perdu. Pour le paiement initial ou le transfert, c’est une objection valable.

ERC-8183 conserve cette idée dans sa structure contractuelle. Les fonds sont détenus en garde jusqu’à ce que l’évaluateur prouve que le livrable respecte les termes. En cas de rejet, ils sont remboursés au client. En cas d’expiration, ils sont automatiquement récupérés. C’est l’équivalent programmable, sans confiance, du modèle autorisation-encaissement — la mécanique qui fait fonctionner la carte, mais avec des termes préprogrammés et exécutés par code, plutôt qu’un jugement d’un réseau avec ses propres intérêts.

Pour des préautorisations à montant variable — comme un dépôt hôtelier ou un service dont l’étendue peut évoluer —, les Hooks peuvent être conçus pour bloquer un montant maximum, puis calculer le montant final lors de la clôture, à partir d’entrées vérifiables. Ce modèle permet d’adapter la confiance et le comportement dans le cadre d’un paiement par carte, tout en maintenant la transparence, l’ouverture, l’absence de confiance et l’enregistrement on-chain.

Les nouveaux acteurs économiques

La vague d’IA crée à une vitesse sans précédent de nouveaux acteurs économiques — acheteurs et vendeurs. Des millions de développeurs et non-développeurs utilisent des assistants IA pour construire et déployer des microservices, API et outils, souvent sans entité légale, sans site web, sans historique de transactions. Des Agents issus de grandes entreprises ou d’open source attirent des millions d’utilisateurs via des Agents personnels et des assistants.

Les systèmes de paiement traditionnels auront du mal à servir ces nouveaux commerçants. Pas par manque de technologie, mais parce qu’en validant un fournisseur, ils prennent en charge le risque : fraude, retards, litiges. Un commerçant sans historique, sans entité, sans historique de transactions est trop risqué pour être souscrit.

ERC-8183, par sa conception, est sans permission. Un fournisseur n’est qu’une adresse de portefeuille. Pas besoin d’inscription, pas besoin de souscription, pas de gardien. Le primitive Job offre à ces commerçants non seulement une méthode de paiement, mais une véritable gestion du cycle de vie commercial : spécification du travail, garde du paiement, soumission vérifiable, certification par évaluateur, fondations pour des transactions fiables.

L’incapacité à souscrire de nouveaux fournisseurs peut sembler une lacune temporaire. Mais un standard ouvert, par sa nature, réduit cette période. N’importe quel facilitateur peut déployer ERC-8183 dès aujourd’hui. L’écosystème évolue par expérimentation, pas par consensus institutionnel. Mais plus fondamentalement, ERC-8183, combiné à ERC-8004, comble non seulement cette lacune de souscription, mais résout la cause profonde : l’absence d’historique vérifiable pour les nouveaux commerçants. Chaque Job terminé est enregistré sur la blockchain : hash de livraison, certification d’évaluateur, résultat. Cet historique est portable, vérifiable, appartenant à personne.

Ce qui est crucial, c’est que ces enregistrements ne sont pas enfermés dans une plateforme unique. Aujourd’hui, la plateforme A connaît ton taux de retards, la plateforme B connaît ta note de vendeur, mais tu ne peux pas transférer ces données. Sur ERC-8183, la réputation devient un actif portable du commerçant, accessible par n’importe quel facilitateur, toute blockchain, toute interface conforme à ce standard. ERC-8183 alimente l’identité et la réputation on-chain (ERC-8004), et fournit des données de souscription.

Construire ensemble l’avenir des Agents et de l’IA décentralisée

ERC-8183 est une norme ouverte pour un commerce d’Agents sans confiance. Voici comment participer :

Construisez avec ERC-8183. Devenez facilitateur ! Déployez ERC-8183 sur votre blockchain. Développez SDK, wrappers, scanners et trackers. Créez de nouvelles interfaces et expériences, permettant un règlement sécurisé, vérifiable, on-chain, via ERC-8183. Construisez un cadre d’Agents natifs intégrant cette norme.

Expérimentez et développez des Hooks. Besoin de paiements par étape ou de résolution de litiges ? Créez-les en tant que Hooks. C’est un espace pour la créativité et la diversification des applications.

Construisez et enregistrez des évaluateurs. Les évaluateurs sont essentiels pour garantir la sécurité et la confiance sans confiance dans le commerce d’Agents, mais leur disponibilité est limitée. Développez des évaluateurs pour des domaines spécifiques, notamment dans des secteurs entièrement vérifiables. Enregistrez-les sur ERC-8004. Contribuez à la réputation et à l’identité des Agents.

Contribuez et donnez votre avis. C’est une norme collective. Elle ne pourra évoluer que par des expérimentations, des usages réels, des retours sincères et des itérations. Si quelque chose manque, proposez. Si vous voyez des erreurs, challengez. La norme, le code, la discussion sont ouverts. Ensemble, elle doit évoluer.

L’économie des Agents reposera sur des standards ouverts ou sur des jardins clos. Nous choisissons l’ouverture. Un espace numérique partagé.

ERC-8004 pour la confiance. ERC-8183 pour le commerce. Et le reste, c’est à vous de le construire.

Liens utiles :

Norme ERC-8183 : [lien à insérer]

Norme ERC-8004 : eips.ethereum.org/EIPS/eip-8004

Discussion ERC-8183 : ethereum-magicians.org/t/erc-8183-agentic-commerce/27902

Communauté Telegram :