Passer au contenu principal

Créer un outil de vérification du solde multichaîne avec les sessions MPP

Mis à jour le
9 juin 2026
Profil de Sergen Uysal
Sergen Uysal
Tout
EVM
Tempo
MPP
Paiements
RPC
TypeScript

14 minutes de lecture

Aperçu​

Le protocole Machine Payments Protocol (MPP) vous permet de payer l'accès à l'API directement dans une requête HTTP. Pas besoin de compte ni de clé API. Il suffit d'un portefeuille contenant un solde en stablecoin.

Les sessions vont encore plus loin. Vous ouvrez un canal de paiement une seule fois, puis vous le réutilisez pour chaque requête. Chaque appel est réglé à l'aide d'un petit bon signé ; ainsi, il n'y a pas de transaction sur la chaîne à chaque fois et les requêtes restent rapides.

Dans ce guide, vous allez créer un script TypeScript qui ouvre une session MPP unique, interroge les soldes des jetons natifs sur 15 chaînes EVM à l'aide des points de terminaison MPP de Quicknode, puis génère un rapport formaté comprenant une ventilation des coûts.

Cette solution est idéale pour les sessions, car le script effectue plusieurs appels RPC sur différents réseaux en une seule exécution. Au lieu de payer chaque appel individuellement, toutes les requêtes transitent par un seul canal de paiement. Vous ne payez les frais d'installation qu'une seule fois, puis vous pouvez réutiliser la configuration pour le reste.

Quicknode prend en charge les sessions MPP sur toutes les chaînes compatibles. Une même session permettant d'interroger Ethereum peut également interroger Base, Arbitrum, Polygon et d'autres chaînes sans configuration supplémentaire.

Formule gratuite

Chaque portefeuille bénéficie d'un quota gratuit partagé de 1 000 000 de crédits API par mois sur l'ensemble des interfaces de paiement agentiques de Quicknode, notamment MPP et x402. Les requêtes RPC standard consomment chacune 1 crédit API, tandis que SQL Explorer consomme les crédits API utilisés par la requête.


MPP est l'un des deux protocoles de paiement « agentic » sur Quicknode

Quicknode prend en charge deux protocoles de paiement par portefeuille pour un accès RPC sans compte : MPP (utilisé dans ce guide) et x402 (une norme ouverte développée par Coinbase). Ces deux protocoles permettent aux scripts et aux agents IA de payer leurs appels API directement, sans avoir besoin de compte ni de clés API, mais ils diffèrent par le format des données, le fonctionnement des sessions et les méthodes de paiement prises en charge. Consultez la présentation des paiements Agentic pour une comparaison côte à côte, ou accédez directement à la documentation x402 et à la documentation MPP pour plus de détails sur les protocoles.

Ce que vous allez apprendre​


  • Fonctionnement du protocole Machine Payments et raison d'être des sessions
  • L'ensemble du cycle de vie d'une session : défi 402, dépôt sur le canal, signature du bon et règlement
  • Comment utiliser le mppx SDK permettant de créer et de gérer des sessions de paiement
  • Comment effectuer plusieurs appels RPC au cours d'une même session sur différentes chaînes à l'aide des points de terminaison MPP de Quicknode

