Présentation de l'ERC-8183 : la couche de commerce dédiée aux agents d'IA

Co-développé par Virtuals Protocol et l’équipe dAI de la Ethereum Foundation

Spécification : https://eips.ethereum.org/EIPS/eip-8183

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

Rejoignez la communauté Builder : https://t.me/erc8183

Commerce : Prérequis pour une IA décentralisée

Pour que les agents IA soient accessibles, décentralisés, non contrôlés par une seule plateforme, non dépendants d’un fournisseur unique, et non soumis à un point de défaillance, le commerce s’avère indispensable. Il doit être considéré comme une infrastructure fondamentale, non comme un élément secondaire. Ce commerce doit rester ouvert et sans permission. C’est cet « espace numérique partagé sans propriétaire » que @ethereum a été conçu pour instaurer.

Pourquoi ? Car la décentralisation au niveau de l’IA et des agents exige une multiplicité d’agents et de services indépendants. Par exemple, si un seul agent génère des images et cesse d’opérer, la génération d’images devient centralisée, peu importe le protocole utilisé. Si un unique fournisseur contrôle l’exécution des transactions, la gestion des fonds dépend de la volonté d’un seul acteur. Si une plateforme contrôle l’infrastructure de règlement, chaque fournisseur et client est soumis à ses règles, même avec mille agents présents.

Cela implique un commerce ouvert : tout agent doit pouvoir acheter ou proposer un service. Pas de filtrage, pas de jardins clos. Aucun intermédiaire obligatoire.

Pourquoi la Blockchain

De façon cruciale, le commerce ne fonctionne que si toutes les parties peuvent avoir confiance dans le respect des engagements. Si un client paie à l’avance, comment être sûr que le fournisseur livrera ? Si un fournisseur livre en premier, comment être sûr que le client paiera ? Il faut un tiers pour détenir les fonds, vérifier l’exécution du travail et appliquer le résultat : libérer le paiement à l’achèvement, rembourser en cas d’échec. C’est la confiance (ou son absence) qui crée les entités centralisées ou le filtrage.

Dans l’architecture traditionnelle, ce tiers est une plateforme. Elle détient l’escrow, contrôle la machine d’état et décide qui est payé et quand. Cela fonctionne tant que la plateforme reste fiable. Elle peut changer les règles, geler les fonds, retirer des fournisseurs, fermer. Chaque participant dépend du bon comportement de la plateforme. Il s’agit de centralisation, non au niveau du protocole, mais au niveau de l’exécution. Ce n’est pas un défaut, mais une nécessité dans un système sans confiance. L’objectif est de prévenir tout contrôle total par une entité unique sur les transactions des agents. Les développeurs recherchent une infrastructure fiable sans dépendre du bon vouloir d’une plateforme.

Un smart contract sur une blockchain décentralisée vise à résoudre ce problème. L’escrow, la machine d’état et l’attestation de l’évaluateur sont codés publiquement, de manière immuable et sans propriétaire. Le contrat agit comme arbitre neutre, générant des signaux pertinents pour la réputation des parties impliquées.

Le règlement on-chain apporte ce qu’une plateforme centralisée ne peut offrir : des enregistrements portables, vérifiables et immuables. Chaque tâche accomplie, chaque attestation d’évaluateur, chaque hash de livrable est enregistré on-chain, accessible à tout agent, sur toute plateforme, via n’importe quelle interface. Ces enregistrements alimentent les systèmes de réputation et d’identité des agents. Sans règlement on-chain, il n’y a pas d’historique vérifiable. Sans historique vérifiable, pas de réputation portable. Sans réputation portable, chaque interaction entre agents démarre à zéro.

C’est pourquoi un standard on-chain est nécessaire. L’escrow, les transitions d’état, l’attestation : ces éléments doivent être neutres, sécurisés et applicables.

La découverte, la négociation et la communication peuvent se faire sur ou hors chaîne, via l’interface la plus naturelle. Un agent peut interagir via HTTP avec le protocole x402, pour une expérience similaire aux API ou requêtes HTTPS standards. L’agent n’a pas forcément besoin d’interagir directement avec la blockchain. Il signe un message unique, un facilitateur gère le règlement on-chain et les standards. Les agents peuvent aussi interagir directement via MCP ou A2A. L’interface est flexible, mais le règlement central doit être sans confiance, programmatique et on-chain. Une infrastructure que les systèmes centralisés ne fourniront pas, car cela réduirait leur contrôle.

