ERPC startet x402-fähige Solana RPC — Der Beginn einer Ära, in der KI-Agenten APIs bei Bedarf bezahlen

ERPC startet x402-fähige Solana RPC — Der Beginn einer Ära, in der KI-Agenten APIs bei Bedarf bezahlen

ERPC startet x402-fähige Solana RPC — Der Beginn einer Ära, in der KI-Agenten APIs bei Bedarf bezahlen
ELSOUL LABO B.V. (Hauptsitz: Amsterdam, Niederlande; CEO: Fumitake Kawasaki) und Validators DAO, die Betreiber von ERPC, geben den Start eines x402-fähigen Solana mainnet JSON-RPC Proxy bekannt.
Der neue Dienst ist eine produktionsfähige x402-fähige Solana RPC auf x402.erpc.global. Nutzer, Anwendungen und KI-Agenten können Solana JSON-RPC Requests an POST https://x402.erpc.global/v1/solana-mainnet senden. Wenn eine Zahlung erforderlich ist, gibt ERPC HTTP 402 Payment Required mit einer x402 Payment Challenge zurück. Der Client kann anschließend ein USDC-Stablecoin-Payment-Payload auf Solana mainnet anhängen und dieselbe Anfrage erneut senden, um nach Verifizierung und Settlement das Solana RPC-Ergebnis zu erhalten.
Bisher folgten API-Zahlungen meist einem Modell, in dem ein Mensch zuerst einen Vertrag abschließt, eine API key erhält und KI-Systeme oder Bots diese key danach verwenden. Mit x402 können KI-Agenten und Programme die zur Request-Zeit zurückgegebenen Zahlungsbedingungen lesen, innerhalb des vom Eigentümer festgelegten Budgets und Berechtigungsrahmens zahlen und die benötigte API sofort nutzen. ERPC setzt diesen Ablauf für einen konkreten Infrastrukturfall um: Solana RPC.
ERPC x402 payment sequence diagram

Was x402 ist

x402 ist ein offenes Payment Protocol, das den HTTP-Status 402 Payment Required modern für Web- und API-Zahlungen nutzt.
Im traditionellen API-Modell erstellt ein Nutzer für jeden Dienst ein Konto, registriert eine Zahlungsmethode, generiert eine API key und verwaltet Abonnements oder Prepaid Credits. Dieser Ablauf funktioniert für Menschen im Browser, ist aber zu schwerfällig für Software und KI-Agenten, die dynamisch Dienste auswählen und nur für tatsächliche Nutzung zahlen müssen.
Mit x402 antwortet der Server zuerst mit 402 Payment Required, wenn ein Client auf eine bezahlte Ressource zugreift. Die Response enthält die Zahlungsbedingungen: Betrag, Netzwerk und Asset. Der Client erzeugt entsprechend ein Payment Payload und sendet dieselbe Anfrage mit Zahlungsnachweis erneut. Der Server verifiziert und settled die Zahlung und gibt dann die angeforderte API-Response oder den Content zurück.
x402 macht bezahlten API-Zugriff damit zu einer natürlichen HTTP request / response-Konversation: diese Operation kostet diesen Betrag; die Zahlung wurde eingereicht; das Ergebnis kann zurückgegeben werden.

Was ERPC implementiert hat

ERPCs x402-fähige Solana RPC ist ein Solana mainnet JSON-RPC Proxy auf Cloudflare Workers. Zahlungsprüfung und Settlement nutzen den Coinbase CDP x402 facilitator, mit USDC-Stablecoin-Zahlungen auf Solana mainnet. /.well-known/x402 veröffentlicht x402 version 2, die facilitator URL, Solana mainnet, USDC und den POST endpoint /v1/solana-mainnet.
Beim ersten Request sendet der Client eine normale Solana JSON-RPC body. Wenn X-Payment fehlt, gibt ERPC 402 Payment Required zusammen mit der x402 challenge, dem RPC method weight und USD-Preisangaben zurück.
Der Client erstellt danach ein USDC-Stablecoin-Payment-Payload auf Solana mainnet und sendet dieselbe JSON-RPC body mit dem Header X-Payment erneut. ERPC bittet den facilitator, die Zahlung zu prüfen und zu settlen, erhält einen settlement receipt und proxyt die Anfrage an die upstream Solana RPC. Der Client erhält das JSON-RPC-Ergebnis zusammen mit einem X-Payment-Response receipt. Aus Kompatibilitätsgründen akzeptiert ERPC auch Payment-Signature als legacy header.
Um doppelte Zahlungsnutzung zu verhindern, werden wiederverwendete Signatures als 409 duplicate_payment behandelt. Ungültige Zahlungen oder zu geringe Beträge werden als 402 payment_invalid oder payment_amount_too_low zurückgegeben.
Die Preisgestaltung folgt ERPCs canonical token model: der raw weight jeder Methode wird mit 0.000001 USD multipliziert. Standard-JSON-RPC-Methoden haben 42 tokens, getProgramAccounts 4200 tokens, getTokenLargestAccounts 2400 tokens und getMultipleAccounts addiert 420 tokens pro pubkey. Um dem minimum settlement amount des facilitators zu entsprechen, gilt für den gesamten Request ein minimum charge von 0.001 USD. getSlot hat zum Beispiel einen raw weight von 42 tokens, wird nach Anwendung des minimum charge aber mit 1000 tokens, also 0.001 USD, berechnet.
Kostenlose Probe endpoints sind ebenfalls verfügbar: GET /health, GET /pricing und GET /.well-known/x402. /pricing zeigt für jede Solana RPC-Methode raw weight, weight nach minimum charge und USD-Preis.

