14 Minuten Lesezeit

Übersicht

Mit dem Machine Payments Protocol (MPP) können Sie den API-Zugang direkt im Rahmen einer HTTP-Anfrage bezahlen. Keine Konten, keine API-Schlüssel. Nur eine Wallet mit einem Stablecoin-Guthaben.

Sessions gehen noch einen Schritt weiter. Man eröffnet einen Zahlungskanal einmalig und nutzt ihn dann für jede Anfrage wieder. Jeder Aufruf wird mit einem kleinen signierten Gutschein bezahlt, sodass nicht jedes Mal eine On-Chain-Transaktion erforderlich ist und die Anfragen schnell bleiben.

In dieser Anleitung erstellen Sie ein TypeScript-Skript, das eine einzelne MPP-Sitzung öffnet, über die MPP-Endpunkte von Quicknode die Guthaben nativer Token in 15 EVM-Chains abfragt und einen formatierten Bericht mit einer Kostenaufschlüsselung ausgibt.

Dies eignet sich hervorragend für Sitzungen, da das Skript bei einem einzigen Durchlauf mehrere RPC-Aufrufe über verschiedene Netzwerke hinweg durchführt. Anstatt jeden Aufruf einzeln zu bezahlen, laufen alle Anfragen über einen einzigen Zahlungskanal. Sie zahlen die Einrichtungskosten einmalig und können diese dann für den Rest wiederverwenden.

Quicknode unterstützt MPP-Sitzungen über alle unterstützten Blockchains hinweg. Mit derselben Sitzung, mit der Abfragen an Ethereum gesendet werden, können auch Abfragen an Base, Arbitrum, Polygon und andere Blockchains gesendet werden, ohne dass eine zusätzliche Konfiguration erforderlich ist.

Kostenlose Stufe

Jede Wallet erhält ein gemeinsames kostenloses Kontingent von 1.000.000 API-Credits pro Monat für alle agentenbasierten Zahlungsschnittstellen von Quicknode, einschließlich MPP und x402. Standard-RPC-Anfragen verbrauchen jeweils 1 API-Credit, während der SQL Explorer die für die Abfrage verwendeten API-Credits verbraucht.

MPP ist eines von zwei agentenbasierten Zahlungsprotokollen auf Quicknode

Quicknode unterstützt zwei Wallet-basierte Zahlungsprotokolle für den kontolosen RPC-Zugriff: MPP (in dieser Anleitung verwendet) und x402 (ein offener Standard von Coinbase). Beide ermöglichen es Skripten und KI-Agenten, API-Aufrufe direkt zu bezahlen, ohne dass ein Konto oder API-Schlüssel erforderlich sind. Sie unterscheiden sich jedoch hinsichtlich des Übertragungsformats, der Sitzungsmechanismen und der unterstützten Zahlungsmethoden. Einen direkten Vergleich finden Sie in der Übersicht zu „Agentic Payments“, oder springen Sie direkt zu den x402-Dokumenten und den MPP-Dokumenten, um Details zu den Protokollen zu erhalten.

Was Sie lernen werden

• Wie das Machine Payments Protocol funktioniert und warum es Sitzungen gibt
• Der gesamte Lebenszyklus einer Sitzung: 402-Challenge, Einzahlung über den Kanal, Unterzeichnung des Gutscheins und Abrechnung
• So verwenden Sie die mppx SDK zum Erstellen und Verwalten von Zahlungssitzungen
• So führen Sie in einer einzigen Sitzung mehrere RPC-Aufrufe über verschiedene Ketten hinweg mithilfe der MPP-Endpunkte von Quicknode durch

Was Sie benötigen

• Node.js v20 oder höher
• Grundlegende Kenntnisse in TypeScript und EVM-Chains
• Es sind weder ein Quicknode-Konto noch API-Schlüssel erforderlich (MPP kümmert sich um den Zugriff und die Abrechnung)
• Eine kleine Menge PathUSD im Tempo-Testnetz (automatische Aufladung über den Faucet im Skript) oder PathUSD/USDC.e im Tempo-Mainnetz für den produktiven Einsatz

