--- title: "FAQ sobre Solana RPC endpoint" description: "Entenda o que é um endpoint RPC da Solana, como obter um endpoint Solana com a ERPC e como solucionar o uso de RPC." canonical: "https://erpc.global/pt/faq/rpc/general/" locale: "pt" --- # 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](https://erpc.global/pt/faq/how-to-start/general/). As perguntas sobre distância, velocidade e regiões estão em [Latência e regiões](https://erpc.global/pt/faq/latency/general/). ## 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](https://dashboard.erpc.global/pt), copie sua API key e adicione-a ao parâmetro `api-key` da URL do endpoint: ```text https://edge.erpc.global?api-key= ``` Use o mesmo formato de API key para assinaturas WebSocket: ```text wss://edge.erpc.global?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](https://dashboard.erpc.global/pt) ## 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: ```text https://edge.erpc.global?api-key=&history=true ``` Ou envie-a no header `Authorization: Bearer ` e mantenha `history=true` na URL: ```text 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](https://erpc.global/pt/doc/rpc/general/) ## 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 } ``` 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`. - [Guia de migração](https://github.com/ValidatorsDAO/solana-stream/blob/main/docs/transaction-v1.md) - [Notas de lançamento do SDK 2.0.0](https://github.com/ValidatorsDAO/solana-stream/releases/tag/v2.0.0) - [Repositório do Solana Stream SDK](https://github.com/ValidatorsDAO/solana-stream) - [SIMD-0385: Transaction v1 — a proposta](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md) - [Upgrade da Solana: Larger Transaction Sizes](https://solana.com/upgrades/larger-transaction-sizes) - [Documentação RPC da Solana: getBlock](https://solana.com/docs/rpc/http/getblock) - [Documentação RPC da Solana: getTransaction](https://solana.com/docs/rpc/http/gettransaction) - [Documentação da ERPC: início rápido do ShredStream](https://erpc.global/pt/doc/shredstream/quickstart/) - [Documentação da ERPC: início rápido do Geyser gRPC](https://erpc.global/pt/doc/geyser-grpc/quickstart/) - [Documentação da ERPC: RPC](https://erpc.global/pt/doc/rpc/general/) ## 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=`. ## 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. - [QoS para nós dedicados (ERPC)](https://erpc.global/pt/staked-connection/) - [Um guia de Stake-weighted Quality of Service em Solana](https://solana.com/developers/guides/advanced/stake-weighted-qos) ## 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](https://erpc.global/pt/baremetal/). 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](https://dashboard.erpc.global/pt)