---
title: "FAQ - Solana RPC Endpoint mit ERPC"
description: "Antworten zu Solana RPC, Solana RPC Endpoint, WebSocket, Regionen, Latenz und API key bei ERPC."
canonical: "https://erpc.global/de/faq/rpc/general/"
locale: "de"
---

# FAQ - Solana RPC Endpoint mit ERPC

Fragen zu Abrechnung, Free-Plan, Zahlung sowie 401- und 429-Fehlern finden Sie unter [So starten Sie](https://erpc.global/de/faq/how-to-start/general/).

Fragen zu Entfernung, Geschwindigkeit und Regionen finden Sie unter [Latenz und Regionen](https://erpc.global/de/faq/latency/general/).

## 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](https://dashboard.erpc.global/de), kopieren Sie Ihren API key und fügen Sie ihn dem Parameter `api-key` der Endpoint-URL hinzu:

```text
https://edge.erpc.global?api-key=<YOUR_API_KEY>
```

Verwenden Sie dasselbe API-key-Format für WebSocket-Abonnements:

```text
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](https://dashboard.erpc.global/de)

## 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:

```text
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:

```text
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](https://erpc.global/de/doc/rpc/general/)

## 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.

- [Migrationsleitfaden](https://github.com/ValidatorsDAO/solana-stream/blob/main/docs/transaction-v1.md)
- [Release Notes zum SDK 2.0.0](https://github.com/ValidatorsDAO/solana-stream/releases/tag/v2.0.0)
- [Solana Stream SDK-Repository](https://github.com/ValidatorsDAO/solana-stream)
- [SIMD-0385: Transaction v1 – der Vorschlag](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md)
- [Solana-Upgrade: Larger Transaction Sizes](https://solana.com/upgrades/larger-transaction-sizes)
- [Solana-RPC-Dokumentation: getBlock](https://solana.com/docs/rpc/http/getblock)
- [Solana-RPC-Dokumentation: getTransaction](https://solana.com/docs/rpc/http/gettransaction)
- [ERPC-Dokumentation: ShredStream-Schnellstart](https://erpc.global/de/doc/shredstream/quickstart/)
- [ERPC-Dokumentation: Geyser gRPC-Schnellstart](https://erpc.global/de/doc/geyser-grpc/quickstart/)
- [ERPC-Dokumentation: RPC](https://erpc.global/de/doc/rpc/general/)

## 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.

- [QoS für dedizierte Nodes (ERPC)](https://erpc.global/de/staked-connection/)
- [Leitfaden zu Stake-weighted QoS auf Solana](https://solana.com/developers/guides/advanced/stake-weighted-qos)

## 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](https://erpc.global/de/baremetal/). 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](https://dashboard.erpc.global/de)
