x402 v2 发布，这不是一次 simple mise à jour, mais une évolution de x402 d'une « implémentation unique » vers « une norme évolutive + une implémentation de référence modulaire ». Faites que x402 ne soit plus seulement un SDK, mais qu'il ressemble vraiment à un langage d'interface payante natif à Internet.

À l'époque de v1, le modèle de x402 était très simple :

Service payant → Client signe et paie → Serveur vérifie → Finalisation du paiement.

Ce modèle est facile à comprendre, mais aussi très « linéaire ».

Dès que vous avez besoin de plus de réseaux, de plusieurs méthodes de paiement, ou de formes de règlement plus complexes, vous vous retrouvez rapidement à bifurquer vers des SDK forkés, appliquer des patchs, ou maintenir des protocoles en privé. Ça fonctionne, mais l’écosystème évolue difficilement de manière cohérente.

Le changement central de x402 v2 peut être résumé en une phrase : il a déplacé « le changement » hors du protocole principal.

Les modifications ne sont plus introduites via « modification du spec / modification du core » mais sont explicitement placées dans les Extensions, mécanismes plug-in, et hooks de cycle de vie.

Cette étape est cruciale, car elle détermine si de nouvelles capacités dans l’écosystème peuvent évoluer parallèlement sans modifier le protocole central.

Dans cette optique, plusieurs changements de v2 peuvent être mieux compris.

Premièrement, au niveau du protocole : x402 devient plus HTTP-native.

La sémantique 402 revient à 402, avec les métadonnées de paiement qui entrent dans l’en-tête (header) ;

Au niveau applicatif, on peut désormais retourner librement une paywall HTML, du JSON ou tout autre corps de réponse, tandis que les middlewares et facilitateurs continuent à gérer la sémantique de paiement de manière stable. Cela permet pour la première fois au protocole de paiement d’être vraiment compatible avec l’infrastructure Internet existante.

Ensuite, au niveau de l’architecture : le SDK introduit un système de registration et des hooks de cycle de vie.

Supportant de nouveaux réseaux, de nouveaux schemes, il n’est plus nécessaire de multiplier les if/else dans le core, mais simplement d’implémenter et enregistrer des interfaces.

Les hooks offrent une porte d’entrée officielle pour la logique stratégique, mais le SDK lui-même devient un « orchestrateur de processus » plutôt qu’un porteur de capacités métier.

Au niveau supérieur, la signification des Extensions.

v2 fournit à l’écosystème un « slot » standardisé pour des capacités optionnelles.

Des capacités comme Discovery, Identity, ou Settlement Router / Programmable Settlement peuvent toutes être déclarées, négociées via Extension, et progressivement faire consensus.

Le serveur peut déclarer quelles extensions il supporte, le facilitateur peut déclarer celles qu’il implémente, et le client peut choisir ou combiner en conséquence — c’est ainsi qu’une norme peut évoluer sur le long terme.

Dans ce contexte, la signification de x402 v2 pour x402x devient plus claire.

x402x est une implémentation concrète d’extensions comme Settlement Router.

Elle utilise un contrat smart sur la blockchain sous le nom de SettlementRouter pour offrir un chemin de règlement atomique, programmable et composable :

Le règlement peut être routé vers plusieurs destinataires, supporter nativement la répartition et la commission, et être combiné de manière transparente avec des hooks de contrat ou d’autres contrats sur la blockchain — par exemple, mint de tokens, appels DeFi, ou autres logiques de règlement basées sur l’état de la blockchain.

À l’époque de x402 v1, ces capacités de règlement nécessitaient souvent de hacker le protocole principal, en introduisant une logique de routage spéciale ;

Mais avec x402 v2, grâce aux Extensions et au mécanisme de registration, ces capacités peuvent pour la première fois exister sous forme d’extensions standard, plutôt que de fork.

Ce changement est structurel :

La valeur de x402x ne vient plus de la façon dont il est implémenté, mais des sémantiques de règlement qu’il exprime, et de leur capacité à être combinées dans l’écosystème de contrats sur la blockchain.

En résumé :

x402 v2 donne pour la première fois à une « API payante » les conditions structurelles pour une collaboration à l’échelle Internet.

Et les extensions de règlement comme x402x peuvent enfin croître dans ce cadre standard — pas en hackant le protocole principal, mais en tant qu’Extensions, qui peuvent être choisies, combinées et évolutives.