Was ist das „Machine Payments Protocol“?

Das „Machine Payments Protocol“ ist ein offener Standard, der der IETF vorgeschlagen wurde und jedem HTTP-Endpunkt Inline-Zahlungen hinzufügt. Es wurde entwickelt, um ein spezifisches Problem zu lösen: Programmierbare Clients (Agenten, Skripte, Bots) haben keine gute Möglichkeit, für den API-Zugriff zu bezahlen, ohne dass zuvor ein Mensch die Abrechnung einrichtet.

Herkömmliche Zahlungsabläufe basieren auf Checkout-Formularen, Browsersitzungen und visuellen CAPTCHAs. MPP ersetzt diese durch einen maschinenlesbaren Zahlungsaushandlungsprozess, der auf HTTP basiert. 402 Zahlung erforderlich.

So funktioniert es

Das Protokoll folgt einem Challenge-Response-Muster:

1. Anfrage: Der Client sendet eine normale HTTP-Anfrage an einen kostenpflichtigen Endpunkt.
2. Herausforderung: Der Server antwortet mit 402 Zahlung erforderlich und ein WWW-Authenticate: Zahlung Überschrift mit Angaben zum Preis, zu den akzeptierten Währungen und zu den verfügbaren Zahlungsmethoden.
3. Bezahlung: Der Kunde wählt eine Zahlungsmethode aus und führt die Zahlung durch (unterzeichnet eine Stablecoin-Überweisung, eröffnet einen Zahlungskanal usw.).
4. Erneut versuchen: Der Client sendet die ursprüngliche Anfrage erneut mit einem Genehmigung: Zahlung Kopfzeile mit Zahlungsnachweis.
5. Liefern: Der Server überprüft die Zahlung und gibt die Antwort mit einem Zahlungsbeleg Kopfzeile.

Client-Bibliotheken wie mppx Die Schritte 2 bis 4 werden automatisch abgewickelt. Aus Sicht Ihres Codes funktioniert die Anfrage einfach.

Gebühr vs. Sitzung

MPP definiert zwei Zahlungsabsichten, die die Funktionsweise der Abrechnung steuern:

	Anklage	Sitzung
Muster	Einmalzahlung pro Anfrage	Pay-as-you-go über den Zahlungskanal
Abrechnung	On-Chain-Transaktion pro Anfrage	Off-Chain-Gutscheine, On-Chain-Abrechnung nur bei Eröffnung/Schließung
Verifizierungslatenz	Hunderte von Millisekunden (onchain)	Mikrosekunden (CPU-gebunden ecrecover)
Am besten geeignet für	Gelegentliche Abfragen, einfache Integrationen	Häufig auftretende Anfragen, Batch-Workflows, Agenten

Der wesentliche Unterschied liegt darin, wie die Zahlungsüberprüfung erfolgt. Bei „Charge“ löst jede Anfrage eine On-Chain-Transaktion aus. Bei „Sessions“ überprüft der Server einen signierten Gutschein mithilfe einer einzigen ecrecover Aufruf, ohne dass RPC-Aufrufe oder Datenbank-Schreibvorgänge im kritischen Pfad enthalten sind. Das bedeutet, dass der Server während der Sitzung zu keinem Zeitpunkt auf die Blockchain zugreift, sodass der Durchsatz durch die Server-CPU begrenzt wird und nicht durch den Blockchain-Konsens.

Auf den MPP-Endpunkten von Quicknode führt dies ebenfalls zu konkreten Kosteneinsparungen: Abrechnungsanfragen kosten jeweils 0,001 US-Dollar, während Sitzungsanfragen jeweils 0,00001 US-Dollar kosten. Für ein Skript, das in einem Durchlauf mehr als 15 RPC-Aufrufe über verschiedene Netzwerke hinweg auslöst, sind Sitzungen die naheliegende Wahl:

