LS-LMSR: Liquidez unificada para mercados de predicción

LS-LMSR: Liquidez unificada para mercados de predicción

En mercados de predicción, casi todo se reduce a una sola cosa: liquidez. Si un mercado tiene poca liquidez, el precio se mueve de más, el spread se siente, y terminás con probabilidades que no reflejan información real sino fricción.

Por eso, en Predik venimos pensando (y leyendo mucho) sobre cómo mejorar el market making en la próxima versión cuando implementemos nuestra infraestructura. Uno de los enfoques más interesantes es LS-LMSR, una variante de los AMMs tipo LMSR que apunta a unificar liquidez en mercados multi-outcome.

El problema: la liquidez se fragmenta

Muchos mercados multi-outcome (por ejemplo, “¿Quién gana la elección?” con varios candidatos) terminan implementándose como varios submercados separados: “Candidato A Sí/No”, “Candidato B Sí/No”, etc.

Ese diseño tiene una trampa: dividís la liquidez. En la práctica, eso trae varios síntomas:

• Slippage alto: con poco volumen, una compra chica ya empuja el precio.
• Probabilidades incoherentes: si cada submercado “vive” por separado, es fácil terminar con odds que no suman 100%.
• Long tail muerto: los outcomes menos populares quedan sin liquidez y se vuelven impracticables.
• Peor experiencia: el usuario siente que “no hay mercado”, aunque haya interés.

La intuición: un solo pool para todos los outcomes

La idea detrás de LS-LMSR es simple de explicar: en vez de repartir la liquidez en muchas piletas, usás una sola pileta compartida para todo el mercado.

Eso tiene una consecuencia clave: cuando alguien compra el outcome A, A sube y, por construcción, los demás bajan. Así, el mercado mantiene una distribución coherente (las probabilidades se comportan como un conjunto y no como islas separadas).

¿Qué es LS-LMSR (sin matemáticas pesadas)?

LS-LMSR se puede pensar como un “motor de precios” que siempre devuelve una probabilidad para cada outcome, y esas probabilidades están acopladas entre sí.

En modelos tipo LMSR, las probabilidades suelen tomar una forma softmax (esto es una intuición, no una receta de implementación):

p_i = exp(q_i / b) / Σ_j exp(q_j / b)

Donde q_i representa el “inventario”/exposición asociada al outcome i, y b controla cuán fácil se mueve el precio (en criollo: cuánta “profundidad” tiene el mercado).

LMSR vs LS-LMSR: el punto clave es b

En LMSR clásico, b suele ser fijo. Y ahí aparece un problema operativo: lo que funciona para un mercado chico puede ser malo para uno grande.

• Si b es muy chico: el mercado es sensible y se mueve con nada (puede ser divertido, pero también volátil).
• Si b es muy grande: el mercado se vuelve “pesado”, con precios que reaccionan lento y requieren mucho capital.

LS-LMSR introduce la idea de que b sea adaptativo (por ejemplo, creciendo con el “tamaño” del mercado). Intuición: al principio, el mercado se puede mover con poco; con más profundidad y actividad, el sistema se vuelve más estable y eficiente.

¿Qué podría significar esto para Predik?

Esto no es un anuncio de roadmap, pero sí una dirección que podríamos explorar en la siguiente versión cuando implementemos infraestructura para soportarlo bien.

En términos prácticos, un enfoque LS-LMSR podría habilitar:

• Mercados multi-outcome nativos: una sola interfaz, una sola fuente de verdad para las probabilidades.
• Menos slippage en mercados nuevos: porque la liquidez se comparte entre outcomes.
• Mejor long tail: outcomes “chicos” heredan profundidad del pool común.
• Probabilidades más coherentes: la suma de probabilidades se mantiene controlada por diseño.

Esto es especialmente relevante para eventos con muchas opciones: elecciones, torneos, premios, lanzamientos, etc. Si el mercado es uno solo, no dependés de que cada outcome tenga su mini-comunidad para ser operable.

Tradeoffs (lo que hay que tomar en serio)

Ningún diseño te regala todo. Algunas cosas que hay que evaluar con cuidado:

• Volatilidad temprana: si al inicio el sistema es muy sensible, puede ser más manipulable o más ruidoso.
• Calibración: definir cómo crece b con el tamaño del mercado es un arte (y un riesgo si se hace mal).
• Implementación robusta: onchain y/o backend requiere cuidado numérico (exp/log, estabilidad, límites).
• UX: multi-outcome tiene que sentirse simple; si no, la mejora técnica no se traduce en adopción.

Una nota importante

Esto es un enfoque exploratorio. Si Predik avanza por este camino, va a depender de investigación, simulaciones, auditorías y validación en producción. Tampoco es consejo financiero: es diseño de mecanismos y experiencia de producto.

Si te interesa este tipo de temas (AMMs, diseño de incentivos, mercados de predicción), vamos a seguir publicando cómo pensamos estas decisiones.

¿Querés ver mercados en vivo? Explorá los mercados activos en Predik y hacé tu predicción.