L’économie des agents

Les modèles et agents IA progressent rapidement, gagnant en performance chaque mois. Des tâches requérant une expertise humaine il y a un an — production de code, génération de médias professionnels, analyse de données financières, coordination de workflows complexes — sont désormais réalisées par des agents avec une qualité comparable ou supérieure. La capacité continue d’accélérer. La trajectoire de l’IA rend cette nouvelle économie inévitable.

À mesure que les agents deviennent plus compétents, ils prennent en charge des travaux de plus grande valeur. Un agent générant des images indiscernables de photographies professionnelles propose un service à forte valeur. Un agent analysant un portefeuille et exécutant des transactions optimisées gère de l’argent réel. Un agent examinant des documents juridiques et détectant des risques effectue un travail facturé des centaines de dollars de l’heure pour un humain.

C’est la transition clé : l’IA et les agents deviennent des participants économiques générateurs de valeur et de services.

À mesure que l’IA devient universellement accessible, chaque individu, organisation ou appareil pourrait fonctionner via des agents. L’économie évolue alors : les agents ne servent pas seulement les humains, ils interagissent et se servent entre eux. Par exemple, un agent coordonnant une campagne engage des agents de contenu, de distribution et d’analyse. L’économie devient un réseau d’agents transigeant entre eux, à la vitesse machine, à l’échelle mondiale.

Quand les agents sont capables de travaux précieux et que chacun y a accès, il en résulte une économie où la majorité des activités commerciales passe par des systèmes autonomes. C’est pour cela que nous construisons.

Le problème : Commerce sans confiance entre agents

Une économie d’agents nécessite le commerce entre agents. Et le commerce entre des agents n’ayant jamais interagi, couvrant différentes organisations et chaînes, doit être sans confiance.

Quand les humains transigent, embauchent ou utilisent un service, la confiance est centrale. Elle est médiée par des plateformes, des avis, des systèmes juridiques et des normes sociales. Quand un agent embauche un autre agent, aucun de ces mécanismes ne s’applique. Il n’y a pas de réputation sociale à vérifier. Aucun recours juridique ou réputation ne fonctionne à la vitesse des transactions machine. Pas de plateforme ou régulateur pour assurer l’exécution.

La question devient donc : comment rendre le commerce entre agents sans confiance ?

On ne peut pas simplement envoyer de l’argent et espérer le meilleur. Un transfert de token n’est pas du commerce. C’est un paiement sans garantie. Aucun enregistrement de ce qui a été convenu. Aucun mécanisme pour retenir les fonds jusqu’à satisfaction du travail. Aucune évaluation générant des signaux pour d’autres agents. Aucun recours si le fournisseur ne livre jamais.

Il faut un engagement structuré : des fonds détenus dans des escrows décentralisés programmables et impartiaux, un travail soumis comme artefact vérifiable, un évaluateur attestant que le livrable respecte les termes, et des résultats déterministes. Des mécanismes assurant la libération des fonds à l’achèvement, le remboursement en cas de rejet et la récupération si expiré. Tout cela contribue à l’identité et à la réputation de chaque partie.

ERC-8183 : Le Job Primitive

En collaboration étroite avec l’équipe dAI de @ethereumfndn, nous formalisons cela en tant que standard. ERC-8183 : Agentic Commerce, est un standard ouvert et sans permission pour les applications de commerce entre agents, avec escrow et attestation d’évaluateur programmés comme smart contracts on-chain.

ERC-8183 définit un élément central : le Job. Chaque Job comprend trois parties : le Client, le Provider et l’Evaluator. Chaque partie est uniquement définie par son adresse de portefeuille, permettant une large application de ce concept.

Les éléments clés et principes du Job primitive sont : (i) la spécification et description du job — un enregistrement clair de la tâche, du service ou du travail lié au paiement ; (ii) le paiement — sécurisé dans un escrow programmé et impartial jusqu’à un état final, libéré de façon programmatique ; (iii) la soumission du livrable, enregistrée, vérifiable et traçable, protégeant client et fournisseur ; et (iv) l’attestation de 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 motive le flux du Job à travers quatre états clés, garantissant des transactions sans confiance :

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

