Confianza por diseño: qué mercados abrimos y cómo los resolvemos

Un mercado de predicción funciona o no funciona por una sola razón: confianza. Si la gente no cree que el resultado se va a resolver según las reglas que se le prometieron al abrir el mercado, no opera. Si no opera, no hay precio. Si no hay precio, no hay mercado.

Por eso, antes de cualquier consideración sobre liquidez, experiencia de usuario o catálogo, la prioridad número uno en Kiwik es que cada mercado se resuelva exactamente como dice que se va a resolver, sin ambigüedad y sin sorpresas. Este post describe cómo lo aseguramos: qué mercados elegimos abrir, qué tecnología usamos para detectar problemas antes de que existan, y cómo es el proceso cuando llega el momento de resolver.

Qué mercados abrimos

Solo abrimos mercados cuyo resultado sea verificable de forma independiente por cualquier persona con acceso a las mismas fuentes públicas que nosotros. Suena obvio, pero descarta una cantidad enorme de mercados aparentemente atractivos.

Tres criterios definen lo que pasa el filtro:

• Resultado público y observable. El evento debe poder verificarse contra una fuente que ya existe — un resultado deportivo oficial, un comunicado regulatorio, un anuncio público de una empresa que cotiza, datos de una elección certificada. Si para resolver el mercado tendríamos que tomar una decisión privada sobre algo que solo nosotros sabemos, no abrimos el mercado.
• Criterios de resolución explícitos antes de operar. Cada mercado declara, en su descripción, exactamente qué fuentes vamos a consultar, en qué momento, y qué cuenta como un "sí". No agregamos reglas a posteriori. Si después aparece una situación que las reglas no cubren, asumimos el costo nosotros — no el usuario.
• Bajo o nulo incentivo para que alguien quiera distorsionar el resultado. No abrimos mercados donde un participante con peso suficiente pueda mover el resultado real (no el precio, sino el resultado del evento) a su favor.

Cosas que no hacemos, como decisión explícita:

• Mercados sobre conflictos armados o eventos de guerra. Las reglas tienden a ser ambiguas, las fuentes son contradictorias y disputadas, y existe un costo humano en convertir esos hechos en oportunidades especulativas. No es el rubro de Kiwik.
• Mercados sobre deudas, quiebras o asuntos privados de personas físicas individuales. Verificación intrusiva, asimetría de información extrema y una invitación abierta al fraude.
• Mercados donde alguien tiene un incentivo claro a romper la ley para forzar el resultado. El desenlace de un proceso judicial en curso donde un participante puede sobornar testigos, eventos cuyo resultado depende de actores con baja accountability legal, escenarios donde un insider puede actuar antes de que el mercado cierre.
• Mercados con criterios de resolución que dependan de nuestro juicio subjetivo. "¿Fue justo el partido?" no es un mercado; "¿ganó el equipo X según el acta oficial?" sí lo es.

Si parece restrictivo, lo es. Preferimos abrir menos mercados y resolver bien, antes que abrir muchos y arrepentirnos.

Cómo evitamos abrir un mercado mal definido

Una pregunta aparentemente clara puede esconder una cantidad sorprendente de ambigüedades. "¿Será X presidente al 1 de enero?" parece directo, hasta que pasa cualquiera de estos:

• X gana la elección pero todavía no asume.
• X gana pero la asunción es disputada.
• La elección se posterga.
• X muere o renuncia entre la elección y la asunción.
• Hay un gobierno de transición ese día específico.

Cada uno de estos casos requiere una respuesta clara antes de que alguien opere, no después. Si no la tenemos, el mercado no se abre.

Para forzarnos a tener esa respuesta, montamos una capa de revisión adversarial que combina dos cosas: un proceso humano y un set de agentes de IA entrenados específicamente para "romper" mercados. La función de esos agentes es generar, a partir del enunciado y las reglas propuestas, escenarios donde el mercado no podría resolverse de forma limpia: edge cases, ambigüedades, inconsistencias entre reglas y descripción, situaciones donde dos fuentes oficiales se contradicen.