Bedeutung für Micropayments

Eine wichtige Bedeutung der x402-Unterstützung ist, dass APIs und RPC nahezu auf Micropayment-Granularität abgerechnet werden können.
Bisher wurde Infrastruktur wie RPC typischerweise über Monatspläne, feste Quoten, Prepaid Credits oder nachträgliche Rechnungen angeboten. Nutzer reservieren dadurch oft mehr Kapazität als sie wirklich benötigen. Ungenutzte Credits verfallen, während plötzliche Lastspitzen Quotenlimits oder Zusatzkäufe auslösen. Besonders bei Workloads wie KI-Agenten und Bots, die nur bei Bedarf viel lesen und danach fast nichts nutzen, ist diese Lücke groß.
Mit Mechanismen wie x402 kann ein Dienst pro API request, Datenabruf oder Operation einen Preis anzeigen, und der Client zahlt nur für das Benötigte. Auch ERPCs Pricing Model basiert darauf, den raw weight jeder Methode mit 0.000001 USD zu multiplizieren. Der aktuelle endpoint wendet einen floor von 0.001 USD auf den ganzen Request an, um dem minimum settlement amount des facilitators zu entsprechen, doch die Basiseinheit ist als 1 token = 0.000001 USD granular gestaltet.
Mit traditionellen Kartenzahlungen ist das nicht realistisch. Bei 0,1 Cent pro Request oder kleineren Beträgen können Gebühren und Freigabeprozesse den Zahlungsbetrag selbst übersteigen. Stablecoin-Zahlungen und internet-native payment protocols wie x402 machen es praktikabel, solche kleinen Zahlungen direkt in API request / response flows einzubetten.
Batch JSON-RPC requests können außerdem mehrere read-only calls in einem Request bündeln, sodass der floor nur einmal auf den Gesamt-weight angewendet wird. Mehrere leichte Statusmethoden können so gemeinsam aufgerufen werden, ohne für jeden call separat einen minimum charge zu zahlen.
ERPCs x402-Unterstützung ist damit ein Schritt von „zuerst Vertrag, dann RPC nutzen“ hin zu „direkt für die gelesenen Daten zahlen“. Diese Zahlungsgranularität wird wichtig, wenn KI-Agenten viele externe Services kontextabhängig kombinieren.

Warum KI-Agent-Zahlungen wichtig sind

KI-Agenten beginnen, autonom zu schreiben, zu recherchieren, zu programmieren, zu überwachen, Tradinggelegenheiten zu finden und Infrastruktur zu betreiben. Diese Aufgaben benötigen oft im richtigen Moment bezahlte externe Ressourcen: APIs, Datensätze, RPC endpoints, Storage, Compute, Analytics Services, Authentifizierung und mehr.
Für Menschen ist es normal, vor der Nutzung eines Dienstes einen SaaS-Vertrag zu unterzeichnen, eine Rechnung zu prüfen und eine API key auszustellen. Wenn ein KI-Agent aber tausende oder zehntausende kleine Entscheidungen trifft, blockiert menschliche Genehmigung für jeden Vertrag oder jede Zahlung den Ablauf.
Das nächste Modell ist, dass ein KI-Agent liest, dass bestimmte Daten 0.001 USD kosten oder eine Berechnung einen bestimmten Betrag erfordert, innerhalb von Budget, Berechtigungen und Policies des Eigentümers zahlt, das Ergebnis erhält und den receipt protokolliert. Entscheidend ist nicht, dass KI unbegrenzt zahlt, sondern dass notwendige Zahlungen innerhalb von spending limits, erlaubten Zwecken und genehmigten Service scopes automatisiert werden.
Das ist nicht nur automatisierter Checkout. Es ist Zahlungsinfrastruktur für Maschinen: KI-Agenten, Bots, APIs, IoT devices, Roboter und Monitoringsysteme tauschen Wert aus, wenn ein Dienst gebraucht wird. In Zukunft wird Agent-to-Agent / Machine-to-Machine billing natürlich: ein Agent bezahlt einen anderen für eine Aufgabe, KI bezahlt pro Daten-API-call und Monitoring bezahlt nur bei Anomalien für hochpräzise Analyse.

Agentic Commerce wird ein großer Markt