En résumé, un Job est initialisé lorsque le Client crée un job avec un Provider et le finance, sécurisant le paiement dans l’escrow. Le Provider effectue le travail et appelle submit, mettant le livrable (ou sa référence) on-chain. Un Evaluator examine la soumission et appelle complete (libérant les fonds au provider) ou reject (remboursant le client). Si ni le provider ni l’évaluateur n’agissent avant la date limite (expiration), le job expire et le client récupère ses fonds.

Le standard est volontairement minimal et forme le concept atomique. Il ne spécifie pas les flux de négociation, structures de frais, résolution de litiges, protocoles de communication ou mécanismes de découverte. Il spécifie le cycle de vie central du job, le minimum viable pour un commerce sans confiance entre agents.

L’Évaluateur

L’un des concepts et choix de conception clés d’ERC-8183 est le concept d’évaluateur, défini simplement comme une adresse. C’est toujours un agent, au sens large.

Pour des tâches subjectives comme l’écriture, le design ou l’analyse, l’évaluateur peut être un agent IA qui lit la soumission, la compare à la demande et rend un jugement. Pour des tâches déterministes comme le calcul, la génération de preuves ou la transformation de données, l’évaluateur est un smart contract enveloppant un vérificateur ZK. Le provider soumet une preuve ; l’évaluateur la vérifie on-chain et appelle complete ou reject automatiquement. Pour des engagements à forts enjeux, l’évaluateur peut être un multi-sig, une DAO ou un validateur adossé à du staking.

Le standard ne distingue pas ces cas. Une adresse appelle complete ou reject. Que cette adresse exécute un agent alimenté par LLM ou un circuit ZK n’est pas du ressort du protocole. Cela permet à la même interface de fonctionner pour un job de génération d’image à $0,10 comme pour une gestion de fonds à $100 000.

Hooks : Extensibilité modulaire

Le Job primitive est volontairement minimal. Mais le commerce ne l’est pas. Les applications réelles nécessitent une validation personnalisée, des mises à jour de réputation, la distribution de frais, des transferts de fonds, des mécanismes d’enchères et une logique spécifique au domaine qui varie selon les cas d’usage. Un job d’évaluation de contenu, un swap de tokens ou une position sur un marché de prédiction nécessitent chacun une logique fondamentalement différente.

ERC-8183 résout cela avec les hooks. Un hook est un smart contract optionnel attaché à un Job lors de sa création. Il reçoit des callbacks avant et après chaque action, permettant d’exécuter une logique personnalisée autour du cycle de vie central sans le modifier. Le hook est identifié par un sélecteur de fonction unique (pour la transition concernée) et reçoit les paramètres pertinents. Il peut imposer des préconditions, bloquer des actions invalides, déclencher des effets secondaires ou exécuter des transferts additionnels de tokens, tout cela dans la même transaction que le changement d’état central.

Si aucun hook n’est défini, le contrat s’exécute normalement. Une implémentation sans hook est pleinement conforme à ERC-8183. Les hooks sont additionnels, non obligatoires. Ce design garde le contrat central petit et l’interface stable. De nouveaux cas d’usage sont pris en charge grâce à de nouveaux hooks, gardant la logique d’extension on-chain, programmatique et sans confiance, comme le cœur.

Exemples d’applications de commerce

Le Job central gère le commerce de service simple : payer, livrer, évaluer. Mais l’économie dans laquelle opèrent les agents n’est pas simple. Certains jobs impliquent la gestion du capital du client, pas seulement la réception d’un paiement. Certains nécessitent une tarification compétitive avant même qu’un provider soit assigné. Certains requièrent des vérifications de confiance qui référencent des données de réputation externes. Ce sont des modèles économiques fondamentalement différents, et les hooks permettent à la même interface Job centrale de supporter cette diversité et font d’ERC-8183 un concept de commerce polyvalent.

• Les Service Jobs sont la base et ne nécessitent aucun hook. Un client paie pour la génération de contenu, l’analyse de données ou la revue de code. L’escrow central et le flux d’évaluation suffisent.

• Les Fund Transfer Jobs vont au-delà d’un simple paiement de service. Le client fournit du capital (tokens à swapper, fonds à investir), le provider le transforme, et le résultat doit revenir. Un hook peut gérer ce flux de capital bidirectionnel avec l’escrow central, assurant que le provider dépose les tokens de sortie avant que le job soit terminé. Cela couvre de nombreuses applications telles que le yield farming, les swaps de tokens, le rééquilibrage de portefeuille, tout job où le provider gère l’argent du client ou requiert du capital initial pour exécuter une tâche, pas seulement gagner une commission.

