Notas de ingeniería de Naly: Polymarket Gamma como capa reproducible de instantáneas de mercado

TL;DRLa ingesta de Polymarket Gamma da a Naly una vista pública y estructurada de eventos, mercados, resultados, precios, etiquetas y metadatos de resolución de los mercados de predicción. Naly usa esa capa para elegir candidatos a artículos, anclar resúmenes de desajustes de precio, respaldar historias de predicción de la KBO, preservar citas de fuentes y crear instantáneas de mercado duraderas para verificación posterior. La afirmación de ingeniería es simple: la confianza editorial empieza con insumos de mercado reproducibles, no con prosa generada.

Resumen

La API Polymarket Gamma debe tratarse como la fuente de descubrimiento de mercados y metadatos de Naly, no como una interfaz de trading. La documentación oficial de Polymarket separa Gamma de las API Data y CLOB: Gamma cubre eventos, mercados, etiquetas, series, metadatos deportivos, búsqueda, comentarios y perfiles públicos, mientras que CLOB maneja libros de órdenes, precios, diferenciales y operaciones de trading autenticadas. Para los artículos de Naly, ese límite es útil. La mayoría de los flujos editoriales necesitan el texto de la pregunta, la identidad del mercado, las etiquetas de resultados, las probabilidades mostradas, las etiquetas de categoría, las fechas límite y el contexto de resolución antes de necesitar detalles del libro de órdenes a nivel de tick.

La tesis de esta nota es que Naly debería ingerir Gamma en una capa versionada de instantáneas de mercado. Una instantánea no es la verdad; es el estado público observado del mercado en un momento específico, vinculado a URLs fuente y a cargas útiles brutas preservadas. Eso permite a Naly publicar lo que otros ocultan: el contexto del mercado, los límites de la señal y la evidencia exacta usada cuando se generó un artículo.

Dónde encaja en Naly

La ingesta de Gamma se ubica antes de la generación de artículos y después del descubrimiento de fuentes externas. En la ruta de publicación de Naly, aporta el lado de mercado de predicción del paquete de evidencia para cuatro usos posteriores:

Los resúmenes de desajustes de precio necesitan candidatos actuales de eventos y mercados, con suficientes metadatos para comparar las probabilidades implícitas del mercado con razonamientos respaldados por fuentes.
Los artículos de predicción de la KBO necesitan mercados deportivos, etiquetas de equipos o eventos, fechas límite de eventos y etiquetas de resultados que puedan renderizarse sin introducir manualmente el contexto del mercado.
Las citas de fuentes necesitan URLs de mercado estables, slugs de eventos e identificadores de mercado para que un lector pueda auditar por qué el artículo discutió un contrato específico.
La verificación de predicciones necesita instantáneas históricas para que la resolución posterior pueda puntuarse frente a la probabilidad que Naly realmente vio en el momento de publicación.

Los hechos del entorno local de ejecución importan sobre todo por la forma, no por la novedad. TypeScript 5.9 y tsx encajan razonablemente bien para scripts de ingesta; drizzle-orm con @neondatabase/serverless puede persistir registros normalizados y JSON bruto; Next.js 16 y React 19 pueden renderizar las páginas de artículos resultantes; los paquetes ai y Claude SDK pueden consumir el paquete de evidencia preparado solo después de que la ingesta haya hecho explícito el estado del mercado.

Mecanismo técnico

Un bucle robusto de ingesta de Gamma tiene seis etapas.

