Virtuals, en collaboration avec la Fondation Ethereum, publie l’ERC-8183 : un protocole commercial décentralisé sur chaîne
TechFlow SélectionTechFlow Sélection
Virtuals, en collaboration avec la Fondation Ethereum, publie l’ERC-8183 : un protocole commercial décentralisé sur chaîne
ERC-8004 pour la confiance, ERC-8183 pour le commerce.
Dédié à des analyses Web3 approfondiesAuteur : Virtuals Protocol
Traduction : TechFlow
Introduction de TechFlow : Virtuals Protocol, en collaboration avec l’équipe dAI de la Fondation Ethereum, a publié la proposition de norme ERC-8183. Son objectif central est d’établir un protocole commercial décentralisé et sans confiance entre agents IA sur la chaîne de blocs.
Il ne s’agit pas d’un simple protocole de paiement, mais bien d’une infrastructure commerciale complète couvrant la spécification des tâches, la mise en séquestre des fonds, la vérification de la livraison et la certification par des évaluateurs.
En complément de la norme antérieure 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 suivez les voies concrètes de déploiement économique des agents IA sur la chaîne de blocs, cet article mérite une lecture attentive.
Texte intégral :
Développé conjointement par Virtuals Protocol et l’équipe dAI de la Fondation Ethereum
Spécification de la norme : https://eips.ethereum.org/EIPS/eip-8183
Espace de discussion : ethereum-magicians.org/t/erc-8183-agentic-commerce/27902
Rejoignez la communauté des développeurs : https://t.me/erc8183
Le commerce : condition préalable à l’IA décentralisée
Si nous voulons que les agents IA soient accessibles, décentralisés, non contrôlés par une seule plateforme, indépendants d’un fournisseur unique et exempts de points de défaillance uniques, alors le commerce est indispensable. Le commerce ne peut pas être une réflexion a posteriori : il doit constituer une partie intégrante de l’infrastructure. Et ce commerce doit rester ouvert et sans autorisation à tout moment. C’est précisément ce « espace numérique partagé sans propriétaire » que @ethereum a été conçu pour bâtir.
Pourquoi ? Parce que la décentralisation au niveau de l’IA et des agents exige un grand nombre d’agents et de services indépendants. Prenons un exemple : si un seul agent est capable de générer des images, et qu’il cesse ses services, alors la génération d’images devient centralisée, quelle que soit la robustesse du protocole sous-jacent. Si un seul fournisseur contrôle l’exécution des transactions, la gestion des fonds dépend entièrement de sa volonté opérationnelle. Si une seule plateforme gère l’infrastructure de règlement, chaque fournisseur et chaque client reste soumis aux règles de cette plateforme, même si celle-ci héberge mille agents.
C’est pourquoi nous avons besoin d’un commerce ouvert : tout agent doit pouvoir acheter des services, tout agent doit pouvoir en fournir. Aucun gardien n’est requis, aucune « jardin fermé » n’est toléré, aucun intermédiaire imposé.
Pourquoi la blockchain ?
L’enjeu essentiel est que le commerce ne fonctionne que lorsque toutes les parties peuvent faire confiance à l’exécution de la transaction. Si le client paie d’abord, comment savoir si le fournisseur livrera effectivement ? Si le fournisseur livre d’abord, comment garantir que le client paiera ? Quelqu’un doit détenir les fonds, suivre l’état d’avancement du travail et exécuter le résultat final : libérer le paiement en cas de succès, rembourser en cas d’échec. C’est précisément la confiance (ou son absence) qui, fondamentalement, engendre des entités centralisées ou des gardiens.
Dans les architectures traditionnelles, ce « quelqu’un » est la plateforme. Une entreprise détient les fonds en séquestre, contrôle la machine à états et décide qui sera rémunéré, et quand. Ce système fonctionne — jusqu’à ce qu’il ne fonctionne plus. La plateforme peut modifier ses règles, geler des fonds, retirer un fournisseur ou fermer complètement. Chaque participant dépend de la bonne foi continue de la plateforme. Il s’agit là d’une centralisation non pas au niveau du protocole, mais au niveau de l’exécution. Cela n’est pas nécessairement mauvais en soi, mais dans un système caractérisé par une absence de confiance, cela devient inévitable. Notre objectif est la « dé-totalisation » : empêcher toute entité unique d’exercer un contrôle absolu sur la manière dont les transactions entre agents sont menées. Nous l’avons constaté de visu : les développeurs recherchent une infrastructure fiable, mais qu’ils ne soient pas obligés de considérer comme dépendante de la bonne foi d’une seule plateforme.
Les contrats intelligents décentralisés sur la chaîne de blocs constituent justement une tentative de réponse à ce défi. La mise en séquestre, la machine à états et la certification par les évaluateurs résident dans un code public, immuable et appartenant à personne. Le contrat agit ainsi comme un exécutant neutre, générant des signaux significatifs pour la réputation de chacune des parties.
Le règlement sur la chaîne permet également de produire ce que les plateformes centralisées ne peuvent offrir : des enregistrements portables, vérifiables et immuables. Chaque tâche achevée, chaque certification par un évaluateur, chaque hachage de livrable est enregistré sur la chaîne, accessible à tout agent, toute plateforme ou toute interface. Ces enregistrements constituent la matière première alimentant les systèmes de réputation et l’identité des agents. Sans règlement sur la chaîne, 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 entre agents commence à zéro confiance.
C’est pourquoi une norme sur la chaîne est indispensable. La mise en séquestre, les transitions d’états et la certification doivent être neutres, sécurisées et exécutables.
La découverte, la négociation et la communication peuvent se dérouler sur ou hors chaîne, via n’importe quelle interface la plus naturelle. Les agents peuvent interagir via le protocole d’interface x402 sur HTTP, avec une expérience similaire à celle d’une API standard ou d’une requête HTTPS. Un agent n’a pas nécessairement besoin d’interagir directement avec la chaîne : il signe un message, que le facilitateur traite ensuite pour le règlement sur la chaîne et la conformité à la norme. Ou bien l’agent peut interagir directement via MCP ou A2A. L’interface est flexible, mais le cœur du règlement doit être sans confiance, programmé et sur la chaîne. Il s’agit d’une infrastructure que les systèmes centralisés ne fourniront jamais, car elle affaiblirait leur capacité de contrôle.
L’économie des agents
Les modèles d’IA et les agents progressent rapidement chaque mois, devenant toujours plus performants. Des tâches qui nécessitaient encore il y a un an l’expertise humaine — rédiger du code de production, générer des contenus multimédias professionnels, analyser des données financières ou coordonner des flux de travail multi-étapes — sont désormais réalisées par des agents avec une qualité égale, voire supérieure. Et leurs capacités continuent de s’accélérer. La trajectoire de développement de l’IA rend inévitable l’émergence d’une nouvelle économie.
A mesure que les agents deviennent plus puissants, les travaux qu’ils accomplissent acquièrent davantage de valeur. Un agent capable de générer des images indiscernables de celles prises par un photographe professionnel constitue un service payant. Un agent capable d’analyser un portefeuille et d’exécuter des transactions d’optimisation gère de véritables fonds. Un agent capable d’examiner des documents juridiques et d’en signaler les risques réalise un travail facturé des centaines de dollars par heure chez les humains.
C’est là la transformation clé : l’IA et les agents deviennent des acteurs économiques créateurs de valeur et fournisseurs de services.
Lorsque l’IA devient universellement accessible, chaque individu, organisation ou appareil pourrait agir via un agent. L’économie subit alors une mutation profonde. Les agents ne se contentent pas d’interagir avec les humains ou de leur fournir des services ; ils interagissent aussi entre eux et se fournissent mutuellement des services. Par exemple, un agent chargé de coordonner une campagne marketing engage des agents spécialisés dans le contenu, la diffusion et l’analyse. L’économie devient ainsi un réseau d’agents transactionnant entre eux, fonctionnant à la vitesse des machines et s’étendant à l’échelle mondiale.
Lorsque les agents sont capables d’accomplir des tâches à forte valeur ajoutée, et que chacun possède son propre agent, le résultat est une économie où la majorité des activités commerciales transitent par des systèmes autonomes. Tel est l’avenir que nous sommes en train de construire.
Problématique : un commerce sans confiance entre agents
L’économie des agents exige un commerce entre agents. Or, le commerce entre agents n’ayant jamais interagi auparavant, issus d’organisations ou de chaînes différentes, doit être sans confiance.
Lorsque des humains concluent des transactions, s’embauchent mutuellement ou utilisent des services, la confiance est au cœur du processus. Dans ces cas, la confiance est médiée par les plateformes, les évaluations, les systèmes juridiques et les normes sociales. Lorsqu’un agent embauche un autre agent, aucun de ces mécanismes n’est applicable : aucune réputation sociale n’est consultable, aucune poursuite juridique ou réputationnelle ne peut fonctionner à la vitesse des transactions entre machines, et aucun organisme de régulation ou plateforme n’est en mesure d’assurer l’exécution.
La question devient donc : comment rendre possible un commerce entre agents sans confiance ?
Vous ne pouvez pas simplement transférer un jeton et espérer que tout se passe bien. Un transfert de jeton n’est pas un acte commercial : c’est uniquement un paiement non garanti. Aucun accord n’indique ce qui a été convenu, aucun mécanisme ne retient les fonds tant que le travail n’est pas jugé satisfaisant, aucune évaluation ne produit de signal exploitable par d’autres agents, et aucune voie de recours n’existe si le fournisseur ne livre pas.
Ce qu’il faut, c’est un mécanisme structuré de collaboration : les fonds sont détenus en séquestre par un mécanisme décentralisé, programmable et impartial ; le travail est soumis sous forme de livrables vérifiables ; un évaluateur certifie si le livrable répond aux termes convenus ; le résultat est déterministe. Les fonds sont libérés en cas de réussite, remboursés en cas de rejet, et récupérables en cas d’expiration. Tous ces éléments contribuent ou renvoient à l’identité et à la réputation des parties concernées.
ERC-8183 : la primitive « Job »
Nous avons collaboré étroitement avec l’équipe dAI de la @ethereumfndn pour formaliser cette approche en une norme. ERC-8183 : Agentic Commerce est une norme ouverte et sans autorisation destinée aux applications commerciales entre agents, où la mise en séquestre et la certification par les évaluateurs sont implémentées sous forme de contrats intelligents sur la chaîne.
ERC-8183 définit une unité fondamentale : le « Job ». Chaque Job implique trois parties — le client (Client), le fournisseur (Provider) et l’évaluateur (Evaluator). Chacune de ces parties est définie uniquement par son adresse de portefeuille, rendant cette primitive largement applicable.
Les composants clés et principes sous-jacents à la primitive « Job » comprennent : (i) la spécification et la description de la tâche — un enregistrement clair de la tâche, du service ou du travail, lié au paiement ; (ii) le paiement lui-même — conservé en séquestre dans un mécanisme de programmation impartial jusqu’à l’état final, puis libéré de façon programmée ; (iii) la soumission de livrables enregistrés, vérifiables et traçables, protégeant à la fois le client et le fournisseur ; (iv) la certification par l’évaluateur — générant des signaux significatifs pour l’identité et la réputation des parties, alignant les incitations pour un règlement sans confiance.
Cela conduit le « Job » à travers quatre états clés, assurant un commerce sans confiance :
Ouvert → Financé → Soumis → Terminal (Terminé / Rejeté / Expiré)
Pour résumer : le client crée un « Job » avec un fournisseur, puis injecte des fonds, verrouillant ainsi le paiement en séquestre. Une fois le travail terminé, le fournisseur appelle la fonction submit, publiant sur la chaîne le livrable (ou sa référence). L’évaluateur examine la soumission et appelle soit complete (libérant les fonds au fournisseur), soit 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.
La norme est volontairement minimaliste, formant une primitive atomique. Elle ne prescrit ni le processus de négociation, ni la structure des frais, ni la résolution des litiges, ni le protocole de communication, ni le mécanisme de découverte. Elle ne définit que le cycle de vie fondamental du « Job » — la surface minimale viable pour un commerce sans confiance entre agents.
L’évaluateur
Un concept clé et une décision de conception fondamentale d’ERC-8183 est celle de l’évaluateur (Evaluator), défini uniquement comme une adresse. Il s’agit toujours d’un agent, pris dans son sens le plus large.
Pour des tâches subjectives telles que l’écriture, la conception ou l’analyse, l’évaluateur peut être un agent IA lisant la soumission, la comparant à la demande initiale et rendant un jugement. Pour des tâches déterministes telles que le calcul, la génération de preuves ou la transformation de données, l’évaluateur est un contrat intelligent intégrant un vérificateur ZK. Le fournisseur soumet une preuve, que l’évaluateur vérifie sur la chaîne et déclenche automatiquement complete ou reject. Dans des scénarios à haut risque, l’évaluateur peut être un multisignature, un DAO ou des validateurs soutenus par des engagements.
La norme ne distingue pas ces cas. Une adresse appelle complete ou reject. Peu importe que cette adresse exécute un agent LLM ou un circuit ZK : le protocole n’en tient pas compte. Cette conception permet à la même interface de traiter aussi bien une tâche de génération d’image à 0,1 $ qu’une mission de gestion de fonds à 100 000 $.
Les Hooks : extensibilité modulaire
La primitive « Job » est volontairement minimaliste. Mais le commerce ne l’est pas. Les applications réelles nécessitent une logique personnalisée pour la validation, la mise à jour de la réputation, la répartition des frais, le transfert de fonds, les mécanismes d’enchères et des logiques spécifiques au domaine. Une tâche d’évaluation de contenu, un échange de jetons et une position sur un marché prédictif exigent chacun une logique radicalement différente.
ERC-8183 résout ce problème grâce aux « Hooks ». Un Hook est un contrat intelligent optionnel attaché lors de la création du « Job ». Il reçoit des rappels avant et après chaque opération, permettant d’exécuter une logique personnalisée autour du cycle de vie fondamental, sans le modifier. Un Hook est identifié par un sélecteur de fonction unique (indiquant quelle transition est en cours) et reçoit les paramètres pertinents. Il peut vérifier des conditions préalables, bloquer des opérations invalides, déclencher des effets secondaires ou effectuer des transferts supplémentaires de jetons, le tout dans la même transaction que la modification d’état principale.
En l’absence de Hook configuré, le contrat s’exécute normalement. Une implémentation sans Hook est pleinement conforme à ERC-8183. Les Hooks sont facultatifs, non requis. Cette conception maintient le contrat principal léger et son interface stable. De nouveaux cas d’usage sont pris en charge par de nouveaux contrats Hook, tandis que la logique d’extension demeure sur la chaîne, programmée et sans confiance — tout comme le cœur du protocole.
Exemples d’applications commerciales
Le « Job » fondamental gère le commerce direct de services : paiement, livraison, évaluation. Mais l’économie pilotée par les agents n’est pas simple. Certains « Jobs » impliquent la gestion des capitaux du client, et non seulement le paiement de frais. D’autres nécessitent des enchères avant l’attribution du fournisseur. D’autres encore exigent des vérifications de confiance basées sur des données externes de réputation. Ce sont des modèles économiques fondamentalement différents, et les Hooks permettent à la même interface de « Job » fondamentale de supporter cette diversité, faisant d’ERC-8183 une primitive commerciale universelle.
Le « Job » de service constitue le cas de base, ne nécessitant aucun Hook. Le client paie pour la génération de contenu, l’analyse de données ou la relecture de code. Le processus fondamental de mise en séquestre et d’évaluation suffit entièrement.
Le « Job » de transfert de fonds va au-delà des frais de service. Le client fournit du capital (jetons à échanger, fonds à investir), le fournisseur le transforme, et la sortie doit être restituée. Un Hook peut gérer ce flux de capitaux bidirectionnel en dehors de la séquestre fondamentale, garantissant que le fournisseur dépose les jetons de sortie avant la fin du « Job ». Cela couvre un large éventail d’applications, telles que le yield farming, l’échange de jetons ou la rééquilibration de portefeuilles — toute situation où le fournisseur traite les fonds du client ou a besoin d’un capital initial pour exécuter la tâche, et non pas simplement percevoir des frais.
Le « Job » aux enchères inverse le modèle d’attribution. Plutôt que le client ne choisisse pas à l’avance le fournisseur, ce sont les fournisseurs qui font des offres concurrentielles sur le prix. Le Hook vérifie, lors de l’attribution, les signatures cryptographiques des offres, prouvant que le fournisseur sélectionné s’est bel et bien engagé au prix annoncé. Aucune des parties ne peut falsifier ou nier les termes convenus.
Le « Job » à accès contrôlé par la réputation met en œuvre la confiance au niveau du protocole. Le Hook interroge ERC-8004 avant d’autoriser une opération, bloquant les fournisseurs à faible réputation ou imposant des conditions plus strictes aux agents non vérifiés.
Le « Job » protégé pour la confidentialité utilise les Hooks pour permettre un commerce sans exposition de données. Un Hook de confidentialité peut exiger que le champ « submit » contienne une référence à une preuve à divulgation nulle de connaissance (ZKP) ou à un environnement chiffré (tel qu’un TEE), plutôt que de publier des données sensibles liées à la tâche directement sur la chaîne. Cela garantit que le paiement est sans confiance et public, tandis que la propriété intellectuelle réelle ou les données personnelles restent dans un « sanctuaire », accessible uniquement aux agents autorisés.
Le « Job » d’évaluation ou de souscription des risques peut mettre en œuvre la souscription au niveau du protocole via les Hooks. Le Hook peut exiger que le fournisseur ou le souscripteur engage un collatéral, vérifie le score de réputation ERC-8004 et d’autres indicateurs pertinents avant attribution, applique une pénalité (slash) sur le dépôt en cas d’échec de l’évaluation, ou interroge un oracle externe de risque. Ces processus d’approbation, autrefois opaques, peuvent ainsi devenir transparents, programmables et compétitifs.
Chacune de ces applications peut être implémentée sous la forme d’un contrat Hook distinct, préservant intactes les fonctions fondamentales et la primitive « Job » standard. De nouveaux modèles économiques, applications commerciales ou variantes de logique personnalisée correspondent à de nouveaux Hooks. Nous avons introduit quelques Hooks initiaux, à titre d’exemples illustrant les possibilités, mais nous pensons n’avoir fait que gratter la surface : les Hooks les plus intéressants restent encore à écrire. À quoi ressemblera le commerce des agents dans les domaines de l’assurance, de la collaboration créative ou de la coordination de la chaîne logistique ? Nous l’ignorons encore — et c’est précisément le point. Le commerce des agents évoluera de façons que nous ne pouvons pas encore pleinement anticiper — de nouveaux modèles économiques, de nouveaux mécanismes de confiance, de nouvelles formes de collaboration entre machines. Cette norme est conçue pour croître avec cette évolution, non pour la contraindre. Elle doit être construite ouvertement — et le sera, car les meilleures idées viendront de l’écosystème. Nous attendons avec impatience de les découvrir ensemble.
Une relation symbiotique avec ERC-8004
ERC-8183 n’existe pas isolément. Elle entretient une relation symbiotique avec ERC-8004 (« Agents sans confiance »), la norme d’identité, de réputation et de vérification des agents sur Ethereum.
ERC-8004 résout les problèmes de découverte et de confiance : comment les agents se trouvent-ils mutuellement et évaluent-ils leur fiabilité ? Toutefois, la valeur de son registre dépend des activités qu’il enregistre. Une identité sans activité commerciale ou comportementale est un dossier vide. La réputation exige des interactions réelles pour être mesurée. La vérification exige des livrables définis à contrôler.
ERC-8183 fournit les activités commerciales qui nourrissent la couche de confiance d’ERC-8004. Chaque « Job » constitue un signal de réputation. Chaque soumission est un livrable que les évaluateurs peuvent examiner. Chaque évaluation est une certification que d’autres agents peuvent référencer.
Les deux normes forment une boucle, susceptible de permettre aux agents d’atteindre une auto-organisation plus robuste grâce à des interactions sans confiance :
Découverte (8004) → Commerce (8183) → Réputation (8004) → Meilleure découverte → Plus de commerce sans confiance
Aucune des deux normes ne peut fonctionner sans l’autre. Ensemble, elles 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 exige bien plus que le simple déplacement d’argent. Le commerce englobe tout ce qui entoure le paiement afin de le rendre fiable et fonctionnel : ce qui a été convenu, si le travail est achevé, qui l’a vérifié, et que faire en cas d’échec. Dans le monde traditionnel, le commerce fonctionne grâce aux dispositifs associés au paiement : l’évaluation des risques et la souscription des commerçants avant qu’ils ne puissent accepter les paiements, l’octroi de crédit permettant aux acheteurs de transiger avant même que les fonds ne soient disponibles, la détection en temps réel de la fraude dans des milliards de transactions, les mécanismes de remboursement et de contestation protégeant les acheteurs en cas de défaillance du service, et les systèmes de réputation accumulés au fil des interactions répétées. Ce sont ces fonctionnalités qui constituent la valeur des processeurs de paiement, des organisations de cartes et des plateformes — pas le simple déplacement des fonds, mais l’infrastructure de confiance qui l’entoure.
Lorsque le commerce migre sur la chaîne, ces fonctionnalités ne disparaissent pas. Elles doivent être reconstruites de façon sans confiance, programmable et ouverte. C’est précisément ce que fait ERC-8183.
Le modèle de mise en séquestre et de certification par l’évaluateur de la primitive « Job » est analogue à un mécanisme de remboursement doté de clauses de règlement programmables et prédéfinies. L’utilisation de la réputation sur la chaîne d’ERC-8004 et d’autres indicateurs de réputation sur la chaîne dans le cadre d’ERC-8183 est similaire à une souscription propriétaire dotée d’un historique portable et vérifiable. Les Hooks remplacent l’évaluation centralisée des risques par une logique modulaire, concurrentielle et auditable, que tout facilitateur peut déployer. Le résultat n’est pas seulement un moyen de transférer des fonds sur la chaîne, mais une reconstruction complète de l’infrastructure de confiance commerciale — ouverte et sans autorisation.
Les protocoles de paiement et d’interfaces existants, qu’il s’agisse de processeurs traditionnels ou de protocoles de transfert de stablecoins comme x402, offrent une expérience fluide et native du Web, gérant le déplacement des fonds. ERC-8183 gère quant à elle le cycle de vie complet transformant un paiement en une transaction sans confiance : spécification, mise en séquestre, soumission de livrables, certification par l’évaluateur et règlement déterministe. Les agents peuvent interagir au niveau de l’interface via x402 ou HTTP, tandis que le règlement sous-jacent s’effectue sur la chaîne via ERC-8183. Ces deux niveaux sont complémentaires.
Irrévocabilité, séquestre et remboursements
Une autre inquiétude liée aux paiements indépendants est leur irrévocabilité. Lorsqu’un débit est effectué sur une carte de crédit et que le service n’est pas satisfaisant, le consommateur peut contester la transaction et annuler le débit. Une fois le paiement envoyé, l’argent a disparu. Pour les paiements et transferts bruts, c’est une objection réelle et valable.
ERC-8183 conserve ce concept fondamental dans sa structure contractuelle. Les fonds sont conservés en séquestre jusqu’à ce qu’un évaluateur atteste que le livrable répond aux termes convenus. En cas de rejet, le remboursement est versé au client. En cas d’expiration, les fonds sont automatiquement récupérés. Il s’agit de l’équivalent programmable et sans confiance du modèle « autorisation-capture » — celui qui fait fonctionner les cartes bancaires — à la différence près que les termes sont codés à l’avance et exécutés par le code, et non arbitrés après coup par un réseau ayant ses propres intérêts.
Pour les autorisations préalables à montant incertain — dépôt d’hôtel, service dont la portée pourrait s’étendre — la flexibilité des Hooks permet de verrouiller un montant maximal, puis de régler le montant final selon des entrées vérifiables à la conclusion. Cette architecture prend en charge les modèles de confiance et les comportements flexibles des cartes bancaires, tout en maintenant la transparence, l’ouverture, l’absence de confiance et le caractère on-chain du règlement.
Une nouvelle vague d’acteurs économiques
La vague d’IA crée, plus rapidement que jamais auparavant, de nouveaux acteurs économiques — à la fois acheteurs et marchands. Des millions de développeurs et de non-développeurs utilisent des assistants de programmation IA pour construire et publier des microservices, des API et des outils, dont beaucoup n’ont pas d’entité juridique, ni de site web, ni d’historique transactionnel. Des agents provenant de sociétés technologiques et de cadres open source attirent déjà des millions d’utilisateurs via des agents IA personnels et des assistants.
Les systèmes de paiement traditionnels auront du mal à servir ces marchands. Ce n’est pas une question de limitation technique, mais plutôt que, lorsqu’un processeur approuve un fournisseur, il assume le risque inhérent à ce fournisseur : fraude, remboursements, litiges. Un marchand sans historique, sans entité légale ni antécédents présente un risque trop élevé pour être souscrit.
ERC-8183 est conçue comme une norme sans autorisation. Un fournisseur est simplement une adresse de portefeuille. Aucun processus d’inscription, aucune souscription, aucun gardien. La primitive « Job » offre à ces marchands bien plus qu’un simple moyen de recevoir des paiements : elle leur fournit un cycle de vie commercial complet — spécification du travail, paiement en séquestre, soumission vérifiable de livrables et certification par l’évaluateur — posant ainsi les bases d’un commerce fiable.
L’incapacité à souscrire de nouveaux fournisseurs peut être perçue comme un écart temporaire. Une norme ouverte comprime structurellement ce délai. Tout facilitateur peut déployer ERC-8183 dès aujourd’hui. L’écosystème évolue par expérimentation, non par consensus institutionnel. Mais plus fondamentalement, ERC-8183 combinée à ERC-8004 ne comble pas seulement cet écart de souscription : elle résout sa cause première. Les processeurs ne peuvent souscrire de nouveaux marchands parce qu’il leur manque un historique vérifiable. ERC-8183 génère précisément cet historique. Chaque « Job » achevé est enregistré sur la chaîne : hachage du livrable, certification par l’évaluateur, résultat. Cet historique est portable, vérifiable et appartient à personne.
Il est important de noter que cet enregistrement n’est pas verrouillé au sein d’une seule plateforme. Aujourd’hui, la plateforme A connaît votre taux de remboursements, la plateforme B connaît votre note de vendeur, mais vous ne pouvez pas emporter ces données avec vous. Avec ERC-8183, la réputation est un actif portable du marchand, lisible par tout facilitateur, toute chaîne ou toute interface compatible avec cette norme. ERC-8183 nourrit l’identité et la réputation sur la chaîne (ERC-8004) et fournit les données nécessaires à la souscription.
Construisons ensemble l’avenir du commerce des agents et de l’IA décentralisée
ERC-8183 est une norme ouverte et sans confiance pour le commerce entre agents. Voici comment y participer :
Bâtissez avec ERC-8183. Devenez facilitateur ! Déployez ERC-8183 sur votre chaîne. Créez des SDK, des wrappers, des scanners et des traceurs. Concevez de nouvelles interfaces et expériences permettant un règlement sûr et vérifiable sur la chaîne via ERC-8183. Développez des frameworks d’agents nativement compatibles avec cette norme.
Explorez, expérimentez et construisez des Hooks. Vous avez besoin de paiements par étapes ou d’un mécanisme de résolution des litiges ? Construisez-les sous forme de Hooks. C’est l’espace où la créativité et la diversité des applications peuvent s’épanouir.
Construisez et enregistrez des évaluateurs. Les évaluateurs sont une composante critique pour assurer la sécurité et le commerce sans confiance entre agents, mais ils sont actuellement très peu nombreux. Construisez des évaluateurs spécialisés pour des domaines spécifiques, notamment ceux entièrement vérifiables. Enregistrez-les sur ERC-8004. Contribuez de façon significative à la réputation et à l’identité des agents.
Contribuez et donnez votre avis. Il s’agit d’une norme collective. Seule une expérimentation large, une utilisation dans le monde réel, des retours francs et une itération continue permettront à cette norme de devenir ce qu’elle doit être. Si quelque chose vous semble manquer, dites-le. Si vous repérez une erreur, remettez-la en question. La spécification est ouverte, le code est ouvert, la discussion est ouverte. Cela exige une évolution commune.
L’économie des agents reposera soit sur des normes ouvertes, soit sur des « jardins clos ». Nous choisissons les normes ouvertes. Un espace numérique partagé.
ERC-8004 pour la confiance. ERC-8183 pour le commerce. Le reste, c’est à vous de le construire.
Liens connexes :
- Spécification ERC-8183 : https://eips.ethereum.org/EIPS/eip-8183
- Spécification ERC-8004 : eips.ethereum.org/EIPS/eip-8004
- Discussion ERC-8183 : ethereum-magicians.org/t/erc-8183-agentic-commerce/27902
- Communauté Telegram : https://t.me/erc8183
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@virtuals_io
