ERPC

Solana RPC endpoint FAQ

बिलिंग, मुफ़्त प्लान, भुगतान और 401 या 429 errors से जुड़े प्रश्न कैसे शुरू करें में हैं।
दूरी, गति और क्षेत्रों से जुड़े प्रश्न विलंबता और क्षेत्र में हैं।

Q. Solana RPC endpoint क्या है, और ERPC से कैसे प्राप्त करें?

Solana RPC endpoint वह URL है जिसे आपका app, trading bot, wallet या analytics system Solana को JSON-RPC requests भेजने और chain data प्राप्त करने के लिए इस्तेमाल करता है। ERPC के साथ आपको managed Solana endpoint मिलता है, जो उसी global proxy network पर HTTP और WebSocket access support करता है।
शुरू करने के लिए ERPC Web Dashboard में account खोलें या login करें, अपनी API key copy करें, और endpoint URL के api-key parameter में जोड़ें:
endpoint
https://edge.erpc.global?api-key=<YOUR_API_KEY>
WebSocket subscriptions के लिए भी यही API key format इस्तेमाल करें:
endpoint
wss://edge.erpc.global?api-key=<YOUR_API_KEY>

Q. क्या WebSocket उपलब्ध है?

हाँ। WebSocket same endpoint से काम करता है, जिससे आप real-time data updates efficiently receive कर सकते हैं।

Q. आपके नोड किन क्षेत्रों में स्थित हैं?

हम अभी इन regions में nodes चलाते हैं:
  • Frankfurt (FRA)
  • Amsterdam (AMS)
  • London (LON)
  • New York (NY)
  • Tokyo (TY)
  • Singapore (SGP)
ERPC के RPC endpoints Cloudflare पर आधारित हैं और दुनिया भर में 300 से अधिक edge servers वाले global network का उपयोग करते हैं। Requests अपने-आप nearest Cloudflare edge location से route होती हैं और फिर optimal ERPC node तक forward होती हैं, जिससे दुनिया में कहीं से भी shortest possible network path और लगातार कम latency मिलती है।
इस architecture से भौगोलिक दूरी और complex routing का असर कम होता है, और Solana nodes तक stable, optimized connectivity मिलती है।
ERPC Web Dashboard: ERPC Web Dashboard

Q. Solana के पुराने blocks या transactions क्यों नहीं मिल रहे, या मुझे -32011 क्यों दिख रहा है?

getTransactionsForAddress को छोड़कर, history=true के बिना भेजे गए request का जवाब हर node के पास मौजूद हाल की range से दिया जाता है, इसलिए पुराने blocks या transactions method के आधार पर error This request needs history access. Add history=true to the endpoint URL. (code -32011), null या खाली result लौटा सकते हैं। उन्हें माँगने के लिए HTTP request के URL https://edge.erpc.global में history=true जोड़ें।
API key को URL में भेजें:
endpoint
https://edge.erpc.global?api-key=<YOUR_API_KEY>&history=true
या उसे header Authorization: Bearer <YOUR_API_KEY> में भेजें और history=true को URL में रखें:
endpoint
https://edge.erpc.global?history=true
पुराने blocks या transactions की खोज सामान्य request से काफ़ी ज़्यादा समय ले सकती है, कुछ मामलों में सेकंड लग सकते हैं। History Access एक अलग option है, जो इन खोजों को सामान्य requests से अलग रखता है, ताकि सामान्य requests तेज़ बने रहें। "full" mode में getTransactionsForAddress को छोड़कर, History Access से जवाब पाने वाले हर call पर method की सामान्य कीमत से 640 tokens अधिक लगते हैं।
Free plan के आवंटन सहित, मुफ़्त आवंटनों की History Access के लिए एक सीमा होती है। Free plan में History Access हर 10 सेकंड में एक request तक सीमित है।
history=true के बिना, transactionDetails को "full" पर सेट करके getTransactionsForAddress चलाने पर वही -32011 error मिलता है, चाहे data कितना भी पुराना या नया हो; इसकी कीमत ERPC docs में दी गई है।
ERPC दस्तावेज़: RPC

