Ceci est un rapport de recherche approfondi produit par OKX Ventures. En raison de sa longueur, il sera publié en deux parties : la partie supérieure se concentre sur le contexte macro, le protocole x402, l'ERC-8004 et le Virtuals Protocol, cliquez ici pour y accéder ; la partie inférieure se concentrera sur l'analyse d'OpenClaw et des tendances globales du secteur.
Chapitre 5 OpenClaw : Étude spécialisée sur l'écosystème applicatif
5.1 Contexte du projet et son explosion
En novembre 2025, le développeur autrichien Peter Steinberger a publié un projet de week-end sur GitHub. Quatre mois plus tard, en mars 2026, ce projet a dépassé React pour devenir le projet logiciel avec le plus d'étoiles (Stars) de l'histoire de GitHub — plus de 250 000 étoiles, un chiffre que React a mis 13 ans à atteindre.
Dans la grande tendance de l'évolution des produits IA d'outils passifs vers des agents actifs, le changement opéré par OpenClaw est le suivant : l'IA n'attend plus que l'utilisateur vienne la chercher, mais agit activement pour l'utilisateur sur les plateformes qu'il utilise déjà. Elle réside sur l'ordinateur de l'utilisateur, tout en ayant accès à plus de 20 canaux tels que WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Lark, etc., et opère via le protocole MCP sur la boîte mail, le calendrier, le navigateur, le système de fichiers, l'éditeur de code. Andrej Karpathy a inventé un terme pour ce type de système : les Claws ; des agents IA locaux fonctionnant en arrière-plan en boucle, capables de prendre des décisions autonomes et d'exécuter des tâches. Ce terme est rapidement devenu l'appellation générique dans la Silicon Valley pour les agents IA hébergés localement.
Chaque publication d'un modèle principal met en avant les capacités d'agent en première page, car les agents sont le multiplicateur de demande qui justifie les investissements dans l'infrastructure IA : une requête de chat consomme quelques centaines de tokens, une exécution d'agent avec appels d'outils et raisonnements multi-étapes consomme des dizaines de milliers à des centaines de milliers de tokens.
Bien que le fondateur ait interdit les discussions sur les cryptomonnaies sur Discord. La communauté Crypto a spontanément construit toute une infrastructure économique on-chain sur OpenClaw : émission de jetons, enregistrement d'identité, protocole de paiement, réseau social, système de réputation, etc. L'explosion d'OpenClaw nous permet pour la première fois d'observer dans un scénario réel et à grande échelle la manière dont les agents interagissent avec l'infrastructure on-chain et fournit à la communauté Crypto un hôte avec une base d'utilisateurs réels pour y attacher une activité économique.
5.2 Analyse de l'architecture technique
Première couche : Canaux de messages — Problème d'identité
OpenClaw accède simultanément à 20+ plateformes, de l'intérieur de l'agent, il sait qu'il est le même, avec une mémoire unifiée, une configuration unifiée, un SOUL.md unifié. Mais de l'extérieur, comment savoir si cet agent sur Telegram et celui sur Discord sont les mêmes ? Chaque plateforme a son propre système d'ID utilisateur, les plateformes ne sont pas interconnectées et il est impossible de consulter les historiques de comportement. C'est précisément le problème central que tente de résoudre l'ERC-8004.
Deuxième couche : Passerelle (Gateway) — Problème de sécurité
Le Gateway est le centre de dispatch du cerveau d'OpenClaw : il route les messages utilisateurs vers le bon agent, charge l'historique de conversation de cet agent et les compétences (Skills) disponibles, délimite les frontières des permissions avant que l'agent ne commence à réfléchir (mécanisme de liste blanche : lorsqu'un message arrive au Gateway, le système génère dynamiquement une liste blanche d'outils basée sur des informations telles que le canal source du message, l'ID utilisateur, l'ID du groupe, etc. Seuls les outils sur la liste blanche sont injectés dans le contexte de l'agent. L'agent ne voit tout simplement pas les outils hors liste blanche, il ne peut donc pas les appeler).
L'avantage de cette conception est la mise en avant de la sécurité. Mais sa gestion des permissions dépend entièrement d'un point unique, le Gateway, s'il est compromis ou mal configuré, l'agent pourrait obtenir des permissions qu'il ne devrait pas avoir.
Troisième couche : Cœur de l'agent (Boucle ReAct) — Problème de prédictibilité
La logique de fonctionnement de l'agent est la boucle ReAct (Raisonnement + Action) : recevoir une entrée → réfléchir (appeler le LLM) → décider d'une action → appeler un outil → obtenir un résultat → réfléchir à nouveau → boucler. Les optimisations techniques faites par OpenClaw incluent : la planification de messages haute fréquence (quatre stratégies : Steer/Collect/Followup/Interrupt), la tolérance aux pannes à double couche pour les LLM (rotation d'authentification + dégradation de modèle) et un mécanisme optionnel de gradation de la réflexion (6 niveaux).
Mais le LLM est de nature probabiliste, sa sortie est incertaine. L'agent est un exécutant non déterministe, opérant dans un environnement non déterministe et effectuant des actions irréversibles.
D'abord, la perte de contraintes due à la compression contextuelle : les contraintes de sécurité font elles-mêmes partie du contexte, lorsque le contexte est compressé avec perte, les contraintes de sécurité peuvent être perdues. Ensuite, l'injection de prompt : quelqu'un cache intentionnellement des instructions dans le contenu que l'agent traitera, amenant l'agent à exécuter le contenu comme une commande utilisateur. La racine commune des deux est : la frontière comportementale de l'agent est définie en langage naturel, et le langage naturel est flou, manipulable et compressible avec perte.
Un exemple est celui de Summer Yu, responsable de l'alignement chez Meta Super Intelligence Lab, qui a demandé à un agent de "suggérer des e-mails qui pourraient être supprimés", mais l'agent a directement supprimé des centaines d'e-mails (dépassement de la fenêtre contextuelle déclenchant une compression, la contrainte clé "suggérer" a été perdue).
Dans ce cas, ce dont nous avons besoin n'est pas un meilleur prompt engineering mais des mécanismes de sécurité structurels : des journaux d'opération auditable, des frontières de permission programmables, et un système économique permettant une responsabilisation et une compensation en cas d'erreur. Ce sont précisément des choses que les smart contracts et l'infrastructure on-chain maîtrisent.
Quatrième couche : Système de mémoire — Problèmes de persistance et de migrabilité
OpenClaw implémente deux types de mémoire : la mémoire de travail quotidienne (fichier YYYY-MM-DD.md) et la mémoire essentielle à long terme (MEMORY.md, préférences clés dédupliquées, catégorisées et affinées). Pour la recherche, il utilise un mode hybride de recherche vectorielle + BM25.
Les sessions sont réinitialisées par défaut chaque jour à 4h du matin. La fenêtre contextuelle est constamment compressée et résumée. Lorsque le contexte approche la limite de tokens, OpenClaw déclenche une compression de session, utilisant le LLM pour résumer les conversations précédentes en une version plus courte. Avant la compression, il exécute d'abord un Memory Flush, donnant une chance à l'agent d'écrire les informations clés dans la mémoire persistante. Cela revient essentiellement à parier que l'agent sait lui-même quelles informations sont cruciales. Un système non déterministe pour juger ce qui est une information clé est en soi incertain.
Toute la mémoire d'OpenClaw est stockée dans le système de fichiers local, elle disparaît si on change d'ordinateur ; il n'y a pas de mécanisme de mémoire partagée lors de la collaboration avec d'autres agents ; les connaissances et l'expérience de l'agent sont verrouillées sur la machine sur laquelle il s'exécute. La collaboration entre sous-agents est limitée à l'intérieur d'une même instance OpenClaw, dès qu'il s'agit de collaboration d'agents跨实例 (cross-instance),跨组织 (cross-organisation), le système est impuissant. Retour des développeurs sur GitHub : les enregistrements de décision sont dans l'historique de chat mais ne sont pas persistés sous forme d'artefact, la passation est floue, la transmission des connaissances est incomplète.
5.3 Problèmes structurels de l'économie des agents
Le contexte ne circule pas : La racine de tous les problèmes
- Verrouillage spatial : La mémoire et les connaissances de l'agent sont stockées sur la machine où il s'exécute, changer d'ordinateur et tout disparaît.
- Isolation de la confiance : L'agent A prétend que "l'utilisateur a exprimé la préférence X la semaine dernière", l'agent B n'a aucun moyen de vérifier la véracité.
- Impossible à découvrir : Vous voulez trouver un agent "expert en analyse DeFi" ? Aucun mécanisme de découverte standardisé.
- Valeur non tarifée : Les connaissances domaines et les préférences utilisateur accumulées par l'agent ont clairement une valeur économique, mais il n'existe actuellement aucun moyen de la tarifer ou de l'échanger.
- Temporel par défaut : Le contexte peut être compressé, résumé ou perdu à tout moment lors d'une réinitialisation de session.
Pour que le contexte circule vraiment, il doit同时具备 (posséder simultanément) cinq attributs : pouvoir traverser les frontières de confiance, avoir des attributs économiques, pouvoir être découvert sans gatekeeper, conserver les traces de décision, s'adapter aux besoins des consommateurs. Actuellement, aucun protocole unique ne fournit ces cinq attributs simultanément. MCP résout "comment le modèle IA appelle un outil". A2A résout "comment un agent communique avec un agent". x402 résout "comment un agent paie". Mais "comment un agent découvre, évalue et utilise de manière autonome des données contextuelles dans un environnement non digne de confiance" n'a pas de réponse.
Paradoxe de la coordination
Un agent a seulement besoin de suffisamment de contexte pour raisonner. Mais la coordination跨组织 (inter-organisationnelle) nécessite tout le contexte historique.
Un agent qui pense "Dois-je réserver ce vol ?" a besoin des informations精简 (simplifiées) de la session actuelle. Mais quand il doit coordonner avec un agent de la chaîne d'approvisionnement, un agent financier, un agent de calendrier (potentiellement sur différentes plateformes, opérés par différentes organisations) : Quel contexte partagent-ils ? Comment le vérifier ? À qui appartient la propriété ?
Gartner prédit que d'ici 2027, plus de 40 % des projets d'IA agentique seront annulés en raison de coûts sans cesse croissants, d'une valeur commerciale incertaine ou d'un contrôle des risques insuffisant. Mais 70 % des développeurs rapportent que le problème central est l'existence de problèmes d'intégration avec les systèmes existants. La raison fondamentale est que les agents sont des exécutants non déterministes, et les entreprises veulent des résultats déterministes. Un exécutant incertain dans un environnement incertain collaborant avec des collaborateurs incertains, sans couche de confiance vérifiable, cette combinaison ne peut pas produire une sortie fiable.
Actuellement, le besoin de collaboration跨平台 (cross-platform) entre agents est encore très faible. Les utilisateurs veulent juste une IA qui les aide à travailler, peu importe si elle peut collaborer avec d'autres agents. Le paradoxe de la coordination est un vrai problème technique, mais qu'il évolue ou non en un problème commercial à grande échelle dépend de si le mode d'utilisation des agents évolue d'un outil personnel à un réseau de collaboration multi-agents.
En combinant les analyses ci-dessus, on obtient un concept architectural :
La couche inférieure est l'endroit où l'agent raisonne, éphémère, liée aux tokens. OpenClaw, Claude Code, Cursor sont ici. Nécessite une réponse rapide, se concentre sur la tâche actuelle.
La couche supérieure est le lieu où la coordination a lieu : persistant, vérifiable, avec tarification économique. Les connaissances跨组织 (inter-organisationnelles) s'y accumulent, la chaîne de traçabilité y est maintenue, la réputation y opère.
Les deux couches ont des besoins différents : L'agent a besoin de concision, tandis que l'organisation a besoin d'un historique. L'agent a besoin de vitesse, tandis que la piste d'audit需要永久性 (a besoin de permanence). L'agent fonctionne de manière probabiliste, tandis que l'entreprise需要确定性的结果 (a besoin de résultats déterministes). La plupart des architectures actuelles tentent de fusionner les deux couches, ce qui ne peut pas réussir.
Est-il possible d'ajouter un module complémentaire modulaire, déployable horizontalement sans autorisation, adapté à tous les systèmes d'agents — avec une neutralité digne de confiance, une persistance et une vérifiabilité ? Ce composant fournit une interface contrôlée entre les couches supérieure et inférieure, permettant au contexte de circuler vers le bas lorsque nécessaire, et permettant aux engagements de remonter vers le haut. Avant l'exécution, analyser et injecter le sous-graphe contextuel pertinent à partir du graphe de connaissances décentralisé ; après l'exécution, soumettre l'opération作为可验证交易 (comme transaction vérifiable) sur la chaîne, avec provenance (traçabilité) et mise à jour de la réputation. L'hypothèse centrale de cette couche est également que la流动性的上下文 (la mobilité du contexte) a de la valeur : Si la plupart des utilisateurs d'agents n'ont pas besoin de collaboration跨平台 (cross-platform) (par exemple, une personne utilisant uniquement un OpenClaw pour tout gérer), alors la couche intermédiaire n'a pas de besoin réel.
La couche intermédiaire, si elle ne fait que la portabilité du contexte, échouera probablement. Mais si elle se concentre sur des cas d'usage clairement motivés par des incitations économiques, comme la vérifiabilité des activités économiques dans des scénarios多方互不信任 (multi-parties sans confiance mutuelle) et la migrabilité de la réputation, les chances de succès sont beaucoup plus élevées. IronClaw est également une tentative d'aller dans la direction d'une couche intermédiaire abstraite — séparant l'environnement d'exécution et la gestion des credentials dans une couche de sécurité vérifiable. Mais c'est toujours une solution interne à l'écosystème Near, manquant de通用性 (généricité)跨平台 (cross-platform).
Le véritable point d'entrée de Crypto
La plupart des besoins de l'économie des agents peuvent en fait être résolus avec des solutions Web2. L'irremplaçabilité de Crypto dans l'économie des agents n'existe que dans un scénario : lorsque vous avez besoin d'une interopérabilité跨组织 (inter-organisationnelle),跨平台 (cross-platform), sans autorisation, et qu'il n'y a pas de relation de confiance préétablie entre les parties prenantes. Par exemple : L'agent A (fonctionnant sur OpenClaw, propriétaire utilisateur甲) doit embaucher l'agent B (fonctionnant sur Claude Code, propriétaire utilisateur乙) pour une tâche. Ils n'ont pas de plateforme commune, pas de système de compte commun, pas de relation commerciale préalable. Dans ce scénario, l'identité on-chain (8004), le paiement on-chain (x402), la réputation on-chain sont en effet plus appropriés que toute solution centralisée — car aucune plateforme centralisée ne peut couvrir simultanément tous les frameworks d'agents.
Et, le fait qu'un agent puisse payer ne signifie pas qu'il doive payer. Les entreprises du F500 ont perdu 400 millions de dollars à cause d'agents payant en boucle de réessai (retry loop). Après que les agents puissent payer de manière autonome, l'infrastructure de décision la plus précieuse est celle qui aide l'agent à juger s'il doit ou non effectuer ce paiement.
Actuellement, Crypto pour l'économie des agents est "nice to have", à moins que les interactions économiques跨平台 entre agents n'atteignent une scale suffisante, mais quand suffisamment d'agents ne seront plus liés au compte bancaire d'un humain spécifique (l'agent lui-même devient une entité économique indépendante plutôt qu'un outil humain), les rails financiers traditionnels ne pourront plus les couvrir, à ce moment-là, les stablecoins sont la meilleure (et on pourrait même dire la seule) façon pour leurs transactions massives de fonds. Devenir must have可能的三个触发条件 (trois conditions déclenchantes possibles) :
- Les agents commencent à embaucher massivement d'autres agents : Par exemple, les systèmes d'agents de différents fournisseurs dans les environnements informatiques d'entreprise doivent interopérer (similaire à l'intégration API d'entreprise d'aujourd'hui, mais plus complexe).
- Les agents commencent à effectuer des transactions跨国 (transnationales) 24/7 : Un workflow orchestré par un agent peut同时调用 (appeler simultanément) un endpoint LLM aux États-Unis, un fournisseur de données en Europe, un cluster de calcul en Asie du Sud-Est, il ne devrait pas avoir besoin de trois rails de paiement différents. Les stablecoins sont globaux, 24h/24 et 7j/7. Cet avantage est plus marqué pour les agents dans des scénarios always-on,跨时区 (cross-timezone) que pour les humains.
- Les micro-paiements atteignent une fréquence que les rails traditionnels ne peuvent pas supporter : Actuellement, les micro-transactions effectuées par les agents on-chain (appels API, requêtes de données, ressources de calcul)平均每笔 (en moyenne par transaction) seulement 0,09 $, tandis que Stripe facture seulement des frais de 0,35 $ + 2,5 %, soit 4 fois plus cher que la transaction elle-même ; lorsqu'un agent a besoin d'appeler des dizaines de milliers de fois une API, les processeurs de paiement traditionnels ne peuvent pas assurer ce type de risque marchand et la structure des frais deviendra un véritable goulot d'étranglement.
Menaces de sécurité et nécessité de l'infrastructure on-chain
Le "paradoxe de Siri" est un cadre clé pour comprendre tout le secteur des agents : Siri est sûr parce qu'il est castré, OpenClaw est utile parce qu'il est dangereux. Pour que l'IA accomplisse de vraies tâches (traiter des e-mails, réserver des vols, déployer du code), elle doit avoir des permissions système étendues. Des permissions étendues signifient naturellement une surface d'attaque plus grande.
Le cas positif le plus célèbre sur OpenClaw est : un utilisateur demande à un agent de réserver un restaurant, mais OpenTable n'a pas de disponibilité, l'agent n'abandonne pas, il trouve lui-même un logiciel de synthèse vocale IA, le télécharge, l'installe, appelle le restaurant et réussit à réserver. Cette capacité autonome de résolution de problèmes est ce dont les gens rêvent. Mais la même autonomie signifie que si le jugement est erroné, les conséquences se propagent à la vitesse de la machine.
Certains qualifient l'arrivée de Steinberger chez OpenAI de "moment iPhone des agents IA". Mais avant cela, il doit y avoir une phase où une infrastructure de sécurité est prête. Sinon, une adoption à grande échelle signifie des pertes à grande échelle. Si les prédictions de "piratages de 100 M$+ générés par l'IA" de Chopping Block se réalisent, deux issues sont possibles : soit la panique publique entraîne un recul de l'adoption des agents (similaire à la période de creux d'Ethereum après l'événement DAO de 2016), soit cela fait émerger une véritable infrastructure de sécurité pour les agents (similaire à l'explosion de l'industrie de l'audit des smart contracts après l'événement DAO). Nous penchons pour la seconde. Parce que la demande pour les agents est réelle :
- Identification des agents malveillants >> Système de réputation 8004. Si chaque agent a une identité on-chain et un enregistrement de réputation publique, les comportements malveillants laissent une trace indélébile. Les autres agents peuvent vérifier la réputation on-chain avant de faire confiance. Bien sûr, le système de réputation doit être suffisamment mature — pas un simple score, mais un modèle de confiance multidimensionnel, pondéré dans le temps, avec des mécanismes anti-manipulation.
- Vérification des Skills malveillants >> Registre de validation (Validation Registry). Si les résultats de l'audit de code des Skills sont enregistrés dans le Validation Registry du 8004 — audité par des validateurs indépendants (service staked, validateurs zkML, oracles TEE) — l'effet du typosquatting est considérablement réduit. Il suffit de vérifier l'état de validation on-chain avant d'installer un Skill.
- Fuites de credentials >> "Paiement即授权 (équivaut à autorisation)" de x402. x402 élimine le problème de gestion des clés API. L'agent n'a pas besoin de stocker des credentials à long terme — à chaque fois qu'il a besoin d'un service, il paie directement pour obtenir un droit d'accès temporaire. Combiné avec la signature EIP-712 liant (liant le droit d'utilisation du service à l'adresse de paiement), même si le token est divulgué, il ne peut pas être utilisé par quelqu'un d'autre.
- Dérapage comportemental >> Journaux d'audit on-chain + permissions programmables. Qu'il s'agisse d'un attaquant externe injectant des instructions (injection de prompt), ou du système lui-même perdant des contraintes lors de la compression (perte de contexte), le résultat est que l'agent exécute des opérations超出预期 (au-delà des attentes). Les smart contracts peuvent définir les frontières comportementales de l'agent — par exemple "aucune transaction unique ne dépasse le montant X", "les opérations de suppression nécessitent une confirmation multi-signature". Les journaux d'opération on-chain sont immuables, en cas de problème, on peut remonter la trace. C'est beaucoup plus fiable que d'ajouter "veuillez demander une autorisation au préalable" dans le prompt, car les contraintes au niveau du prompt peuvent être perdues lors de la compression, mais les contraintes au niveau du smart contract ne le seront pas.
Bien sûr, l'infrastructure on-chain ne peut qu'atténuer les conséquences des problèmes de sécurité, pas les prévenir. Un smart contract peut limiter "aucune transaction unique ne dépasse X", mais si l'agent est injecté et fait continuellement des actions malveillantes dans la limite ? Une transaction malveillante de 0,09 $ effectuée dix mille fois fait aussi 900 $. La véritable résolution de la sécurité nécessite une double approche au niveau de la couche d'exécution de l'agent (TEE/sandbox) et de la couche on-chain (permissions/audit). Seulement faire la couche on-chain ne suffit pas.
Chapitre 6 Analyse globale du secteur
Les douves technologiques traditionnelles (capacité d'ingénierie, taille de l'équipe, efficacité d'exécution) sont en train d'être homogénéisées par les outils d'IA. Toute personne ayant une idée, via OpenClaw ou Claude Code, peut implémenter un prototype de produit en très peu de temps. Cela signifie :
- La fenêtre d'opportunité pour les petites équipes est plus courte que jamais (les grandes équipes utilisant les mêmes outils rattraperont leur retard plus rapidement).
- L'avantage du premier mover a une valeur plus élevée que jamais au niveau de l'idée, car votre agent peut itérer plus vite que n'importe quel concurrent.
- Le plus rare n'est pas la capacité technique, mais le jugement sur les bons problèmes à résoudre.
La vraie concurrence des pistes n'est pas à l'intérieur de Crypto
Beaucoup comparent quel L1/L2 fait mieux les agents — Base vs Solana vs Ethereum vs Near. Mais la vraie concurrence est entre les solutions Crypto et les solutions Web2.
Par exemple, Sapiom a levé 15,75 M$, il suit une approche Web2 pour la gestion de l'accès aux services des agents. Dans le pire des cas, si la solution de Sapiom est suffisamment bonne — les agents obtiennent via lui l'accès à tous les services Web2, sans avoir à toucher aux paiements on-chain — alors x402 n'a plus de raison d'être. La solution de carte virtuelle de Stripe, si elle peut résoudre le problème d'anti-automatisation par des négociations commerciales (convaincre les marchands de supprimer le CAPTCHA pour certaines cartes virtuelles spécifiques), la solution de deuxième phase peut durer plus longtemps. C'est-à-dire le champ de bataille que Visa, Mastercard, Stripe sont en train de se disputer actuellement, une代理授权 (autorisation par procuration) contrôlée dans des limites autorisées. L'essentiel est la carte virtuelle + API de paiement dédiée. Transformer la relation de confiance de "faire confiance à une IA incertaine" en "faire confiance à un outil de paiement aux paramètres déterminés, contrôlé par l'émetteur de la carte". Actuellement le plus adapté à une application à grande échelle, mais lorsque les scénarios agentiques B2B atteindront une autre magnitude, la programmabilité des informations d'autorisation et les limitations de volume de données des cartes bancaires deviendront des goulots d'étranglement.
La condition préalable pour que x402 gagne est que son modèle "Paiement即授权 (équivaut à autorisation)" soit supérieur en termes de coût, de latence et d'expérience développeur au modèle "gestion par proxy intermédiaire". Actuellement, x402 a un avantage dans les scénarios de micro-paiements (jusqu'à 0,001 $/transaction), mais dans les scénarios企业 (d'entreprise) nécessitant une gestion complexe des permissions, il pourrait être inférieur aux solutions Web2.
De même, la condition préalable pour que 8004 gagne est : l'identité on-chain et la réputation sont plus utiles que les systèmes d'identité gérés par des plateformes centralisées (comme le propre mécanisme de modération de ClawHub). Actuellement, l'adoption de 8004 n'est pas encore assez large, l'expérience de consultation de la réputation on-chain est inférieure à la consultation des notes sur une plateforme. L'acquisition de moltbook par Meta vise également cette capacité fondamentale de vérification d'identité et de registre (directory) des agents. Ils veulent contrôler la couche d'identité des agents.
Les solutions Crypto ne peuvent pas se contenter d'être théoriquement meilleures. Elles doivent rattraper voire dépasser les solutions Web2 en termes d'expérience développeur et d'expérience utilisateur. Sinon, elles finiront comme beaucoup de produits Crypto, avec une idée décentralisée excellente mais trop compliquée à utiliser pour attirer des utilisateurs.
Les géants du paiement traditionnel définissent le calendrier d'adoption
Le marché évoluera en trois phases. Dans les 3-5 prochaines années, la solution Stripe/Visa dominera le marché早期 (early) — la rétrocompatibilité est imbattable, les agents peuvent immédiatement交易 (transiger) avec des millions de marchands dans le monde acceptant déjà les cartes de crédit. Au-delà de 5 ans, les points de douleur de la deuxième phase s'accumuleront jusqu'à être insupportables — manque de système d'autorisation programmable, incapacité à construire une identité agentique avec suffisamment d'informations, frais de micro-transactions élevés, règlement跨国 (transnational) lent — le marché se tournera naturellement vers l'infrastructure Crypto de la troisième phase.
Cela signifie que les solutions Crypto n'ont pas besoin de battre Stripe aujourd'hui. Elles doivent perfectionner l'infrastructure dans les 3-5 prochaines années, pour prendre le relais lorsque la solution de deuxième phase atteindra ses limites. C'est actuellement une course à la construction d'infrastructure, pas encore à la conquête de parts de marché. Bien sûr, l'infrastructure doit être en place à l'avance, mais avoir seulement une infrastructure ne génère pas automatiquement une adoption, il faut une explosion au niveau applicatif pour l'activer. TCP/IP a été inventé dans les années 1970, mais n'a été massivement utilisé qu'avec l'apparition des navigateurs web dans les années 1990. Actuellement, nous pouvons voir l'infrastructure se perfectionner progressivement, mais personne ne l'utilise à grande échelle. Par exemple, x402 a été pendant la majeure partie de 2025 un protocole techniquement utilisable mais manquant de cas d'usage杀手级 (tueur). Nous avons besoin de plus d'applications pour relier ces infrastructures en une pile utilisable. L'explosion d'OpenClaw/Moltbook est le premier moteur de demande que nous voyons — soudainement, des centaines de milliers d'agents ont besoin de paiement, d'identité, de réputation, x402 et 8004 sont passés de "utilisables" à "utilisés".
Vendre des pelles est plus rentable que chercher de l'or
L'ensemble de l'écosystème "lobster" sur Base valide une sagesse投资 (d'investissement) ancienne : pendant une ruée vers l'or, ceux qui gagnent de l'argent le plus sûrement sont ceux qui vendent des pelles.
Felix a gagné 75 000 dollars. Mais les frais perçus par Clanker sur 64 000 déploiements de jetons dépassent largement ce montant. ClawRouter vend des services de routage LLM (0,003 $/requête). ClawCloud vend de la puissance de calcul pour agents. Venice vend des quotas d'inférence et金融化 (financialise) la puissance de calcul via le modèle VVV/DIEM. Les modèles commerciaux de ces fournisseurs d'infrastructure sont beaucoup plus matures et fiables que ceux des agents gagnant de l'argent de manière autonome.
L'infrastructure dont toutes les catégories d'agents ont besoin — identité, paiement, sécurité, coordination, ressources de calcul. Peu importe quel框架 (framework) d'agent l'emporte (OpenClaw, IronClaw, le prochain produit d'OpenAI), ils en auront tous besoin. Le terme "Claws" inventé par Karpathy捕捉 (capture) une tendance plus grande qu'OpenClaw — l'IA agentique本地化 (localisée),持久化 (persistante),自主化 (autonome) est une catégorie, l'infrastructure Crypto doit servir l'ensemble de la catégorie Claw. IronClaw (version sécurisée TEE de Near), les divers frameworks d'agents personnalisés pour entreprises, l'agent intégré qu'OpenAI s'apprête à lancer appartiennent tous à cette catégorie. OpenClaw est le précurseur de cette catégorie, mais ne sera pas le seul.
Product-Agent Fit remplacera Product-Market Fit
Plusieurs plateformes (Taobao, Xiaohongshu, Weibo, Xueqiu) ont commencé à bloquer les comptes d'utilisateurs d'OpenClaw, car les agents contournent les mécanismes anti-scraping de ces plateformes via une simulation de navigateur. Les plateformes et les utilisateurs d'agents sont天然对立 (naturellement opposés). Le modèle commercial des plateformes est basé sur l'attention des utilisateurs humains, les utilisateurs d'agents consomment des données mais ne génèrent pas de valeur publicitaire.
Le marketing traditionnel dépend de l'économie de l'attention — belles images, publicités vidéo, boutons限时 (limités dans le temps) — des stratégies ciblant la consommation impulsive humaine. L'agent est un代理 (agent) de décision absolument rationnel, se concentrant uniquement sur la clarté des données renvoyées par l'API, l'exhaustivité des paramètres. Il compare les spécifications du produit, les prix historiques, les délais de livraison, les évaluations des utilisateurs甚至 (voire) l'empreinte carbone. Il n'y aura pas de占领用户心智 (capture de l'esprit des utilisateurs). La future douve n'est pas la marque (l'agent ne reconnaît pas les marques), ni l'UX (l'agent n'utilise pas d'interface), mais le degré de structuration des données, la stabilité de l'API, la compatibilité MCP, et les enregistrements de qualité de service vérifiables on-chain.
Le modèle commercial d'Internet pourrait évoluer vers un paiement按爬取付费 (au crawl), l'agent en tant que consommateur de services, n'utilisant plus le modèle gratuit soutenu par la publicité, mais payant directement des frais de récupération de données : chaque requête de données, chaque appel API, chaque utilisation de service nécessite un paiement direct de frais微小的 (infimes) et aide l'agent à accéder合规地 (conformément) aux données de la plateforme demande. C'est précisément ce que résout x402, en obtenant un droit d'accès aux données via un paiement direct et en supportant les micro-transactions. Et ce monde a déjà une forme早期 (naissante) : Lord of a Few a mis en ligne 80+ endpoints payants x402 en une semaine, chacun coûtant 0,50 $ à construire, facturant de quelques centimes à几十美分 (quelques dizaines de centimes).
De plus, lorsque l'acheteur et le vendeur sont tous deux des agents, comment les bassins de profit seront-ils redistribués ?
Conclusion
Nous sommes dans une fenêtre rare : l'infrastructure est en place, mais l'application杀手级 (tueuse) n'est pas encore arrivée. L'histoire a maintes fois prouvé que les véritables révolutions ne s'annoncent pas à l'avance — elles ne font que, à un moment inattendu,让所有人意识到 (faire réaliser à tous) que l'ancien monde est terminé.
Références partielles
[1] McKinsey & Company, "The Agentic Commerce Opportunity," 2025. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-agentic-commerce-opportunity
[2] Morgan Stanley Research, "AI Agentic Shoppers: The Next Frontier of E-Commerce," 2025.
[3] Edgar Dunn & Company, "Agentic Commerce: The Future of AI-Driven Retail," 2025.
[4] Dune Analytics — x402 Transactions per Project Dashboard
[5] Artemis Analytics — app.artemisanalytics.com/asset/x402
[6] x402 White Paper — x402.org
[7] EIP-8004 — ethereum-magicians.org
[8] ERC-8183 — ETH Foundation dAI Team, March 2026
[9] Virtuals Protocol Documentation — virtuals.io
[10] SecurityScorecard — OpenClaw Exposure Report, 2026.03
[11] The Block, Phemex, Allium Labs — Various x402 Data Reports
[12] MarketsandMarkets, "Agentic AI in Retail and eCommerce Market Report," 2025.
