Le dépôt officiel de x402 intègre une spécification pour les paiements en bitcoin via Lightning. La fusion du 23 septembre 2026 définit le schéma exact/lnbtc pour x402 v2 : une facture Lightning, un paiement préalable et une preuve cryptographique avant l’accès au service. Cette étape documente un fonctionnement technique ; elle ne démontre pas un déploiement généralisé.

Une spécification Lightning désormais dans le dépôt officiel

La contribution intitulée « Specify exact Lightning on lnbtc », intégrée sous le numéro 2861, ajoute un document dédié au schéma exact sur Bitcoin Lightning. GitHub horodate sa fusion au 23 septembre, à 06:01:22 UTC, soit 08:01:22 à Paris. C’est cette intégration qui constitue la nouveauté, pas la date initiale de création de la proposition.

Le texte vise la version 2 de x402 et distingue le réseau principal Bitcoin de son réseau de test. Il précise comment un logiciel peut payer une ressource ou un appel d’outil avec Lightning. Il ne modifie pas les règles de consensus de Bitcoin et ne lance pas une nouvelle cryptomonnaie.

Pour situer le projet, notre article sur le passage de x402 sous l’égide de la Linux Foundation revient sur son cadre de gouvernance. L’évolution du jour est différente : elle décrit les règles d’un mode de paiement précis, et non une nouvelle annonce institutionnelle.

Payer d’abord, présenter la preuve ensuite

Le mécanisme ne prévoit ici qu’une méthode : une facture au format BOLT11 et un flux dit upfront, c’est-à-dire un paiement effectué avant le traitement de la demande. Le serveur crée une facture fraîche liée à la requête. Le client la vérifie, la paie, puis transmet la préimage du paiement, un secret permettant d’en vérifier la preuve cryptographique.

Le facilitateur, composant chargé de contrôler cette preuve, vérifie notamment que son empreinte correspond à celle inscrite dans la facture et que la clé de signature désigne le receveur attendu. Il n’a pas besoin d’accéder au nœud Lightning du receveur pour ce contrôle. Le serveur ne traite la demande protégée qu’après validation et enregistrement de la preuve comme utilisée.

Cette distinction évite un contresens : l’étape appelée settlement dans ce schéma ne déplace pas une seconde fois les fonds. Le paiement Lightning a déjà eu lieu. Un portefeuille ou un adaptateur incapable de restituer la préimage ne peut donc pas utiliser ce mécanisme conformément à la spécification.

Lier le paiement au bon service et empêcher sa réutilisation

Une preuve de paiement ne doit pas ouvrir l’accès à n’importe quelle ressource au même prix. La spécification lie la facture à une empreinte de la requête : selon le profil, celle-ci couvre notamment l’URL et le contenu HTTP, ou l’identité du serveur, le nom de l’outil et ses arguments pour MCP, un protocole de connexion aux outils logiciels.

Le texte impose aussi une protection persistante contre le rejeu. Le facilitateur doit enregistrer de façon atomique qu’une preuve a déjà servi, afin que deux demandes concurrentes ne puissent pas la consommer toutes les deux. Un simple stockage en mémoire ne suffit pas : les enregistrements doivent survivre à un redémarrage.

La clé du receveur constitue une autre condition importante. Le serveur doit disposer de l’autorité exclusive pour émettre les factures sous cette clé. Un nœud mutualisé qui permettrait à un tiers non fiable de créer des factures avec la même clé ne répondrait pas à cette exigence. Ces contraintes interdisent de présenter la compatibilité comme automatique pour tous les services Lightning.

Des montants précis, sans garantie de remboursement intégrée

Le document exprime les montants en millisatoshis et exige une correspondance exacte avec le montant de la facture. Les frais de routage restent à la charge du payeur, en supplément. Un éventuel trop-payé ne donne ni accès supplémentaire ni crédit dans ce schéma.

La spécification ne fournit pas de procédure de remboursement intégrée : un remboursement relèverait d’un accord distinct avec le receveur. Elle définit des obligations techniques pour les implémentations, mais ne prouve ni des volumes de paiements déjà réalisés, ni une adoption universelle par les portefeuilles ou les fournisseurs de services.

🔍 DUC, mon avis

L’intérêt de cette étape tient à la précision des règles : associer un paiement Lightning à un service défini, puis empêcher la réutilisation de sa preuve. Pour des logiciels qui paieraient des données ou des outils à l’usage, ce cadre est plus utile qu’une simple promesse de paiements entre machines.

Je reste attentif à l’écart entre une spécification fusionnée et un service effectivement exploitable. La restitution de la préimage, l’isolement de la clé du receveur et le stockage anti-rejeu sont des conditions concrètes à remplir. Les implémentations et leurs tests devront montrer comment elles les respectent.

Sources

Dépôt officiel x402 : commit d’intégration signé ; pull request 2861 et horodatage de fusion ; spécification exact sur Bitcoin Lightning, version fixée à ce commit.

En bref

x402 intègre le 23 septembre une spécification de paiement Bitcoin Lightning pour sa version 2. Le schéma repose sur BOLT11, un paiement préalable et une preuve à usage unique liée à la requête. Il s’agit d’une avancée documentaire et technique vérifiable, pas de la preuve d’un déploiement général.

✍️ DUC