ERPC

FAQ - Solana RPC Endpoint mit ERPC

Fragen zu Abrechnung, Free-Plan, Zahlung sowie 401- und 429-Fehlern finden Sie unter So starten Sie.
Fragen zu Entfernung, Geschwindigkeit und Regionen finden Sie unter Latenz und Regionen.

Q. Was ist ein Solana RPC Endpoint und wie bekomme ich einen mit ERPC?

Ein Solana RPC Endpoint ist die URL, über die Ihre App, Ihr Trading-Bot, Ihre Wallet oder Ihr Analysesystem JSON-RPC-Anfragen an Solana sendet und Chain-Daten empfängt. Mit ERPC erhalten Sie einen verwalteten Solana Endpoint, der HTTP- und WebSocket-Zugriff über dasselbe globale Proxy-Netzwerk unterstützt.
Erstellen oder öffnen Sie zunächst Ihr ERPC-Konto im ERPC Web Dashboard, kopieren Sie Ihren API key und fügen Sie ihn dem Parameter api-key der Endpoint-URL hinzu:
endpoint
https://edge.erpc.global?api-key=<YOUR_API_KEY>
Verwenden Sie dasselbe API-key-Format für WebSocket-Abonnements:
endpoint
wss://edge.erpc.global?api-key=<YOUR_API_KEY>

Q. Kann ich WebSocket verwenden?

Ja, WebSocket wird unterstützt. Es funktioniert über denselben Endpoint, sodass Sie Echtzeit-Updates effizient empfangen können.

Q. In welchen Regionen liegen Ihre Knoten?

Aktuell betreiben wir Knoten in den folgenden Regionen:
  • Frankfurt (FRA)
  • Amsterdam (AMS)
  • London (LON)
  • New York (NY)
  • Tokio (TY)
  • Singapur (SGP)
Die RPC endpoints von ERPC werden über Cloudflare bereitgestellt und nutzen ein globales Netzwerk mit mehr als 300 Edge-Servern. Anfragen werden automatisch über den nächstgelegenen Cloudflare Edge-Standort geleitet und anschließend an den optimalen ERPC Node weitergegeben, damit der Netzwerkpfad möglichst kurz bleibt und die Latenz weltweit niedrig ist.
Diese Architektur reduziert die Auswirkungen geografischer Entfernung und komplexer Routen und bietet optimierte Verbindungen zu Solana Nodes mit hoher Stabilität und Performance.
ERPC Web Dashboard: ERPC Web Dashboard

Q. Warum fehlen ältere Solana-Blöcke oder -Transaktionen, oder warum sehe ich -32011?

Mit Ausnahme von getTransactionsForAddress wird eine Anfrage ohne history=true aus dem aktuellen Bereich beantwortet, den jeder Knoten vorhält, sodass ältere Blöcke oder Transaktionen je nach Methode den Fehler This request needs history access. Add history=true to the endpoint URL. (Code -32011), null oder ein leeres Ergebnis zurückgeben können. Hängen Sie history=true an die URL https://edge.erpc.global einer HTTP-Anfrage an, um sie abzurufen.
Senden Sie den API key in der URL:
endpoint
https://edge.erpc.global?api-key=<YOUR_API_KEY>&history=true
Oder senden Sie ihn im Header Authorization: Bearer <YOUR_API_KEY> und behalten Sie history=true in der URL bei:
endpoint
https://edge.erpc.global?history=true
Der Abruf älterer Blöcke oder Transaktionen kann deutlich länger dauern als eine reguläre Anfrage, in manchen Fällen mehrere Sekunden. History Access ist eine separate Option, die diese Abrufe von regulären Anfragen trennt, damit reguläre Anfragen schnell bleiben. Mit Ausnahme von getTransactionsForAddress im Modus "full" kostet jeder von History Access beantwortete Aufruf 640 Token mehr als der reguläre Preis der Methode.
Kostenlose Kontingente, einschließlich des Kontingents des Free-Plans, haben ein Limit für History Access. Der Free-Plan ist auf eine Anfrage mit History Access pro 10 Sekunden begrenzt.
Ohne history=true gibt getTransactionsForAddress mit auf "full" gesetztem transactionDetails denselben Fehler -32011 zurück, unabhängig vom Alter der Daten; den Preis nennt die ERPC-Dokumentation.
ERPC-Dokumentation: RPC

