ERPC

Solana RPC endpoint FAQ

Vragen over facturering, het Free-abonnement, betalingen en 401- of 429-fouten staan bij Zo begint u.
Vragen over afstand, snelheid en regio's staan bij Latentie en regio's.

V. Wat is een Solana RPC endpoint en hoe krijg ik er een met ERPC?

Een Solana RPC endpoint is de URL waarmee uw app, trading bot, wallet of analytics-systeem JSON-RPC requests naar Solana stuurt en chain data ontvangt. Met ERPC krijgt u een beheerd Solana endpoint dat HTTP en WebSocket via hetzelfde wereldwijde proxynetwerk ondersteunt.
Open of maak uw ERPC-account in het ERPC Web Dashboard, kopieer uw API key en voeg die toe aan de api-key-parameter van de endpoint-URL:
endpoint
https://edge.erpc.global?api-key=<YOUR_API_KEY>
Gebruik dezelfde API key-indeling voor WebSocket-abonnementen:
endpoint
wss://edge.erpc.global?api-key=<YOUR_API_KEY>

V. Kan ik WebSocket gebruiken?

Ja, WebSocket wordt ondersteund. Het werkt via hetzelfde endpoint, waardoor u efficiënt realtime gegevensupdates kunt ontvangen.

V. In welke regio's bevinden zich uw nodes?

We beheren momenteel nodes in de volgende regio's:
  • Frankfurt (FRA)
  • Amsterdam (AMS)
  • Londen (LON)
  • New York (NY)
  • Tokyo (TY)
  • Singapore (SGP)
ERPC's RPC-endpoints worden aangedreven door Cloudflare en maken gebruik van een wereldwijd netwerk van meer dan 300 edge-servers. Verzoeken worden automatisch gerouteerd via de dichtstbijzijnde Cloudflare edge-locatie en vervolgens doorgestuurd naar de optimale ERPC-node, wat het kortst mogelijke netwerkpad en consistent lage latentie van overal ter wereld garandeert.
Deze architectuur elimineert de impact van geografische afstand of complexe routering en biedt altijd geoptimaliseerde connectiviteit naar Solana-nodes met maximale stabiliteit en prestaties.
ERPC Web Dashboard: ERPC Web Dashboard

V. Waarom ontbreken oudere Solana-blokken of -transacties, of waarom zie ik -32011?

Met uitzondering van getTransactionsForAddress wordt een request zonder history=true beantwoord vanuit het recente bereik dat elke node bijhoudt, waardoor oudere blokken of transacties afhankelijk van de methode de fout This request needs history access. Add history=true to the endpoint URL. (code -32011), null of een leeg resultaat kunnen teruggeven. Voeg history=true toe aan de URL https://edge.erpc.global van een HTTP-request om ze op te vragen.
Stuur de API key mee in de URL:
endpoint
https://edge.erpc.global?api-key=<YOUR_API_KEY>&history=true
Of stuur deze mee in de header Authorization: Bearer <YOUR_API_KEY> en houd history=true in de URL:
endpoint
https://edge.erpc.global?history=true
Het ophalen van oudere blokken of transacties kan veel langer duren dan een gewoon request, in sommige gevallen seconden. History Access is een aparte optie die dit ophalen scheidt van gewone requests, zodat gewone requests snel blijven. Met uitzondering van getTransactionsForAddress in de modus "full" kost elke aanroep die door History Access wordt beantwoord 640 tokens meer dan de normale prijs van de methode.
Gratis toewijzingen, waaronder die van het Free-abonnement, hebben een limiet voor History Access. Het Free-abonnement is beperkt tot één request met History Access per 10 seconden.
Zonder history=true geeft getTransactionsForAddress met transactionDetails ingesteld op "full" dezelfde fout -32011 terug, ongeacht de leeftijd van de data; de ERPC-documentatie vermeldt de prijs.
ERPC-documentatie: RPC

V. Mijn Shreds- / getBlock-output ziet er ineens kapot uit of geeft -32015 terug — wat is er veranderd?

Solana Transaction v1 (SIMD-0385) is op 15 september 2026, bij epoch 1035, live gegaan op het Solana-mainnet. De wire-layout van een v1-transactie begint met de versieprefix-byte 0x81, de handtekeningen komen na het bericht, en er is geen legacy lengteprefix meer.
Als u ShredStream- of UDP Forwarding-entries zelf decodeert, leest een bincode- of solana-entry-decoder ouder dan versie 4.2 die 0x81-byte ten onrechte als aantal handtekeningen, wat zich uit als een EOF-fout, een compact-length-overflow of een "invalid message version"-fout. Geyser gRPC-gebruikers die raw transacties deserialiseren met crates van vóór 4.2 lopen tegen hetzelfde probleem aan. RPC-aanroepen van getBlock en getTransaction met maxSupportedTransactionVersion: 0 geven -32015 Transaction version (1) is not supported by the requesting client terug; getTransactionsForAddress in de modus full meldt dezelfde fout op elke getroffen rij. Dit raakt u niet als u de geparste JSON-responses van ERPC al met versie 1 ingesteld leest.
Zet maxSupportedTransactionVersion op 1 in het options-object — de tweede parameter van getBlock en getTransaction, en ook in de options van getTransactionsForAddress:
json
{
  "maxSupportedTransactionVersion": 1
}
Werk de Solana Stream SDK bij naar 2.0.0: Rust solana-stream-sdk op crates.io, of npm @validators-dao/solana-stream-sdk en @validators-dao/solana-shreds-client. Werk @validators-dao/solana-entry-decoder apart bij naar 2.5.0. 1.4.0 en entry-decoder 2.4.0 ondersteunen v1 niet. Eigen Rust-decoders zouden moeten overstappen op solana-entry 4.2.x.

V. Welke methodes ondersteunt Unlimited Endpoint?

Unlimited Endpoints zijn bedoeld voor standaard Solana RPC-aanroepen met lage latentie. Ondersteunde methodes zijn:
  • getSlot
  • getBlockHeight
  • getLatestBlockhash
  • getBalance
  • getAccountInfo
  • getMultipleAccounts
  • getTransaction
  • sendTransaction
  • simulateTransaction
  • getSignatureStatuses
  • getRecentPrioritizationFees
  • getHealth
  • getVersion
  • getEpochInfo
  • getBlock
Gebruik https://edge.erpc.global?api-key=<YOUR_API_KEY> voor andere methodes.

V. Transacties op mijn dedicated node hebben een laag slagingspercentage

Het transactiesuccespercentage en de snelheid worden aanzienlijk beïnvloed door een mechanisme genaamd QoS (Quality of Service). We bieden QoS specifiek voor dedicated nodes. Raadpleeg voor meer details de onderstaande pagina's of neem contact met ons op via ons ERPC Web Dashboard.

V. Hoe kan ik de laagst mogelijke latentie bereiken?

De ideale setup voor minimale latentie is een dedicated RPC-node gecombineerd met onze Bare-Metal servers. Beide delen hetzelfde netwerk, wat privécommunicatie op nulafstand mogelijk maakt met pinglatencies rond 0,1ms.
Neem contact met ons op via het ERPC Web Dashboard voor meer details.
ERPC Web Dashboard
VorigeSnelheidsvergelijkingVolgendeEdge RPC / Ethereum / Snelstart