¿Qué debo saber sobre los endpoints de Polygon PoS?

Polygon PoS es una de las cadenas EVM más concurridas, y la mayoría de los equipos acceden a ella a través de un endpoint JSON-RPC en lugar de ejecutar su propio nodo. La parte complicada no es encontrar una URL, sino elegir una que se ajuste a tu carga de trabajo, conectarla correctamente en billeteras y servicios backend, y saber qué verificar cuando las llamadas comienzan a fallar.

Esta página está escrita para desarrolladores y compradores de infraestructura que necesitan endpoints de Polygon PoS funcionales, además del contexto para elegir entre una URL pública compartida y capacidad dedicada. Si primero quieres la descripción general de la red, consulta la página de Polygon RPC.

Configuración de la cadena de un vistazo

Antes de conectar cualquier cosa, confirma los valores a continuación. Polygon migró su token nativo de gas de MATIC a POL, por lo que los tutoriales antiguos que aún hacen referencia a MATIC pueden causar confusión en las configuraciones de billeteras y en la estimación de gas.

Un endpoint público de OnFinality para mainnet está disponible en https://polygon.api.onfinality.io/public, y el endpoint de Amoy testnet es https://polygon-amoy.api.onfinality.io/public. Los endpoints públicos son compartidos, así que trátalos como un punto de partida para desarrollo y lecturas de bajo volumen, en lugar del destino final para una aplicación de producción con alto tráfico.

Cuándo un endpoint compartido es suficiente — y cuándo no

Esta es la decisión que la mayoría de los equipos toma mal. Un endpoint público compartido está bien cuando tu volumen de llamadas es modesto, tus solicitudes son principalmente lecturas, y una variación ocasional de latencia no romperá la experiencia del usuario. Se convierte en una desventaja cuando necesitas rendimiento predecible, capacidad aislada o suscripciones de larga duración.

Usa esta verificación rápida de idoneidad:

Si no estás seguro de dónde encajas, comienza en un endpoint compartido, mide tus patrones de solicitud y pasa a nodos dedicados una vez que puedas describir tu carga máxima. Para un marco más amplio, la guía de selección de proveedor de RPC recorre los criterios de evaluación.

Conexión desde código

La forma más simple de confirmar que un endpoint funciona es una llamada JSON-RPC sin procesar. Esto verifica la conectividad y devuelve el número de bloque actual:

curl -s https://polygon.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

Una respuesta exitosa se ve así: {"jsonrpc":"2.0","id":1,"result":"0x..."}. Si obtienes un timeout o un estado que no es 200, el problema es el endpoint o tu ruta de red, no la lógica de tu aplicación.

En JavaScript, la mayoría de los equipos usan viem o ethers. Con viem:

import { createPublicClient, http } from 'viem';
import { polygon } from 'viem/chains';

const client = createPublicClient({
  chain: polygon,
  transport: http('https://polygon.api.onfinality.io/public'),
});

const block = await client.getBlockNumber();
console.log('Polygon PoS head:', block);

Para trabajo en tiempo real, Polygon PoS soporta suscripciones WebSocket. Un eth_subscribe mínimo sobre wss se ve así:

import WebSocket from 'ws';

const ws = new WebSocket('wss://polygon.api.onfinality.io/public/ws');

ws.on('open', () => {
  ws.send(JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'eth_subscribe',
    params: ['newHeads'],
  }));
});

ws.on('message', (data) => {
  console.log('New head:', data.toString());
});

La disponibilidad de WebSocket depende del endpoint y del plan que uses. Si las suscripciones son parte de tu diseño, confirma el soporte de transporte antes de comprometerte, porque no todos los endpoints compartidos exponen wss.

Agregar Polygon PoS a una billetera

Las configuraciones de billetera y red son una fuente común de errores de "cadena incorrecta". Los campos a continuación coinciden con los valores de la tabla de configuración:

{
  "chainId": "0x89",
  "chainName": "Polygon Mainnet",
  "nativeCurrency": { "name": "POL", "symbol": "POL", "decimals": 18 },
  "rpcUrls": ["https://polygon.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://polygonscan.com"]
}

Ten en cuenta que 0x89 es la forma hexadecimal del decimal 137. Mezclar ambos formatos es una de las causas más frecuentes de llamadas fallidas a wallet_addEthereumChain.

Métodos, límites y lo que suele fallar

Polygon PoS es compatible con EVM, por lo que se aplica el conjunto estándar de métodos: eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_estimateGas, eth_sendRawTransaction, y así sucesivamente. Los fallos que más probablemente encontrarás no son exóticos:

