FAQ del endpoint RPC de Solana

Las preguntas sobre facturación, el plan Gratis, pagos y errores 401 o 429 están en Cómo empezar.

Las preguntas sobre distancia, velocidad y regiones están en Latencia y regiones.

P: ¿Qué es un endpoint RPC de Solana y cómo puedo obtener uno con ERPC?

Un endpoint RPC de Solana es la URL que tu app, bot de trading, wallet o sistema de analítica usa para enviar solicitudes JSON-RPC a Solana y recibir datos de la cadena. Con ERPC, obtienes un endpoint de Solana gestionado con acceso HTTP y WebSocket a través de la misma red global de proxies.

Para empezar, crea o abre tu cuenta de ERPC en el ERPC Web Dashboard, copia tu API key y añádela al parámetro api-key de la URL del endpoint:

endpoint

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

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

Usa el mismo formato de API key para suscripciones WebSocket:

endpoint

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

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

P: ¿Puedo usar WebSocket?

Sí, WebSocket es compatible. Funciona a través del mismo endpoint, lo que te permite recibir actualizaciones de datos en tiempo real.

P: ¿En qué regiones se encuentran sus nodos?

Actualmente operamos nodos en las siguientes regiones:

Frankfurt (FRA)
Amsterdam (AMS)
Londres (LON)
Nueva York (NY)
Tokio (TY)
Singapur (SGP)

Los endpoints RPC de ERPC están impulsados por Cloudflare, aprovechando una red global de más de 300 servidores edge. Las solicitudes se dirigen automáticamente a través de la ubicación edge Cloudflare más cercana y luego se envían al nodo ERPC óptimo, asegurando la ruta de red más corta posible y baja latencia constante desde cualquier lugar del mundo.

Esta arquitectura elimina el impacto de la distancia geográfica o el enrutamiento complejo, proporcionando conectividad siempre optimizada a los nodos de Solana con la máxima estabilidad y rendimiento.

ERPC Web Dashboard: ERPC Web Dashboard

P: ¿Por qué faltan bloques o transacciones más antiguos de Solana, o por qué veo -32011?

Excepto getTransactionsForAddress, una solicitud sin history=true se responde desde el rango reciente que conserva cada nodo, por lo que los bloques o transacciones más antiguos pueden devolver el error This request needs history access. Add history=true to the endpoint URL. (código -32011), null o un resultado vacío, según el método. Añade history=true a la URL https://edge.erpc.global de una solicitud HTTP para pedirlos.

Envía la API key en la URL:

endpoint

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

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

O envíala en el header Authorization: Bearer <YOUR_API_KEY> y mantén history=true en la URL:

endpoint

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

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

Una consulta de bloques o transacciones más antiguos puede tardar mucho más que una solicitud normal, en algunos casos segundos. History Access es una opción independiente que mantiene estas consultas separadas de las solicitudes normales, de modo que las solicitudes normales sigan siendo rápidas. Excepto getTransactionsForAddress en modo "full", cada llamada respondida por History Access cuesta 640 tokens más que el precio normal de su método.

Las asignaciones gratuitas, incluidas las del Plan Free, tienen un límite para History Access. El Plan Free se limita a una solicitud de History Access cada 10 segundos.

Sin history=true, getTransactionsForAddress con transactionDetails establecido en "full" devuelve el mismo error -32011, sea cual sea la antigüedad de los datos; la documentación de ERPC indica su precio.

Documentación de ERPC: RPC

P: Mi salida de Shreds / getBlock de repente se ve rota o devuelve -32015: ¿qué ha cambiado?

Solana Transaction v1 (SIMD-0385) entró en vigor en la mainnet de Solana el 15 de septiembre de 2026, en la época 1035. El formato wire de una transacción v1 empieza con el byte de prefijo de versión 0x81, las firmas van después del mensaje y ya no hay prefijo de longitud legacy.

Si decodificas tú mismo las entries de ShredStream o UDP Forwarding, un decodificador bincode o solana-entry anterior a la versión 4.2 interpreta ese byte 0x81 como el número de firmas, lo que se manifiesta como un error EOF, un desbordamiento de compact-length o un error "invalid message version". Los usuarios de Geyser gRPC que deserializan transacciones en bruto con crates anteriores a 4.2 tienen el mismo problema. Las llamadas RPC a getBlock y getTransaction con maxSupportedTransactionVersion: 0 devuelven -32015 Transaction version (1) is not supported by the requesting client; getTransactionsForAddress en modo full informa del mismo error en cada fila afectada. No te afecta si ya lees las respuestas JSON parseadas de ERPC con la versión 1 configurada.

Establece maxSupportedTransactionVersion en 1 dentro del objeto de opciones: el segundo parámetro de getBlock y getTransaction, y también las opciones de getTransactionsForAddress:

json

{
  "maxSupportedTransactionVersion": 1
}

{
  "maxSupportedTransactionVersion": 1
}

Actualiza el Solana Stream SDK a 2.0.0: solana-stream-sdk de Rust en crates.io, o @validators-dao/solana-stream-sdk y @validators-dao/solana-shreds-client en npm. Actualiza @validators-dao/solana-entry-decoder a 2.5.0 por separado. 1.4.0 y entry-decoder 2.4.0 no soportan v1. Los decodificadores Rust propios deberían pasar a solana-entry 4.2.x.

P: ¿Qué métodos admite Unlimited Endpoint?

Unlimited Endpoints están diseñados para llamadas estándar de Solana RPC de baja latencia. Los métodos compatibles son:

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

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

P: Las transacciones en mi nodo dedicado tienen una baja tasa de éxito

Las tasas de éxito de transacción y la velocidad se ven significativamente afectadas por un mecanismo llamado QoS (Calidad del Servicio). Ofrecemos QoS específicamente para nodos dedicados. Para más detalles, consulta las páginas siguientes o contáctanos desde el ERPC Web Dashboard.

P: ¿Cómo puedo lograr la latencia más baja posible?

La configuración ideal para la latencia mínima es un nodo RPC dedicado combinado con nuestros servidores bare metal. Ambos comparten la misma red, lo que permite una comunicación privada de distancia cero con latencias de ping de alrededor de 0.1ms.

Contáctanos desde el ERPC Web Dashboard para más detalles.

ERPC Web Dashboard