Ce dont vous aurez besoin​


  • Node.js v20 ou version ultérieure
  • Connaissances de base de TypeScript et des chaînes EVM
  • Aucun compte Quicknode ni aucune clé API ne sont nécessaires (MPP gère l'accès et la facturation)
  • Une petite quantité de PathUSD sur le testnet de Tempo (financée automatiquement via un « faucet » dans le script) ou de PathUSD/USDC.e sur le mainnet de Tempo pour une utilisation en production

Qu'est-ce que le protocole Machine Payments ?​

Le protocole Machine Payments est une norme ouverte proposée à l'IETF qui permet d'intégrer des paiements directement à n'importe quel point de terminaison HTTP. Il est conçu pour résoudre un problème spécifique : les clients programmatiques (agents, scripts, bots) ne disposent d'aucun moyen efficace de payer l'accès à une API sans qu'un utilisateur ne configure au préalable la facturation.

Les flux de paiement traditionnels reposent sur des formulaires de paiement, des sessions de navigateur et des CAPTCHA visuels. Le MPP les remplace par une négociation de paiement lisible par machine, basée sur le protocole HTTP. 402 Paiement requis.

Comment ça marche ?​

Le protocole suit un modèle « challenge-response » :


  1. Requête: le client envoie une requête HTTP standard à un point de terminaison payant.
  2. Défi: Le serveur répond par 402 Paiement requis et un WWW-Authenticate : Paiement en-tête indiquant le prix, les devises acceptées et les modes de paiement disponibles.
  3. Paiement: le client choisit un mode de paiement et procède au paiement (signe un transfert de stablecoin, ouvre un canal de paiement, etc.).
  4. Réessayer: Le client renvoie la requête d'origine avec un Autorisation : paiement en-tête comportant la preuve de paiement.
  5. Livrer: Le serveur vérifie le paiement et renvoie une réponse contenant un Reçu de paiement en-tête.

Des bibliothèques client telles que mppx gère automatiquement les étapes 2 à 4. Du point de vue de votre code, la requête fonctionne tout simplement.

Frais vs. Session​

MPP définit deux « intentions de paiement » qui régissent le fonctionnement de la facturation :

FraisSession
MotifPaiement unique par demandePaiement à l'utilisation via un canal de paiement
RèglementTransaction sur la chaîne par requêteBons hors chaîne, règlement sur la chaîne uniquement à l'ouverture et à la clôture
Latence de vérificationDes centaines de millisecondes (sur la blockchain)Microsecondes (dépendant du processeur) ecrecover)
Idéal pourRequêtes ponctuelles, intégrations simplesRequêtes à haute fréquence, flux de travail par lots, agents

La principale différence réside dans la manière dont s'effectue la vérification du paiement. Avec le mode « charge », chaque requête déclenche une transaction sur la blockchain. Avec le mode « sessions », le serveur vérifie un bon signé à l'aide d'un seul ecrecover appel, sans aucun appel RPC ni écriture dans la base de données sur le chemin critique. Cela signifie que le serveur n'intervient jamais sur la chaîne pendant la session ; le débit est donc limité par le processeur du serveur, et non par le consensus de la blockchain.

Sur les points de terminaison MPP de Quicknode, cela se traduit également par des économies concrètes : les requêtes de facturation coûtent 0,001 $ chacune, tandis que les requêtes de session coûtent 0,00001 $ chacune. Pour un script qui effectue plus de 15 appels RPC sur différents réseaux en une seule exécution, les sessions constituent la solution la plus adaptée :

Chaînes interrogéesFrais (0,001 $ par requête)Session (0,00001 $/requête)
10$0.010$0.0001
25$0.025$0.00025
50$0.050$0.0005

Comprendre le cycle de vie d'une session​

Avant de se plonger dans le code, il est important de comprendre comment fonctionnent les sessions en arrière-plan. Le schéma suivant illustre le déroulement complet de notre outil de vérification de solde multichaîne :

Concepts clés​

Moyen de paiement: un contrat d'entiercement sur la blockchain dans lequel le client dépose des fonds à l'avance. Cette opération a lieu une seule fois, au début de la session.

Bons cumulatifs: chaque requête comprend un message signé indiquant « J'ai désormais utilisé un total de X ». Les bons sont cumulatifs, et non incrémentiels. Le serveur n'a besoin que du dernier bon pour réclamer l'intégralité des fonds dus. Par exemple, après trois requêtes de 0,00001 $ chacune : bon(1) = 10, bon(2) = 20, bon(3) = 30 unités atomiques.

Sessions multi-réseaux: Une seule instance de session gère les requêtes provenant de différentes /session/ : réseau points de terminaison. La session gère le canal de paiement ; le « slug » réseau détermine vers quel backend RPC Quicknode la requête est redirigée.

