Après neuf paiements, TBC accueille l'entrée commerciale des machines AI

Le 20 octobre, Mastercard a réalisé une petite démonstration lors de Cloudflare Connect, mais cela pourrait ouvrir un grand marché. Un agent AI a effectué neuf paiements à deux commerçants indépendants dans le cadre d'un budget approuvé, pour acheter des services de recherche et de génération d'images.

Les neuf transactions en elles-mêmes ne sont pas impressionnantes. Le véritable changement est que l'AI a réussi pour la première fois à découvrir des services, à les appeler et à payer les frais de manière claire et visible en même temps. L'infrastructure de paiement nécessaire pour le commerce des machines passe d'une idée à un processus opérationnel.

Un réseau de paiement pour les agents AI dans l'ère des machines

Les humains utilisent les services Internet en s'inscrivant d'abord, en liant une carte bancaire, en achetant un forfait, puis en réglant mensuellement. Le fonctionnement d'un agent AI est complètement différent. Pour accomplir une tâche, il peut appeler plusieurs interfaces de données, modèles et ressources de calcul en quelques minutes, chaque paiement étant très faible, mais nécessitant une confirmation immédiate pour continuer l'exécution.

Le modèle traditionnel rencontre ici des résistances évidentes. Créer un compte et une clé API pour chaque service entraîne une gestion massive des identités et des autorisations ; un solde prépayé disperse les fonds ; chaque transaction attendant une approbation manuelle perd en efficacité d'automatisation. Mais si l'on confie des droits complets au portefeuille à l'agent, toute erreur d'instruction pourrait se transformer en risque financier.

L'idée proposée par Mastercard Agent Pay for Machines est que l'entreprise définisse d'abord la tâche, les autorisations et le budget. Le serveur envoie une demande de paiement HTTP 402, l'agent émet un reçu de paiement conforme au montant, et le commerçant vérifie avant de continuer à fournir le service. Les reçus hors chaîne garantissent la rapidité de réponse, tandis que le règlement consolidé est effectué par la blockchain et le réseau de paiement.

Cette démonstration a été réalisée avec le règlement en chaîne fourni par Base, l'infrastructure de portefeuille par Coinbase Developer Platform, et BVNK a géré le portefeuille de l'agent ainsi que le règlement en monnaie fiduciaire ou en stablecoin. Mastercard précise que le produit est encore en phase pilote et n'est pas encore commercialisé, mais il a déjà exposé clairement le problème de l'industrie : le cœur de la compétition des paiements des machines est de permettre à l'agent de consommer de manière continue sans céder des autorisations illimitées.

La structure UTXO de TBC convient naturellement aux budgets de niveau tâche

Lorsqu'un agent gère plusieurs tâches simultanément, partager un solde total n'est pas la structure de financement idéale. Une approche plus raisonnable consiste à donner à chaque tâche un budget indépendant : la tâche de recherche ne peut acheter que des données, la tâche de conception ne peut appeler que des services d'image, et le budget s'arrête automatiquement une fois épuisé ou la tâche terminée.

Le modèle UTXO enregistre les actifs comme des sorties indépendantes les unes des autres. Chaque fonds peut être géré et suivi séparément, et des conditions de dépense différentes peuvent être configurées. Comparé à la centralisation de toutes les règles dans un backend, cette structure est plus adaptée à la correspondance entre budget et tâche, permettant à l'état des fonds d'entrer directement dans des transactions vérifiables sur la chaîne.

TBC utilise le modèle UTXO de type Bitcoin et le PoW SHA256, tout en fournissant des capacités de contrat intelligent de niveau 1 via TuringContract. Les développeurs peuvent concevoir des seuils de signature, des limites de montant, des destinataires et des conditions temporelles autour d'UTXO indépendants, permettant à l'agent d'obtenir les fonds nécessaires à l'exécution de la tâche, sans obtenir le contrôle total du portefeuille.

Cela signifie que TBC ne fournit pas simplement un canal de transfert ordinaire pour les agents AI, mais une infrastructure plus adaptée à la gestion des fonds par les machines. Les tâches peuvent être décomposées, les budgets peuvent être isolés, les règles de dépense peuvent être vérifiées, et les enregistrements de règlement peuvent être retracés. Pour les API, modèles et services de calcul facturés à la demande, ces capacités ont une valeur produit directe.

Quatre capacités qui donnent à TBC une base pour les paiements des machines

La première est le budget programmable en chaîne. Le code des nœuds TBCNODE est public, et TuringContract permet à UTXO de porter des règles de contrat. Les projets peuvent allouer des fonds à des tâches spécifiques, permettant à l'agent de payer de manière autonome dans des conditions définies, tout en laissant d'autres actifs en dehors des autorisations de la tâche.

