Tutorial de Bot de Polymarket · Capítulo 5 de 32
Comparación de proveedores de Polygon RPC para bots de Polymarket en 2026: Alchemy, QuickNode, Ankr, endpoints públicos, autohospedado. Latencia, rate limits, utilizable en free tier para paper trading.
Qué cubre este capítulo
El endpoint de Polygon RPC es la única vista directa que tiene tu bot del estado on-chain: saldos, allowances, confirmaciones de settlement, eventos de UMA. La API propia de Polymarket oculta la mayor parte de esto, pero un bot de producción necesita leer la verdad on-chain para verificar su propia contabilidad. Este capítulo compara los principales proveedores de RPC bajo carga real, indica los umbrales de free tier en los que cada uno deja de funcionar y termina con el patrón de failover de dos proveedores que la mayoría de los bots termina adoptando.
- Qué hace un RPC para tu bot
- Alchemy: free tier y precios
- QuickNode: nodos dedicados
- Ankr: el tier pago más barato
- RPCs públicos de Polygon (gratis, con rate limits)
- Nodo de Polygon autohospedado (cuándo tiene sentido)
- Benchmarks de latencia (US-East vs EU)
- Patrones de failover
Qué hace un RPC para tu bot
Un endpoint RPC es la URL HTTPS o WebSocket a través de la cual tu bot lee y escribe el estado de la cadena Polygon. Para un bot de Polymarket, el RPC se encarga de cuatro tareas.
- Leer saldos: cuánto pUSD o USDC hay en el proxy, cuántos outcome tokens realmente posees. Es necesario para verificar que la vista de la API CLOB coincida con la verdad de la cadena.
- Leer allowances: si los contratos de Polymarket pueden gastar tus tokens. Un allowance mal configurado produce rechazos de órdenes silenciosos.
- Suscribirse a eventos: propuestas y disputas de UMA Optimistic Oracle, confirmaciones de depósitos, transferencias on-chain grandes desde otras wallets.
- Verificar settlement: cuando el CLOB dice "matched", la cadena todavía no ha confirmado la transferencia ERC-1155. Leer la cadena confirma que realmente ocurrió.
El bot no firma órdenes a través del RPC - la firma de órdenes se hace localmente y el payload firmado se envía a la API HTTP del CLOB. El RPC es puramente un canal de lectura y eventos para la mayoría de las estrategias.
Alchemy: free tier y precios
Alchemy es el proveedor de Polygon RPC más usado entre los builders de Polymarket que conocemos. El free tier cubre la mayoría de los casos de uso de paper trading y bots pequeños: 300 unidades de cómputo por segundo, 300 millones por mes, con el mismo dashboard usado para aprovisionar endpoints de Polygon mainnet y Polygon testnet.
Un bot típico de 20 mercados que lee saldos + eventos de UMA cada 30 segundos consume alrededor de 50-80 millones de CU/mes, cómodamente por debajo del límite gratis. Los planes pagos arrancan cerca de $50/mes y principalmente compran mayor throughput por segundo, no más llamadas totales. El rate limit del free tier es la restricción que la mayoría de los bots de paper trading alcanzan, no el volumen mensual.
Alchemy incluye un dashboard útil para inspeccionar requests fallidos y un desglose de latencia por método que ayuda al depurar lecturas lentas. Solo por el dashboard ya vale la pena elegirlos por encima de un proveedor sin dashboard para un primer bot.
QuickNode: nodos dedicados
QuickNode se posiciona para necesidades de mayor throughput. Su pricing escala con el volumen mensual de requests en lugar de por tiers, lo que es más relevante para bots que se suscriben a muchos filtros de eventos WebSocket o hacen consultas pesadas de logs históricos. El tier de entrada ronda $10-20/mes e incluye soporte WebSocket que algunos planes gratis de Alchemy limitan.
La latencia por request de QuickNode desde US-East suele ser de 5-15 ms, ligeramente mejor que el free tier de Alchemy bajo carga. Para un bot de una sola estrategia la diferencia es invisible; para un market maker cotizando 100 mercados puede importar. El acceso a su archive node (estado histórico completo) es el más barato entre los tres principales si tu estrategia lo necesita.
El punto débil: sus respuestas de error JSON-RPC son menos específicas que las de Alchemy, así que depurar toma más tiempo cuando falla un método.
Ankr: el tier pago más barato
Ankr ofrece el Polygon RPC pago más barato dentro del tier de proveedores principales: aproximadamente $10/mes para el plan premium de entrada con 1,500 CU/segundo. El free tier tiene rate limits estrictos, pero es usable para paper trading.
Dos advertencias. Primero, el endpoint balanceado de Ankr ocasionalmente sirve datos de bloques ligeramente desactualizados (1-2 bloques detrás del tip). Para lecturas de balance está bien; para estrategias de arbitraje que dependen del último bloque, es un problema importante. Segundo, el tiempo de respuesta de soporte es más lento que el de Alchemy o QuickNode cuando los nodos de una región tienen un problema.
Ankr es un proveedor primario razonable para bots sensibles al costo y un excelente proveedor de respaldo sin importar cuál sea el primario. La sección de patrones de failover abajo explica cómo combinarlos.
RPCs públicos de Polygon (gratis, con rate limits)
Polygon publica varios endpoints públicos gratis de RPC: polygon-rpc.com, rpc.ankr.com/polygon (público, separado de Ankr pago) y algunos mantenidos por la comunidad. Funcionan, pero con salvedades.
- Los rate limits son agresivos y no están documentados. Espera throttling si superas ~10 req/seg sostenidas.
- Sin soporte, sin dashboard. Cuando un endpoint falla, te enteras porque sube la tasa de errores de tu bot.
- Frecuentemente van 1-3 bloques detrás. Bien para lecturas no sensibles al tiempo.
Usa endpoints públicos para: desarrollo en una laptop, el tercer nivel de una pila de failover (después de dos proveedores pagos), scripts de una sola ejecución. No corras trading en vivo de un bot contra un endpoint público como primario.
Nodo de Polygon autohospedado (cuándo tiene sentido)
Operar tu propio nodo full de Polygon es viable: Bor + Heimdall en un VPS de 4 vCPU/16 GB con ~2 TB de SSD, sincronizando en un par de días. La matemática a favor o en contra es simple.
Costo: aproximadamente $40-80/mes en VPS + storage en un proveedor grande. Unos 4x un plan RPC pago cómodo.
Ventaja: cero fees por request, sin rate limits y la menor latencia posible hacia el estado de la cadena (1-3 ms vs 20-50 ms por internet hacia un proveedor hospedado).
Pain: gestión de snapshots, Heimdall y Bor tienen modos de falla, y una sincronización trabada a mitad de trading produce lecturas obsoletas silenciosas.
Para el 95% de los builders, no lo autohospedes. Las horas dedicadas al mantenimiento del nodo superan por mucho el ahorro en la factura del RPC. Autohospeda solo si tienes una estrategia en la que 30 ms de latencia de lectura importan en términos de PnL y ya comprobaste la estrategia con un proveedor hospedado.
Benchmarks de latencia (US-East vs EU)
Tiempos medianos de ida y vuelta medidos desde VPS en tres regiones hacia el Polygon RPC más cercano de cada proveedor, mayo de 2026.
| Región del VPS | Alchemy | QuickNode | Ankr (pagado) | polygon-rpc.com |
|---|---|---|---|---|
| NY (US-East) | 14ms | 11ms | 22ms | 34ms |
| AMS (EU) | 21ms | 17ms | 28ms | 41ms |
| SG (Asia) | 97ms | 89ms | 110ms | 140ms |
Los números cambian semana a semana dentro de ~3 ms. El patrón es estable: QuickNode y Alchemy están dentro del ruido estadístico entre sí; Ankr queda consistentemente 5-10 ms detrás; los endpoints públicos quedan 15-25 ms detrás. Los bots alojados en Asia pagan un impuesto inevitable de ~80 ms contra la infraestructura backbone de Polygon centrada en Norteamérica.
Patrones de failover
Un solo RPC es un punto único de falla. Los bots de producción usan dos proveedores con una regla simple de intercambio.
Patrón: llamada primaria contra el proveedor A; en timeout (3s) o respuesta 5xx, reintentar contra el proveedor B; si ambos fallan, dormir 5s y reintentar el primario. Lleva el conteo de fallas consecutivas del primario y cambia automáticamente a B por 60s después de 3 fallas, luego vuelve a probar el primario.
Combinación recomendada: Alchemy pago como primario, Ankr gratis o el endpoint público de Polygon como respaldo. Usan operadores de nodos upstream distintos, así que un problema en uno rara vez está correlacionado con el otro. Evita correr dos endpoints del mismo proveedor (por ejemplo, dos keys de Alchemy): eso no da redundancia real.
Implementación: un wrapper delgado alrededor de web3.py o ethers.js que selecciona entre proveedores en cada llamada. Unas 30 líneas de código; se paga solo la primera vez que un proveedor sufre una caída regional.
