La Solana Foundation a annoncé le 3 septembre 2026 la mise en production de son programme de canaux de paiement, déployé sur le mainnet à l'adresse `CHNLxYvVA28MJP9PrFuDXccuoGXAx7jBacfLEkahyGsX`. Le code est ouvert et la fondation indique que le programme a été audité par Cantina en juillet 2026.
À quel problème ce dispositif répond-il ?
Un agent logiciel qui appelle une API payante déclenche aujourd'hui une transaction par appel. Chaque appel coûte des frais de réseau et un délai de confirmation, et chaque paiement suppose une autorisation. La fondation cite deux cas où ce modèle casse : une requête dont le coût n'est pas connu à l'avance, comme une complétion de modèle de langage facturée au jeton, et une rafale de centaines d'appels bon marché sur une courte durée. Les alternatives existantes reposent sur des crédits prépayés, c'est-à-dire un solde débité dans la base de données d'un opérateur. Le canal de paiement vise l'effet inverse : les fonds restent détenus par le programme, pas par le prestataire.
Comment fonctionne un canal ?
Le cycle tient en quatre étapes :
- Ouverture : le payeur dépose un plafond de dépense dans un compte séquestre créé par le programme.
- Comptage hors chaîne : chaque autorisation de dépense prend la forme d'un message signé, pas d'une transaction. Ces bons portent un montant cumulé, si bien qu'un bon récent annule les précédents.
- Règlement : le montant réellement consommé est inscrit sur la chaîne en une seule transaction.
- Distribution : les bénéficiaires sont payés, le dépôt non consommé revient au payeur et le compte séquestre est fermé.
Le message signé fait exactement 50 octets et contient l'identifiant du canal, le montant cumulé et une date d'expiration. Le programme ne règle jamais plus que le dépôt initial. Si le prestataire cesse de coopérer, le payeur peut lancer une fermeture forcée qui ouvre une période de grâce, au terme de laquelle le canal est scellé et le reliquat récupérable. Cette fenêtre de grâce signifie qu'un retrait n'est pas immédiat en cas de litige.
Quels protocoles sont concernés ?
Les canaux servent de couche de règlement à deux protocoles de paiement HTTP déjà présents sur Solana, x402 et MPP. Tous deux reposent sur le même échange : le serveur répond par un code 402, le client paie, puis rejoue sa requête avec une preuve de paiement.
| Mode | Usage visé |
|---|---|
| x402 upto | un seul appel mesuré, l'opérateur règle le montant réel et rembourse la différence |
| x402 batch-settlement | plusieurs livraisons réglées ensemble |
| MPP session | un flux de livraisons mesurées, réglé à la fermeture de la session |
Un kit de développement accompagne le dispositif, avec des bibliothèques serveur en TypeScript, Rust, Go, Python, Ruby, PHP et Lua, et des bibliothèques client en TypeScript, Rust, Go, Python, Kotlin et Swift. Les montants sont libellés en monnaies numériques adossées au dollar ou à l'euro, USDC, USDT, PYUSD ou EURC selon les cas. La fondation met en avant l'absence de vérification d'identité préalable côté payeur, un point qui distingue ces rails des obligations de KYC imposées aux plateformes et qui ne préjuge pas des règles applicables à un opérateur d'API.
Que valent les chiffres avancés ?
La fondation dit avoir fait passer 100 000 portefeuilles distincts par un proxy de canal de paiement et avoir émis plus d'un million de paiements par seconde, soit plus de 80 milliards de paiements sur 24 heures, pour un coût de traitement estimé à 0,000000000776 dollar par paiement. Ce test a été conduit par la fondation elle-même, dans un cadre qu'elle ne détaille pas, et n'a pas été reproduit par un tiers. Les outils de charge sont fournis avec un modèle de déploiement. Ces ordres de grandeur reposent sur le fonctionnement de Solana, qui traite tout sur une seule chaîne, avec un règlement annoncé autour de 200 millisecondes et des frais de réseau médians situés à environ 0,0013 dollar par transaction.
Qui l'utilise déjà ?
Alibaba Cloud est cité comme partenaire de lancement, avec des points d'accès d'API opérationnels dès l'annonce. La fondation présente une série d'évolutions sous forme de propositions techniques, dont le règlement groupé de bons et le réarmement d'un canal entre deux sessions. Aucune n'est activée en production.