• Les Bidding Jobs inversent le modèle d’assignation. Au lieu que le client choisisse un provider d’emblée, les providers se concurrencent sur le prix. Un hook vérifie les offres signées cryptographiquement au moment de l’assignation, prouvant que le provider sélectionné s’est engagé sur le prix annoncé. Aucun côté ne peut falsifier ou nier les termes.

• Les Reputation-Gated Jobs imposent la confiance au niveau du protocole. Un hook interroge ERC-8004 avant d’autoriser des actions, bloquant les providers à faible réputation ou imposant des conditions plus strictes aux agents non éprouvés.

• Les Privacy-Preserving Jobs utilisent des hooks pour permettre le commerce sans exposition de données. Au lieu de publier des données sensibles on-chain, un Privacy Hook peut imposer que le champ 'Submission' contienne une preuve Zero-Knowledge (ZKP) ou une référence à un environnement chiffré (comme un TEE). Ainsi, le paiement est sans confiance et public, mais la propriété intellectuelle ou les données personnelles restent un « sanctuaire », accessible uniquement aux agents autorisés.

• Les Risk-Assessed ou Underwriting Jobs peuvent imposer l’underwriting au niveau du protocole via des hooks. Un hook peut exiger du collatéral mis en staking par les providers ou les souscripteurs, vérifier les scores de réputation ERC-8004 et d’autres métriques avant l’assignation, imposer des bonds qui sont slashed en cas d’échec, ou interroger des oracles de risque externes. Ces processus d’approbation auparavant opaques deviennent transparents, programmables et compétitifs. Par exemple, différentes tolérances au risque peuvent être servies ; une pour les agents établis à haute confiance peut requérir des contrôles minimaux, tandis qu’une autre dans des domaines à forts enjeux peut exiger un collatéral important.

Chacune de ces applications peut être implémentée comme un hook contract distinct, gardant la fonctionnalité centrale et le standard Job primitive. De nouveaux modèles économiques, applications de commerce ou variantes pour une logique personnalisée sont de nouveaux hooks. Nous avons introduit les premiers hooks, qui sont des exemples pour démontrer ce qui est possible, mais nous pensons n’avoir fait qu’effleurer la surface et que les hooks les plus intéressants n’ont pas encore été écrits. À quoi ressemblera le commerce entre agents pour l’assurance, la collaboration créative, la coordination de la supply chain ? Nous ne le savons pas encore, et c’est tout l’intérêt. De plus, le commerce entre agents évoluera de façon imprévisible, avec de nouveaux modèles économiques, de nouveaux mécanismes de confiance, de nouvelles formes de collaboration entre machines. Le standard est conçu pour accompagner cette évolution, pas la contraindre. Il doit être construit de manière ouverte, car les meilleures idées viendront de l’écosystème, et nous avons hâte de les découvrir ensemble.

Symbiose avec ERC-8004

ERC-8183 n’existe pas isolément. Il est en symbiose avec ERC-8004 (« Trustless Agents »), le standard Ethereum pour l’identité, la réputation et la validation des agents.

ERC-8004 résout la découverte et la confiance : comment les agents se trouvent et évaluent leur fiabilité. Mais ses registres ne valent que par l’activité qu’ils enregistrent. L’identité sans commerce ou actions est un profil vide. La réputation nécessite de vraies interactions pour être mesurée. La validation requiert des livrables définis pour être vérifiée.

ERC-8183 fournit le commerce qui alimente la couche de confiance d’ERC-8004. Chaque job est un signal de réputation. Chaque soumission est un livrable que les validateurs peuvent évaluer. Chaque évaluation est une attestation que d’autres agents peuvent référencer.

Les deux standards forment une boucle qui permet potentiellement une auto-organisation plus grande et plus puissante entre agents via des interactions sans confiance :

Discovery (8004) → Commerce (8183) → Reputation (8004) → Better Discovery → More Trustless Commerce

Aucun n’est complet sans l’autre. Ensemble, ils forment la base du commerce et de l’interaction sans confiance entre agents.

Au-delà du paiement

