3 de agosto de 2026

Visión general

runner.exchange es un launchpad de tokens sobre Robinhood Chain. Cualquiera puede lanzar un token al instante. Las compras y ventas se cotizan con una curva de bonding, y cuando una curva reúne su umbral de graduación el token gradúa: la curva se convierte en un pool de liquidez bloqueado permanentemente y propiedad del launchpad. No se emite ningún token de LP, y no hay ninguna vía de retiro. Esa última frase es todo el producto. Cada decisión de diseño se desprende de ella. Construí las dos mitades: los contratos en Solidity y la interfaz de trading.

El problema contra el que está construido

La categoría de los launchpads tiene un problema de reputación que se ha ganado. El fracaso estándar es el rug: se aporta liquidez, el token sube y luego la liquidez se va. La mayoría de plataformas responden con promesas: un periodo de bloqueo, un multisig, un compromiso del equipo, una insignia de auditoría. La premisa aquí es que una promesa es el instrumento equivocado. Si la liquidez puede retirarse, la pregunta es solo si alguien decide hacerlo. Por eso el pool graduado es interno al contrato del launchpad y no tiene función de retiro alguna. No es un timelock. No es un custodio de confianza. No existe una ruta de código que lo saque. El lema del sitio enuncia el mecanismo sin rodeos: cada token se gana su salida. Un token opera en su curva hasta reunir volumen real suficiente para graduar, y entonces su liquidez queda bloqueada para siempre y el trading continúa contra ella.

Diseñar en un contexto adversario

Diseñar una interfaz de trading no se parece a diseñar casi ningún otro producto, porque una parte de tus usuarios es activamente hostil y el resto se mueve rápido con dinero.

• La interfaz es monoespaciada y tipográfica, más cerca de una terminal que de una app fintech. No es nostalgia. Los números en tipografía proporcional son más difíciles de comparar de un vistazo, y esta es una pantalla donde leer mal un número cuesta dinero.
• Los mecanismos se enuncian, no se publicitan. La página de información abre con cómo funciona la graduación y qué puede y no puede hacer el owner, en lugar de con rendimientos. En una categoría construida sobre el hype, describir las restricciones es el argumento de venta.
• Los estados de carga están diseñados, no ausentes. Los datos de la cadena llegan tarde y desordenados. Las tarjetas esqueleto y un estado explícito de «cargando feed» existen para que un bloque lento nunca se lea como una página rota o, peor, como un saldo en cero.
• El flujo de lanzamiento es un formulario que se explica solo. Elegir entre modo de curva y modo de listado instantáneo es la decisión más consecuente que toma un creador, así que ambas opciones se describen completas en el punto de elección y no en la documentación.

Lo que el owner no puede hacer

El modelo de confianza de un launchpad lo definen sus poderes de administración, así que conviene ser explícito. El owner puede ajustar el esquema de niveles de comisión posterior a la graduación, acotado on-chain a un 3% total, y eso sí afecta a pools en vivo: una consecuencia honesta de las comisiones dinámicas. El owner no puede pausar el trading, tocar el ETH de las curvas ni las reservas de los pools bloqueados, acuñar o mover ningún token, alterar los parámetros congelados de una curva viva, ni actualizar los contratos. Tras el despliegue, la propiedad queda en un Safe multisig detrás de un timelock, y el runbook de despliegue trata el traspaso como una compuerta: el sistema no se considera vivo hasta verificar on-chain que runner.owner() == timelock. Escribir lo que no puedes hacer es más útil que listar lo que prometes no hacer.

Arquitectura

Contratos. Un proyecto de Foundry con versiones de herramientas fijadas y compilación vía IR. Un contrato singleton contiene tanto la lógica de la curva como el creador de mercado bloqueado, con tokens ERC-20 de suministro fijo por lanzamiento. Los parámetros de la curva deben satisfacer una igualdad exacta de aterrizaje entero verificada on-chain: los genera un script, nunca se escriben a mano, de modo que una curva no puede desplegarse en un estado donde su matemática de graduación no cierre limpiamente. Pruebas. Suites unitarias, de fuzzing y de invariantes sobre la curva, el hook y el router, incluyendo un archivo dedicado de pruebas de auditoría y una prueba de envenenamiento de pin. Las pruebas de invariantes importan más que las unitarias aquí: la propiedad que debe cumplirse no es «esta función devuelve el número correcto» sino «el balance del contrato siempre cubre cada curva viva, cada pool bloqueado y todas las comisiones sin cobrar». Un script de operaciones verifica exactamente esa solvencia contra el contrato desplegado. Indexador. La interfaz no consulta la cadena una vez por usuario. Un snapshot compartido en memoria se refresca con un temporizador y se sirve a todos los clientes, con una profundidad de reorganización configurable para que un bloque reorganizado no aparezca como operaciones fantasma. Tres variables de entorno intercambian latencia por costo de RPC, siendo el intervalo de sincronización del servidor la única palanca de costo real. En producción el snapshot persiste en Netlify Blobs, donde perderlo cuesta un reescaneo y nada más.

Tecnologías utilizadas

• Contratos: Solidity 0.8.30 con Foundry, compilado vía IR; suites unitarias, de fuzzing y de invariantes.
• Frontend: Next.js con wagmi v2 y viem para la cadena, TanStack Query para los datos, lightweight-charts para los gráficos de precio.
• Extras: LiveKit para audio en vivo en las salas de trading, React Three Fiber para piezas visuales, Supabase para datos fuera de cadena.
• Infraestructura: Netlify con Blobs para el snapshot del indexador; un Safe detrás de un timelock como owner de los contratos.
• Operaciones: runbook de despliegue, paquetes de verificación on-chain y un script de comprobación de solvencia.

Retos y aprendizajes

La permanencia tiene que ser estructural. Habría sido mucho más fácil publicar un retiro con timelock y llamarlo liquidez bloqueada. Eliminar la función por completo es un diseño más duro porque cierra opciones, incluida la de arreglar tus propios errores. Ese es el costo de que la garantía sea real, y la razón por la que la generación de parámetros y las pruebas de invariantes tenían que ser tan rigurosas. No puedes parchear un pool que no puedes tocar. Los datos de la cadena no son una base de datos. Los bloques se reorganizan, los endpoints RPC limitan el ritmo, y una interfaz ingenua que consulta por usuario convierte un lanzamiento popular en una caída autoinfligida. El indexador con snapshot compartido y un retraso de confirmación explícito fue la diferencia entre una demo y algo que sobrevive a su propio tráfico. El mejor trabajo de seguridad es legible. Un documento de revisión que nadie lee no protege a nadie. Enunciar los poderes de administración como una lista corta y acotada —incluido el poder que sí se conserva y por qué afecta a los usuarios— hace más por la confianza que una insignia de auditoría, porque quien lee puede contrastarlo con el código.

Resultado

Un launchpad cuya afirmación central es verificable en vez de prometida: liquidez que gradúa a un pool sin salida, comisiones que siguen fluyendo después de graduar, y un owner cuyos poderes son una lista corta que un escéptico puede leer en un minuto. La interfaz está hecha para quien lee números rápido, y los contratos para quien intenta romperlos.