Q. मेरा Shreds / getBlock output अचानक टूटा हुआ दिख रहा है या -32015 लौटा रहा है — क्या बदला है?

Solana Transaction v1 (SIMD-0385) 15 सितंबर 2026 को epoch 1035 पर Solana mainnet पर लाइव हो गया। v1 transaction का wire layout version prefix byte 0x81 से शुरू होता है, signatures message के बाद आते हैं, और legacy length prefix नहीं होता।
अगर आप ShredStream या UDP Forwarding की entries खुद decode करते हैं, तो version 4.2 से पुराना bincode या solana-entry decoder उस 0x81 byte को गलती से signature count समझ लेता है, जो EOF error, compact-length overflow या "invalid message version" error के रूप में दिखता है। 4.2 से पहले के crates से raw transactions deserialize करने वाले Geyser gRPC users को भी यही समस्या आती है। maxSupportedTransactionVersion: 0 के साथ getBlock और getTransaction की RPC calls -32015 Transaction version (1) is not supported by the requesting client लौटाती हैं; getTransactionsForAddress full mode में हर प्रभावित row पर यही error रिपोर्ट करता है। अगर आप पहले से ERPC के parsed JSON responses को version 1 सेट करके पढ़ रहे हैं, तो आप प्रभावित नहीं हैं।
options object में maxSupportedTransactionVersion को 1 पर सेट करें — यह getBlock और getTransaction का दूसरा parameter है, और getTransactionsForAddress के options में भी:
json
{
  "maxSupportedTransactionVersion": 1
}
Solana Stream SDK को 2.0.0 पर upgrade करें: crates.io पर Rust solana-stream-sdk, या npm पर @validators-dao/solana-stream-sdk और @validators-dao/solana-shreds-client। @validators-dao/solana-entry-decoder को अलग से 2.5.0 पर upgrade करें। 1.4.0 और entry-decoder 2.4.0 v1 को support नहीं करते। अपने खुद के Rust decoders को solana-entry 4.2.x पर ले जाना चाहिए।

Q. Unlimited Endpoint किन विधियों को support करता है?

Unlimited Endpoints कम विलंबता वाली मानक Solana RPC calls के लिए बनाए गए हैं। समर्थित विधियाँ ये हैं:
  • getSlot
  • getBlockHeight
  • getLatestBlockhash
  • getBalance
  • getAccountInfo
  • getMultipleAccounts
  • getTransaction
  • sendTransaction
  • simulateTransaction
  • getSignatureStatuses
  • getRecentPrioritizationFees
  • getHealth
  • getVersion
  • getEpochInfo
  • getBlock
अन्य विधियों के लिए https://edge.erpc.global?api-key=<YOUR_API_KEY> इस्तेमाल करें।

Q. Dedicated node पर transactions की success rate कम है

Transaction success rate और speed पर QoS (Quality of Service) का बड़ा impact होता है। हम dedicated nodes के लिए QoS provide करते हैं। Details के लिए नीचे दिए गए pages देखें या ERPC Web Dashboard से पूछें।

Q. मैं सबसे कम संभव विलंबता कैसे प्राप्त कर सकता हूँ?

न्यूनतम विलंबता के लिए आदर्श सेटअप है dedicated RPC node को हमारे Bare-Metal सर्वर के साथ इस्तेमाल करना। दोनों एक ही network साझा करते हैं, जिससे लगभग 0.1ms के ping के साथ निजी, शून्य-दूरी वाला communication संभव होता है।
अधिक जानकारी के लिए ERPC Web Dashboard से संपर्क करें।
ERPC Web Dashboard
पिछलास्पीड तुलनाअगलाEdge RPC / Ethereum / क्विकस्टार्ट