Circle Nanopayments expliqué : des paiements USDC sans gas jusqu'à 0,000001 $

Les blockchains ont un prix plancher. Chaque transfert on-chain paie du gas : un paiement plus petit que son propre coût de gas n'a donc aucun sens économique. Sur la plupart des réseaux, tout ce qui est sous le centime est mort-né. Or c'est exactement là que veut vivre la prochaine vague du commerce. Les agents IA n'achètent pas comme des humains : ils paient à l'appel d'API, à la seconde de calcul, à la lecture de jeu de données, et chacun de ces événements vaut une fraction de centime.

Circle Nanopayments supprime ce plancher. Les paiements sont signés hors chaîne sans aucun coût de gas, vérifiés en quelques millisecondes, et réglés on-chain par lots de plusieurs milliers : le gas d'une seule transaction se répartit alors sur tous les paiements qu'elle contient. Résultat : des paiements en USDC jusqu'à 0,000001 $, sans gas pour l'acheteur comme pour le vendeur, en production sur 12 chaînes EVM.

Dans cet article, nous verrons comment cela fonctionne, comparerons ce mécanisme au flux x402 standard décrit dans notre précédent tutoriel x402, puis construirons la boucle complète en Node.js : une API Express facturée 0,0001 $ par requête, et un client acheteur qui dépose une fois puis paie à l'appel, avec de simples signatures.

Qu'est-ce que Circle Nanopayments ?

Nanopayments est un rail de paiement construit par Circle au-dessus de deux briques existantes :

• Circle Gateway, le solde USDC unifié de Circle. Vous déposez de l'USDC dans un contrat Gateway Wallet non custodial sur n'importe quelle chaîne prise en charge, et ce dépôt devient un solde inter-chaînes unique, dépensable ou retirable sur toute autre chaîne prise en charge en moins de 500 ms.
• Le protocole x402, le standard ouvert qui met au travail le code de statut HTTP 402 Payment Required : les serveurs annoncent un prix de façon lisible par une machine, et les clients le paient au moyen d'une autorisation de stablecoin signée.

Nanopayments combine les deux : les acheteurs dépensent leur solde Gateway via des autorisations signées de type x402, et Circle Gateway joue le rôle de facilitateur qui vérifie chaque paiement instantanément et les règle on-chain en masse. Circle l'a lancé en production en avril 2026 dans le cadre de son Agent Stack, avec des adoptants précoces comme Alchemy, QuickNode, Goldsky et blockrun.ai, et une prise en charge sur Ethereum, Base, Arbitrum, OP Mainnet, Polygon PoS, Avalanche, Unichain, Sonic, World Chain, Sei, HyperEVM et Arc.

L'économie : pourquoi le regroupement change tout

L'intuition de départ est simple. Si chaque paiement est sa propre transaction on-chain, chaque paiement paie le gas complet, et le plus petit paiement viable tourne autour de 0,01 $, même sur des L2 bon marché. Si dix mille paiements partagent une seule transaction de règlement, le gas par paiement est divisé par dix mille, et un paiement de 0,000001 $ porte soudain une surcharge négligeable.

Gateway fait plus que concaténer des paiements : il les compense. Il collecte les autorisations signées hors chaîne, calcule la variation nette de solde par compte sur l'ensemble du lot, et n'applique on-chain que ces variations nettes. Un acheteur ayant passé 5 000 appels au même vendeur devient une seule mise à jour de solde, et non 5 000 transferts. C'est ce qui permet au système d'absorber des flux de paiement à vitesse machine sans imposer une charge machine à la chaîne.

Le cycle de vie d'un paiement

Voici la vie complète d'un nanopaiement, de l'approvisionnement au règlement final :