Abgefragte Ketten	Gebühr (0,001 $/Anfrage)	Sitzung (0,00001 $/Anfrage)
10	$0.010	$0.0001
25	$0.025	$0.00025
50	$0.050	$0.0005

Den Lebenszyklus einer Sitzung verstehen

Bevor wir uns mit dem Code befassen, ist es wichtig zu verstehen, wie Sessions im Hintergrund funktionieren. Das folgende Diagramm zeigt den gesamten Ablauf unseres Multichain-Guthabenprüfers:

Zentrale Konzepte

Zahlungskanal: Ein On-Chain-Treuhandvertrag, bei dem der Kunde im Voraus Geld einzahlt. Dies geschieht einmalig zu Beginn der Sitzung.

Kumulative Gutscheine: Jede Anfrage enthält eine signierte Nachricht mit dem Wortlaut „Ich habe nun insgesamt bis zu X verbraucht.“ Gutscheine sind kumulativ und nicht inkrementell. Der Server benötigt lediglich den neuesten Gutschein, um alle fälligen Beträge einzufordern. Beispiel: Nach drei Anfragen zu je 0,00001 $: Gutschein(1) = 10, Gutschein(2) = 20, Gutschein(3) = 30 atomare Einheiten.

Sitzungen über mehrere Netzwerke hinweg: Eine einzelne Sitzungsinstanz verarbeitet Anfragen über verschiedene /session/:network Endpunkte. Die Sitzung verwaltet den Zahlungskanal; der Netzwerk-Slug legt fest, an welches Quicknode-RPC-Backend die Anfrage weitergeleitet wird.

Abrechnung: Wenn die Sitzung beendet wird, rechnet der Server den endgültigen Beleg in der Blockchain ab. Der Kunde erhält eine Rückerstattung des nicht verbrauchten Guthabens.

Projekteinrichtung

Das vollständige Skript befindet sich in der qn-Anleitung-Beispiele Repository (die Quelldatei direkt anzeigen). Klonen Sie es und installieren Sie die Abhängigkeiten:

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

Sie können auch die index.ts Datei in Ihr eigenes Projekt einbinden und die erforderlichen Abhängigkeiten installieren.

Das Projekt nutzt zwei Laufzeitabhängigkeiten:

Paket	Zweck
mppx	MPP-Protokoll-Client (Sitzungsverwaltung, Signieren von Vouchern)
viem	Wallet-Funktionen und Darstellung des Guthabens

Und zwei Entwicklungsabhängigkeiten: tsx um TypeScript direkt auszuführen, und Typescript zur Typüberprüfung.

Definition des Chain-Registers

Das Skript fragt die nativen Guthaben über mehrere EVM-Chains hinweg ab. Jede Chain wird durch ihren MPP-Netzwerk-Slug, ihren Anzeigenamen, ihr natives Token-Symbol und ihre Dezimalgenauigkeit definiert:

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 },
]

Der Netzwerk-Slug ist hier das entscheidende Element. Er wird dem MPP-Sitzungsendpunkt unter https://mpp.quicknode.com/session/:slug. Die /session/ Das Präfix in der URL weist den Server an, statt „charge intent“ „session intent“ zu verwenden.

Sie können Ketten nach Bedarf hinzufügen oder entfernen. Die MPP-Endpunkte von Quicknode unterstützen alle unterstützten Netzwerke. Sie können die vollständige Liste der unterstützten Slugs auch dynamisch abrufen:

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

Beachten Sie, dass die von Ihnen abgefragten Blockchains vom Zahlungsnetzwerk entkoppelt sind. Ihre Sitzung läuft auf der Tempo-Blockchain (Testnetz oder Hauptnetz), kann jedoch auf RPC-Endpunkte jeder unterstützten Blockchain zugreifen.

Einrichten der Wallet

