--- title: "Solana RPC endpoint FAQ" description: "Lees wat een Solana RPC endpoint is, hoe u met ERPC een Solana endpoint krijgt en hoe u RPC-gebruik oplost." canonical: "https://erpc.global/nl/faq/rpc/general/" locale: "nl" --- # Solana RPC endpoint FAQ Vragen over facturering, het Free-abonnement, betalingen en 401- of 429-fouten staan bij [Zo begint u](https://erpc.global/nl/faq/how-to-start/general/). Vragen over afstand, snelheid en regio's staan bij [Latentie en regio's](https://erpc.global/nl/faq/latency/general/). ## 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](https://dashboard.erpc.global/nl), kopieer uw API key en voeg die toe aan de `api-key`-parameter van de endpoint-URL: ```text https://edge.erpc.global?api-key= ``` Gebruik dezelfde API key-indeling voor WebSocket-abonnementen: ```text wss://edge.erpc.global?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](https://dashboard.erpc.global/nl) ## 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: ```text https://edge.erpc.global?api-key=&history=true ``` Of stuur deze mee in de header `Authorization: Bearer ` en houd `history=true` in de URL: ```text 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](https://erpc.global/nl/doc/rpc/general/) ## 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`. - [Migratiegids](https://github.com/ValidatorsDAO/solana-stream/blob/main/docs/transaction-v1.md) - [Release notes van 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 – het voorstel](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-documentatie: getBlock](https://solana.com/docs/rpc/http/getblock) - [Solana RPC-documentatie: getTransaction](https://solana.com/docs/rpc/http/gettransaction) - [ERPC-documentatie: ShredStream-snelstart](https://erpc.global/nl/doc/shredstream/quickstart/) - [ERPC-documentatie: Geyser gRPC-snelstart](https://erpc.global/nl/doc/geyser-grpc/quickstart/) - [ERPC-documentatie: RPC](https://erpc.global/nl/doc/rpc/general/) ## 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=` 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. - [QoS voor Dedicated Nodes (ERPC)](https://erpc.global/nl/staked-connection/) - [Handleiding voor Stake-weighted Quality of Service op Solana](https://solana.com/developers/guides/advanced/stake-weighted-qos) ## 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](https://erpc.global/nl/baremetal/). 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](https://dashboard.erpc.global/nl)