1. Dépôt (une fois). L'acheteur dépose de l'USDC dans le contrat Gateway Wallet. C'est la seule transaction pour laquelle il paiera du gas.
2. Requête et négociation. L'acheteur demande une ressource payante ; le vendeur répond 402 Payment Required avec un en-tête PAYMENT-REQUIRED décrivant le prix, le réseau et la destination.
3. Signature. L'acheteur signe hors chaîne un message EIP-3009 TransferWithAuthorization, autorisant Gateway à déplacer exactement le montant annoncé de son solde vers le vendeur. Aucun gas.
4. Règlement et livraison. L'acheteur rejoue la requête avec l'en-tête PAYMENT-SIGNATURE. Le vendeur transmet l'autorisation à l'endpoint settle de Gateway ; celui-ci vérifie la signature, bloque les fonds de l'acheteur, crédite le solde du vendeur et répond en quelques centaines de millisecondes. Le vendeur livre la ressource immédiatement.
5. Regroupement on-chain. Périodiquement, Gateway compense toutes les autorisations en attente et soumet une seule transaction on-chain. Une fois confirmée, les vendeurs peuvent retirer leur solde sur n'importe quelle chaîne prise en charge.

La propriété déterminante : dès l'étape 4, le paiement du vendeur est garanti et son solde crédité, alors même que rien n'a encore touché la chaîne. Latence de vérification et finalité de règlement sont découplées, ce qui rend la tarification à la requête utilisable dans un chemin de code critique.

Nanopayments face au x402 standard

Si vous avez lu notre tutoriel sur le verrouillage d'une API avec x402, le flux ci-dessus vous semblera familier : même code de statut, mêmes en-têtes, mêmes signatures EIP-3009. Les différences tiennent entièrement à l'endroit où se trouve l'argent et à la façon dont il est réglé.

Les deux approches sont complémentaires. Un rapport à 5 $ vendu quelques centaines de fois par jour est parfaitement servi par le x402 standard, et atterrit directement dans votre wallet. Un appel d'inférence à 0,0001 $ servi un million de fois par jour ne fonctionne qu'en lots. Comme les deux parlent x402, un vendeur peut exposer les deux et laisser chaque acheteur choisir l'option que son client prend en charge.

Architecture et modèle de confiance

La question évidente sur le regroupement : pendant que les paiements attendent dans un lot, qu'est-ce qui empêche Circle de les altérer ? La réponse de conception est un Trusted Execution Environment. Chaque signature est vérifiée et chaque lot calculé à l'intérieur d'une AWS Nitro Enclave, et l'enclave signe le résultat du lot avec une clé accessible uniquement à l'image d'enclave auditée ; même les opérateurs de Circle ne peuvent l'extraire. Le smart contract Gateway Wallet vérifie la signature de l'enclave avant d'exécuter un lot et rejette tout ce qui n'est pas autorisé, et l'enclave produit des attestations cryptographiques que chacun peut vérifier de façon indépendante.

À cela s'ajoute le caractère non custodial des dépôts : les fonds résident dans le contrat Gateway Wallet, pas chez Circle, et le contrat inclut un chemin de retrait sans confiance à 7 jours, de sorte que vous pouvez sortir vos fonds même si Gateway cessait de fonctionner. C'est aussi pour cela que les autorisations de paiement doivent rester valides au moins 7 jours, plus une marge : la signature doit survivre au pire scénario de règlement.

Tutoriel : accepter et envoyer des nanopaiements en Node.js

Construisons les deux côtés sur testnet. Le vendeur est une API Express qui vend /premium-data à 0,0001 $ la requête ; l'acheteur est un script qui dépose une fois, puis paie à l'appel, uniquement par signatures. Le tout utilise le SDK @circle-fin/x402-batching de Circle.

Prérequis

• Node.js 22.6+ (il exécute directement du TypeScript par type stripping, donc aucune étape de build)
• Deux adresses EOA : une pour recevoir les fonds (le vendeur, l'adresse suffit) et une pour payer (l'acheteur, clé privée requise)
• De l'USDC de testnet pour l'acheteur via le faucet de Circle, plus un peu de jeton natif pour la seule transaction de dépôt
• Une réserve à connaître d'emblée : l'acheteur doit être un EOA simple. Les comptes de type smart contract ne sont pas pris en charge, car Gateway vérifie les signatures hors chaîne avec ecrecover, incompatible avec les signatures de contrat EIP-1271.