El proceso es simple en concepto. Cada mercado, antes de salir a producción, pasa por un ciclo donde estos agentes producen un set de escenarios problema, y nosotros — los humanos — tenemos que documentar la respuesta para cada uno, o reescribir las reglas hasta que el escenario quede cubierto. No hay mercado en producción sin que ese ciclo haya pasado al menos una vez. Si los agentes encuentran una ambigüedad genuina que no podemos cerrar sin reescribir la pregunta, el mercado no se abre, y punto.

Esta es una de las inversiones de ingeniería más importantes que hicimos en el último año: tratamos cada mercado como un contrato y a los agentes adversariales como nuestro equipo de auditoría interno antes del lanzamiento.

Cómo resolvemos un mercado

Cuando un mercado vence, el proceso de resolución también combina automatización y humanos, pero la decisión final la toma siempre una persona, no un agente. Esto es una decisión arquitectural deliberada, no un detalle.

El proceso a alto nivel:

1. Recolección automática de evidencia. Un set de agentes de IA recoge, exclusivamente de las fuentes que el mercado declaró desde el principio, la información necesaria para determinar el resultado. Cada agente actúa de forma independiente y deja rastro de qué fuente consultó, en qué momento, y con qué versión del contenido.
2. Validación adversarial entre agentes. Otro agente recibe la propuesta de resolución y argumenta el caso contrario — busca razones por las que la primera podría estar mal, fuentes alternativas, interpretaciones distintas. Si la disputa entre agentes no se cierra, el caso se escala automáticamente. Esto evita un sesgo común: que un solo modelo tenga un blindspot consistente.
3. Revisión humana. Una persona del equipo de resolución mira la propuesta, los argumentos a favor y en contra, y las fuentes. Si todo coincide y no hay disputa, aprueba. Si hay cualquier duda — interpretativa, factual o de fuentes — el mercado se pausa y se resuelve manualmente con el rastro completo del análisis.
4. Resolución y publicación. Cuando se resuelve, se publica la decisión, las fuentes consultadas y el razonamiento. El usuario ve no solo el resultado, sino por qué fue ese resultado.

Por qué este nivel de cuidado

Hay una historia larga de plataformas de mercados de predicción que tropezaron exactamente acá. Las resoluciones disputadas — donde la comunidad cree que el mercado se decidió mal — se han vuelto el escenario más costoso para una plataforma: se pierden usuarios, se pierde reputación y se pierde la confianza que tomó años construir. Wolfers y Zitzewitz lo plantearon con claridad ya en 2004:

"El valor informativo de un mercado de predicción depende totalmente de la credibilidad de su mecanismo de resolución; sin un mecanismo de resolución claro y confiable, los precios no se interpretan como probabilidades genuinas sino como ruido."¹

La industria aprendió esa lección a los golpes. Los protocolos descentralizados como UMA construyeron oráculos optimistas con períodos de disputa precisamente para amortiguar resoluciones controversiales²; las plataformas centralizadas que ignoraron esa lección pagaron caro. En Kiwik elegimos la ruta cara desde el inicio: revisión adversarial antes del lanzamiento, validación adversarial al resolver, y una persona firmando cada cierre.

No prometemos perfección — nadie puede. Prometemos algo más concreto: si algún día nos equivocamos, el rastro completo va a estar publicado, y la corrección la vamos a asumir nosotros, no quien operó.

— Producto @ Kiwik

Footnotes

1. Wolfers, Justin, y Eric Zitzewitz. "Prediction Markets." Journal of Economic Perspectives 18, no. 2 (Spring 2004): 107–126. Versión working paper disponible en NBER: https://www.nber.org/papers/w10504. ↩

2. UMA Project. "Optimistic Oracle: how UMA's oracle works." Documentación técnica del oráculo optimista usado por varios protocolos de mercados de predicción descentralizados, incluido el período de disputa que permite revertir resoluciones controversiales antes de que se confirmen on-chain. https://docs.uma.xyz ↩