ERC-8183 n’est pas un protocole de paiement. C’est un standard de commerce.

Un paiement déplace de l’argent. Mais le commerce implique bien plus que déplacer de l’argent. Le commerce, c’est tout ce qui entoure le paiement et le rend fiable et fonctionnel : ce qui a été convenu, si le travail a été fait, qui l’a vérifié, et ce qui se passe si ce n’est pas le cas. Dans le monde traditionnel, le commerce fonctionne grâce à ce qui entoure le paiement : l’évaluation du risque et l’underwriting des marchands avant qu’ils puissent accepter des paiements, l’octroi de crédit pour permettre aux acheteurs de transiger avant d’avoir les fonds, la détection de fraude sur des milliards de transactions en temps réel, les mécanismes de chargeback et de litige qui protègent les acheteurs quand les services échouent, et les systèmes de réputation qui accumulent la confiance au fil des interactions répétées. Ces fonctions sont ce qui rend les processeurs de paiement, les réseaux de cartes et les plateformes précieux ; non pas le mouvement des fonds, mais l’infrastructure de confiance qui l’entoure.

Quand le commerce passe on-chain, ces fonctions ne disparaissent pas. Elles doivent être reconstruites, sans confiance, de façon programmatique et ouverte. C’est ce qu’est ERC-8183.

Le modèle d’escrow et d’attestation d’évaluateur du Job primitive est analogue aux mécanismes de chargeback avec des conditions de règlement programmables et préalables. Utiliser la réputation on-chain d’ERC-8004 et d’autres métriques historiques on-chain dans ERC-8183 est analogue à l’underwriting propriétaire avec un historique portable et vérifiable.

Les hooks remplacent l’évaluation centralisée des risques par une logique modulaire, compétitive et auditable que tout facilitateur peut déployer. Le résultat n’est pas seulement une façon de déplacer de l’argent on-chain, mais un moyen de reconstruire toute l’infrastructure de confiance du commerce, ouvertement et sans autorisation.

Les protocoles de paiement et interfaces existants, qu’il s’agisse de processeurs traditionnels ou de protocoles de transfert de stablecoins comme x402, offrent des expériences fluides et natives à l’internet pour le mouvement des fonds. ERC-8183 gère le cycle complet qui transforme un paiement en une transaction sans confiance : spécification, escrow, soumission du livrable, attestation de l’évaluateur et règlement déterministe. Un agent peut interagir via x402 ou HTTP à la couche d’interface tandis que le règlement sous-jacent passe par ERC-8183 on-chain. Ces approches sont complémentaires.

Irréversibilité, Escrow et le problème du chargeback

Un autre problème avec les paiements autonomes est l’irréversibilité. Quand une carte est débitée et que le service n’est pas satisfaisant, le consommateur conteste et annule le débit. Quand un paiement est transféré, l’argent est parti. C’est une objection réelle et pertinente, pour les paiements bruts et les transferts.

ERC-8183 intègre ce concept dans sa structure contractuelle. Les fonds sont détenus en escrow jusqu’à ce qu’un évaluateur atteste que le livrable respecte les termes convenus. Le rejet rembourse le client. L’expiration permet la récupération automatique. C’est un équivalent programmable et sans confiance du modèle d’autorisation et de capture qui fait fonctionner le commerce par carte, sauf que les termes sont codés à l’avance et appliqués par code, plutôt que décidés a posteriori par un réseau avec ses propres incitations.

Pour la pré-autorisation de montants incertains, une réservation d’hôtel, un service dont le périmètre peut évoluer, la flexibilité des hooks permet de verrouiller un montant maximum et de régler un montant final déterminé par des entrées vérifiables à l’achèvement. L’architecture supporte les modèles de confiance et de comportement du commerce par carte, tout en gardant le règlement transparent, ouvert, sans confiance et on-chain.

La nouvelle vague de participants économiques

La vague IA crée de nouveaux participants économiques, acheteurs et marchands, plus rapidement que toute évolution précédente. Des millions de développeurs et non-développeurs créent et distribuent des micro-services, des API et des outils avec des assistants IA, souvent sans entité légale, sans site web, sans historique de transaction. Des agents issus d’entreprises tech et de frameworks open-source intègrent des millions d’utilisateurs avec des agents IA personnels.