Partie 1 : le vendeur

Créez le projet serveur :

Copy
mkdir nano-seller && cd nano-seller
npm init -y && npm pkg set type=module
npm pkg set scripts.start="node --env-file=.env server.ts"
npm install @circle-fin/x402-batching @x402/core @x402/evm viem express typescript
npm install --save-dev @types/node @types/express

Configurez l'adresse de réception via l'environnement :

SELLER_ADDRESS=0xYourSellerAddress

Puis le serveur complet :

import express from 'express'
import { formatUnits } from 'viem'
import { createGatewayMiddleware } from '@circle-fin/x402-batching/server'

type PaidRequest = express.Request & {
  payment?: {
    verified: boolean
    payer: string
    amount: string
    network: string
    transaction?: string
  }
}

const sellerAddress = process.env.SELLER_ADDRESS as `0x${string}` | undefined
if (!sellerAddress) throw new Error('SELLER_ADDRESS not configured')

const gateway = createGatewayMiddleware({
  sellerAddress,
  facilitatorUrl: 'https://gateway-api-testnet.circle.com',
})

const app = express()

app.get('/premium-data', gateway.require('$0.0001'), (req: PaidRequest, res) => {
  const { payer, amount, network } = req.payment!
  console.error(`Paid ${formatUnits(BigInt(amount), 6)} USDC by ${payer} on ${network}`)

  res.json({
    signal: 'Funding rates flipped negative on three venues.',
    paid_by: payer,
  })
})

app.get('/free', (_req, res) => {
  res.json({ status: 'ok' }) // Routes without gateway.require() stay free.
})

app.listen(3000, () => console.error('Listening on http://localhost:3000'))

Voilà toute l'intégration côté vendeur : un middleware, un prix sous forme de chaîne en dollars. gateway.require('$0.0001') répond aux requêtes non payées par un 402 et une offre encodée en base64 dans l'en-tête PAYMENT-REQUIRED ; lorsqu'une requête arrive avec un PAYMENT-SIGNATURE valide, le middleware appelle l'endpoint settle de Gateway, obtient la garantie de paiement en quelques centaines de millisecondes, attache les détails à req.payment et laisse votre handler s'exécuter. Votre code de handler ne touche jamais une blockchain.

Par défaut, le middleware accepte les paiements depuis tous les réseaux pris en charge par Gateway ; vous pouvez le restreindre avec une option networks: ['eip155:5042002'] si vous voulez fixer des chaînes précises. Notez le prix : 0,0001 $, soit un dixième du minimum réaliste du x402 standard, et vous pourriez descendre quatre ordres de grandeur plus bas.

Démarrez-le et interrogez-le sans payer :

Copy
npm start
curl -i http://localhost:3000/premium-data

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: eyJ4NDAyVmVyc2lvbiI6Mi...

Partie 2 : l'acheteur

Dans un projet séparé :

Copy
mkdir nano-buyer && cd nano-buyer
npm init -y && npm pkg set type=module
npm pkg set scripts.pay="node --env-file=.env pay.ts"
npm install @circle-fin/x402-batching viem typescript
npm install --save-dev @types/node

PRIVATE_KEY=0xYourBuyerPrivateKey

Tout l'acheteur tient dans un script : vérifier les soldes, déposer une fois si nécessaire, puis payer.

import { GatewayClient } from '@circle-fin/x402-batching/client'

const privateKey = process.env.PRIVATE_KEY as `0x${string}` | undefined
if (!privateKey) throw new Error('PRIVATE_KEY not configured')

const client = new GatewayClient({
  chain: 'arcTestnet',
  privateKey,
})

// 1. Where do we stand?
const balances = await client.getBalances()
console.log(`Wallet USDC:  ${balances.wallet.formatted}`)
console.log(`Gateway USDC: ${balances.gateway.formattedAvailable}`)

