Notas de Ingeniería de Naly: Ingesta de la API Gamma de Polymarket para artículos sobre mercados de predicción

TL;DRNaly ingiere la API Gamma de Polymarket como un sustrato determinista de descubrimiento y fijación de precios para todos los flujos de trabajo de mercados de predicción, reemplazando scrapes de noticias ad hoc con entidades de mercado estructuradas. En cada ciclo, convierte eventos y mercados en vivo en señales listas para artículos para recopilaciones de infravaloración, vistas previas de KBO, paquetes de citas y verificación posterior de resultados, de modo que la generación de historias siempre comience desde probabilidades y estructura de mercado observables públicamente, en lugar de opiniones inferidas.

Resumen

Naly usa datos de mercados de predicción como infraestructura, no como superposición, por lo que los artefactos editoriales quedan directamente ligados a un estado de mercado externo que luego puede auditarse. La API Gamma ofrece una ruta de lectura para eventos, mercados, etiquetas y precios sin requerir claves a nivel de wallet. El reto de diseño consiste en mantener esa capa de ingesta lo bastante estricta para la fiabilidad y, a la vez, suficientemente flexible para los equipos de contenido que necesitan descubrir temas con rapidez.

Dónde se ubica en Naly

La ingesta de Polymarket Gamma se encuentra en el límite superior entre los primitivos de mercado en bruto y los activos editoriales publicables. Es el primer paso de un pipeline más amplio:

Capa de entrada: obtener eventos, mercados, etiquetas y estados de mercado desde Gamma.
Capa de interpretación: normalizar en el esquema interno de Naly (event_id, market_id, IDs de token, outcomes, probabilities, timestamps, active/closed flags).
Capa narrativa: alimentar entradas normalizadas a los flujos de compilación de infravaloración y redacción de predicciones de KBO.
Capa de validación: guardar estados de mercado resueltos/cerrados para la verificación de verdad de los artículos y las scorecards retrospectivas.

A fecha de 10 de junio de 2026, esto está especialmente alineado con tácticas activas que requieren evidencia de forecasting fiable y lista para citar: visibilidad de calibración de predicciones, obtención repetible de contenido y flujos de verificación posteriores.

Mecanismo técnico

Polymarket define tres API, con Gamma como el plano de descubrimiento público para la navegación y metadatos de eventos/mercados, mientras que los datos de libro de órdenes/estilo trading se exponen por CLOB y los datos de usuario/posiciones por la API de Data (docs). Gamma y Data son públicas según la documentación de Polymarket, mientras que CLOB tiene superficies privadas/comerciales que requieren autenticación para operaciones de orden.

Naly puede implementar un flujo diario robusto con solo endpoints públicos:

Descubrir mercados candidatos activos mediante GET /events con active=true, closed=false, paginación (limit, offset), y filtros de ordenación opcionales.
Expandir a mercados constituyentes usando cargas útiles a nivel de evento, ya que los eventos incluyen los mercados asociados y reducen las llamadas a la API en comparación con búsquedas de mercado separadas.
Apuntar a entidades exactas usando llamadas basadas en slug cuando ya se identifica un evento o mercado.
Normalizar precios mapeando outcomes y outcomePrices arrays índice por índice a probabilidades con nombre.
Persistir artefactos de auditoría tanto como filas normalizadas como instantáneas brutas para que cada artículo pueda rastrear cada cifra de origen.
Restringir la generación aguas abajo según checks de frescura + esquema; las instantáneas obsoletas o incompletas se marcan para refrescar antes de usar.

La documentación de Gamma describe exactamente esta forma operativa: endpoints públicos como /events, /markets, /public-search, /tags, y /series están disponibles para descubrimiento, mientras que paginación y filtrado se admiten mediante limit/offset, tag_id, y filtros relacionados. También ofrece recomendaciones directas para tres patrones de recuperación: búsqueda por slug, descubrimiento basado en etiquetas y enumeración de eventos para escaneos amplios. Para Naly, el patrón de evento primero es el más rentable al construir grandes candidatos diarios porque cada evento puede mostrar muchos registros de mercado.

En la práctica, un registro mínimo de fuente de verdad para Naly debería incluir:

IDs de evento y mercado
mercado question
clobTokenIds (para reconciliación posterior de precios con CLOB cuando sea necesario)
outcomes y outcomePrices
enableOrderBook
active, closed, y campos temporales (timestamps de inicio/fin)
marca de tiempo de obtención y URL de origen

Aunque Gamma ya puede aportar una base probabilística sólida, existe una ruta de refinamiento secundaria opcional: cuando Naly necesita actualizaciones intradía de intervalo más corto, los endpoints de CLOB como /price, /prices, o /book , pueden fusionarse más tarde.

Lo que dice la literatura

La investigación sobre mercados de predicción respalda este enfoque de datos primero, pero añade guardarraíles alrededor de la interpretación.