Règlement: À la fin de la session, le serveur procède au règlement du bon final sur la blockchain. Le client reçoit le remboursement de tout acompte non utilisé.

Configuration du projet​

Le script complet se trouve dans le qn-guide-exemples référentiel (consulter directement le fichier source). Clonez-le et installez les dépendances :

git clone https://github.com/quiknode-labs/qn-guide-examples.git
cd qn-guide-examples/mpp/multichain-balance-checker
npm installer

Vous pouvez également copier le index.ts fichier dans votre propre projet et installez les dépendances nécessaires.

Le projet utilise deux dépendances d'exécution :

ColisObjectif
mppxClient du protocole MPP (gestion des sessions, signature des bons)
viemOpérations sur le portefeuille et mise en forme du solde

Et deux dépendances de développement : tsx pour exécuter TypeScript directement, et Typescript pour la vérification des types.

Définition du registre de la chaîne​

Le script interroge les soldes natifs sur plusieurs chaînes EVM. Chaque chaîne est définie par son identifiant MPP, son nom d'affichage, le symbole de son jeton natif et sa précision décimale :

const CHAINS = [
  { slug: 'ethereum-mainnet', name: 'Ethereum', symbol: 'ETH', decimals: 18 },
  { slug: 'base-mainnet', name: 'Base', symbol: 'ETH', decimals: 18 },
  { slug: 'arbitrum-mainnet', name: 'Arbitrum', symbol: 'ETH', decimals: 18 },
  { slug: 'optimism-mainnet', name: 'Optimism', symbol: 'ETH', decimals: 18 },
  { slug: 'matic-mainnet', name: 'Polygon', symbol: 'POL', decimals: 18 },
  { slug: 'worldchain-mainnet', name: 'World Chain', symbol: 'ETH', decimals: 18 },
  { slug: 'bsc-mainnet', name: 'BNB Chain', symbol: 'BNB', decimals: 18 },
  { slug: 'fantom-mainnet', name: 'Fantom', symbol: 'FTM', decimals: 18 },
  { slug: 'celo-mainnet', name: 'Celo', symbol: 'CELO', decimals: 18 },
  { slug: 'xdai-mainnet', name: 'Gnosis', symbol: 'xDAI', decimals: 18 },
  { slug: 'zksync-mainnet', name: 'zkSync Era', symbol: 'ETH', decimals: 18 },
  { slug: 'scroll-mainnet', name: 'Scroll', symbol: 'ETH', decimals: 18 },
  { slug: 'linea-mainnet', name: 'Linea', symbol: 'ETH', decimals: 18 },
  { slug: 'mantle-mainnet', name: 'Mantle', symbol: 'MNT', decimals: 18 },
  { slug: 'blast-mainnet', name: 'Blast', symbol: 'ETH', decimals: 18 },
]

Le « slug » réseau est ici l'élément clé. Il correspond au point de terminaison de la session MPP situé à l'adresse https://mpp.quicknode.com/session/:slug. Le /session/ C'est le préfixe de l'URL qui indique au serveur d'utiliser l'intention « session » plutôt que l'intention « charge ».

Vous pouvez ajouter ou supprimer des chaînes selon vos besoins. Les points de terminaison MPP de Quicknode prennent en charge tous les réseaux compatibles. Vous pouvez également récupérer dynamiquement la liste complète des slugs pris en charge :

curl https://mpp.quicknode.com/networks

Notez que les chaînes que vous interrogez sont dissociées du réseau de paiement. Votre session s'exécute sur la blockchain Tempo (testnet ou mainnet), mais elle peut accéder aux points de terminaison RPC de n'importe quelle chaîne prise en charge.

Configuration du portefeuille​

Le script a besoin d'un portefeuille pour signer les bons de paiement destinés au canal de paiement. Il peut soit utiliser une clé privée existante fournie par l'environnement, soit en générer une nouvelle automatiquement :