Les systèmes de paiement traditionnels auront du mal à servir ces marchands. Non pas par manque de technologie, mais parce que lorsqu’un processeur approuve un Provider, il absorbe le risque : fraude, chargebacks, litiges. Un marchand sans historique, sans entité, sans antécédents est trop risqué à couvrir.

ERC-8183 est sans permission par conception. Un provider est une adresse de portefeuille. Pas d’onboarding, pas d’underwriting, pas de filtrage. Le Job primitive offre à ces marchands non seulement un moyen d’être payés, mais tout le cycle du commerce : spécification du travail, paiement en escrow, soumission vérifiable du livrable, attestation de l’évaluateur, fondation d’une transaction fiable.

L’incapacité à couvrir de nouveaux providers peut être vue comme un manque temporaire. Un standard ouvert réduit ce délai structurellement. Tout facilitateur peut déployer ERC-8183 dès aujourd’hui. L’écosystème évolue par l’expérimentation, non par consensus institutionnel. Plus fondamentalement, ERC-8183 combiné à ERC-8004 ne comble pas seulement le manque d’underwriting, il résout la cause racine. Si les processeurs ne peuvent pas couvrir de nouveaux marchands, c’est par absence d’historique vérifiable. ERC-8183 produit cet historique. Chaque job terminé est enregistré on-chain : le hash du livrable, l’attestation de l’évaluateur, le résultat. Cet historique est portable, vérifiable et sans propriétaire.

Surtout, le track record n’est pas enfermé dans une plateforme unique. Aujourd’hui, la plateforme A connaît votre taux de chargeback, la plateforme B votre score vendeur, mais vous ne pouvez pas emporter ce dossier ailleurs. Sur ERC-8183, la réputation est l’actif portable du marchand, lisible par tout facilitateur, sur n’importe quelle chaîne, via toute interface qui lit le standard. ERC-8183 alimente l’identité et la réputation on-chain (ERC-8004) et fournit des données pour l’underwriting.

Construire ensemble l’avenir du commerce entre agents et de l’IA décentralisée

ERC-8183 est un standard ouvert pour le commerce sans confiance entre agents. Voici comment participer :

Développez avec ERC-8183. Soyez facilitateur ! Déployez ERC-8183 sur votre chaîne. Créez des SDK. Créez des wrappers. Créez des scanners et trackers. Créez de nouvelles interfaces et expériences, et laissez-les s’établir de façon sécurisée et vérifiable on-chain avec ERC-8183. Concevez des frameworks d’agents qui interagissent nativement avec le standard.

Explorez, expérimentez et développez des hooks. Besoin de paiements par étapes ou de résolution de litiges ? Créez-les sous forme de hooks. C’est l’espace de créativité et d’évolution pour une grande diversité d’applications.

Développez et enregistrez des évaluateurs. Les évaluateurs sont essentiels pour garantir un commerce sûr et sans confiance entre agents, mais ils sont rares. Développez des évaluateurs pour des domaines spécifiques, surtout pour des domaines et services entièrement vérifiables. Enregistrez-les sur ERC-8004. Contribuez significativement à la réputation et à l’identité des agents.

Contribuez et donnez votre avis. C’est un standard collectif. Il ne deviendra ce qu’il doit être que par une large expérimentation, une utilisation réelle, un retour honnête et une itération. Si quelque chose manque, proposez-le. Si quelque chose est erroné, contestez-le. La spécification est ouverte, le repo est ouvert, la discussion est ouverte. Cela évolue ensemble.

L’économie des agents sera construite sur des standards ouverts ou sur des jardins clos. Nous choisissons les standards ouverts. Un espace numérique partagé.

ERC-8004 pour la confiance. ERC-8183 pour le commerce. Tout le reste est à vous de construire.

Envie d’en savoir plus ?

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

Rejoignez la communauté Telegram : https://t.me/erc8183

Avertissement :

1. Cet article est reproduit depuis [virtuals_io]. Tous droits réservés à l’auteur original [virtuals_io]. En cas d’objection à cette reproduction, veuillez contacter l’équipe Gate Learn, qui prendra les mesures nécessaires rapidement.

2. Décharge de responsabilité : Les opinions et points de vue exprimés dans cet article sont ceux de l’auteur et ne constituent en aucun cas un conseil en investissement.

3. Les traductions de l’article dans d’autres langues sont réalisées par l’équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits sont interdits.