Q. Meine Shreds- / getBlock-Ausgabe sieht plötzlich kaputt aus oder liefert -32015 — was hat sich geändert?

Solana Transaction v1 (SIMD-0385) ist am 15. September 2026 in Epoche 1035 auf dem Solana-Mainnet live gegangen. Das Wire-Layout einer v1-Transaktion beginnt mit dem Versionspräfix-Byte 0x81, die Signaturen folgen nach der Message, und ein Legacy-Längenpräfix gibt es nicht mehr.
Wenn Sie ShredStream- oder UDP-Forwarding-Entries selbst dekodieren, liest ein bincode- oder solana-entry-Decoder unter Version 4.2 dieses 0x81-Byte fälschlich als Signaturanzahl — das zeigt sich als EOF-Fehler, als Compact-Length-Overflow oder als Fehler "invalid message version". Geyser-gRPC-Nutzer, die Raw-Transaktionen mit Crates vor 4.2 deserialisieren, haben dasselbe Problem. RPC-Aufrufe von getBlock und getTransaction mit maxSupportedTransactionVersion: 0 liefern -32015 Transaction version (1) is not supported by the requesting client; getTransactionsForAddress im Modus full meldet denselben Fehler für jede betroffene Zeile. Sie sind nicht betroffen, wenn Sie bereits die geparsten JSON-Antworten von ERPC mit gesetzter Version 1 lesen.
Setzen Sie maxSupportedTransactionVersion im Options-Objekt auf 1 — im zweiten Parameter von getBlock und getTransaction sowie in den Options von getTransactionsForAddress:
json
{
  "maxSupportedTransactionVersion": 1
}
Aktualisieren Sie das Solana Stream SDK auf 2.0.0: Rust solana-stream-sdk auf crates.io oder npm @validators-dao/solana-stream-sdk und @validators-dao/solana-shreds-client. Aktualisieren Sie @validators-dao/solana-entry-decoder separat auf 2.5.0. 1.4.0 und entry-decoder 2.4.0 unterstützen v1 nicht. Eigene Rust-Decoder sollten auf solana-entry 4.2.x umsteigen.

Q. Welche Methoden unterstützt Unlimited Endpoint?

Unlimited Endpoints sind für latenzarme Standardaufrufe der Solana RPC gedacht. Unterstützte Methoden sind:
  • getSlot
  • getBlockHeight
  • getLatestBlockhash
  • getBalance
  • getAccountInfo
  • getMultipleAccounts
  • getTransaction
  • sendTransaction
  • simulateTransaction
  • getSignatureStatuses
  • getRecentPrioritizationFees
  • getHealth
  • getVersion
  • getEpochInfo
  • getBlock
Verwenden Sie für andere Methoden https://edge.erpc.global?api-key=<YOUR_API_KEY>.

Q. Transaktionen auf meinem dedizierten Node haben eine geringe Erfolgsrate

Transaktionserfolgsraten und Geschwindigkeit werden stark durch QoS (Quality of Service) beeinflusst. Wir bieten QoS speziell für dedizierte Nodes. Weitere Informationen finden Sie auf den folgenden Seiten oder über unser ERPC Web Dashboard.

Q. Wie kann ich die niedrigstmögliche Latenz erreichen?

Das ideale Setup für minimale Latenz ist ein dedizierter RPC Node kombiniert mit unseren Bare-Metal-Servern. Beide teilen dasselbe Netzwerk und ermöglichen private Zero-Distance-Kommunikation mit Ping-Latenzen um 0,1 ms.
Bitte kontaktieren Sie uns über das ERPC Web Dashboard für weitere Details.
ERPC Web Dashboard
ZurückGeschwindigkeitsvergleichWeiterEdge RPC / Ethereum / Schnellstart