Ce document est un rapport d'étude approfondie produit par OKX Ventures. En raison de sa longueur, il sera publié en deux parties : la première partie se concentrera sur le contexte macroéconomique, le protocole x402, l'ERC-8004 et le protocole Virtuals ; la deuxième partie analysera en profondeur OpenClaw et les tendances de l'ensemble du secteur, restez à l'écoute.
Résumé
Les Agents AI évoluent d'assistants passifs à participants actifs de l'économie. Ce rapport comprend six chapitres, systématiquement récapitulant la pile d'infrastructure fondamentale de l'économie des Agents, l'explosion de l'écosystème d'applications et l'évolution du secteur : analyse macroéconomique des prévisions de marché de l'Agentic Commerce et des lacunes d'infrastructure ; analyse approfondie des trois protocoles complémentaires x402, ERC-8004, Virtuals Protocol ; étude de cas d'OpenClaw sur les chemins réels d'atterrissage de l'économie des Agents ; enfin, fournissant un jugement global sur le secteur selon les dimensions de la dynamique concurrentielle, des voies de paiement, des menaces de sécurité et des modèles commerciaux.
x402 (couche de paiement) a été lancé conjointement par Coinbase et Cloudflare, intégrant des micropaiements en stablecoin dans la couche de protocole HTTP. À la fin de 2025, plus de 100 millions de transactions ont été traitées, avec un volume de paiements annualisé atteignant 600 millions de dollars.
L'ERC-8004 (couche de confiance) a été proposé par l'équipe dAI de la Fondation Ethereum en collaboration avec MetaMask, Google, Coinbase, fournissant aux Agents AI trois grands registres d'identité, de réputation et de validation, mis en ligne sur le réseau principal Ethereum le 29 janvier 2026.
Le protocole Virtuals (couche commerciale) construit une plateforme complète de commercialisation des Agents, permettant un commerce autonome entre Agents via l'ACP. Plus de 18 000 Agents ont été déployés, avec un aGDP dépassant 479 millions de dollars.
OpenClaw (couche d'application) a été développé par le développeur autrichien Peter Steinberger, atteignant plus de 250 000 étoiles GitHub en quatre mois, surpassant React et devenant le projet open source à la croissance la plus rapide de l'histoire de GitHub. Il intègre l'AI de manière native dans plus de 20 plateformes de messagerie existantes, déclenchant la communauté Crypto à construire spontanément une infrastructure économique sur chaîne, c'est un échantillon central de l'interaction réelle entre les Agents et les protocoles sur chaîne observés dans ce rapport.
Chapitre 1 Contexte macroéconomique
1.1 Prévisions de taille du marché
Le secteur des paiements Agentic est en phase d'expansion rapide, plusieurs institutions ont des prévisions optimistes quant à sa taille de marché :
1.2 Lacunes d'infrastructure
Les infrastructures existantes sont hostiles à l'économie des Agents : OAuth nécessite des clics humains, les formulaires de cartes de crédit nécessitent une saisie manuelle, les îlots de données entravent l'accès autonome. Les Agents peuvent déjà penser et agir de manière autonome à un niveau "capacité", mais au niveau "économie", ils sont toujours enfermés dans des infrastructures conçues pour les humains (identité / coordination / activités économiques).
Deux voies d'évolution apparaissent actuellement :
Voie de conformité centralisée : communication A2A + intégration d'outils MCP + paiement AP2/ACP (dirigé par OpenAI et Stripe, purement Web2)
Voie décentralisée sans autorisation : x402 + ERC-8004/8183 + ACP (cadre de collaboration des Agents)
1.3 Chronologie clé
Remarque : au 31 mars 2026, le nombre moyen de transactions par jour a considérablement diminué par rapport au pic de décembre, les projets d'infrastructure ayant enregistré la plus forte baisse (>80 %).
Chapitre deux protocole x402 : couche de paiement des Agents
x402 est un protocole de paiement open source, en réactivant le code d'état HTTP 402, permettant à toute requête HTTP de porter nativement un paiement en stablecoin, permettant aux Agents AI de réaliser des transactions instantanées au paiement à l'utilisation.
Comprendre x402 ne doit pas le considérer comme un autre protocole de paiement. Cela représente une redéfinition de l'unité fondamentale des activités économiques : de "inscription → vérification → autorisation → utilisation" à "paiement → utilisation". x402 = "Swift for agents".
Le fonctionnement actuel de l'économie API repose sur une hypothèse implicite : il y a des humains qui opèrent au milieu. Le processus d'obtention d'une clé API : inscription → remplissage de l'email → vérification → copie de la clé → collage dans le code, chaque étape suppose une intervention humaine. Ce processus ne fonctionne pas dans une économie d'Agents, car les Agents AI ne peuvent pas s'inscrire, remplir des formulaires ou gérer des clés eux-mêmes. x402 utilise le code d'état HTTP 402 pour réaliser des paiements en stablecoin natifs. L'Agent reçoit une réponse 402 et effectue immédiatement le paiement sur la chaîne (USDC) et reçoit un reçu.
2.1 Aperçu du protocole et flux de travail
Rôles clés
Processus de transaction en cinq étapes
Demande de ressources : le client envoie une requête HTTP standard au serveur de ressources (par exemple, GET /api/weather)
Retour de l'offre : le serveur renvoie un code d'état HTTP 402, l'en-tête de réponse contient une demande de paiement structurée (monnaie, montant, adresse de portefeuille, réseau)
Paiement par signature : le client utilise la clé privée de son portefeuille pour construire et signer l'autorisation de paiement, plaçant la charge utile signée dans l'en-tête de demande X-PAYMENT et la renvoyant
Validation du règlement : le serveur transmet les informations de paiement à un Facilitateur pour vérification, le Facilitateur confirme ensuite et exécute le transfert de stablecoin sur la chaîne
Livraison des ressources : le serveur renvoie les données/contenus/résultats de calcul au client après confirmation
Le processus complet, de l'initiation de la demande à la réception des ressources, est complété en environ 2 secondes.
Comparaison avec les méthodes de paiement traditionnelles
Caractéristique centrale : aucune inscription de compte requise, aucune clé API requise, aucun abonnement requis, aucune intervention humaine requise. Le paiement est aussi naturel que l'envoi d'une requête HTTP, c'est pourquoi il est appelé "couche de paiement native à Internet".
2.2 Données clés
Description de la qualité des données : selon l'analyse d'Artemis, les transactions x402 montrent que Real et Gamed sont proches de 1:1 (par exemple, le 2026.01.11, Real 520 000 contre Gamed 518 000), la taille organique réelle doit être comprise avec prudence.
Distribution par chaîne
Classification par utilisation (2026.01.11 instantané sur chaîne)
2.3 Classement de l'utilisation des principaux projets (au 2026 年 3 月)
Sources de données : panneau Dune Analytics x402 Transactions par Projet
2.4 Améliorations clés de la V2
Identité de portefeuille + session réutilisable
Dans V1, chaque appel API devait passer par un processus de transaction complet sur la chaîne. V2 introduit le mécanisme Sign-In-With-X (SIWx), permettant aux Agents de vérifier une fois l'identité de leur portefeuille, après quoi les appels suivants peuvent réutiliser la session, sans nécessiter de confirmation sur la chaîne à chaque fois. En essence, cela met à niveau le paiement à l'appel en un modèle d'abonnement, résolvant ainsi le goulet d'étranglement de performance dans les scénarios à haute fréquence.
Unification multi-chaînes + compatibilité avec les paiements traditionnels
La norme V2 a standardisé la façon dont les réseaux et les actifs sont identifiés, créant un format de paiement unifié pouvant fonctionner à la fois sur des chaînes différentes et sur des voies de paiement traditionnelles X402. Base, Solana, d'autres L2 ainsi que ACH, SEPA et les réseaux de cartes bancaires sont tous intégrés dans le même modèle de paiement. C'est la mise à niveau la plus cruciale : x402 est passé de "protocole de paiement cryptographique" à une couche de paiement neutre connectant Crypto et finance traditionnelle.
Découverte automatique des services
La V2 introduit l'extension Discovery, les services x402 peuvent exposer des métadonnées structurées pour permettre aux Facilitators de les indexer automatiquement, les Agents AI peuvent découvrir les services, comprendre les prix et initier des paiements de manière autonome. C'est particulièrement crucial pour l'économie des Agents - les Agents n'ont pas besoin de connaître à l'avance l'interface de paiement du fournisseur de services, ils peuvent découvrir et effectuer des paiements de manière autonome en cours d'exécution.
SDK modulaire
Architecture modulaire, ajout de chaînes en tant que paquet indépendant, réduisant les coûts d'intégration. Cloudflare a proposé un schéma de paiement différé, y compris le schéma Gateway de Circle, qui est toujours en cours de développement.
2.5 Participants à l'écosystème
Fondation et couche de protocole
2.6 Paysage de la pile de paiement des Agents
Comparaison détaillée des protocoles
Perspicacité clé : ce n'est pas qui remplace qui, mais comment les combiner. Google a collaboré avec Coinbase pour publier l'extension A2A x402, AP2 intègre nativement x402 en tant que voie de paiement cryptographique. Le véritable risque de concurrence est la fragmentation des normes.
2.7 Signaux de risque clés
Le volume quotidien des transactions est passé d'environ 731 000 transactions en décembre 2025 à environ 57 000 transactions en mars 2026 (-92 %), la taille réelle des transactions étant d'environ 14 000 $/jour (selon Artemis, au pic de décembre, 95 % des 250 000 $ par jour étaient Gamed)
La capitalisation de l'écosystème est de 7 milliards de dollars (LINK 6 milliards + Virtuals 600 millions), l'évaluation s'écartant sévèrement de l'utilisation réelle
Les projets liés aux infrastructures ont connu la plus forte baisse d'utilisation : x402secure.com (-80 %+), AgentLISA (proche de zéro), pay.codenut.ai (forte contraction)
Analyse des trois niveaux de causes
Première couche : disparition des catalyseurs. L'explosion du volume des transactions d'octobre à décembre 2025 a été alimentée par trois facteurs : la frénésie des tokens meme, les attentes de TGE de plusieurs projets, et les Facilitators rivalisant pour améliorer leur classement sur Dune.
Deuxième couche : déséquilibre fondamental de l'offre et de la demande. Le problème que x402 résout est "l'Agent AI appelant les API de manière autonome", mais la grande majorité des Agents AI utilisent encore l'API Key + le modèle d'abonnement pour appeler des services ; les Agents ayant une véritable capacité de décision économique autonome sont presque inexistants dans l'industrie ; les vendeurs d'API qui acceptent de se faire payer par USDC à l'unité sont également très rares. La route est prête, mais les voitures ne sont pas encore fabriquées.
Troisième couche : le marché de la cryptographie se refroidit dans son ensemble.
Avantages : l'intégration de Stripe dans x402 est un événement majeur. John Collison, co-fondateur de Stripe, prédit que "le torrent commercial des agents" arrivera dans les mois et années à venir. Stripe se positionne à la fois sur l'ACP (voie de carte de crédit Web2) et sur x402 (voie de stablecoin Web3), étant ainsi un contrepoids à ces deux voies.
x402 a donné naissance à une série de nouveaux projets de middleware, qui aident essentiellement les Agents à accéder plus facilement à divers services sous un paradigme de paiement à l'autorisation instantanée : de l'inférence AI aux API Web2. Un canal de paiement Crypto programmable, sans autorisation et 24/7 est le choix naturel pour les Agents autonomes. Mais cela suppose que les Agents aient réellement besoin de "sans autorisation" ; si les Agents opèrent toujours sous l'autorisation humaine (deuxième phase : Agents contrôlés), alors les voies de paiement traditionnelles plus une carte virtuelle suffisent. Ce n'est que lorsque les Agents commencent à mener des activités économiques indépendamment des humains (troisième phase : entité économique autonome) que le "sans autorisation" devient une nécessité.
De plus, les cartes de crédit disposent d'un mécanisme de remboursement (les consommateurs peuvent contester une transaction et récupérer des fonds), un système de protection des consommateurs établi depuis des décennies. Les paiements sur chaîne sont un règlement final, une fois payés, ce sont des paiements définitifs, sans possibilité de remboursement. Cela signifie que si un Agent effectue une erreur (par exemple, une attaque par injection de prompt), dans un système de carte de crédit, l'utilisateur peut appeler la banque pour récupérer son argent. Dans le système x402, l'argent est déjà sur la chaîne, impossible à récupérer. C'est le véritable inconvénient de x402 par rapport aux paiements traditionnels.
Les humains agissant comme "middleware humain" entre différents systèmes provoquent de nombreuses frictions, qui sont en fait des mécanismes d'établissement de confiance. La lutte contre la fraude, le contrôle d'accès, la responsabilité, la résolution des litiges, les documents d'audit, ces frictions maintiennent le fonctionnement du système commercial.
Les directions de solution pourraient être un mécanisme d'escrow sur chaîne (les fonds sont d'abord bloqués dans un contrat intelligent, puis libérés après confirmation de la livraison du service), des protocoles d'assurance (fournissant une assurance pour les transactions des Agents), ou un système de réputation 8004 réduisant la probabilité des transactions avec des parties non fiables. Mais pour l'instant, ceux-ci ne sont pas encore matures.
2.8 Perspective d'investissement VC
Directions d'investissement à surveiller
Fournisseurs de services API avec une réelle demande de paiement (vendeurs) : analyse de données / capture de pages Web / Oracle / audit de sécurité / paiement de raisonnement / conformité KYC, etc. Critères de jugement : peut également gagner de l'argent avec un modèle traditionnel, x402 n'est qu'un canal de distribution supplémentaire.
Couche de garantie de résolution des litiges et de paiement Gateway : les transactions sur la chaîne ne peuvent pas être annulées ou remboursées, les grandes transactions nécessitent un mécanisme de résolution des litiges. Projets représentatifs : Circle Gateway (dépôts prépayés non gérés + règlements hors chaîne en masse), Kamiyo (réputation de l'Agent / garde de fonds / détermination du réseau oracle / arbitrage ZKP)
Outils Dashboard / FinOps : aident les entreprises à gérer les dépenses multi-Agents (combien dépensé / où dépensé / est-ce que cela en vaut la peine / comment économiser), comparables à CloudHealth/Cloudability dans le cloud computing, comparativement à l'espace acquis pour 300-500 millions de dollars par de grandes entreprises.
Chapitre trois ERC-8004 : couche de confiance des Agents
L'ERC-8004 est une norme de coordination sur chaîne, établissant un cadre de découverte et d'interaction entre Agents sans confiance à travers trois grands registres : Identité, Réputation, Validation.
3.1 Aperçu des normes et distinctions clés
Dans les interactions traditionnelles, les interactions entre Agents nécessitent souvent l'établissement de relations de confiance préalables ou dépendent d'institutions tierces, souvent limitées au sein du même écosystème. Dans un environnement ouvert, comment les Agents découvrent des partenaires, consultent des performances historiques et vérifient la fiabilité, est un problème central.
Distinction importante : l'ERC-8004 n'est pas un Token, il utilise l'ERC-721 NFT pour représenter l'identité de l'Agent, mais la norme elle-même concernant la coordination et la confiance, ne porte pas de valeur économique, n'est pas échangeable.
3.2 Trois grands registres
Registre d'identité
Basé sur l'ERC-721 + URIStorage, chaque Agent obtient une identification NFT, associée à agentURI pointant vers un fichier d'enregistrement (JSON), contenant le nom, la description, le point de service (A2A/MCP/Web), l'état de support x402, etc. L'URL peut être stockée sur IPFS (décentralisé, anti-censure), serveur HTTPS (simple mais centralisé), ou directement encodée sur la chaîne (la plus décentralisée mais coûteuse).
Registre de réputation
Publication des interfaces standard et obtention de signaux de feedback, supportant l'évaluation sur chaîne et les algorithmes hors chaîne. Peut accompagner la preuve de paiement x402 en tant que signal de confiance économique. Les Agents se notent mutuellement, mais pour éviter le bourrage, une preuve ERC-8183 est requise pour attester qu'il existe une interaction Job réelle entre les Agents.
Registre de validation
Introduction de TEE (environnement d'exécution de confiance), mécanisme de mise en jeu PoS, ZK (preuve à connaissance nulle), pour valider et certifier les tâches traitées par l'Agent :
Via TEE : les tâches vérifiables s'exécutent dans une boîte noire sécurisée, le code et les données n'ont pas été espionnés ou altérés par des tiers.
Via PoS : les validateurs doivent mettre en jeu des actifs pour participer aux tâches, en cas de méfaits, leur mise est confiscée.
Via ZK : vérifiabilité de la justesse du processus de raisonnement de l'Agent, sans connaître ses poids internes.
3.3 Jalons de développement
Partisans : ENS, EigenLayer, The Graph, Taiko. Environ 1 000 à 2 000 développeurs ont rejoint.
Mais les limitations actuelles de 8004 sont reconnues par Crapis lui-même : "8004 est essentiellement un ensemble de registres." Il a donné aux Agents une carte d'identité et a fourni un mécanisme d'évaluation, mais ne peut garantir que le comportement des Agents est fiable. La véritable validation nécessite un audit comportemental (ce que l'Agent a fait par le passé), des preuves d'environnement d'exécution (preuves d'exécution dans un TEE), et une vérification des intentions (l'Agent prétendait faire X, a effectivement fait X). La partie TEE du Registre de validation est encore en discussion avec la communauté et n'est pas encore mature.
En d'autres termes : 8004 est une condition nécessaire mais pas suffisante. Il a résolu la question "qui est cet Agent", mais n'a pas résolu la question "cet Agent est-il fiable". Cette dernière nécessite une combinaison de 8004 + TEE + audit de comportement, et cette combinaison n'a pas encore été entièrement réalisée par quiconque.
Bien sûr, il y a une autre direction sous-estimée : dans l'économie humaine, le système de crédit est établi sur des bilans et des historiques de crédit - combien d'argent vous avez, combien de prêts vous avez remboursés dans le passé. Les Agents n'ont pas cela mais ont des données comportementales : combien de tâches ils ont exécutées dans le passé, quel est leur taux de réussite, quel est leur temps de réponse moyen, ont-ils été signalés ? Si les données comportementales peuvent devenir des primitives financières, alors le système de réputation 8004 ne se limite pas à des évaluations positives ou négatives, mais devient le score de crédit du monde des Agents. Un Agent ayant un score de réputation élevé peut obtenir une limite de crédit plus élevée (préautorisation de fonds supplémentaires), des coûts de transaction plus bas (car le risque est moindre), et une priorité dans l'attribution des tâches (les employeurs choisissent en priorité les Agents ayant une bonne réputation).
Le registre d'identité et de réputation de 8004 n'est que la couche de données de base. La création de valeur réside dans qui peut établir une évaluation de crédit et des services financiers sur cette couche de données - prêts pour Agents, assurances pour Agents, limites de crédit pour Agents, c'est-à-dire l'ensemble de la pile de services financiers.
3.4 Relation avec d'autres protocoles
3.5 ERC-8183 : standardisation Ethereum de l'ACP
L'ERC-8183 est la version standardisée d'open Ethereum du protocole ACP interne de Virtuals (publiée le 10 mars 2026, actuellement en phase de brouillon).
La primitive centrale est le Job - une machine d'état sur chaîne (Ouvert → Financé → Soumis → Complété / Rejeté / Expiré), gérant des fonds via un escrow programmable, avec un Evaluateur indépendant arbitraire de la qualité de livraison qui règle automatiquement. Supporte le mécanisme d'extension Hooks (seuil de réputation, enchères, paiements par étapes, etc.).
Conception clé : chaque Job complété génère automatiquement un enregistrement d'interaction et l'alimente dans le Registre de Réputation de l'ERC-8004 - comparable à "les avis des consommateurs nécessitent une consommation préalable pour être évalués, et incluent un arbitre tiers", c'est le point de connexion entre le 8183 et le 8004 formant un cycle symbiotique.
Chapitre quatre Virtuals Protocol : couche commerciale des Agents
4.1 Aperçu du projet
Le protocole Virtuals est une infrastructure complète et décentralisée pour les Agents AI, permettant à quiconque de créer, tokeniser, co-propriétaire et monétiser des agents AI autonomes sur la chaîne. Le projet a été initialement fondé sous l'identité de PathDAO (guilde de jeux) en 2021, se transformant en direction des Agents AI début 2024, actuellement principalement déployé sur Base, et s'étendant à Ethereum, Solana et Ronin.
Équipe centrale : fondateur Jansen Teng (ancien consultant BCG, diplômé en biotechnologie et gestion de l'Imperial College) et Weekee Tiew (diplômé en biotechnologie de l'Imperial College + MBA de la London Business School, antécédents PE/BCG), basée à Kuala Lumpur, Malaisie, avec environ 38 personnes dans l'équipe. Historique de financement : financement de démarrage de 16 millions de dollars de PathDAO (DeFiance Capital, Beam en tête).
4.2 Architecture technique : quatre grands piliers
Pilier un : cadre GAME - comment un Agent prend des décisions en interne
GAME est le cerveau : donner à un Agent un objectif, une personnalité, des capacités de perception et des actions exécutables, afin qu'il puisse planifier de manière autonome "quelle doit être ma prochaine étape", puis décomposer la tâche pour que les Workers internes l'exécutent. L'ensemble du processus se déroule dans les limites d'un seul Agent.
Noyau de l'architecture : architecture de planification hiérarchique, séparant "quoi penser" et "comment faire" - le générateur de tâches (planificateur de haut niveau/HLP) génère des tâches en fonction des objectifs de l'Agent et sélectionne les Workers ; les Workers (planificateurs de bas niveau/LLP) ont chacun un ensemble de fonctions exécutables spécifiques ; les fonctions exécutent des appels API, des transactions sur la chaîne, des opérations de recherche de données, etc.
Soutien au modèle de base : Llama 3.1 405B (par défaut), Llama 3.3 70B, DeepSeek R1, DeepSeek V3 - conception d'indépendance par rapport au modèle. Avec la publication des cadres Agent d'OpenAI/Google, la différenciation de GAME ne reste qu'un point : c'est le seul cadre d'Agents ayant intégré nativement le niveau économique sur chaîne (ACP + token VIRTUAL).
Pilier deux : ACP - le "droit commercial" entre Agents.
Le Protocole de Commerce Agent (ACP) est un protocole standardisé sur la chaîne, permettant aux Agents de découvrir, d'embaucher, de négocier, de gérer des fonds, de livrer et de régler - le tout sans intervention humaine.
Machine à états en quatre phases de l'ACP
Pilier trois : Butler - l'entrée super de l'utilisateur
Butler est la passerelle consommateur du réseau ACP - un Agent construit sur LLM, essentiellement un orchestre du protocole ACP, responsable de traduire le langage naturel de l'utilisateur en flux de travail de collaboration multi-Agents sur chaîne.
Butler est une architecture à deux niveaux : la couche supérieure étant une interface de conversation LLM (actuellement le backend est Gemini 3 Pro) ; la couche inférieure est l'orchestre du protocole ACP, exécutant l'ensemble du processus de découverte de l'Agent → confirmation de l'offre → verrouillage de l'escrow → routage des tâches → vérification de la livraison → libération des fonds. Ce que l'utilisateur voit, c'est une conversation, ce que fait Butler, c'est la planification des contrats.
Le mode Pro de Butler séparera clairement la planification et l'exécution : phase de planification → phase de révision (l'utilisateur peut optimiser le plan) → phase d'exécution (orchestration autonome du processus complet). Les capacités intégrées incluent l'échange de tokens, l'investissement DCA, les contrats perpétuels, le fonds de fonds.
Pilier quatre : plateforme de lancement - Wall Street des Agents
Le système de lancement à trois niveaux couvre le cycle de vie complet des projets d'Agents de 0→1→100 :
Projet phare de Titan : XMAQUINA ($DEUS, DAO détient des actions dans des entreprises d'intelligence incarnée comme Figure AI, 60 millions de dollars FDV), Fabric Foundation ($ROBO, collaboration avec OpenMind sur l'économie des robots)
4.3 Analyse du PIB agentique (aGDP)
aGDP (Produit Intérieur Brut Agentique) est l'indicateur écologique central personnalisé de Virtuals, mesurant la valeur économique totale créée par tous les Agents autonomes à travers des services, de la coordination et des activités sur chaîne.
Trajectoire de croissance de aGDP
Problèmes de qualité de aGDP - trois signaux d'alerte :
L'exposition à la dépendance spéculative des fluctuations de revenus : le revenu du jour de protocole du 1er janvier 2025 était de 1,02 million de dollars → fin février 35 000 dollars (baisse de 97 %). Le revenu provient principalement de la taxe sur les échanges de Tokens Agents (1 %), plutôt que des paiements continus pour les services des Agents.
Concentration sévère au sommet : Ethy AI, un Agent, contribue à 218 millions de dollars de aGDP (45,5 % de l'écosystème), les trois premiers totalisant 407 millions de dollars (84,9 %). Ces trois sont tous des Agents d'exécution de transactions, le aGDP est essentiellement le volume des transactions traitées, et non le revenu des services des Agents. Luna, en tant qu'IP phare, a un taux de prise proche de 100 % ; le taux de prise d'Ethy AI est seulement de 0,26 %.
$3 milliards hypothèse de conditions cibles : passer de 470 millions de dollars à 3 milliards nécessite une croissance de 6,4 fois. Si la composante spéculative dans l'aGDP domine, cet objectif parie essentiellement sur la chaleur du marché des Tokens Agents, plutôt que sur la croissance organique de l'économie des Agents.
4.4 Modèle économique des tokens
$VIRTUAL Mécanisme de capture de valeur quadruple
Structure fiscale ACP : utilisateurs paient 100 % → portefeuille de l'Agent 90 % (peut être retiré ou réembauché pour d'autres Agents, composant aGDP sur chaîne) + Trésor 10 % (dont 1 % va à la Trésorerie G.A.M.E) → le revenu du Trésor rachète continuellement des Tokens Agents, alignant les incitations à long terme.
Structure d'offre : total de 1 milliard de VIRTUAL, offre fixe, pas d'inflation initiale ; état actuel : tout débloqué et en circulation ; augmentation potentielle : jusqu'à 10 % par an au cours des trois prochaines années, nécessitant une approbation de gouvernance ; veVIRTUAL : mise en jeu pour obtenir des droits de vote en matière de gouvernance + droits d'airdrop de tokens Agent.
4.5 Vue d'ensemble des données de l'écosystème
Cas d'étude d'Agents de référence
4.6 Dynamique concurrentielle et fossé de protection
Niveau de fossé de protection (du fort au faible)
Effet de réseau + roue de jetons (la plus forte) : plus de 18 000 Agents + plus de 650 000 détenteurs composent un marché bilatéral. Chaque Agent doit être couplé avec VIRTUAL pour créer un cycle de rétroaction positif. C'est quelque chose que le cadre open source ne peut pas reproduire - LangChain n'a pas de couche de règlement économique entre Agents natifs.
Droit de définition des normes (fort) : ACP → ERC-8183 (publié en collaboration avec la Fondation Ethereum) + ERC-8004 + x402, les trois combinés luttent pour le "système juridique fondamental" de l'économie des Agents AI.
Avantage du premier arrivé + marque (moyen) : les Agents AI + la piste Crypto sont en tête en matière de part de marché, avec le soutien d'institutions telles que Grayscale et Fundstrat.
Capacité technique (la plus faible) : l'architecture en couches de GAME a un avantage de conception, mais dépend des LLM tiers, n'a pas de modèles auto-développés, et la couche d'orchestration peut facilement être remplacée par des cadres plus puissants.