Das Skript benötigt eine Wallet, um Belege für den Zahlungskanal zu signieren. Es kann entweder einen vorhandenen privaten Schlüssel aus der Umgebung verwenden oder automatisch einen neuen generieren:

import { generatePrivateKey, privateKeyToAccount } aus 'viem/accounts'

const privater Schlüssel = (process.env.MPPX_PRIVATE_KEY als `0x${Zeichenkette}`) || generatePrivateKey()
const Konto = privateKeyToAccount(privaterSchlüssel)

Wenn ein Schlüssel automatisch generiert wird, speichert das Skript ihn in einer .env Datei (mit chmod 600 Berechtigungen), damit bei zukünftigen Durchläufen dieselbe Wallet wiederverwendet wird:

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 },
  )
}

Finanzierung über den Testnet-Faucet

Für die Nutzung im Testnetz füllt das Skript das Wallet automatisch über den Tempo-Testnetz-Faucet auf. Dadurch erhält das Wallet PathUSD (eine Testnetz-Stablecoin) sowie Gas auf Tempo Moderato (Chain-ID 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)
  }
}

Die waitForFunding Die Funktion fragt den PathUSD-Kontrakt auf Tempo Moderato ab, um zu überprüfen, ob der Restbetrag eingegangen ist, bevor sie fortfährt:

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')
}

Dank dieser reibungslosen Vorgehensweise kann jeder das Repo klonen und das Skript ausführen, ohne sich irgendwo registrieren oder manuell Geld auf ein Wallet einzahlen zu müssen.

Info

Der MPP-Sitzungsablauf von Quicknode nutzt denselben Free-Tier-Bucket wie x402: 1.000.000 API-Credits pro Monat und Wallet. RPC-Anfragen verbrauchen jeweils 1 API-Credit, während der SQL Explorer die für die Abfrage verwendeten API-Credits verbraucht. Sobald das Free Tier aufgebraucht ist, wechseln Sie zu einem mit Mainnet-Guthaben finanzierten Wallet. Siehe „Going to Production“.

Erstellen der Sitzung und Abfragen der Kontostände

Hier befindet sich die Kernlogik der Sitzung. Das Skript erstellt eine MPP-Sitzung mit tempo.session(), durchläuft dann jede Kette und sendet eth_getBalance Anfragen während der Sitzung:

import { tempo } from 'mppx/client'

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

Die maxDeposit Mit diesem Parameter wird das Gesamtbudget für den Zahlungskanal festgelegt. Der nicht ausgegebene Betrag wird Ihnen bei Beendigung der Sitzung gutgeschrieben.

Info

Sollte das Guthaben auf dem Kanal während der Sitzung aufgebraucht sein, wird das mppx Der Client kann den Kanal durch eine zusätzliche On-Chain-Einzahlung aufstocken, ohne die Sitzung zu schließen und erneut zu öffnen. Für unser 15-Chain-Skript reicht bereits eine kleine Einzahlung völlig aus, doch dies ist nützlich, wenn Sie länger laufende Anwendungen entwickeln, die Tausende von Anfragen stellen.

RPC-Aufrufe über die Sitzung

Für jede Kette ruft das Skript Folgendes auf: session.fetch() mit einem Standard-JSON-RPC eth_getBalance Nutzdaten. Die Sitzung übernimmt automatisch alle MPP-Abläufe:

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)
}

Auf der erste Anfrage, session.fetch() übernimmt den gesamten 402-Challenge-Response-Ablauf: Es empfängt die Challenge, hinterlegt PathUSD im On-Chain-Treuhandvertrag und versucht es erneut mit einem signierten Voucher. Dies dauert etwa 500 ms.

Am jede weitere Anfrage, erhöht die Sitzung lediglich den kumulativen Belegwert und nimmt ihn in die Genehmigung Header. Der Server überprüft den Gutschein mit einem einzigen ecrecover Vorgang (keine On-Chain-Transaktion erforderlich), sodass die Antworten mit nahezu null Zahlungsaufwand zurückkommen.

