FAQ sobre Solana RPC endpoint

As perguntas sobre cobrança, o plano Free, pagamento e erros 401 ou 429 estão em Como começar.

As perguntas sobre distância, velocidade e regiões estão em Latência e regiões.

P. O que é um Solana RPC endpoint e como consigo um com a ERPC?

Um Solana RPC endpoint é a URL que seu app, trading bot, carteira ou sistema de analytics usa para enviar requisições JSON-RPC à Solana e receber dados da blockchain. Com a ERPC, você obtém um endpoint Solana gerenciado com suporte a HTTP e WebSocket pela mesma rede global de proxy.

Para começar, crie ou acesse sua conta no ERPC Web Dashboard, copie sua API key e adicione-a ao parâmetro api-key da URL do endpoint:

endpoint

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

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

Use o mesmo formato de API key para assinaturas WebSocket:

endpoint

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

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

P. Posso usar WebSocket?

Sim, o WebSocket é suportado. Ele opera através do mesmo endpoint, permitindo que você receba atualizações de dados em tempo real de forma eficiente.

P. Em que regiões estão localizados os seus nós?

Atualmente operamos nós nas seguintes regiões:

Frankfurt (FRA)
Amsterdã (AMS)
Londres (LON)
Nova York (NY)
Tóquio (TY)
Singapura (SGP)

Os endpoints RPC do ERPC são alimentados pela Cloudflare, aproveitando uma rede global de mais de 300 servidores de borda. As requisições são roteadas automaticamente pelo local de borda da Cloudflare mais próximo e, em seguida, encaminhadas ao nó ERPC ideal, garantindo o caminho de rede mais curto possível e latência consistentemente baixa de qualquer lugar do mundo.

Essa arquitetura elimina o impacto da distância geográfica ou do roteamento complexo, proporcionando conectividade sempre otimizada aos nós da Solana com máxima estabilidade e desempenho.

ERPC Web Dashboard: ERPC Web Dashboard

P. Por que blocos ou transações mais antigos da Solana estão faltando, ou por que vejo -32011?

Exceto por getTransactionsForAddress, uma requisição sem history=true é respondida a partir do intervalo recente que cada nó mantém, então blocos ou transações mais antigos podem retornar o erro This request needs history access. Add history=true to the endpoint URL. (código -32011), null ou um resultado vazio, dependendo do método. Adicione history=true à URL https://edge.erpc.global de uma requisição HTTP para solicitá-los.

Envie a API key na 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 envie-a no header Authorization: Bearer <YOUR_API_KEY> e mantenha history=true na URL:

endpoint

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

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

Uma consulta por blocos ou transações mais antigos pode levar muito mais tempo do que uma requisição normal, em alguns casos segundos. O History Access é uma opção separada que mantém essas consultas afastadas das requisições normais, para que as requisições normais continuem rápidas. Exceto por getTransactionsForAddress no modo "full", cada chamada respondida pelo History Access custa 640 tokens a mais que o preço normal do seu método.

As alocações gratuitas, incluindo as do Plano Free, têm um limite para o History Access. O Plano Free é limitado a uma requisição com History Access a cada 10 segundos.

Sem history=true, getTransactionsForAddress com transactionDetails definido como "full" retorna o mesmo erro -32011, seja qual for a idade dos dados; a documentação da ERPC informa o preço.

Documentação da ERPC: RPC

P. Minha saída de Shreds / getBlock de repente parece quebrada ou retorna -32015 — o que mudou?

A Solana Transaction v1 (SIMD-0385) entrou em vigor na mainnet da Solana em 15 de setembro de 2026, no epoch 1035. O layout wire de uma transação v1 começa com o byte de prefixo de versão 0x81, as assinaturas vêm depois da mensagem e não há mais o prefixo de comprimento legacy.

Se você decodifica por conta própria as entries do ShredStream ou do UDP Forwarding, um decodificador bincode ou solana-entry abaixo da versão 4.2 interpreta esse byte 0x81 como a quantidade de assinaturas, o que aparece como um erro de EOF, um overflow de compact-length ou um erro "invalid message version". Usuários do Geyser gRPC que desserializam transações raw com crates anteriores à 4.2 têm o mesmo problema. Chamadas RPC a getBlock e getTransaction com maxSupportedTransactionVersion: 0 retornam -32015 Transaction version (1) is not supported by the requesting client; getTransactionsForAddress no modo full reporta o mesmo erro em cada linha afetada. Você não é afetado se já lê as respostas JSON parseadas da ERPC com a versão 1 definida.

Defina maxSupportedTransactionVersion como 1 no objeto de opções — o segundo parâmetro de getBlock e getTransaction, e também nas opções de getTransactionsForAddress:

json

{
  "maxSupportedTransactionVersion": 1
}

{
  "maxSupportedTransactionVersion": 1
}

Atualize o Solana Stream SDK para 2.0.0: solana-stream-sdk em Rust no crates.io, ou @validators-dao/solana-stream-sdk e @validators-dao/solana-shreds-client no npm. Atualize @validators-dao/solana-entry-decoder separadamente para 2.5.0. 1.4.0 e entry-decoder 2.4.0 não suportam v1. Decodificadores Rust próprios deveriam migrar para solana-entry 4.2.x.

P. Quais métodos o Unlimited Endpoint suporta?

Unlimited Endpoints foram criados para chamadas padrão de Solana RPC com baixa latência. Os métodos suportados são:

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

Para outros métodos, use https://edge.erpc.global?api-key=<YOUR_API_KEY>.

P. Transações no meu nó dedicado têm uma baixa taxa de sucesso

As taxas de sucesso da transação e a velocidade são significativamente afetadas por um mecanismo chamado QoS (Qualidade de Serviço). Oferecemos QoS especificamente para nós dedicados. Para mais detalhes, consulte as páginas abaixo ou entre em contato conosco pelo ERPC Web Dashboard.

P. Como posso alcançar a menor latência possível?

A configuração ideal para latência mínima é um nó RPC dedicado combinado com nossos servidores Bare-Metal. Ambos compartilham a mesma rede, possibilitando comunicação privada, de distância zero, com latências de ping em torno de 0.1ms.

Entre em contato conosco através do ERPC Web Dashboard para mais detalhes.

ERPC Web Dashboard