Was ist ein RPC auf Solana?

RPC steht für Remote Procedure Call — die Schnittstelle, über die Wallets, dApps und Bots mit dem Solana-Netzwerk sprechen. Ein RPC-Node beantwortet Abfragen wie Kontostände und Transaktionshistorien und leitet neue Transaktionen ins Netzwerk weiter.

Was ist der Unterschied zwischen einem RPC-Node und einem Validator?

Beide laufen mit derselben Node-Software. Ein Validator nimmt am Konsens teil und stimmt über Blöcke ab. Ein RPC-Node läuft typischerweise ohne Voting und ist darauf ausgelegt, Abfragen zu beantworten — beides auf einer Maschine gilt wegen der Ressourcenlast als schlechte Praxis.

Welchen RPC-Endpoint nutzt meine Wallet?

Jede Wallet ist mit einem oder mehreren RPC-Endpoints vorkonfiguriert, meist bei einem kommerziellen Provider. Du merkst davon nichts — aber jeder Kontostand, den du siehst, kommt über diesen Endpoint. Manche Wallets erlauben es, einen eigenen Endpoint einzutragen.

Sind öffentliche RPC-Endpoints kostenlos?

Ja, aber streng rate-limitiert. Der öffentliche Mainnet-Endpoint erlaubt laut Solana-Doku etwa 100 Requests pro 10 Sekunden und IP. Für Tests reicht das, für produktive Apps nicht — die laufen über dedizierte oder geteilte Provider-Endpoints.

Kann ein RPC-Provider sehen, was ich mache?

Ja. Der Betreiber deines Endpoints sieht deine IP-Adresse und jede Abfrage — also welche Adressen du beobachtest und welche Transaktionen du sendest. Wer das nicht will, betreibt einen eigenen Node oder wählt Provider nach deren Datenschutz-Praxis aus.

Solana RPC erklärt: Nodes, Endpoints, Provider — wie Wallets mit der Chain sprechen

Wenn deine Wallet einen Kontostand anzeigt oder du eine Transaktion abschickst, spricht die App nicht direkt mit der Blockchain — sie spricht mit einem RPC-Node. RPC steht für Remote Procedure Call: die Schnittstelle, über die Programme Daten von Solana abfragen und Transaktionen einreichen. Jede Wallet, jede dApp und jeder Bot braucht dafür einen RPC-Endpoint — eine URL, hinter der ein solcher Node läuft.

Kurzantwort: Ein Solana-RPC-Node ist ein Server, der den aktuellen Zustand der Chain vorhält und Anfragen beantwortet: Kontostände, Transaktionen, Programm-Daten. Er läuft mit derselben Software wie ein Validator, nimmt aber typischerweise nicht am Konsens teil. Wallets und Apps verbinden sich über einen Endpoint (eine URL) mit ihm — öffentlich und rate-limitiert oder dediziert über kommerzielle Provider.

In einfachen Worten: Der RPC-Node ist die Telefonzentrale zwischen dir und Solana. Deine Wallet ruft dort an, fragt “Wie viel SOL liegt auf dieser Adresse?” — und reicht deine unterschriebenen Transaktionen ans Netzwerk weiter.

Was ein RPC-Node ist

Ein RPC-Node ist ein vollwertiger Solana-Node, der die Chain live mitverfolgt und eine JSON-RPC-Schnittstelle nach außen anbietet. Über diese Schnittstelle laufen Methoden wie getBalance (Kontostand einer Adresse), getAccountInfo (Daten eines Accounts), getTransaction (Details einer Transaktion) und sendTransaction (eine signierte Transaktion einreichen).

Der Endpoint ist schlicht die Adresse, unter der dieser Node erreichbar ist — zum Beispiel https://api.mainnet.solana.com. Wenn du in Solscan eine Transaktion nachschlägst, passiert im Hintergrund dasselbe: Ein Explorer ist am Ende eine Oberfläche über RPC-Daten (plus eigene Indizes).

RPC-Node vs. Validator: gleiche Software, anderer Job

Ein RPC-Node und ein Validator laufen mit derselben Node-Software. Der Unterschied liegt in der Rolle:

Ein Validator nimmt am Konsens teil: Er stimmt über Blöcke ab und produziert selbst welche, wenn er an der Reihe ist. Wie du als Staker einen guten auswählst, erklärt der Artikel zur Validator-Auswahl.
Ein RPC-Node läuft laut Anza-Dokumentation typischerweise mit dem Flag --no-voting — er verfolgt die Chain, stimmt aber nicht ab. Seine Ressourcen gehen ins Beantworten von Abfragen.

Beides auf einer Maschine gilt als schlechte Praxis: Konsens-Arbeit und Abfrage-Last konkurrieren um dieselben Ressourcen. Im Standard-Setup lauscht die RPC-Schnittstelle auf Port 8899.

Manche RPC-Nodes halten zusätzlich die komplette Transaktionshistorie vor (“full history”) — das braucht deutlich mehr Speicher als der Normalbetrieb, bei dem ältere Daten aus dem lokalen Ledger fallen.

Warum jede Wallet einen Endpoint nutzt

Eine Wallet speichert deine Schlüssel — mehr nicht. Alles, was sie dir anzeigt, muss sie irgendwo abfragen: Kontostände, Token-Bestände, NFT-Bilder, Transaktionsstatus. Diese Daten kommen über den RPC-Endpoint, mit dem die Wallet vorkonfiguriert ist. Auch der Versand läuft darüber: Die Wallet signiert lokal und übergibt die Transaktion per sendTransaction an den RPC-Node, der sie an den aktuell zuständigen Block-Produzenten weiterleitet.