Das Skript sieht außerdem einen Wiederholungsversuch bei 404-Fehlern vor, um vorübergehende MPP-Routing-Probleme zu beheben:

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

Formatierung der Bilanz

Die eth_getBalance Die Antwort gibt eine Hexadezimalzeichenfolge zurück, die den Kontostand in Wei (oder der entsprechenden kleinsten Einheit der Blockchain) angibt. Das Skript wandelt diesen Wert in eine für Menschen lesbare Dezimalzahl um:

import { formatUnits } from 'viem'

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

Die Sitzung beenden

Nachdem alle Abfragen abgeschlossen sind, schließt das Skript die Sitzung, um die Abrechnung auf der Blockchain auszulösen. Der Server rechnet den endgültigen kumulierten Gutschein ab und erstattet die nicht genutzte Einzahlung an das Wallet zurück:

// Sitzungsdaten vor dem Schließen erfassen
const channelId = session.channelId
const kumulierteAusgaben = session.kumulativ

Konsole.Protokoll(„Sitzung wird geschlossen und auf der Blockchain abgerechnet...“)
const Quittung = await session.close()

Das Skript gibt anschließend eine Zusammenfassung aus, in der die Gesamtkosten, der Rückerstattungsbetrag und die Abrechnungsdetails angezeigt werden:

printSummary(
      Ergebnisse,
      Gesamtanzahl der Anfragen,
      Kanal-ID,
      cumulativeSpend,
      receipt?.txHash,
    );

Das Skript umschließt zudem die gesamte Abfrageschleife mit einem „try/catch“-Block und versucht, die Sitzung auch im Fehlerfall zu schließen, damit der Zahlungskanal nicht unbegrenzt offen bleibt:

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)
}

Das Skript ausführen

Wenn alles eingerichtet ist, führen Sie das Skript aus:

# Mit einer automatisch generierten Testnet-Wallet ausführen (keine Einrichtung erforderlich)
npx tsx index.ts

# Oder geben Sie Ihren eigenen privaten Schlüssel über eine .env-Datei an
echo "MPPX_PRIVATE_KEY=0x..." > .env
npx tsx --env-file=.env index.ts

Die Ausgabe sollte in etwa so aussehen:

Multichain-Kontostandsabfrage (über MPP-Sitzung)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Wallet:  0x1234...abcd (automatisch generiert)
Ziel:  0xd8dA...6045

 Kette            | Guthaben               | Status
──────────────────┼───────────────────────┼──────────
 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
 ...              | ...                   | ...

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Zusammenfassung der Sitzung
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Abgefragte Chains:    15 (15 ok, 0 Fehler)
 Gesamtzahl der RPC-Aufrufe:   15
 Sitzungskosten:      0,000150 PathUSD (0,00015 $)
 Einzahlung in den Kanal:   1,000000 PathUSD
 Rückerstattet:          0,999850 PathUSD
 Kanal-ID:        0xdef456...abc123
 Abwicklungs-Transaktion:     0xabc123...def456

Sobald die Sitzung beendet ist, können Sie die Abrechnung im Block-Explorer überprüfen. Die Abrechnung tx Der Hash in den Ausgabelinks verweist auf die abschließende On-Chain-Transaktion. Verwenden Sie den Testnetz-Explorer für „Tempo Moderato“ oder das Mainnet-Explorer für Serienfertigung.

Der folgende Screenshot zeigt, wie eine Abwicklungstransaktion aussieht:

Der rote Kasten zeigt die beiden mit dem Zahlungskanal verbundenen Saldoübertragungen: 1 PathUSD, der bei Eröffnung der Sitzung an den Treuhandvertrag gesendet wurde, und 0,99985 PathUSD, der bei Abschluss der Sitzung als Rückerstattung zurückgezahlt wurde. Der orangefarbene Kasten zeigt die tatsächlichen Sitzungskosten (0,00015 PathUSD), die im Rahmen der Abwicklungstransaktion an den Server gezahlt wurden.