import { générerCléPrivée, cléPrivéePourCompte } à partir de 'viem/accounts'

const clé privée = (process.env.MPPX_PRIVATE_KEY comme `0x${chaîne}`) || générerCléPrivée()
const compte = cléPrivéeDuCompte(clé privée)

Lorsqu'une clé est générée automatiquement, le script l'enregistre dans un .env fichier (avec chmod 600 (autorisations) afin que les exécutions futures réutilisent le même portefeuille :

import { existsSync, writeFileSync } from 'fs'

if (isGenerated && !existsSync(envPath)) {
  writeFileSync(
    envPath,
    [
      '# Auto-generated by multichain balance checker',
      '# This file is gitignored — never commit private keys.',
      `MPPX_PRIVATE_KEY=${privateKey}`,
      '',
    ].join('\n'),
    { mode: 0o600 },
  )
}

Financement via le « Testnet Faucet »​

Pour une utilisation sur le testnet, le script approvisionne automatiquement le portefeuille via le « faucet » du testnet Tempo. Le portefeuille reçoit ainsi des PathUSD (un stablecoin du testnet) et du gas sur Tempo Moderato (ID de chaîne 42431) :

async function fundWallet(address: string): Promise<void> {
  const res = await fetch('https://docs.tempo.xyz/api/faucet', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ address }),
  })
  if (res.ok) {
    console.log('Faucet: Request accepted — waiting for onchain confirmation...')
    await waitForFunding(address)
  }
}

Le en attente de financement La fonction interroge le contrat PathUSD sur Tempo Moderato afin de vérifier que le solde a bien été crédité avant de poursuivre :

const TEMPO_RPC = 'https://rpc.moderato.tempo.xyz'
const PATHUSD_ADDRESS = '0x20c0000000000000000000000000000000000000'

async function getPathUSDBalance(walletAddress: string): Promise<bigint> {
  const data = '0x70a08231' + walletAddress.slice(2).padStart(64, '0')
  const res = await fetch(TEMPO_RPC, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0', id: 1,
      method: 'eth_call',
      params: [{ to: PATHUSD_ADDRESS, data }, 'latest'],
    }),
  })
  const json = (await res.json()) as { result?: string }
  return BigInt(json.result ?? '0x0')
}

Grâce à cette configuration sans aucune contrainte, n'importe qui peut cloner le dépôt et exécuter le script sans avoir à s'inscrire où que ce soit ni à approvisionner manuellement un portefeuille.

informations

Le flux de session MPP de Quicknode utilise le même forfait gratuit que x402 : 1 000 000 de crédits API par mois et par portefeuille. Les requêtes RPC consomment chacune 1 crédit API, tandis que SQL Explorer consomme les crédits API utilisés par la requête. Une fois le forfait gratuit épuisé, passez à un portefeuille alimenté depuis le mainnet. Voir la section « Passage en production ».

Création de la session et consultation des soldes​

C'est ici que réside la logique principale de la session. Le script crée une session MPP avec tempo.session(), puis parcourt chaque chaîne, en envoyant eth_getBalance requêtes effectuées au cours de la session :

import { tempo } from 'mppx/client'

const session = tempo.session({
  account,
  maxDeposit: '1', // 1 PathUSD — covers 100,000 requests at $0.00001/each
})

Le maxDeposit Ce paramètre définit le budget total alloué au canal de paiement. À la fin de la session, le montant non dépensé vous est restitué.

informations

Si le dépôt du canal est épuisé en cours de séance, le mppx Le client peut recharger le canal par un dépôt supplémentaire sur la chaîne sans avoir à fermer puis rouvrir la session. Pour notre script à 15 chaînes, même un petit dépôt suffit amplement, mais cela s'avère utile si vous développez des applications de longue durée qui effectuent des milliers de requêtes.

Effectuer des appels RPC via la session​