McKinsey schätzt, dass agentic commerce bis 2030 weltweit zwischen 3 und 5 Billionen US-Dollar orchestrieren könnte. KI wird bereits zum Einstiegspunkt für Suche, Vergleich, Empfehlungen und Entscheidungsunterstützung. Mit reifender identity, authorization und payments werden KI-Agenten voraussichtlich tiefer in Kauf- und Serviceausführung eingebunden.
Gleichzeitig zeigen internet-native payment protocols wie x402 bereits großskalige transaction activity und experimentelle Use Cases. Die offizielle x402-Seite veröffentlicht Live-Metriken zu transactions, volume, buyers und sellers der letzten 30 Tage. Circle erwähnte, dass x402 in den ersten Monaten mehr als 100 Millionen US-Dollar an Zahlungen verarbeitete. Chainalysis analysierte zudem, dass x402 agentic payments auf Base bis Q1 2026 mehr als 100 Millionen transactions überschritten.
Diese Zahlen zeigen, dass x402 nicht nur ein Konzept ist, sondern bereits in eine Phase hochfrequenter machine payment experimentation und Nutzung eingetreten ist. Der Markt ist noch früh, doch Infrastruktur für request-granulare Zahlungen von APIs, Daten, Compute und digitalen Services entsteht schnell.

Solana RPC passt natürlich zu Agentic Payments

Für Solana-Anwendungen ist RPC kein Nebenfeature. Balance checks, slot queries, account reads, program account searches, transaction status checks, block retrieval und Echtzeitmonitoring hängen alle von RPC ab.
Wenn KI-Agenten beginnen, Solana state zu prüfen, Entscheidungen zu treffen und Aktionen auszuführen, wird RPC fast zu ihren Augen und Händen. Der Agent entscheidet, welches account geprüft, welches program abgefragt, wann erneut geprüft und wie tief gesucht wird.
In diesem Umfeld passen Monatsverträge und feste Quoten nicht immer zu feingranularer Nutzung. Wenn ein Agent genau die benötigte RPC-Methode im benötigten Moment aufrufen und direkt für diesen Request zahlen kann, kann er externe Services flexibler kombinieren.
ERPCs x402-Unterstützung ist ein produktionsreifer erster Schritt in diese Welt. KI-Agenten und Programme können Solana RPC nicht nur als vorab gebuchten festen Dienst betrachten, sondern auch als service primitive, das sie on demand bezahlen und nutzen.

Was das für Entwickler bedeutet

Für Entwickler bietet x402-enabled ERPC eine reale Umgebung zum Testen von agentic workflows und pay-per-use API designs.
Ein Research Agent, der Solana account state prüfen muss, kann zunächst einen RPC request an ERPC senden. Wenn Zahlung erforderlich ist, liest der Agent den Betrag aus der 402 response, bestätigt das Budget, erstellt das USDC-Stablecoin-Payment-Payload und sendet den Request erneut. ERPC verifiziert die Zahlung und gibt das RPC-Ergebnis zurück. Der Agent kann Ergebnis und receipt im task log speichern.
Dieser Ablauf kann auch von Bots, Monitoringsystemen, data collection pipelines, MCP servers und AI agent runtimes genutzt werden. Entwickler können Service Composition auf Ebene von task, API call oder data request testen, statt nur auf monatliche Fixverträge angewiesen zu sein.
Auch für Serviceanbieter macht x402 API monetization granularer. Kleine APIs, Spezialdaten, kurze Compute Jobs und einzelne Analyseergebnisse können in Einheiten bepreist werden, die traditionelle Zahlungssysteme nur schwer unterstützen.

Frühe Einführung und reale Umsetzung

ELSOUL LABO und Validators DAO verbessern kontinuierlich die Infrastruktur für Solana-Anwendungen und Validator Operations über Solana RPC, Geyser gRPC, Shredstream, SLV, SLV AI, Validators Solutions und das AS200261 Solana-specialized data center.
KI-Agent-Zahlungen passen natürlich zu dieser Arbeit. Wenn KI Entwicklung und Betrieb unterstützt, benötigte Daten oder Compute auswählt und bei Bedarf bezahlt, wird Infrastruktur mehr als ein von Menschen gebuchter Dienst. Sie wird zu Primitives, die Agenten autonom kombinieren.
Durch die frühe Einführung internet-native payment protocols wie x402 und die Bereitstellung über einen konkreten Solana RPC Use Case treiben wir die reale Umsetzung von KI-Agent-Zahlungen voran.
Das ist nicht nur eine Geschichte über die Zukunft. Der endpoint gibt bereits HTTP 402 zurück, akzeptiert USDC-Stablecoin-Payment, führt Solana RPC aus und gibt einen receipt zurück.
ERPC wird seine Leistung als Solana-specialized infrastructure weiter verbessern und zugleich payment-, authorization- und execution layers erforschen und entwickeln, die für KI-Agenten und autonome Systeme einfacher nutzbar sind.

Nutzungsumfang

Dieser endpoint dient dazu, ERPC Solana RPC usage fees über x402 zu bezahlen. Er bietet keine crypto asset exchange-, brokerage-, custody- oder wallet services.

Kontakt

Für Fragen zu ERPC, x402-enabled Solana RPC, Solana RPC, Geyser gRPC, Shredstream und Infrastruktur für KI-Agenten kontaktieren Sie uns bitte über das ERPC Dashboard.