x402 est-il vraiment en train d’optimiser le paiement, ou cache-t-il la complexité du Web3 ?

x402 est effectivement multi-chaînes et multi-devises au niveau du protocole, ce qui ne pose pas de problème. Mais dans la pratique opérationnelle, il dépend presque entièrement du facilitateur fourni par Coinbase. Autrement dit, il ressemble davantage à « une couche de paiement hébergée par Coinbase » qu’à un véritable réseau de protocole neutre.

Passons aux frais de Gas.

Le Gas n’a pas disparu, il a simplement été déplacé. Désormais, c’est le facilitateur qui avance le gas pour toutes les requêtes. Sur Base, une transaction coûte environ quelques cents, ce qui peut sembler peu, mais à grande échelle, par exemple 1 million de requêtes API, cela représente plusieurs dizaines de milliers de dollars en coûts réels.

Le problème, c’est qui paie ces coûts à long terme ?

Ce sont les commerçants ? Les utilisateurs ? Ou bien la monétisation se fait-elle via les données, le trafic, ou le profilage comportemental ?

Quelle que soit la voie choisie, l’essence du problème est que ces coûts sont concentrés sur un rôle centralisé, plutôt que d’être éliminés.

Passons au temps de confirmation.

La signature est instantanée, mais la confirmation réelle du paiement doit attendre la finalité de la chaîne.

Sur Base, cela prend environ 2 secondes, sur le réseau principal Ethereum, plus de 10 secondes.

Cela signifie que la connexion HTTP doit rester ouverte pendant ce temps.

Dans un réseau idéal, cela pourrait être acceptable, mais sur mobile, avec des agents à longue latence, ou dans des environnements réseau instables, c’est une conception très contre-intuitive.

Si ces 2 à 15 secondes sont interrompues, le client se retrouve dans un état embarrassant : ai-je vraiment payé ou non ?

Une nouvelle tentative pourrait entraîner une double facturation. Sans tentative, il se peut que le paiement ait été effectué mais que la requête n’ait pas abouti, ce qui nécessite finalement d’ajouter une couche de « vérification de l’état ».

Et dès que vous avez besoin de vérifier l’état, vous introduisez à nouveau des RPC, des services d’indexation, ou une dépendance continue au facilitateur.

Cela s’éloigne de l’objectif initial de simplicité, comme avec HTTP.