• Limitación de tasa en endpoints compartidos. Los escaneos eth_getLogs en ráfaga o los bucles de sondeo pueden activar límites compartidos. Agrupa y almacena en caché cuando sea posible.
• Límites de rango de eth_getLogs. Los proveedores limitan el rango de bloques por consulta. Si tu indexador escanea rangos grandes en una sola llamada, divídelo en fragmentos.
• Manejo de reorganizaciones. Polygon PoS puede reorganizarse, por lo que las confirmaciones importan. No trates un solo recibo como final para lógica que involucra valor.
• Brechas de archivo. Las llamadas históricas eth_call contra bloques antiguos necesitan datos de archivo. Los endpoints compartidos pueden no servir historia profunda.
• Caídas de WebSocket. Las suscripciones de larga duración necesitan lógica de reconexión con retroceso y un paso de resuscripción.

Ruta de depuración para llamadas fallidas

Cuando una llamada falla, sigue este orden en lugar de adivinar:

1. Reproduce con curl. Si la solicitud sin procesar falla, el problema es el endpoint o la red, no tu SDK.
2. Verifica el chain ID. Llama a eth_chainId y confirma que obtienes 0x89 en mainnet.
3. Aísla el método. Prueba el método específico que falla. Un eth_blockNumber que funciona no prueba que eth_getLogs tendrá éxito.
4. Inspecciona el cuerpo del error. Los errores JSON-RPC llevan códigos y mensajes: los errores de límite de tasa, método no encontrado y rango se ven diferentes.
5. Compara endpoints. Si un segundo endpoint tiene éxito, el primero es el problema.
6. Verifica el momento. Los picos que se correlacionan con tu propio despliegue o trabajos cron generalmente apuntan al volumen de solicitudes, no al proveedor.

Elegir entre capacidad compartida y dedicada

Si tu ruta de depuración sigue terminando en límites de tasa, topes de rango o caídas de suscripción, la solución es capacidad, no código. OnFinality ofrece Polygon PoS a través de un servicio API RPC compartido y mediante despliegues de nodos dedicados que dan a tu carga de trabajo recursos aislados. Los nodos dedicados son la opción habitual para indexadores, exchanges y aplicaciones con tráfico de producción constante.

Al comparar proveedores, mira las mismas dimensiones independientemente del proveedor:

Los precios para opciones compartidas y dedicadas están en la página de precios de RPC, y puedes explorar otras cadenas en la lista de redes RPC compatibles.

Puntos clave

• Polygon PoS mainnet usa chain ID 137 (0x89), token nativo POL y explorador polygonscan.com.
• Endpoints públicos de OnFinality: https://polygon.api.onfinality.io/public para mainnet y https://polygon-amoy.api.onfinality.io/public para Amoy testnet.
• Los endpoints compartidos son adecuados para desarrollo y lecturas ligeras; los nodos dedicados son adecuados para tráfico de producción, indexadores y suscripciones.
• La mayoría de los fallos se remontan a límites de tasa, topes de rango de eth_getLogs, manejo de reorganizaciones o caídas de WebSocket, no a la cadena en sí.
• Siempre confirma el soporte de transporte y el acceso a archivo antes de comprometerte con un endpoint para una carga de trabajo de producción.

Preguntas frecuentes

¿Cuál es el chain ID de Polygon PoS? Mainnet es 137, escrito como 0x89 en hexadecimal. El testnet Amoy es 80002.

¿Cuál es el token nativo de Polygon PoS? POL, con 18 decimales. Reemplazó a MATIC como token de gas y staking de la red.

¿Puedo usar un endpoint público en producción? Puedes, pero los endpoints compartidos están sujetos a contención. Para tráfico constante, suscripciones o consultas masivas de logs, un nodo dedicado te da capacidad aislada.

¿Polygon PoS soporta suscripciones WebSocket? Sí, la red soporta eth_subscribe, pero el endpoint que uses debe exponer wss. Confirma el soporte de transporte para el plan que elijas.

¿Por qué falla eth_getLogs en rangos grandes? Los proveedores limitan el rango de bloques por consulta para proteger la infraestructura compartida. Divide los escaneos grandes en fragmentos más pequeños y pagina.

¿Cómo cambio de endpoint sin tiempo de inactividad? Ejecuta al menos dos endpoints y haz conmutación por error cuando fallen las verificaciones de estado. Una sonda simple que llame a eth_blockNumber de forma programada es suficiente para detectar un endpoint degradado.