Sie können die zu überprüfende Wallet-Adresse ändern, indem Sie die WALLET_ADDRESS Konstante am Anfang von index.ts:

const WALLET_ADDRESS = '0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045' // beliebige Adresse

In die Produktion gehen

Das Skript ist standardmäßig auf das Testnetz eingestellt, um eine reibungslose Einbindung zu gewährleisten. Folgendes ändert sich bei der Nutzung in der Produktionsumgebung:

	Testnetz (Standard)	Mainnet
Zahlungsnetzwerk	Tempo Moderato (Ketten-ID 42431)	Tempo-Mainnet (Ketten-ID 4217)
Währung	PathUSD	PathUSD oder USDC.e
Kostenlose Stufe	1.000.000 API-Credits pro Monat und Wallet, verteilt auf MPP und x402	Unbegrenzt
Einzahlung auf das Wallet	Automatische Finanzierung über Faucet	Manuelle Finanzierung erforderlich

Um zum Mainnet zu wechseln, geben Sie einen Wallet-Schlüssel an, der „PathUSD“ oder „USDC.e“ im Tempo-Mainnet enthält. Der mppx Die Client-Anwendung erkennt automatisch die verfügbaren Guthaben und wählt die richtige Zahlungsmethode aus der 402-Challenge aus.

Erweiterung des Skripts

Der Kontostandsprüfer ist bewusst einfach gehalten, um den Fokus auf die Funktionsweise der Sitzung zu legen. Das Wichtigste dabei ist das Muster: eine Sitzung öffnen, zahlreiche RPC-Aufrufe über verschiedene Blockchains hinweg durchführen, schließen und abrechnen. Da eine einzelne MPP-Sitzung Anfragen über alle Netzwerk-Slugs hinweg verarbeitet, können Sie das Skript so erweitern, dass beliebige RPC-Methoden auf jeder unterstützten Blockchain aufgerufen werden, ohne die Sitzungseinstellungen ändern zu müssen. Sie könnten beispielsweise Überprüfungen des Kontostands von ERC-20-Token hinzufügen, indem Sie eth_getBalance für ein eth_call zum Token-Vertrag Saldo Funktion.

Fazit

Sie haben einen Multichain-Kontostandsprüfer entwickelt, der über eine einzige MPP-Sitzung 15 EVM-Chains abfragt. Das wichtigste Lernziel dabei: Eröffnen Sie einen Zahlungskanal, führen Sie mithilfe von Off-Chain-Gutscheinen so viele RPC-Aufrufe durch, wie Sie benötigen – über eine beliebige Kombination der unterstützten Chains hinweg –, und schließen Sie den Kanal anschließend ab und wickeln Sie die Transaktion ab. Die Sitzung hat alle Zahlungsabläufe automatisch abgewickelt, von der anfänglichen 402-Challenge über die Signierung der Gutscheine bis hin zur endgültigen Abrechnung und Rückerstattung.

Dieses Muster gilt für jeden Workflow, der mehrere RPC-Aufrufe durchführt: Portfolio-Tracker, Überwachungsskripte, Datenpipelines oder KI-Agenten, die den On-Chain-Status netzwerkübergreifend abfragen müssen. Mithilfe von Sitzungen können diese Tools den Zugriff programmgesteuert bezahlen – ohne Konten oder API-Schlüssel –, wobei der Zahlungsaufwand nicht in den kritischen Pfad einfließt.

Nächste Schritte

Um mehr über MPP, Tempo und die MPP-Integration von Quicknode zu erfahren, sehen Sie sich die folgenden Ressourcen an:

• Dokumentation zum Machine Payments Protocol
• Leitfaden zur sitzungsbasierten Abrechnung bei MPP
• mppx SDK auf npm
• Quicknode MPP-Protokollreferenz
• IETF-Spezifikation zur Zahlungsauthentifizierung
• MPP mit Foundry und Tempo verwenden (Begleitleitfaden für Solidity-Entwickler)

