FAQ - Solana RPC endpoints ERPC

Les questions sur la facturation, le forfait Gratuit, le paiement et les erreurs 401 ou 429 se trouvent dans Comment démarrer.

Les questions sur la distance, la vitesse et les régions se trouvent dans Latence et régions.

Q. Qu'est-ce qu'un endpoint Solana RPC et comment en obtenir un avec ERPC?

Un endpoint Solana RPC est l'URL qu'utilise votre application, votre bot de trading, votre wallet ou votre système d'analyse pour envoyer des requêtes JSON-RPC à Solana et recevoir les données de la chaîne. Avec ERPC, vous obtenez un endpoint Solana géré qui prend en charge l'accès HTTP et WebSocket via le même réseau mondial de proxys.

Pour commencer, créez ou ouvrez votre compte ERPC dans l'ERPC Web Dashboard, copiez votre API key et ajoutez-la au paramètre api-key de l'URL de l'endpoint:

endpoint

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

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

Utilisez le même format d'API key pour les abonnements WebSocket:

endpoint

wss://edge.erpc.global?api-key=<YOUR_API_KEY>

wss://edge.erpc.global?api-key=<YOUR_API_KEY>

Q. Puis-je utiliser WebSocket?

Oui, WebSocket est pris en charge sur le même endpoint, ce qui permet de recevoir efficacement des mises à jour de données en temps réel.

Q. Dans quelles régions se trouvent vos nœuds?

Nous opérons actuellement des nœuds dans les régions suivantes:

Francfort (FRA)
Amsterdam (AMS)
Londres (LON)
New York (NY)
Tokyo (TY)
Singapour (SGP)

Les endpoints RPC d'ERPC s'appuient sur Cloudflare et son réseau mondial de plus de 300 serveurs edge. Les requêtes sont automatiquement acheminées vers l'edge Cloudflare le plus proche, puis transmises au nœud ERPC optimal afin d'emprunter le chemin réseau le plus court possible et de maintenir une latence faible partout dans le monde.

Cette architecture élimine l'impact de la distance géographique et des routages complexes, et offre une connectivité toujours optimisée aux nœuds Solana, avec une stabilité et des performances maximales.

ERPC Web Dashboard: ERPC Web Dashboard

Q. Pourquoi des blocs ou transactions Solana plus anciens sont-ils manquants, ou pourquoi vois-je -32011?

À l'exception de getTransactionsForAddress, une requête sans history=true est traitée à partir de la plage récente que détient chaque nœud ; les blocs ou transactions plus anciens peuvent donc renvoyer l'erreur This request needs history access. Add history=true to the endpoint URL. (code -32011), null ou un résultat vide, selon la méthode. Ajoutez history=true à l'URL https://edge.erpc.global d'une requête HTTP pour les demander.

Envoyez l'API key dans l'URL :

endpoint

https://edge.erpc.global?api-key=<YOUR_API_KEY>&history=true

https://edge.erpc.global?api-key=<YOUR_API_KEY>&history=true

Ou envoyez-la dans l'en-tête Authorization: Bearer <YOUR_API_KEY> et conservez history=true dans l'URL :

endpoint

https://edge.erpc.global?history=true

https://edge.erpc.global?history=true

Une recherche de blocs ou de transactions plus anciens peut prendre beaucoup plus de temps qu'une requête ordinaire, parfois plusieurs secondes. History Access est une option distincte qui sépare ces recherches des requêtes ordinaires, afin que celles-ci restent rapides. À l'exception de getTransactionsForAddress en mode "full", chaque appel traité par History Access coûte 640 tokens de plus que le prix habituel de sa méthode.

Les allocations gratuites, y compris celles du forfait Free, ont une limite pour History Access. Le forfait Free est limité à une requête avec History Access toutes les 10 secondes.

Sans history=true, getTransactionsForAddress avec transactionDetails défini sur "full" renvoie la même erreur -32011, quel que soit l'âge des données ; la documentation ERPC en donne le prix.

Documentation ERPC : RPC

Q. Ma sortie Shreds / getBlock semble soudain cassée ou renvoie -32015 — qu'est-ce qui a changé?

Solana Transaction v1 (SIMD-0385) est entré en vigueur sur le mainnet Solana le 15 septembre 2026, à l'epoch 1035. Le format wire d'une transaction v1 commence par l'octet de préfixe de version 0x81, les signatures viennent après le message, et il n'y a plus de préfixe de longueur legacy.

Si vous décodez vous-même les entries ShredStream ou UDP Forwarding, un décodeur bincode ou solana-entry antérieur à la version 4.2 interprète cet octet 0x81 comme un nombre de signatures, ce qui se manifeste par une erreur EOF, un dépassement de compact-length ou une erreur "invalid message version". Les utilisateurs Geyser gRPC qui désérialisent des transactions brutes avec des crates antérieures à 4.2 rencontrent le même problème. Les appels RPC getBlock et getTransaction avec maxSupportedTransactionVersion: 0 renvoient -32015 Transaction version (1) is not supported by the requesting client ; getTransactionsForAddress en mode full signale la même erreur sur chaque ligne concernée. Vous n'êtes pas concerné si vous lisez déjà les réponses JSON parsées d'ERPC avec la version 1 activée.

Définissez maxSupportedTransactionVersion à 1 dans l'objet d'options — le second paramètre de getBlock et getTransaction, ainsi que dans les options de getTransactionsForAddress :

json

{
  "maxSupportedTransactionVersion": 1
}

{
  "maxSupportedTransactionVersion": 1
}

Mettez à jour le Solana Stream SDK vers 2.0.0 : solana-stream-sdk en Rust sur crates.io, ou @validators-dao/solana-stream-sdk et @validators-dao/solana-shreds-client sur npm. Mettez à jour @validators-dao/solana-entry-decoder séparément vers 2.5.0. 1.4.0 et entry-decoder 2.4.0 ne prennent pas en charge v1. Vos propres décodeurs Rust devraient passer à solana-entry 4.2.x.

Q. Quelles méthodes Unlimited Endpoint prend-il en charge ?

Les Unlimited Endpoints sont conçus pour les appels Solana RPC standard à faible latence. Les méthodes prises en charge sont :

getSlot
getBlockHeight
getLatestBlockhash
getBalance
getAccountInfo
getMultipleAccounts
getTransaction
sendTransaction
simulateTransaction
getSignatureStatuses
getRecentPrioritizationFees
getHealth
getVersion
getEpochInfo
getBlock

Pour les autres méthodes, utilisez https://edge.erpc.global?api-key=<YOUR_API_KEY>.

Q. Les transactions sur mon nœud dédié ont un faible taux de succès

Les taux de réussite et la vitesse des transactions sont considérablement affectés par un mécanisme appelé QoS (Quality of Service). Nous proposons une QoS spécifique pour les nœuds dédiés. Pour plus de détails, veuillez consulter les pages ci-dessous ou nous contacter via notre ERPC Web Dashboard.

Q. Comment puis-je obtenir la latence la plus faible possible?

La configuration idéale pour la latence minimale est un nœud RPC dédié combiné avec nos serveurs bare metal. Les deux partagent le même réseau, ce qui permet une communication privée à distance zéro avec des pings d'environ 0,1 ms.

Veuillez nous contacter via l'ERPC Web Dashboard pour plus de détails.

ERPC Web Dashboard