// 2. One-time top-up of the Gateway balance (USDC has 6 decimals).
if (balances.gateway.available < 1_000_000n) {
  console.log('Depositing 1 USDC into the Gateway Wallet...')
  const deposit = await client.deposit('1')
  console.log(`Deposit tx: ${deposit.depositTxHash}`)
}

// 3. Pay for the resource. No gas, no transaction: just a signature.
const { data, status } = await client.pay('http://localhost:3000/premium-data')
console.log(`Status: ${status}`)
console.log('Response:', data)

// 4. The balance moved by exactly $0.0001.
const updated = await client.getBalances()
console.log(`Gateway USDC after: ${updated.gateway.formattedAvailable}`)

Lancez-le contre votre serveur local :

Copy
npm run pay

Copy
Wallet USDC:  10.0
Gateway USDC: 0.0
Depositing 1 USDC into the Gateway Wallet...
Deposit tx: 0x83f2...9a1c
Status: 200
Response: {
  signal: 'Funding rates flipped negative on three venues.',
  paid_by: '0xYourBuyerAddress'
}
Gateway USDC after: 0.9999

Derrière client.pay(), le SDK a émis la première requête, analysé l'offre du 402, signé l'autorisation EIP-3009 sur le domaine GatewayWalletBatched, rejoué la requête avec l'en-tête PAYMENT-SIGNATURE et renvoyé la réponse payée. Appelez-le en boucle et vous verrez le solde baisser de 0,0001 à chaque appel, sans un centime de gas ; le dépôt de l'étape 2 ne se relance jamais. Si vous voulez vérifier qu'une URL quelconque accepte les paiements Gateway avant de payer, client.supports(url) fait exactement cela.

Retirer vos revenus

Les deux parties détiennent de la valeur sous forme de solde Gateway, et Gateway est inter-chaînes par construction. Retirez sur la même chaîne ou sur n'importe quelle autre prise en charge :

// Same chain as the client: immediate.
const sameChain = await client.withdraw('5')
console.log(`Withdrew ${sameChain.formattedAmount} USDC - tx: ${sameChain.mintTxHash}`)

// Or receive on a different chain entirely.
const crossChain = await client.withdraw('5', { chain: 'baseSepolia' })
console.log(`Withdrew to ${crossChain.destinationChain}`)

C'est un détail discrètement puissant pour les vendeurs : vous pouvez accepter des nanopaiements d'acheteurs répartis sur une douzaine de chaînes et retirer l'agrégat sur l'unique chaîne où vit votre trésorerie.

Passer en mainnet

Trois changements font passer ce tutoriel en production :

1. URL du facilitateur : pointez facilitatorUrl vers https://gateway-api.circle.com plutôt que vers l'endpoint de testnet.
2. Chaîne : basculez la chaîne du GatewayClient vers un réseau mainnet (Base, par exemple ; voyez la liste des chaînes prises en charge par Circle pour les identifiants exacts) et approvisionnez l'acheteur en vrais USDC.
3. Gestion des clés : la clé privée de l'acheteur autorise désormais de vraies dépenses. Gardez-la dans un gestionnaire de secrets, dotez le wallet d'un petit flottant plutôt que de fonds de trésorerie, et plafonnez les prix par requête dans la logique de votre client. Le vendeur, lui, ne détient toujours aucun secret, seulement une adresse publique de réception.

Cas d'usage : ce que débloquent les paiements sous le centime

Un paiement de 0,000001 $ qui fonctionne est une primitive nouvelle, et les produits intéressants sont précisément ceux que l'ancien plancher de 0,01 $ rendait impossibles :