Descubrimiento. Usa eventos de Gamma cuando Naly necesite un descubrimiento amplio de mercados activos, y usa slugs de mercado o evento cuando un artículo esté anclado a una URL conocida de Polymarket. La guía de datos de mercado de Polymarket recomienda eventos para el descubrimiento activo completo porque los eventos incluyen mercados asociados, lo que reduce las llamadas a la API. Para trabajo por categorías, como deportes, las etiquetas y los metadatos deportivos deberían acotar el rastreo antes de clasificar candidatos.
Paginación. Gamma admite tanto endpoints de estilo offset como endpoints keyset. Para rastreos grandes o repetidos, la paginación keyset es más segura porque next_cursor se convierte en el token de continuación y offset se rechaza explícitamente en el endpoint keyset de mercados. Para trabajos de artículos más pequeños y focalizados, la paginación offset aún puede ser aceptable cuando la ventana de consulta es estrecha y la salida se guarda inmediatamente como instantánea.
Normalización. La regla clave de normalización es que las etiquetas de resultados y los precios de resultados deben mapearse por posición. El resumen de datos de mercado de Polymarket documenta outcomes y outcomePrices como arreglos uno a uno, así que la disciplina de índices importa. Un arreglo intercambiado no es un error cosmético; invierte la interpretación del mercado en el artículo.
Captura de instantáneas. Guarda tanto columnas normalizadas como JSON bruto. Las columnas normalizadas deberían incluir proveedor, marca de tiempo de obtención, id o slug de evento, id o slug de mercado, texto de la pregunta, id de condición cuando esté presente, identificadores de tokens cuando estén presentes, etiquetas de resultados, precios de resultados, banderas de activo y cerrado, hora de finalización, etiquetas, URL fuente y hash de la carga útil. El JSON bruto protege a Naly frente a cambios de esquema y permite que la verificación reproduzca el artefacto exacto de ingesta.
Puntuación de candidatos. Los trabajos de artículos deberían clasificar mercados usando criterios editoriales, no criterios de ejecución de trading: frescura, volumen o liquidez cuando estén disponibles, proximidad de resolución, disponibilidad de fuentes, ajuste de categoría y si el mercado puede producir un contraste claro para el lector. La puntuación de candidatos nunca debería implicar que un precio de mercado sea automáticamente incorrecto; debería marcar un mercado como digno de investigación.
Vinculación de publicación. Cuando un artículo generado cita un mercado, el artículo debería enlazar al id de la instantánea almacenada, la URL fuente de Polymarket y el conjunto de evidencia externa usado por el redactor. Esa es la diferencia entre una página que dice que el mercado estaba en 62 por ciento y una página que puede probar cuándo, dónde y de qué carga útil vino ese valor.

Los límites de tasa forman parte del mecanismo. Polymarket documenta limitación de solicitudes aplicada por Cloudflare y límites específicos de Gamma para /events, /markets, /tags, y /public-search. Naly no necesita acercarse a esos límites para la publicación diaria, así que la postura correcta es conservadora: concurrencia acotada, reintentos con jitter, hashes de carga útil para idempotencia y alertas cuando un trabajo recibe respuestas limitadas, vacías o estructuralmente inesperadas.

Qué dice la literatura

Trabajos recientes de arXiv respaldan el diseño centrado en instantáneas. Jia et al. describen los datos de mercados de predicción descentralizados como fragmentados entre metadatos off-chain, registros de trading a nivel de ejecución y eventos de resolución de oráculos, y luego defienden un sistema relacional unificado con resolución de identificadores, actualizaciones incrementales y mecanismos de consistencia. El sistema de publicación más pequeño de Naly tiene la misma clase de problema: los metadatos de mercado por sí solos no bastan a menos que luego puedan unirse con precios, afirmaciones de artículos y resultados de resolución.

El estudio de calibración de Le es directamente relevante para el lenguaje de los artículos. Usando grandes conjuntos de datos de Kalshi y Polymarket, el paper sostiene que la calibración depende del dominio, el horizonte y los efectos del tamaño de las operaciones; los consumidores que tratan los precios como probabilidades nominales pueden malinterpretarlos sistemáticamente. Para Naly, esto significa que un artículo debería decir probabilidad implícita de mercado, precio observado o señal pública de mercado, no verdad. El artículo puede discutir un posible desajuste de precio solo después de separar la observación bruta del mercado del modelo de Naly o del razonamiento respaldado por fuentes.

El paper de Dubach sobre la microestructura de Polymarket trata principalmente sobre datos del libro de órdenes, pero ofrece una advertencia útil para el diseño de ingesta: la evidencia de mercado de alta frecuencia tiene modos de error específicos de la fuente, demoras de ingesta y uniones que importan. Gamma es menos granular que los feeds del libro de órdenes, pero se aplica el mismo principio. La fuente de un número debe ser visible. Una instantánea de Gamma, un punto medio CLOB y un registro de operación on-chain están relacionados, pero no son intercambiables.

Madrigal-Cianci, Monsalve Maya y Breakey enmarcan los mercados de predicción como problemas inversos bayesianos en los que los historiales observados de probabilidad y volumen son ruidosos, endógenos y moldeados por tipos heterogéneos de traders. Eso refuerza la postura editorial de Naly. El estado de mercado ingerido es evidencia, no un veredicto. La buena ingeniería hace que esa incertidumbre sea inspeccionable en lugar de diluirla durante la generación.

Compensaciones de diseño

Gamma frente a CLOB es la primera compensación. Gamma da a Naly descubribilidad, contexto para artículos y metadatos. CLOB da precios más precisos y mecánica del libro de órdenes. Para artículos diarios de ingeniería y resúmenes de mercados de predicción, Gamma debería ser el insumo predeterminado porque responde de qué trata el mercado. CLOB puede añadirse cuando el artículo necesite precisión de diferencial, punto medio o historial de precios.

