Lancement de x402 Foundation en collaboration avec Coinbase et prise en charge des transactions x402

Cloudflare s'associe à Coinbase pour lancer x402 Foundation. Cette fondation aura pour mission d'encourager l'adoption du protocole x402, un cadre mis à jour qui permet aux clients et aux services d'échanger de la valeur sur le web à l'aide d'un langage commun. En complément du partenariat annoncé ce jour, nous déployons un ensemble de fonctionnalités permettant aux développeurs d'utiliser x402 dans le SDK Agents et dans nos intégrations MCP, ainsi que de proposer un nouveau schéma de paiement différé.

D'un point de vue historique, les paiements sur le web ont été conçus pour les humains. Nous parcourons le site web d'un revendeur, nous indiquons notre intention en ajoutant des articles à un panier, puis nous confirmons notre intention d'acheter en saisissant les informations de notre carte de paiement avant de cliquer sur « Payer ». Mais que faire si vous souhaitez permettre des transactions directes entre différents services numériques ? Nous avons besoin de protocoles pour permettre les transactions de machine à machine. 

Chaque jour, les sites hébergés sur Cloudflare envoient plus d'un milliard de codes de réponse HTTP 402 à des bots et des robots d'indexation qui tentent d'accéder à leurs contenus et leurs boutiques d'e-commerce. Ce code de réponse est accompagné d'un message simple : « Payment Required » (paiement nécessaire).

Pourtant, ces codes 402 restent trop souvent sans réponse, notamment en raison d'un manque de standardisation. En l'absence de spécification concernant le formatage et le traitement de ces codes de réponse, les créateurs de contenu, les éditeurs et les exploitants de sites web ne disposent pas d'outils adéquats pour transmettre leurs demandes de paiement. x402 peut fournir aux développeurs un protocole clair et ouvert, permettant aux sites web et aux agents automatisés de négocier les paiements dans le monde entier. 

Coinbase a élaboré le flux de transactions x402, décrit ci-dessous, pour permettre aux machines de payer directement des ressources via HTTP :

1. Un client tente d'accéder à une ressource protégée par x402. 

2. Le serveur répond en renvoyant le code d'état 402, « Payment Required ». Le corps de la réponse contient des instructions de paiement, notamment le montant du paiement et le destinataire.

3. Le client demande la ressource protégée par x402 avec l'en-tête d'autorisation de paiement.

4. Le facilitateur de paiement vérifie les données de paiement du client, puis règle la transaction.

5. Le serveur répond en renvoyant la ressource demandée dans la réponse, ainsi que l'en-tête de réponse de paiement confirmant le résultat du paiement. 

Ce flux crée un accès programmatique aux ressources disponibles sur l'ensemble d'Internet. Les clients et serveurs capables d'interpréter le protocole x402 peuvent effectuer des transactions, sans qu'il soit nécessaire de disposer de comptes, d'abonnements ou de clés API.

x402 peut être utilisé pour la monétisation de scénarios d'utilisation traditionnels, mais permet également de monétiser une nouvelle classe de scénarios d'utilisation, par exemple :

• Un assistant capable d'acheter des accessoires pour votre costume d'Halloween auprès de plusieurs marchands.

• Un agent IA effectuant des paiements par session de rendu de navigateur, au lieu de souscrire un abonnement mensuel payant.

• Un robot de trading en bourse autonome qui effectue des micropaiements pour accéder à un flux de données en temps réel de haute qualité, facilitant la prise de décisions.

Les futures versions de x402 pourraient être agnostiques des infrastructures de paiement et accepter les cartes de paiement et les comptes bancaires, en plus des stablecoins. 

Les agents et les robots d'indexation nécessitent souvent deux fonctions importantes qui existent déjà dans une grande partie de l'infrastructure financière actuelle : le règlement différé, permettant de prendre en compte les litiges, et un paiement unique et agrégé, permettant de simplifier leur comptabilité. Par exemple, les robots d'indexation participant à notre version bêta privée du paiement à l'exploration peuvent facilement indexer un grand nombre de pages, générer des journaux d'audit, puis être facturés d'un montant unique via une carte de paiement ou un compte bancaire associé, à la fin de chaque journée. 

Pour prendre en compte ces types de scénarios de paiement, nous proposons un nouveau schéma de paiement différé pour le protocole x402. Ce nouveau schéma est spécifiquement conçu pour les paiements agentiques qui ne nécessitent pas de règlement immédiat et peuvent être gérés à l'aide de méthodes de paiement traditionnelles ou de stablecoins. En proposant cet ajout, nous contribuons à assurer que tout serveur conforme peut, si nécessaire, découpler la négociation cryptographique du règlement de paiement lui-même, offrant ainsi aux agents et aux serveurs la possibilité d'utiliser des accords de licence, des règlements par lots ou des abonnements préalablement négociés.

Nous introduirons ce nouveau système de paiement différé pour le paiement à l'exploration à mesure que nous développerons et ferons évoluer la version bêta privée. 

Voici notre proposition initiale pour la négociation, qui pourrait être publiée dans la prochaine version majeure de x402 :

Aujourd'hui, un client non authentifié ou non autorisé tente d'accéder à une ressource et reçoit une réponse 402, « Payment Required ». Le serveur fournit des données d'engagement de paiement que le client peut utiliser pour créer une nouvelle requête. Cette réponse est une offre lisible par machine, et notre proposition inclut un nouveau schéma différé.

HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "accepts": [
    {
      "scheme": "deferred",
      "network": "example-network-provider",
      "resource": "https://example.com/page",
      "...": "...",
      "extras": {
        "id": "abc123",
        "termsUrl": "https://example.com/terms"
      },
    }
  ]
}

Ensuite, le client renvoie la requête avec des données signées contenant son engagement de paiement. Le schéma différé utilise HTTP Message Signatures, où une clé publique au format JWK est disponible dans un répertoire hébergé. L'en-tête Signature-Input explique clairement quelles parties de la requête sont incluses dans la Signature pour servir de preuve cryptographique de l'intention du client, vérifiable par le prestataire de services sans transaction on-chain. 

GET /path/to/resource HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 Chrome/113.0.0 MyBotCrawler/1.1
Payment:
    scheme="deferred",
    network="example-network-provider",
    id="abc123"
Signature-Agent: signer.example.com
Signature-Input:
    sig=("payment" "signature-agent");
    created=1700000000;
    expires=1700011111;
    keyid="ba3e64==";
    tag="web-bot-auth"
Signature: sig=abc==

Le serveur de ressources valide la signature et renvoie le contenu avec un en-tête de confirmation. Le serveur est chargé d'attribuer le paiement au compte associé à la signature de message HTTP, de vérifier l'identité du client, puis de transmettre le contenu. Dans ce scénario, aucune blockchain n'est associée aux paiements. 

HTTP/1.1 200 OK
Content-Type: text/html
Payment-Response:
    scheme="deferred",
    network="example-network-provider",
    id="abc123",
    timestamp=1730872968

Le serveur peut désormais traiter le règlement de manière flexible. L'identifiant validé issu de la négociation sert de référence pour la transaction. Cette approche propose un modèle d'utilisation flexible, sans frais supplémentaires par requête, permettant au serveur de regrouper les paiements sur la base d'un abonnement, sur une base quotidienne ou même par lot. Elle permet ainsi d'obtenir un cadre flexible, permettant l'établissement immédiat de la confiance cryptographique, tandis que le règlement financier peut utiliser des infrastructures de paiement traditionnelles ou des stablecoins. 

L'exécution de code est ce qui permet à une convention ouverte d'évoluer de la théorie à l'utilité véritable, puis de devenir une norme reconnue. Les agents développés avec le SDK Agents de Cloudflare peuvent désormais payer les ressources avec x402, et les serveurs MCP peuvent exposer les outils à payer via x402. Pour illustrer ce fonctionnement, nous avons créé le bac à sable x402, une démo en direct utilisant x402. Le bac à sable x402 est piloté par le SDK Agents et a accès aux outils provenant des serveurs MCP déployés sur Cloudflare.

Lorsque vous ouvrez le bac à sable x402, un nouveau wallet est créé et financé en USDC Testnet sur un testnet de la blockchain Base. L'agent, développé avec le SDK Agents, a accès à un serveur MCP proposant des outils, aussi bien gratuits que payants.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { McpAgent } from "agents/mcp";
import { withX402 } from "agents/x402";

export class PayMCP extends McpAgent {
  server = withX402(
    new McpServer({ name: "PayMCP", version: "1.0.0" }),
    X402_CONFIG
  );

  async init() {
    // Paid tool
    this.server.paidTool(
      "square",
      "Squares a number",
      0.01, // Tool price
      {
        a: z.number()
      },
      {},
      async ({ number }) => {
        return { content: [{ type: "text", text: String(a ** 2) }] };
      }
    );

    // Free tool
    this.server.tool(
      "add-two-numbers",
      "Adds two numbers",
      {
        a: z.number(),
        b: z.number(),
      },
      async ({ a, b }) => {
        return { content: [{ type: 'text', text: String(a + b) }] };
      }
    );
  }
}

Lorsque l'agent tente d'utiliser un outil payant, le serveur MCP répond par un code 402, « Payment Required ». L'agent est capable d'interpréter les instructions de paiement et d'inviter l'utilisateur à confirmer s'il souhaite poursuivre à la transaction. La création d'un client compatible x402 nécessite un simple wrapper sur l'appel de l'outil :

import { Agent } from "agents";
import { withX402Client } from "agents/x402";

export class MyAgent extends Agent {
  // Your Agent definitions...

  async onToolCall() {

    // Build the x402 client
    const x402Client = withX402Client(
      myMcpClient,
      { network: "base-sepolia", account: this.account }
    );

    // The first parameter becomes the confirmation callback.
    // We can set it to `null` if we want the agent to pay automatically.
    const res = await x402Client.callTool(
      this.onPaymentRequired,
      {
        name: toolName,
        arguments: toolArgs
    });
  }
}

Cet agent de test retire les fonds du wallet, puis transmet les données de paiement au serveur MCP, qui règle la transaction. Les transactions peuvent être configurées pour être exécutées avec ou sans confirmation humaine, vous permettant ainsi de concevoir l'interface la mieux adaptée à votre application.

Vous pouvez vous lancer dès aujourd'hui en utilisant le SDK Agents ou en déployant votre propre serveur MCP.

Nous continuerons à travailler en étroite collaboration avec Coinbase pour développer x402 Foundation. Restez à l'écoute pour découvrir très prochainement de nouvelles annonces présentant les spécificités de la structure.

Nous croyons en la valeur des protocoles ouverts et interopérables ; c'est pourquoi nous vous encourageons tous à contribuer directement au protocole x402. Pour contacter l'équipe de Cloudflare qui travaille sur x402, envoyez-nous un message à l'adresse x402@cloudflare.com.