Predik V2: La próxima evolución de los mercados de predicción

Después de meses de investigación, diseño y pruebas, estamos listos para compartir lo que viene: Predik V2.

V2 no es un simple upgrade. Es una reimaginación completa de cómo deberían funcionar los mercados de predicción cuando se toman en serio tres problemas que el resto ignora:

Integridad del lanzamiento: ¿Cómo evitás que el PreMarket sea teatro y que el precio "real" aparezca recién cuando ya es tarde?
Ejecución vs Custodia: ¿Cómo lográs velocidad sin comprometer la seguridad de los fondos?
Resolución confiable: ¿Cómo garantizás que la verdad gane, incluso cuando hay incentivos para mentir?

Predik V2 responde estas preguntas con una arquitectura híbrida que combina Yellow Network (ejecución off-chain de alta velocidad) con BNB Chain (settlement y custodia on-chain). El resultado es un sistema que puede moverse rápido sin sacrificar confianza.

El problema que estamos resolviendo

Los mercados de predicción actuales tienen patrones predecibles de falla:

PreMarkets falsos: la mayoría son solo "registros de interés" sin riesgo real. Cuando el mercado finalmente abre, el precio inicial no refleja nada.
Manipulación de última hora: sin caps ni anti-sybil, las ballenas pueden mover precios justo antes del cierre.
Accounting roto: cuando la ejecución y la custodia están desacopladas, aparecen bugs que pueden drenar protocolos enteros.
Disputas baratas: si desafiar un resultado cuesta poco, el sistema se llena de griefing y nadie confía en las resoluciones.

Ninguno de estos problemas es nuevo. Pero la industria los trata como "tradeoffs inevitables" en vez de bugs a resolver. V2 los trata como bugs.

PreMarket es BET (no deposit pool)

La decisión más importante de V2 es esta: PreMarket es un mercado real de apuestas.

Cuando comprás YES o NO en PreMarket, no estás "reservando" una posición. Estás apostando ahora, con el LMSR determinando el precio basado en el flow real. Tu posición existe, tu riesgo existe, y el precio refleja información real.

La única restricción: no podés vender hasta que el mercado califique y pase a Live. Eso previene manipulación early-exit, pero mantiene la integridad del price discovery.

Cuando el mercado "gradúa" a Live, no hay conversión ni discontinuidad. El estado LMSR es el mismo, solo se habilita SELL. Esto elimina el "gap sniping" que destruye confianza en otros protocolos.

Yellow Network + BNB Chain: lo mejor de dos mundos

La arquitectura de V2 es híbrida por diseño:

Yellow Network (ejecución): sesiones off-chain gestionadas por ClearNode. Alta velocidad, bajo costo, sequencing determinístico via stateVersion.
BNB Chain (settlement): la custodia de USDC siempre vive on-chain en contratos auditados. Settlement batched con idempotencia y ordenamiento determinístico.

¿Por qué Yellow? Porque necesitamos velocidad para soportar mercados con alta frecuencia de trades sin gas fees prohibitivos. ¿Por qué BNB? Porque necesitamos un EVM maduro, con liquidez real de USDC y costos razonables para settlement.

El punto clave: Yellow es el execution layer, pero el dinero siempre vive on-chain. Si Yellow falla (sesión corrupta, desconexión, lo que sea), el sistema degrada a WithdrawalOnly mode: trading deshabilitado, pero retiros funcionan si la liquidez lo permite.

Session Watcher: el guardián silencioso

Porque confiamos en Yellow para ejecución, necesitamos un sistema que monitoree la salud de cada sesión 24/7. Ese sistema es el Session Watcher.

Watcher hace tres cosas críticas:

Heartbeat continuo: cada 5-15 minutos, verifica que stateVersion sea monotónico y que las firmas sean válidas.
Checkpointing: persiste snapshots del estado en cada trade exitoso y en cada transición de fase (PreMarket → Live, etc.).
Escalation ladder: cuando detecta un mismatch (soft o hard), activa automáticamente el protocolo de remediación:
- Soft mismatch → retry + log
- Hard mismatch → WithdrawalOnly + alerta a ops
- Unresolvable → close session con último snapshot válido + settlement conservativo

Esto no es paranoia. Es arquitectura que asume que cualquier componente puede fallar y diseña el sistema para que la falla no drene fondos ni deje users atrapados.

Caps anti-manipulación (porque Sybil existe)

PreMarket tiene caps estrictos diseñados para prevenir que una sola entidad domine el mercado:

Early cap: máximo 20% del volumen total por address hasta que se alcancen U_min participantes únicos (default: 15).
Concentration cap: máximo 33% del volumen total por address durante todo PreMarket.
Minimum commitment: para contar como "participante único", necesitás gastar al menos c_min (configurable por admin).

Estos caps no eliminan Sybil (ese es un problema imposible sin KYC), pero lo hacen costoso y lo vuelven detectable. Si alguien quiere manipular, va a tener que distribuir capital en muchas wallets y pagar tx fees por cada una. Eso cambia la economía del ataque.

Kleros + Bonos escalados: la verdad tiene que ganar