• Les paiements agentiques. Un agent IA doté d'un solde Gateway peut acheter données, outils et calcul de façon autonome, en payant à l'appel, sans humain, sans formulaire de carte, sans clé d'API. C'est le cas d'usage phare : x402 a traité plus de 100 M$ de paiements en quelques mois d'existence, et Circle positionne Nanopayments comme le rail nativement machine qui le soutient.
• Une vraie facturation à l'usage. Tarifez votre API à son coût marginal : 0,0001 $ la requête, 0,000005 $ la ligne, le jeton, la milliseconde de GPU. Sans abonnement, sans système de crédits prépayés, sans infrastructure de facturation mensuelle.
• Des places de marché de machine à machine. Des services qui achètent à d'autres services : un scraper qui paie un proxy à la requête, un agent qui paie un autre agent pour une sous-tâche, un oracle qui vend des points de données à l'unité. À fréquence machine, seul le règlement par lots tient le rythme.
• L'argent en flux continu. Contenu payé à la seconde, calcul loué à la minute, fichier livré au fragment : toute ressource mesurée peut se régler en continu, par des paiements trop petits pour être remarqués individuellement.

Limites et pièges

• Wallets EOA uniquement. La vérification hors chaîne par ecrecover de Gateway exclut les smart accounts et les signatures EIP-1271. Si vos agents vivent aujourd'hui dans des smart wallets, il leur faut une clé de dépense EOA pour les nanopaiements.
• Les acheteurs préfinancent. Le modèle de dépôt implique que les fonds de l'acheteur reposent sur le solde Gateway avant d'être dépensés. C'est non custodial, avec une sortie sans confiance à 7 jours, mais cela reste un flottant à gérer, contrairement au x402 simple où les fonds restent dans le wallet jusqu'à chaque paiement.
• Les autorisations doivent être longues. Les signatures de paiement doivent rester valides au moins 7 jours plus une marge (maxTimeoutSeconds autour de 604 900), conséquence directe de la fenêtre de retrait sans confiance. N'improvisez pas d'expirations plus courtes : l'endpoint settle les rejettera.
• Solana fait exception. Le solde unifié de Gateway couvre Solana, mais Nanopayments est aujourd'hui EVM uniquement ; les 12 chaînes compatibles sont toutes EVM.
• Pas pour les gros transferts. Au-delà d'environ un centime par paiement, le x402 standard avec règlement par paiement est plus simple et donne au vendeur une finalité on-chain immédiate. Le regroupement ne justifie sa complexité qu'en dessous de cette limite.

Questions fréquentes

Circle Nanopayments est-il custodial ? Non. Les dépôts résident dans le smart contract Gateway Wallet, les lots sont calculés et signés dans un TEE attesté auquel même les opérateurs de Circle n'ont pas accès, et un chemin de retrait sans confiance à 7 jours existe indépendamment de la disponibilité de Circle.

L'acheteur ou le vendeur paient-ils du gas ? Seuls le dépôt initial de l'acheteur (et un éventuel retrait) sont des transactions on-chain. Tous les paiements entre les deux sont des signatures hors chaîne ; Gateway paie le gas du règlement par lots.

Quel est le plus petit paiement possible ? 0,000001 $, soit un millionième de dollar, ce qui correspond aussi à une unité de base de l'USDC.

Faut-il des clés d'API Circle ? Non. L'endpoint settle n'est pas authentifié et le système est sans permission : une adresse de réception suffit à un vendeur, un EOA approvisionné suffit à un acheteur.

Où cela s'inscrit

Nanopayments complète une pile que nous construisons avec nos clients depuis un an : x402 met une étiquette de prix sur HTTP, et le règlement par lots de Gateway ajoute quatre décimales à cette étiquette. Ensemble, ils font de « facturer exactement ce que coûte une requête » un vrai modèle de facturation pour les API, les agents et les produits de données, sans système de facturation à construire.

Chez Etherwave Labs, nous intégrons toute la famille x402 de bout en bout : tarification et verrouillage de votre API, branchement de Gateway ou d'un autre facilitateur, et équipement de vos agents avec des wallets de dépense sûrs. Nous détaillons le protocole sur notre page de service x402 et, si vous voulez des revenus en USDC à la requête en production, parlons-en.