La ingesta centrada en eventos frente a la centrada en mercados es la segunda compensación. Centrarse primero en eventos es más barato para escaneos amplios porque un evento puede contener múltiples mercados y metadatos compartidos. Centrarse primero en mercados es más limpio para la verificación porque la puntuación final se adjunta a un resultado binario específico. Naly debería ingerir ambas formas, pero hacer que los enlaces de artículos apunten a la afirmación a nivel de mercado siempre que se evalúe un solo resultado.

JSON bruto frente a esquema tipado es la tercera compensación. Solo JSON bruto es fácil de almacenar pero difícil de consultar con seguridad. Solo columnas tipadas son fáciles de consultar pero frágiles cuando evolucionan los campos del proveedor. El patrón duradero es ambos: campos tipados para clasificación, renderizado y uniones; cargas útiles brutas para auditoría, reproducción y migración.

Renderizado en vivo frente a renderizado congelado es la cuarta compensación. Un widget de mercado en vivo puede ser útil, pero las afirmaciones del artículo deben vincularse a la instantánea del momento de publicación. De lo contrario, un artículo antiguo puede cambiar de significado silenciosamente cuando Polymarket mueve, cierra o resuelve un mercado. Para la estrategia de confianza de Naly, la evidencia congelada supera a la frescura cuando una página hace una afirmación fechada.

Modos de fallo

El fallo más peligroso es la desalineación entre resultado y precio. Si Yes y No las etiquetas se analizan por separado de los precios, el artículo puede invertir la señal y aun así parecer plausible.

El segundo fallo es la reutilización de mercados obsoletos. Un mercado puede estar activo durante el descubrimiento y cerrado para el momento de publicación. Cada trabajo de artículo debería revalidar los campos activo, cerrado, archivado y hora de finalización inmediatamente antes de vincular la instantánea.

El tercer fallo es la ambigüedad multimercado. Un evento de Polymarket puede contener varios mercados negociables. Un resumen puede citar el evento, pero un registro de verificación debe citar el mercado y resultado específicos que Naly evaluó.

El cuarto fallo es el cambio de esquema. Las API públicas cambian nombres de campos, valores predeterminados y relaciones anidadas. El almacenamiento de instantáneas debería incluir hashes de carga útil, versión del analizador, URL del proveedor y errores de validación para que el cambio sea observable.

El quinto fallo es exagerar la calibración. Un precio de mercado es una señal pública útil, pero la literatura advierte contra tratarlo como una probabilidad limpia en todos los dominios y horizontes. El texto de Naly debería preservar la diferencia entre probabilidad implícita de mercado, estimación de Naly y resultado realizado.

El sexto fallo es la pérdida de citas. Si un artículo solo almacena markdown renderizado, la verificación posterior no puede probar qué página de mercado y carga útil respaldaron la afirmación. Las uniones artículo-mercado deberían ser registros de primera clase, no prosa incrustada.

Notas de implementación

Una implementación práctica de Naly puede mantener pequeño el contrato de ingesta:

provider: polymarket-gamma.
provider_url: el endpoint exacto de Gamma o la URL pública de mercado usada para el descubrimiento.
fetched_at: marca de tiempo del servidor en UTC.
event_key y market_key: identificadores o slugs estables del proveedor.
question: texto canónico de la pregunta del mercado.
outcomes: etiquetas ordenadas.
outcome_prices: cadenas decimales ordenadas normalizadas a valores numéricos solo después de la validación.
status: banderas de activo, cerrado, archivado y publicabilidad.
raw_payload: respuesta completa del proveedor.
payload_hash: hash determinista para idempotencia y reproducción.
parser_version: el contrato de código que interpretó la carga útil.

El generador de artículos debería recibir esto como evidencia estructurada, no como texto suelto de prompt. Luego puede producir markdown mediante la pila de IA existente, renderizar con la canalización del sitio y mantener las citas adjuntas a registros fuente. Un worker de verificación puede unir posteriormente la instantánea de mercado del artículo con datos de resolución y puntuar si la afirmación publicada envejeció bien.

El principio de ingeniería es deliberadamente conservador: ingerir, normalizar, capturar instantánea, citar y luego escribir. Ese orden es más lento que pedirle a un modelo que navegue y resuma una página de mercado, pero crea el artefacto que Naly realmente necesita para adquisición y retención: un artículo público cuya evidencia de mercado puede reproducirse después de conocerse el resultado.