Pour chaque chaîne, le script appelle session.fetch() avec un JSON-RPC standard eth_getBalance charge utile. La session gère automatiquement tous les mécanismes MPP :

const MPP_BASE_URL = 'https://mpp.quicknode.com/session'

for (const chain of CHAINS) {
  const response = await session.fetch(`${MPP_BASE_URL}/${chain.slug}`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0',
      id: 1,
      method: 'eth_getBalance',
      params: [WALLET_ADDRESS, 'latest'],
    }),
  })

  const data = (await response.json()) as { result?: string; error?: { message: string } }
  // Parse hex balance to human-readable format
  const balance = formatBalance(data.result!, chain.decimals)
}

Sur le première demande, session.fetch() gère l'intégralité du flux de requête-réponse 402 : il reçoit la requête, dépose des PathUSD dans le contrat d'entiercement sur la blockchain, puis effectue une nouvelle tentative avec un bon signé. Ce processus prend environ 500 ms.

Le chaque demande suivante, la session se contente d'incrémenter le numéro de bon cumulé et de l'inclure dans le Autorisation en-tête. Le serveur vérifie le bon à l'aide d'un seul ecrecover opération (aucune transaction sur la blockchain n'est nécessaire), de sorte que les réponses sont renvoyées avec des frais de paiement quasi nuls.

Le script prévoit également une nouvelle tentative en cas de réponse 404 afin de gérer les problèmes de routage MPP temporaires :

if (response.status === 404) {
  response = await session.fetch(`${MPP_BASE_URL}/${chain.slug}`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: rpcBody,
  })
}

Mise en forme du bilan​