La resolución es donde la mayoría de los protocolos colapsan. Si desafiar un resultado es barato, el sistema se llena de griefing. Si es caro, nadie desafía resultados claramente incorrectos.

V2 usa bonos escalados que crecen linealmente con el tamaño del mercado:

bond = max(b_min, α × marketCollateral)

Donde:

marketCollateral = USDC total en el mercado
α = 2%
b_min = $25 (mínimo)
Sin máximo: un mercado de $1M requiere $20,000 de bond

Si alguien desafía, el caso va a Kleros (arbitraje descentralizado). El challenger pone el bond + arbitration fees. Si gana, recupera su bond + recibe el bond del proposer como reward. Si pierde, pierde todo.

Esto hace que las disputas honestas sean racionales y las disputes frívolas sean costosas. Y lo más importante: no hay "admin override". Si Kleros tarda 7 días, el mercado espera 7 días. La verdad importa más que la velocidad.

Settlement batched: gas-efficient y determinístico

Cuando un mercado se resuelve, el orchestrator cierra la sesión Yellow y genera batches de settlement on-chain. Cada batch incluye:

Array de users (ordenado determinísticamente por address)
Array de deltas (positivos o negativos)
batchNonce único para prevenir replay

Chunks default: 150-250 users por tx (adaptativo según gas). El sistema persiste cada batch en DB antes de enviarlo, para que retries usen el mismo payload y el contrato rechace duplicados via nonce.

Antes del primer batch, hay un Settlement Audit gate: el admin debe confirmar que la suma de los deltas calza con el collateral del mercado. Esto previene bugs de accounting que podrían drenar el vault.

Oracle tiering: de canónico a manual

V2 usa un sistema de 3 tiers para resolución:

Tier 1: oracles canónicos (ej: Azuro para deportes, feeds oficiales). Si disponible en 1h → auto-resolve.
Tier 2: múltiples fuentes públicas. Si al menos 2 coinciden → propone outcome. Si conflict → escala a Tier 3.
Tier 3: juicio manual del admin con criterios explícitos y evidencia citada.

Cada propuesta incluye un Evidence Packet con sources, timestamps, snapshot hashes y summary. Esto hace auditable cualquier resolución y da context a Kleros si hay disputa.

Fees: 1% on buys only, split 70/30

Simple:

1% fee on buys (sells are free, PreMarket no fees)
70% → Treasury (protocol revenue)
30% → Creator (claimable después de settlement)

Market Buffer no se usa para "inflar liquidez virtual" en V2. Es safety capital para upgrades futuros y como backstop en caso de edge cases.

Withdrawal-Only mode: trust-preserving safe mode

Si algo sale mal (session corrupta, accounting mismatch, etc.), el sistema entra en WithdrawalOnly:

Trading disabled
Withdrawals permitidos si FreeLiquidity ≥ withdrawal amount
Admin ve dashboard con remediation status

FreeLiquidity es definido explícitamente:

FreeLiquidity = TotalVaultUSDC - Σ(marketCollateral + fees + pendingRefunds + pendingSettlement)

Esto garantiza que nunca gastamos collateral reservado para otros mercados. Si el vault tiene free liquidity, los users pueden salir. Si no, tienen que esperar a que el problema se resuelva (o a que otros users reclamen refunds y liberen capital).

Gas-safe refunds: no homework para users

Si un mercado falla (no califica en el deadline), todos los PreMarket spends son refundables. Pero nunca iteramos sobre todos los users en una sola tx (gas trap).

En vez de eso:

markFailed(marketId) es O(1)
Users reclaman con claimRefund(marketId) o claimRefunds([marketIds])
El frontend auto-bundlea refund claims en el próximo withdraw/deposit/trade

Para el user, se siente automático. Para el sistema, es gas-efficient y seguro.

¿Qué viene después?

V2 es la fundación. Una vez que esto esté vivo y probado en producción, el roadmap incluye:

Merkle settlement (V2.5): exit proofs para máxima trustlessness
Multi-outcome markets (posiblemente con LS-LMSR)
Creator economy: herramientas para que cualquiera pueda lanzar mercados con seeds propios
Cross-chain: bridging a otras chains (L2s, alt-L1s)
Liquidity incentives: rewards para early LPs y market makers

Pero primero, V2. Porque si no podemos hacer esto bien — PreMarket real, ejecución confiable, resolución justa — nada más importa.

Timing

Estamos en desarrollo activo. El testnet está planeado para Q1 2025, con mainnet siguiendo después de auditorías y stress testing.

Mientras tanto, V1 sigue funcionando en Moonbeam. Los mercados existentes no se ven afectados. V2 será un deployment separado, y los users podrán migrar cuando estén listos.

Conclusión

Predik V2 no es un upgrade incremental. Es una apuesta de que los mercados de predicción pueden ser rápidos, seguros y honestos al mismo tiempo.

No es fácil. Requiere pensar en cada edge case, diseñar para el peor escenario, y asumir que cualquier componente puede fallar. Pero si lo hacemos bien, el resultado es un sistema que users pueden confiar — no porque "confiamos en el equipo", sino porque la arquitectura no permite otra cosa.

Eso es lo que estamos construyendo.

Predik V2: La próxima evolución de los mercados de predicción