La deuxième est l'outil d'actifs stables. Le SDK tbc-contract a déjà fourni des requêtes en chaîne, l'obtention d'UTXO, la construction de transactions, la signature et la diffusion. Le SDK TBC20 Stablecoin prend en charge l'émission, l'augmentation, le transfert, le transfert en masse, le gel et le dégel, fournissant une entrée de développement prête à l'emploi pour établir des actifs de valorisation stable pour les achats des machines.

La troisième est la capacité d'autorisation multi-parties. Le SDK couvre le processus MultiSig, et la documentation du TBC20 Stablecoin fournit également un exemple de signature conjointe 2-of-2 pour les administrateurs. Les projets peuvent séparer la gestion des fonds de l'exécution par l'agent, permettant aux machines d'agir dans les limites, tandis que les opérations clés continuent d'être confirmées par plusieurs parties autorisées.

La quatrième est l'orientation vers des coûts bas et une haute fréquence. Les documents publics de TBC indiquent que le TPS du réseau principal dépasse 13 000, et que la confirmation zéro et les faibles frais sont des priorités de conception. Les agents AI achètent souvent des services numériques à bas prix, et ce n'est que lorsque les frais de règlement sont suffisamment bas et que le réseau peut traiter un grand nombre de demandes simultanées que le paiement à la demande a une chance de former un modèle commercial à long terme.

Ces capacités combinées donnent à TBC une base technique pour entrer sur le marché des paiements AI. Il conserve la structure d'actifs UTXO de la route technique de Bitcoin tout en ajoutant des contrats intelligents et des outils d'actifs stables, pouvant gérer simultanément l'isolement des budgets, l'exécution conditionnelle et le règlement de valeur.

Bien sûr, les indicateurs de performance publics nécessitent encore plus de tests répétables, et UTXO et la multi-signature ne peuvent pas remplacer l'identité des commerçants, la sécurité des appareils et les systèmes de gestion des risques. Actuellement, aucune information publique ne montre que TBC a intégré x402 ou établi des collaborations avec Mastercard, Base, Coinbase ou BVNK. La relation de TBC avec les sujets d'actualité de cette semaine est une question de route technique et d'opportunité de marché, et non de collaborations existantes.

Passer des capacités de protocole aux produits de paiement AI

Une fenêtre de marché s'est déjà ouverte, et la prochaine étape dépend de la vitesse des produits. TBC peut s'adapter autour de l'adaptateur HTTP 402, des stratégies de portefeuille d'agent, des modèles de limites et de listes blanches, des cas de paiement en stablecoin TBC20, des reçus vérifiables et des SDK pour commerçants, formant un ensemble d'outils de paiement pour machines que les développeurs peuvent déployer rapidement.

Lorsque ces composants seront progressivement améliorés, les scénarios que TBC pourra prendre en charge s'étendront des paiements ordinaires à l'achat de données à la demande, à la facturation des inférences de modèles, au règlement instantané des capacités, aux achats de robots et au renouvellement automatique des appareils intelligents. L'équipe du projet peut se charger des services et des utilisateurs, tandis que TBC gère les actifs, les règles et le règlement, permettant aux transactions entre machines de ne plus dépendre d'opérations manuelles par transaction.

Cela offre également aux développeurs et aux projets une nouvelle direction de croissance. Actuellement, les paiements par agents sur les chaînes dominantes se concentrent encore sur un petit nombre de réseaux et d'expérimentations précoces, et le marché n'a pas encore formé de schéma fixe. Plus tôt TBC terminera des cas de portefeuille d'agent fonctionnels, d'API payantes et de règlements en stablecoin, plus il aura de chances d'établir des normes techniques, d'accumuler les premiers commerçants et de prendre une position de premier plan avant l'expansion réelle du commerce des machines.

Mastercard choisit des reçus hors chaîne et des règlements en masse, ce qui montre que les paiements des machines nécessitent à la fois rapidité et autorisations claires. TBC peut tirer parti des caractéristiques d'UTXO et des contrats de niveau 1 pour placer l'état du budget et les règles clés sur la chaîne, puis connecter les services HTTP via une couche d'adaptation. La combinaison de ces deux approches fournit un chemin réaliste pour TBC d'entrer dans les paiements natifs AI.

Neuf paiements ne sont que le début. Ils prouvent que les agents AI ont déjà fait le pas de "pouvoir accomplir des tâches" à "pouvoir acheter les ressources nécessaires pour accomplir des tâches".

Lorsque le commerce des machines commence à rivaliser pour de nouveaux réseaux de règlement, TBC possède déjà UTXO, TuringContract, TBC20 et une direction de haute concurrence. La prochaine étape consiste à combiner ces technologies en un produit de paiement que les développeurs AI seront prêts à utiliser directement.

Source d'information Mastercard Agent Pay for Machines · Mastercard Early Access · TBC Contract SDK · TBC20 Stablecoin SDK · TBCNODE · TBC White Paper