Le eth_getBalance La réponse renvoie une chaîne hexadécimale représentant le solde en wei (ou l'unité la plus petite équivalente de la chaîne). Le script convertit cette valeur en un nombre décimal lisible par l'utilisateur :

import { formatUnits } from 'viem'

function formatBalance(hexBalance: string, decimals: number): string {
  const value = BigInt(hexBalance)
  return parseFloat(formatUnits(value, decimals)).toFixed(4)
}

Clôture de la session​

Une fois toutes les requêtes traitées, le script ferme la session pour déclencher le règlement sur la blockchain. Le serveur règle le bon de paiement cumulé final et rembourse le dépôt non utilisé sur le portefeuille :

// Enregistrer les données de session avant la fermeture
const channelId = session.channelId
const dépensesCumulées = session.cumulative

console.journal(« Fermeture de la session et validation sur la blockchain... »)
const reçu = await session.close()

Le script affiche ensuite un récapitulatif indiquant le coût total, le montant du remboursement et les détails du règlement :

printSummary(
      résultats,
      nombre total de requêtes,
      channelId,
      dépenses cumulées,
      reçu?.txHash,
    );

Le script encadre également l'ensemble de la boucle de requêtes dans un bloc try/catch et tente de fermer la session même en cas d'erreur, afin que le canal de paiement ne reste pas ouvert indéfiniment :

try {
  // ... query loop ...
  await session.close()
} catch (err) {
  console.error('Fatal error:', err instanceof Error ? err.message : err)
  try {
    await session.close()
    console.log('Session closed after error.')
  } catch {
    console.log('Could not close session.')
  }
  process.exit(1)
}

Exécution du script​

Une fois tout configuré, exécutez le script :

# Exécuter avec un portefeuille testnet généré automatiquement (aucune configuration requise)
npx tsx index.ts

# Ou fournissez votre propre clé privée via un fichier .env
echo "MPPX_PRIVATE_KEY=0x..." > .env
npx tsx --env-file=.env index.ts

Vous devriez obtenir un résultat similaire à celui-ci :

Vérificateur de solde multichaîne (via une session MPP)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Portefeuille :  0x1234...abcd (généré automatiquement)
Cible :  0xd8dA...6045

 Chaîne            | Solde               | Statut
──────────────────┼───────────────────────┼──────────
 Ethereum         | 1,2345 ETH            | ok
 Base             | 0,5000 ETH            | ok
 Arbitrum         | 0,0000 ETH            | ok
 Optimism         | 2,1000 ETH            | ok
 Polygon          | 150,0000 POL          | ok
 BNB Chain        | 0,0312 BNB            | ok
 ...              | ...                   | ...

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Résumé de la session
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Chaînes interrogées :    15 (15 ok, 0 erreur)
 Nombre total d'appels RPC :   15
 Coût de la session :      0,000150 PathUSD (0,00015 $)
 Dépôt sur le canal :   1,000000 PathUSD
 Remboursé :          0,999850 PathUSD
 ID du canal :        0xdef456...abc123
 Transaction de règlement :     0xabc123...def456

Une fois la session terminée, vous pouvez vérifier le règlement sur l'explorateur de blocs. Le Règlement tx Le hachage figurant dans les liens de sortie renvoie à la transaction finale sur la blockchain. Utilisez le Explorateur du réseau de test pour « Tempo Moderato » ou le explorateur du réseau principal pour les séries de production.

La capture d'écran ci-dessous montre à quoi ressemble une opération de règlement :

Transaction de règlement de session MPP sur l'explorateur de blocs Tempo

L'encadré rouge indique les deux transferts de solde liés au canal de paiement : 1 PathUSD envoyé au contrat d'entiercement à l'ouverture de la session, et 0,99985 PathUSD restitué à titre de remboursement lors de la clôture de celle-ci. L'encadré orange indique le coût réel de la session (0,00015 PathUSD) versé au serveur dans le cadre de la transaction de règlement.

Vous pouvez modifier l'adresse du portefeuille vérifiée en modifiant le fichier ADRESSE_DE_PORTEFEUILLE constante en haut de index.ts:

const WALLET_ADDRESS = '0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045' // n'importe quelle adresse

Passage en production​

Par défaut, le script utilise le testnet pour faciliter la mise en route. Voici les changements à effectuer pour une utilisation en production :

Testnet (par défaut)Mainnet
Réseau de paiementTempo Moderato (ID de chaîne 42431)Réseau principal Tempo (ID de chaîne 4217)
DevisePathUSDPathUSD ou USDC.e
Formule gratuite1 000 000 de crédits API partagés par mois et par portefeuille, répartis entre MPP et x402Illimité
Approvisionnement du portefeuilleFinancement automatique via un « faucet »Financement manuel requis

Pour passer au réseau principal, fournissez une clé de portefeuille contenant des PathUSD ou des USDC.e sur le réseau principal de Tempo. Le mppx Le client détecte automatiquement les soldes disponibles et choisit le mode de paiement approprié parmi les options proposées dans le défi 402.

Extension du script​

L'outil de vérification des soldes est volontairement simple afin de mettre l'accent sur le fonctionnement des sessions. Ce qu'il faut retenir, c'est le schéma suivant : ouvrir une session, effectuer plusieurs appels RPC sur différentes chaînes, puis fermer la session et procéder au règlement. Étant donné qu'une seule session MPP gère les requêtes sur l'ensemble des « slugs » du réseau, vous pouvez étendre le script pour appeler n'importe quelle méthode RPC sur n'importe quelle chaîne prise en charge sans modifier la configuration de la session. Par exemple, vous pourriez ajouter des vérifications de solde de jetons ERC-20 en remplaçant eth_getBalance pour un eth_call vers le contrat du jeton soldeDe fonction.

Conclusion​

Vous avez développé un outil de vérification de solde multichaîne qui interroge 15 chaînes EVM via une seule session MPP. Le principe clé à retenir est le suivant : ouvrez un canal de paiement, effectuez autant d'appels RPC que nécessaire sur n'importe quelle combinaison de chaînes prises en charge à l'aide de bons hors chaîne, puis fermez le canal et procédez au règlement. La session a géré automatiquement tous les mécanismes de paiement, depuis la requête initiale 402 jusqu'à la signature des bons, en passant par le règlement final et le remboursement.

Ce modèle s'applique à tout workflow effectuant plusieurs appels RPC : outils de suivi de portefeuille, scripts de surveillance, pipelines de données ou agents d'IA devant lire l'état on-chain sur différents réseaux. Les sessions permettent à ces outils de payer l'accès par programmation, sans compte ni clé API, tout en évitant que les frais de paiement ne constituent un goulot d'étranglement.

Prochaines étapes​

Pour en savoir plus sur MPP, Tempo et l'intégration de MPP à Quicknode, consultez les ressources suivantes :

Foire aux questions​

Qu'est-ce que le MPP et en quoi diffère-t-il de l'authentification traditionnelle par clé API ?

Le Machine Payments Protocol (MPP) est une norme ouverte qui permet d'intégrer des paiements directement dans les points de terminaison HTTP à l'aide du code d'état 402 « Paiement requis ». Au lieu de créer un compte et de gérer des clés API, vous payez à chaque requête à l'aide de stablecoins depuis un portefeuille. Cela permet aux scripts, aux agents et aux bots de commencer à utiliser les API immédiatement, sans avoir à passer par une configuration de facturation gérée par un intervenant humain.

Dans quels cas dois-facturer une session MPP plutôt que de facturer à chaque requête ?

Utilisez les sessions lorsque votre script ou votre application effectue plusieurs appels RPC au cours d'une même exécution. Les sessions ouvrent un canal de paiement sur la chaîne et utilisent des bons hors chaîne pour les requêtes suivantes. La vérification des bons est un contrôle de signature gourmand en ressources CPU qui ajoute quelques microsecondes de surcharge, contre plusieurs centaines de millisecondes pour les paiements par prélèvement sur la chaîne. Sur les points de terminaison MPP de Quicknode, les sessions sont également nettement moins coûteuses par requête. Si vous effectuez moins de 10 requêtes, le paiement par prélèvement est plus simple.

Dois-je disposer d'un compte Quicknode pour utiliser les points de terminaison MPP ?

Non. Les points de terminaison MPP ne nécessitent ni compte, ni clés API, ni inscription. Il vous suffit de disposer d'un portefeuille contenant des stablecoins (ou des jetons du testnet). Le paiement s'effectue directement lors de chaque requête HTTP.

Puis-je interroger des chaînes non-EVM, comme Solana, via une session MPP ?

Les points de terminaison MPP de Quicknode prennent en charge Solana et d'autres chaînes non EVM. Vous pouvez utiliser la même instance de session pour interroger n'importe quelle chaîne prise en charge en modifiant le slug du réseau dans l'URL. Par exemple, utilisez /session/solana-mainnet pour interroger les points de terminaison RPC de Solana via le même canal de paiement.

Que se passe-t-il si mon script plante avant la fermeture de la session ?

Si la session n'est pas explicitement fermée, le canal de paiement reste ouvert jusqu'à ce qu'il expire. Le serveur peut alors toujours traiter le dernier bon de paiement qu'il a reçu. Pour éviter cela, le script encadre la boucle de requêtes dans un bloc « try/catch » et tente de fermer la session même en cas d'erreur.

Comment fonctionne l'offre gratuite et comment puis-je passer au réseau principal ?

Les points de terminaison MPP de Quicknode utilisent le même quota gratuit de 1 000 000 de crédits API par mois et par portefeuille, partagé avec x402. Les requêtes RPC consomment chacune 1 crédit API, tandis que SQL Explorer consomme les crédits API utilisés par la requête. Pour une utilisation illimitée, fournissez un portefeuille approvisionné en PathUSD ou en USDC.e sur le mainnet de Tempo (ID de chaîne 4217).

Nous ❤️ les commentaires !

Faites-nous savoir si vous avez des commentaires ou des suggestions de nouveaux sujets. Nous serions ravis de vous entendre.

Dernière mise à jour sur
Partager ce guide