Un desarrollador crea un chat donde cada mensaje tiene coste y va directo a la cadena TON
El proyecto Centence evita los muros legales y de las app stores haciendo que los usuarios firmen transacciones de envío de fondos directamente desde su billetera, sin que el servidor toque el dinero.
Un desarrollador móvil ha publicado los detalles de una aplicación de mensajería llamada Centence, donde enviar un mensaje cuesta dinero y el destinatario lo recibe directamente. La aplicación funciona como una Mini App de Telegram y utiliza la blockchain TON para ejecutar pagos reales, sin que la plataforma intermediaria llegue a tocar los fondos de los usuarios.
El creador del proyecto, que trabaja habitualmente con Kotlin, diseñó la arquitectura con dos restricciones imposibles: evitar que Apple y Google cobren su comisión del 30% por compras digitales, y eludir las licencias regulatorias para operadores de dinero. La solución técnica fue hacer que el servidor de la aplicación fuera incapaz de mover fondos. Los usuarios firman las transacciones desde sus propias billeteras a través de TON Connect, enviando el pago al destinatario y una comisión del 10% al creador en la misma operación.
El desafío técnico principal fue vincular una transacción en la cadena con un mensaje específico sin tener acceso a las claves privadas. El flujo funciona así: el cliente envía el texto al servidor, que calcula el precio y genera un identificador único (UUID). Luego, el usuario construye la transacción en su billetera, añadiendo el UUID como comentario o payload. Un índice en el servidor consulta a toncenter para detectar pagos a la billetera de la plataforma que coincidan con ese UUID y monto exacto. Solo entonces se desbloquea el mensaje para el receptor.
Stack tecnológico y lecciones aprendidas
El servidor se ejecuta con Bun y Fastify, utilizando SQLite en un volumen persistente. No usa Redis ni WebSockets; la sincronización se gestiona mediante sondeos cada siete segundos. El cliente está construido con React y Vite, todo en TypeScript para compartir tipos entre ambos lados. Esta simplicidad reduce la superficie de bugs, aunque el depurado resultó costoso al tratarse de dinero real.
El autor destaca tres errores críticos durante el desarrollo. Primero, la API v3 de toncenter devolvía nulo en el campo de comentarios, obligándole a decodificar manualmente el payload en formato base64 BOC de la cadena TON. Segundo, hubo un conflicto de formatos de dirección: la API devuelve direcciones en formato hexadecimal crudo, mientras que TON Connect requiere el formato legible comenzando por UQ. La conversión se solucionó con un parseo adecuado. Finalmente, la caché agresiva de la webview de Telegram obligó a implementar un sistema de verificación de versiones del lado del cliente para evitar que los usuarios ejecutaran builds obsoletos.