Das heißt praktisch: Zwischen dir und der Chain steht immer ein Server, den jemand betreibt. Welcher das ist, entscheidet der Wallet-Anbieter — die meisten großen Wallets nutzen kommerzielle RPC-Provider im Hintergrund. Manche Wallets lassen dich in den Einstellungen einen eigenen Endpoint eintragen.

Öffentliche vs. dedizierte Endpoints

Grob gibt es drei Stufen:

Öffentliche Endpoints: Solana stellt für jedes Netzwerk einen bereit — für das Mainnet ist das https://api.mainnet.solana.com (lange unter dem Namen api.mainnet-beta.solana.com bekannt; beide Adressen antworten). Kostenlos, aber streng rate-limitiert und ohne Verfügbarkeits-Garantie. Gut zum Ausprobieren, ungeeignet als Rückgrat einer App.
Geteilte Provider-Endpoints: Kommerzielle RPC-Provider betreiben Node-Flotten und verkaufen Zugang über API-Keys — mit höheren Limits, Uptime-Zusagen und oft Zusatz-APIs, die über den RPC-Standard hinausgehen. Das ist die Kategorie, in der die meisten Wallets und dApps unterwegs sind.
Dedizierte Nodes oder eigener Betrieb: Wer maximale Kontrolle braucht — etwa Indexer oder latenzkritische Anwendungen — mietet einen exklusiven Node oder betreibt selbst einen. Das kostet spürbar Hardware und Betreuung, entfernt aber den Mittelsmann.

Provider unterscheiden sich in Preis, Latenz, Regionen und Zusatzfunktionen — eine Wertung sparen wir uns hier bewusst: Die Kategorie ist wichtiger als der Name.

Rate-Limits: die Zahlen des öffentlichen Endpoints

Für den öffentlichen Mainnet-Endpoint dokumentiert Solana (Stand Juli 2026) unter anderem diese Limits — mit dem ausdrücklichen Hinweis, dass sie sich ändern können:

Maximal 100 Requests pro 10 Sekunden pro IP
Maximal 40 Requests pro 10 Sekunden pro IP für eine einzelne RPC-Methode
Maximal 40 gleichzeitige Verbindungen pro IP
Maximal 100 MB Datenvolumen pro 30 Sekunden

Zum Vergleich: Eine einzige Wallet-Oberfläche mit ein paar Token-Konten feuert beim Öffnen schnell ein Dutzend Abfragen ab. Für eine App mit vielen Nutzern sind die öffentlichen Limits deshalb in Minuten erschöpft — der eigentliche Grund, warum es den Provider-Markt gibt.

Datenschutz: Dein RPC sieht dich

Ein Punkt, der selten ausgesprochen wird: Der Betreiber deines RPC-Endpoints sieht deine IP-Adresse und jede einzelne Abfrage. Daraus lässt sich einiges ablesen:

Welche Wallet-Adressen du regelmäßig abfragst — also vermutlich deine eigenen
Welche Token und Programme dich interessieren
Wann du aktiv bist und von wo (IP-Geolokation)
Welche Transaktionen du sendest, bevor sie bestätigt sind

Das ist kein Vorwurf an einzelne Anbieter, sondern eine strukturelle Eigenschaft des Modells: Wer die Anfragen beantwortet, kennt die Anfragen. Wer das minimieren will, hat drei Hebel — einen eigenen Node betreiben, Provider nach deren Datenschutz-Erklärung auswählen oder die eigene IP (etwa per VPN) vom Wallet-Verhalten entkoppeln.

WebSockets und Subscriptions in Kürze

Neben dem Frage-Antwort-Muster per HTTP bietet die RPC-Schnittstelle einen WebSocket-Kanal: Statt ständig nachzufragen (“Polling”), abonnierst du Ereignisse und bekommst sie gepusht. Die Solana-Doku listet dafür Methoden wie accountSubscribe (ein Account ändert sich), logsSubscribe (Programm-Logs), signatureSubscribe (eine bestimmte Transaktion wird bestätigt) und slotSubscribe (neue Slots).

Genau so zeigt deine Wallet den Haken “bestätigt” an, ohne im Sekundentakt nachzufragen. Für alles Ereignisgetriebene — Preis-Updates, Bot-Trigger, Live-Dashboards — sind Subscriptions der saubere Weg.

Wohin sich RPC entwickelt

Zwei Richtungen sind aktuell sichtbar. Erstens: Die Solana Foundation hat im Frühjahr 2026 RPC 2.0 angekündigt — einen überarbeiteten Read-Layer, der Latenz, Kosten und Query-Ausdruckskraft verbessern und Teile der bisherigen Provider-Sonderwege standardisieren soll. Eine finale Spezifikation steht noch aus.

Zweitens tut sich etwas am Transport: Provider modernisieren die Verbindungsschicht unterhalb der API — etwa mit HTTP/3 und QUIC, was vor allem auf mobilen und instabilen Verbindungen spürbar wird, ohne dass sich an den RPC-Methoden selbst etwas ändert.

Auf einen Blick

RPC ist die Schnittstelle zwischen Apps und Solana — jede Wallet nutzt einen Endpoint.
Ein RPC-Node läuft mit Validator-Software, aber typischerweise ohne Konsens-Teilnahme.
Öffentliche Endpoints sind kostenlos und eng rate-limitiert; produktive Apps laufen über Provider oder eigene Nodes.
Der RPC-Betreiber sieht IP und Abfragen — ein oft übersehener Datenschutz-Punkt.
WebSocket-Subscriptions ersetzen Polling; RPC 2.0 soll den Read-Layer modernisieren.

Hinweis: Keine Finanzberatung.