Frontle

Frontle es un juego diario de geografía: te damos dos países y tenés que conectarlos por sus fronteras usando la menor cantidad de países posible. El que lo resuelve con el camino más corto —y si hay empate, más rápido— se lleva una parte del pozo del día, pagado en stablecoins.

Vive dentro de MiniPay, la billetera de Opera con más de 16 millones de usuarios, y corre sobre Celo. Ganó el tercer puesto en la hackathon Colombia de Celo y hoy está en revisión para publicarse dentro de MiniPay.

Qué tiene de raro

Casi toda app cripto empieza pidiéndote tres cosas antes de dejarte hacer nada: instalar una billetera, guardar doce palabras y conseguir el token nativo para pagar gas. Tres paredes antes de la primera pantalla útil.

Frontle no pide ninguna. Abre dentro de MiniPay, donde la billetera ya existe y ya tiene saldo. Y gracias a CIP-64 —abstracción de comisiones en Celo— el usuario paga el gas en el mismo USDT que ya tiene. Nunca ve CELO, nunca entiende qué es CELO, y no le hace falta.

La arquitectura

Tres capas, con una frontera explícita entre lo que es dinero y lo que no:

1. frontend/ — Next.js 16 y TypeScript. Toda la lógica de juego: el grafo de fronteras, la validación del camino, los mapas con d3-geo y topojson-client. Conecta a la billetera por window.ethereum nativo de MiniPay, sin librería de conexión, con Privy como respaldo fuera de MiniPay.
2. supabase/ — Postgres con RLS para el ranking, y Edge Functions en Deno disparadas por pg_cron. Acá vive lo que cambia seguido y no necesita estar en cadena.
3. contracts/ — El contrato FrontleGame en Celo Mainnet. Cobra, acumula y reparte. Nada más.

El reparto es 80% al pozo del día, 20% al protocolo (protocolBps = 2000). Si un nivel no tuvo ganadores, su pozo cae en cascada al siguiente nivel más difícil que sí los tuvo.

El patrón de oráculo

Esta es la parte que más me costó resolver bien.

El ranking vive en Postgres porque consultarlo en cadena sería absurdo de caro. Pero el premio no puede depender de una base de datos que yo controlo. La solución fue separar el cálculo de la verdad:

A las 00:10 UTC una Edge Function corre close-day: lee los ganadores del ranking por nivel y llama rollDay(day, winners) en el contrato. A partir de ahí el ganador llama claim(day, level) y cobra. Solo el operador puede invocar rollDay, y la tabla winners queda pública para auditar.

La fuente de verdad del premio es siempre el contrato. Postgres propone, la cadena dispone.

El reto diario es determinista: se deriva de la fecha UTC, sin aleatoriedad de servidor. Todo el mundo juega exactamente el mismo problema y cualquiera puede verificar que no se manipuló.

Qué haría distinto

• Modelar el pozo en cadena desde el primer día. La v1 del contrato (0x7Ea1...) no tenía niveles; agregarlos obligó a desplegar la v2 y migrar. Era previsible.
• Escribir el close-day con reintentos antes de necesitarlos. Un cron que mueve dinero y falla en silencio a las 00:10 UTC es un problema que te enterás tarde.
• Medir el embudo del primer intento gratis mucho antes. Es la métrica que de verdad importa y tardé en instrumentarla.

Dónde está

En producción en frontle.earth, con usuarios y dinero real, compitiendo en Proof of Ship, el programa mensual de builders de Celo. En revisión para entrar al catálogo de MiniPay.