Tonalli Memo ya vive en mainnet: texto, NFTs y enlaces sobre eCash
Lo importante no es convertir OP_RETURN en una red social gigantesca. Es demostrar que una capa pequeña, verificable y autocustodiada puede crecer sin romper su formato canónico.
Tonalli Memo cruzó una línea que suele separar los prototipos de la infraestructura: ya no es solamente una idea de mensajería on-chain. Hay publicaciones reales en eCash mainnet, un indexador que las consume en vivo, un feed que distingue estados de verificación y una interfaz capaz de enriquecer el mismo payload con referencias NFT y enlaces seguros.
El punto técnico clave es que esta evolución se hizo sin cambiar el wire format de TM1 Draft 0.2. El formato canónico sigue siendo pequeño y deliberadamente rígido; las nuevas capacidades se construyen alrededor de él como convenciones de aplicación, verificación y presentación.
Un protocolo mínimo, no una página web disfrazada de blockchain
TM1 identifica sus mensajes mediante el LOKAD ID 544d4d00 —los bytes de TMM\0—, usa versión 0x01 y un evento POST 0x01. El límite de compatibilidad del script es de 223 bytes; dentro de ese presupuesto, el campo eventData puede ocupar hasta 212 bytes UTF-8.
@nft1: + tokenId + saltoEso obliga a ser disciplinados. Tonalli Memo no intenta incrustar HTML, imágenes o metadatos gigantes dentro de cada transacción. Guarda una señal canónica y deja que indexadores y clientes hagan el trabajo pesado de lectura y presentación.
De la transacción al feed: Chronik como nervio de lectura
El flujo de producción ya conecta la wallet con un indexador dedicado. La publicación se firma y transmite como una transacción eCash; Chronik la detecta desde mempool, el servicio tonalli-memo la interpreta y el read model la expone al feed público.
En pruebas de producción se verificó algo especialmente importante: no fue necesario un backfill administrativo para cada publicación. Un segundo memo llegó al indexador automáticamente desde mempool por WebSocket y después avanzó a estado confirmado. Es la diferencia entre una demo que “sabe leer una transacción” y un sistema que empieza a comportarse como servicio vivo.
Tres huellas mainnet que cuentan la historia
Primer canary TM1:
Primer auto-ingest live desde mempool:
Primer Memo + NFT:
Adjuntar un NFT sin convertir TM1 en otro protocolo
La solución para NFTs es deliberadamente conservadora. El mensaje puede comenzar con una directiva textual:
@nft1:<64_hex_token_id>\n<mensaje opcional>La directiva ocupa 71 bytes. El backend extrae el tokenId y comprueba de manera independiente que el activo sea un SLP NFT1 Child y que la wallet observada posea el token en el momento del indexado. Si la evidencia es positiva, el attachment queda marcado como VERIFIED_AT_INDEXING.
La imagen y el resto de la metadata no se consideran parte de la prueba de propiedad. RMZWallet resuelve el genesisInfo.url, obtiene el JSON desde IPFS y después resuelve metadata.image con failover entre gateways. Así, una caída de IPFS puede afectar la presentación, pero no cambia el estado criptográfico que ya decidió el backend.
El primer NFT mostrado en el feed fue “Evangelio RMZ del Xoloitzcuintle — Bloque Génesis”, tokenId:
Hipervínculos: la URL viaja on-chain, la seguridad vive en el cliente
Las URLs no requirieron otra extensión del protocolo. Si el usuario escribe https://..., esos mismos bytes quedan dentro de eventData. El feed convierte solamente esquemas http: y https: en enlaces clickeables usando nodos React, sin interpretar HTML del usuario.
El renderer añade noopener, noreferrer, nofollow y ugc; además rechaza URLs con credenciales embebidas como https://trusted.example@evil.example, una forma clásica de disfrazar el host real. También aplica aislamiento bidireccional para reducir spoofing visual.
Adiós al límite histórico de 80 bytes
Mientras Tonalli Memo era apenas un micro-mensaje, la wallet mantenía una política conservadora de 80 bytes. Los hipervínculos hicieron evidente que ese límite ya no correspondía con la capacidad real de TM1. La política de Composer ahora es dinámica:
El contador usa bytes UTF-8 reales, no caracteres. Si alguien escribe 180 bytes y después adjunta un NFT, el texto no se trunca: la interfaz cambia el límite efectivo a 141, marca error y bloquea publicación hasta que el usuario reduzca el contenido o retire el NFT. El wire final nunca puede superar 212 bytes.
Qué significa “verificado” en Tonalli Memo
Conviene separar tres cosas que visualmente pueden aparecer juntas: la validez del payload TM1, la autorización de publicación en la interfaz oficial y la metadata externa.
TM1 define cómo reconocer y decodificar el mensaje. La aplicación oficial añade una capa de autoridad basada en identidad .xec, verificación de ownership y estados de recuperación antes de firmar. En attachments NFT, el backend verifica propiedad del token al indexar. IPFS, en cambio, solamente enriquece la presentación.
Importante: Tonalli Memo no convierte cada dato remoto en verdad criptográfica. Un badge de ownership no certifica que una descripción o imagen IPFS sea “verdadera”; certifica una relación específica observada por el backend. Esa separación de confianza es una característica, no una limitación accidental.
¿Es ya una red social descentralizada?
No en el sentido amplio. No hay timeline algorítmico complejo, almacenamiento multimedia on-chain ni un sistema universal de moderación. Y esa modestia técnica es precisamente parte de su valor.
Tonalli Memo hoy se parece más a una capa social verificable y mínima sobre eCash: identidad, pequeños mensajes, enlaces, referencia a activos y lectura pública. Su base es una transacción que cualquier tercero puede volver a interpretar sin depender del HTML de una página específica.
Eso abre una ruta interesante para comunidades, wallets y agentes: los clientes pueden construir experiencias distintas sobre el mismo rastro canónico, siempre que respeten la semántica del protocolo y distingan con cuidado lo que está firmado, lo que fue verificado por un servicio y lo que solamente viene de una fuente externa.
La lección para eCash
eCash suele discutirse desde pagos, escalabilidad o pre-consensus. Tonalli Memo muestra otra propiedad: una L1 de bajo costo y confirmación rápida puede servir también como sustrato para pequeñas declaraciones públicas verificables.
El avance no está en “meter redes sociales en la blockchain”. Está en construir una ruta donde cada capa conozca sus límites: TM1 conserva un formato compacto; Chronik entrega observabilidad; el indexador produce un read model; la wallet conserva autoridad de firma; IPFS resuelve metadata; y el front-end transforma bytes en una experiencia legible.
Después de meses de gates, pruebas, merges y canaries, Tonalli Memo ya no es una maqueta. Tiene transacciones mainnet, ingestión automática, un NFT verificable en el feed, enlaces seguros y el presupuesto completo de TM1 habilitado en producción.
Probar Tonalli Memo
El feed y el Composer están disponibles en la wallet Tonalli.