El modelo de datos de mercado en mercados de predicción solo es útil si está calibrado e interpretado correctamente; los precios no son probabilidades universales sin contexto. Un estudio de 2026 sobre Polymarket y Kalshi encontró patrones de calibración sistemáticos que varían por dominio y horizonte, incluyendo subconfianza medible en espacios específicos.
Otro estudio de 2026 centrado en el ciclo de vida enfatiza que un análisis de mercado con sentido requiere ingeniería de datos multicapa sincronizada: metadatos de mercado, eventos de trading y señales de resolución necesitan vínculos explícitos y revisiones periódicas de consistencia, en lugar de extracciones aisladas.
Trabajos anteriores sobre microestructura de mercado muestran que los precios transmiten información de los traders bajo un flujo estilo subasta continua, por eso Naly puede tratar los precios de mercado como señales de pronóstico colectivo mientras valida resultados con el tiempo.
La literatura de pronóstico que compara precios de mercado con otros métodos (por ejemplo, pronósticos basados en encuestas) muestra que los mercados de predicción pueden ser altamente predictivos, pero solo cuando se conserva la verificación de resultados y la disciplina del modelo.

La consecuencia práctica para Naly es directa: ingerir todo con procedencia, nunca tratar una sola instantánea de precio como verdad final, y separar readiness (frescura + integridad de datos) de story quality (encuadre editorial).

Compromisos de diseño

Naly optimiza intencionalmente por fiabilidad sobre velocidad en la ingesta.

Solo Gamma versus Gamma+CLOB: Gamma aporta descubrimiento estable y contexto público rápidamente; agregar CLOB mejora la riqueza de microestructura pero añade complejidad de autenticación y de endpoints.
Instantánea diaria frente a streaming continuo: una extracción programada determinística es más fácil de auditar y reproducir que los flujos continuos, pero pierde cambios de régimen subminutales.
Extracción primero por evento frente a extracción primero por mercado: el enfoque por evento reduce llamadas duplicadas y mejora la cobertura contextual; el enfoque por mercado da un payload ligeramente menor para tareas puntuales.
Esquema amplio frente a esquema estricto: un esquema JSON-first amplio acelera la integración pero aumenta el riesgo de deriva de esquema; la normalización estricta detecta la deriva antes, pero incrementa la sobrecarga de migración.
Campos generalizados frente a campos específicos del dominio: usar campos compartidos mejora la reutilización entre artículos; agregar extensiones específicas del dominio (por ejemplo, ventanas de confianza específicas de deporte) aumenta la precisión inmediata pero puede fragmentar el mantenimiento a largo plazo.

Dado el objetivo de Naly de confianza y retención, la reproducibilidad estricta y la calidad de citas deberían dominar sobre la optimización inmediata de latencia.

Modos de fallo

Los modos de fallo más grandes son operativos, no algorítmicos.

Falta de datos por errores de paginación: si limit y offset las ventanas cambian entre sondeos, pueden aparecer duplicados o huecos. Mitigación: registrar cursores de paginación y aplicar upserts idempotentes.
Predeterminado closed=false descartar contexto histórico: las extracciones de mercado abierto omiten elementos resueltos a menos que closed=true se solicite explícitamente. Mitigación: ejecutar una ruta de backfill histórico dedicada para tareas de verificación.
Inestabilidad del slug: las URL de producto y los slugs legibles por humanos pueden desviarse. Mitigación: preferir IDs primarios internamente y conservar el slug como clave secundaria.
Deriva semántica de campo: outcomes/outcomePrices la interpretación puede romperse si las suposiciones de orden del esquema son incorrectas. Mitigación: afirmar la alineación de arrays y verificaciones de longitud en la ingesta.
Disponibilidad transitoria o throttling de API: los endpoints públicos pueden fallar o devolver payloads parciales. Mitigación: reintentos con backoff exponencial, cola de fallos para errores repetidos y conservar snapshots previas.
Resolución tardía y narrativas obsoletas: los artículos de verificación pueden ejecutarse antes de que la liquidación se asiente limpiamente. Mitigación: guardar el estado de liquidación como parte del estado de publicación y actualizar posteriormente con un registro de correcciones inmutable.

Dada la estrategia first-trust de Naly, el pipeline debe fallar en modo cerrado: es mejor retrasar un artículo que publicarlo con un estado de mercado no verificable.

Notas de implementación

Con el stack de runtime indicado, una implementación práctica sigue siendo directa:

Usar manejadores de servidor de Next.js (next@16.0.7) para alojar endpoints de ingesta y jobs programados.
Persistir filas normalizadas en Neon usando drizzle-orm@^0.44.7 upsert sobre @neondatabase/serverless@^1.0.2 con restricciones únicas explícitas en identificadores de mercado.
Guardar snapshots de payload sin procesar en Vercel Blob (@vercel/blob@^2.0.0) para auditabilidad y comparación posterior para post-mortem.
Mantener la generación de origen markdown y el ensamblaje del artículo fuera del núcleo de ingesta; usar marked@^17.0.1 para transformaciones seguras y ai@6.0.0-beta.105 además @anthropic-ai/claude-agent-sdk@^0.2.15 solo después de que pasen los controles de integridad de datos.
Usar tsx@^4.21.0/typescript@^5.9.3 para replays puntuales reproducibles cuando se hace backfilling de ventanas históricas.

El 10 de junio de 2026, la arquitectura debería priorizar tres resultados duros: inmutabilidad de la snapshot sin procesar, proyección determinística en el esquema interno y una trazabilidad de auditoría orientada a verificación desde la URL de la API de origen hasta la cita final del artículo.