Häufig gestellte Fragen

Was ist MPP und worin unterscheidet es sich von der herkömmlichen API-Schlüssel-Authentifizierung?

Das Machine Payments Protocol (MPP) ist ein offener Standard, der HTTP-Endpunkten mithilfe des Statuscodes 402 „Payment Required“ Inline-Zahlungen hinzufügt. Anstatt ein Konto zu eröffnen und API-Schlüssel zu verwalten, zahlen Sie pro Anfrage mit Stablecoins aus einer Wallet. So können Skripte, Agenten und Bots APIs sofort nutzen, ohne dass eine von Menschen durchgeführte Abrechnungskonfiguration erforderlich ist.

Wann sollte ich eine MPP-Sitzung anstelle von Zahlungen pro Anfrage nutzen?

Verwenden Sie Sitzungen, wenn Ihr Skript oder Ihre Anwendung mehrere RPC-Aufrufe in einem einzigen Durchlauf durchführt. Bei Sitzungen wird ein Zahlungskanal in der Blockchain eröffnet, und für nachfolgende Anfragen werden Off-Chain-Gutscheine verwendet. Die Gutscheinüberprüfung ist eine CPU-intensive Signaturprüfung, die einen Mehraufwand von Mikrosekunden verursacht, im Vergleich zu Hunderten von Millisekunden bei Zahlungen über die Blockchain. An den MPP-Endpunkten von Quicknode sind Sitzungen zudem pro Anfrage deutlich kostengünstiger. Wenn Sie weniger als 10 Anfragen stellen, ist die Abrechnung einfacher.

Benötige ich ein Quicknode-Konto, um MPP-Endpunkte nutzen zu können?

Nein. Für MPP-Endpunkte sind weder ein Konto noch API-Schlüssel noch eine Registrierung erforderlich. Sie benötigen lediglich eine Wallet mit Stablecoins (oder Testnet-Token). Die Zahlung erfolgt direkt im Rahmen jeder HTTP-Anfrage.

Kann ich über eine MPP-Sitzung Abfragen an Nicht-EVM-Blockchains wie Solana senden?

Die MPP-Endpunkte von Quicknode unterstützen Solana und andere Nicht-EVM-Chains. Sie können dieselbe Sitzungsinstanz verwenden, um beliebige unterstützte Chains abzufragen, indem Sie den Netzwerk-Slug in der URL ändern. Verwenden Sie beispielsweise /session/solana-mainnet, um Solana-RPC-Endpunkte über denselben Zahlungskanal abzufragen.

Was passiert, wenn mein Skript abstürzt, bevor die Sitzung geschlossen wird?

Wird die Sitzung nicht explizit geschlossen, bleibt der Zahlungskanal bis zum Ablauf der Zeitüberschreitung offen. Der Server kann den zuletzt empfangenen Gutschein weiterhin abrechnen. Um dies zu vermeiden, umschließt das Skript die Abfrageschleife mit einem „try/catch“-Block und versucht, die Sitzung auch bei Fehlern zu schließen.

Wie funktioniert die kostenlose Stufe und wie wechsle ich zum Mainnet?

Die MPP-Endpunkte von Quicknode nutzen denselben kostenlosen Kontingent-Bucket von 1.000.000 API-Credits pro Monat und Wallet, der auch für x402 gilt. RPC-Anfragen verbrauchen jeweils 1 API-Credit, während der SQL Explorer die für die Abfrage verwendeten API-Credits verbraucht. Für eine unbegrenzte Nutzung stellen Sie bitte ein Wallet bereit, das mit PathUSD oder USDC.e im Tempo-Mainnet (Chain-ID 4217) aufgeladen ist.

Wir ❤️ Feedback!

Teilen Sie uns gerne mit, wenn Sie Feedback oder Vorschläge für neue Themen haben. Wir freuen uns auf Ihre Rückmeldung.