Seraphis y Jamtis: el gran salto del protocolo Monero explicado

Cuando el Monero Research Lab fusionó discretamente la primera rama auditada de la librería Seraphis en el fork de pruebas a finales de 2025, confirmó algo que los observadores del protocolo venían rastreando desde hacía casi cuatro años: Monero se prepara para la reescritura más profunda de su capa de transacciones desde que RingCT entró en producción en 2017. Seraphis no es una actualización cosmética. Sustituye por completo el protocolo de transacciones, las pruebas criptográficas que protegen la ambigüedad del emisor y el esquema de direcciones que el usuario ve en su billetera. Jamtis, la capa de direccionamiento diseñada para montar sobre Seraphis, jubila el formato de subdirecciones que ha sido el pilar de toda billetera Monero durante media década.

Esta guía desmenuza ambos: qué son, por qué los investigadores principales (koe, jberman, UkoeHB) han dedicado miles de horas a construirlos, qué cambia para el usuario de a pie y cómo un servicio sin KYC como MoneroSwapper gestiona la migración sin obligar a sus clientes a reaprender cómo gastar de forma privada. Si alguna vez has enviado o recibido XMR, la dirección que utilizaste acabará quedando obsoleta. Entender ahora la actualización sale mucho más barato que improvisar el día del hard fork.

Por qué Monero necesitaba Seraphis

El protocolo de transacciones actual de Monero es una colcha de retales. La prueba base, CLSAG, sustituyó a MLSAG en el hard fork de octubre de 2020 y redujo el tamaño de la firma de anillo en torno a un 25%, pero sigue operando sobre un anillo fijo de dieciséis señuelos seleccionados entre salidas recientes. Dieciséis-entre-muchos suena robusto, pero las heurísticas estadísticas, el análisis temporal y el famoso "ataque EAE" (Eve-Alice-Eve) van mordisqueando el anonimato del emisor en modelos adversariales. Desde 2019, varios artículos académicos revisados por pares han mostrado cómo un analista bien financiado, con visibilidad amplia sobre el mempool, puede desanonimizar de forma probabilística una fracción no trivial de las salidas.

El argumento de la fungibilidad agrava el problema. Cada anillo CLSAG incluye un gasto real y quince señuelos, pero esos señuelos son a su vez salidas de transacciones anteriores. Si dos transacciones se referencian mutuamente como señuelos, y el análisis de la cadena puede descartar una de las posibilidades, eso afina la probabilidad contra la otra. El sistema es robusto en agregado, pero gotea por los márgenes. Seraphis cierra esa fuga ensanchando drásticamente el conjunto de anonimato y, al mismo tiempo, reestructurando la prueba para desacoplar pertenencia y propiedad.

• Conjunto de anonimato mucho mayor: Seraphis está diseñado para soportar pruebas de pertenencia sobre 128 o 256 salidas (o más, según la curva y el sistema de pruebas elegidos en la activación), en lugar de 16. La matemática es logarítmica respecto al tamaño de la prueba, así que 128-entre-muchos cuesta apenas algo más de bytes que los actuales 16-entre-muchos de CLSAG.
• Separación más limpia de responsabilidades: Hoy, una sola prueba CLSAG empaqueta a la vez "soy dueño de una de estas salidas" y "todavía no la he gastado". Seraphis separa eso en una prueba de pertenencia y una prueba de composición. Cada una puede optimizarse, auditarse y actualizarse de forma independiente.
• Cirugía sobre la clave de visualización: La clave de visualización actual revela cada salida entrante a quien la posea. Auditores, exchanges y asesores fiscales reciben todos la misma manguera. Seraphis introduce claves de visualización por niveles, de modo que el usuario puede conceder acceso de solo lectura a los ingresos sin exponer las salidas de cambio ni los autoenvíos.
• Pruebas intercambiables: La arquitectura de Seraphis trata las pruebas de pertenencia como módulos enchufables. El objetivo actual es FCMP++ (Full-Chain Membership Proofs Plus Plus), que permitiría que cualquier salida de la cadena actuase como señuelo potencial. Pasar de dieciséis a toda la UTXO es un salto cualitativo, no cuantitativo.

Nada de esto significa que CLSAG esté roto hoy. Significa que el espacio de diseño ha avanzado, la criptografía académica ha madurado y la cultura investigadora de Monero se niega a aceptar el "ya está bien" cuando hay un "demostrablemente mejor" sobre la mesa. El precio es complejidad de ingeniería y una transición de varios años; el beneficio es una postura de privacidad capaz de aguantar la próxima década de herramientas de análisis.

Cómo Seraphis remodela las transacciones

Seraphis es un protocolo de transacciones completo, no una primitiva aislada. Para entender qué cambia conviene seguir paso a paso lo que ocurre al enviar XMR hoy y contrastar cada paso con su equivalente Seraphis. Las diferencias son sutiles a nivel de experiencia de usuario, pero profundas debajo del capó.

De CLSAG a pruebas de composición + pertenencia

Con CLSAG, tu billetera elige quince señuelos de la cadena, construye un anillo de dieciséis y firma una prueba afirmando que una de esas dieciséis salidas es tuya y que no has hecho doble gasto. Con Seraphis, tu billetera construye dos pruebas distintas. La prueba de composición dice "soy legítimamente dueño de una salida concreta dentro de este conjunto, y aquí está la imagen de clave que demuestra que no la he gastado antes". La prueba de pertenencia dice "la salida a la que hago referencia existe dentro de este conjunto de anonimato mayor en la cadena". Ambas pruebas están enlazadas criptográficamente, pero se generan por separado, y eso es justo lo que permitirá ampliar el conjunto de anonimato más adelante sin tener que rediseñar todo el formato de transacción.

Las propias imágenes de clave también se rediseñan. La imagen de clave actual se deriva de forma determinista a partir de la clave de salida de un solo uso y la clave de gasto: una construcción elegante, pero foco de investigación sobre casos límite desde hace años. Seraphis introduce un nuevo formato de imagen de clave, compatible hacia adelante con FCMP++, el sistema de pruebas de pertenencia con el que los investigadores aspiran a que, eventualmente, el conjunto de anonimato abarque todo el UTXO de la cadena.

Carrot: la nueva capa de codificación de salidas

Carrot es el esquema de codificación de salidas diseñado junto con Seraphis. Mientras que las salidas actuales emplean una dirección sigilosa derivada de la clave pública de visualización del receptor y de un secreto compartido específico de la transacción, las salidas Carrot añaden nuevos campos: claves de balance, marcadores de salida interna o externa y pistas para confidencialidad hacia adelante. El resultado práctico es que el escaneo de la billetera se vuelve más rápido (porque las salidas internas —el cambio que te envías a ti mismo— se identifican sin necesidad de descifrarlas por completo) y la auditoría con clave de visualización se vuelve más segura (porque el auditor solo ve lo que el usuario autoriza).

Carrot, además, incorpora protección contra ataques Janus por defecto. Un ataque Janus ocurre cuando un emisor malicioso construye una salida que más tarde le permite demostrar cuál de dos direcciones del receptor recibió los fondos. El protocolo Monero actual lo mitiga con una comprobación a nivel de subdirección, pero Carrot integra la prevención en el propio formato de salida, eliminando toda una clase de errores a nivel criptográfico en lugar de a nivel de política de la billetera.

Tamaño de transacción y comisiones

Una crítica habitual pregunta si Seraphis supondrá transacciones más grandes y comisiones más caras. Respuesta honesta: probablemente sí, de forma modesta, a corto plazo, y probablemente no, a medio plazo. Las pruebas Seraphis iniciales son mayores que las CLSAG, quizá 1,5x a 2x según la configuración elegida en la activación. Pero el tamaño de bloque dinámico de Monero hace que las comisiones se ajusten en función de la congestión y no del peso bruto en bytes, y Bulletproofs+ ya recortó agresivamente las pruebas de rango en 2022. Cuando FCMP++ aterrice y el conjunto de anonimato se expanda a escala de toda la cadena, el coste en bytes por unidad de privacidad caerá en picado frente al actual.

Jamtis: la capa de direcciones que sí vas a ver

Seraphis es el motor. Jamtis es el salpicadero. La mayoría de los usuarios no leerá nunca una prueba de composición, pero todo usuario copia y pega una dirección Monero. Jamtis rediseña esa dirección —y las claves que hay detrás— para que las ganancias de privacidad de Seraphis se reflejen en cómo billeteras, exchanges y comercios interactúan con la red.

Las direcciones actuales de Monero son 95 caracteres en base58 que empiezan por "4" para las primarias de mainnet o por "8" para las subdirecciones. Codifican una clave pública de gasto y una clave pública de visualización y, en esencia, nada más. Las direcciones Jamtis tendrán una longitud algo distinta —el formato final aún se está afinando a nivel de protocolo—, pero codifican muchísima más estructura: un índice de dirección, un indicador del tipo de dirección (principal, exchange, integrada o "auxiliar") y etiquetas de autenticación que previenen ciertos ataques de phishing y sustitución.

El sistema de niveles de la clave de visualización merece atención especial porque resuelve un dolor real. Hoy, si entregas tu clave de visualización a un asesor fiscal, este ve todas las salidas que has recibido jamás: incluidos los cambios de tus propios gastos, los pagos entre tus propias subdirecciones y cualquier ingreso auxiliar. Jamtis te permite conceder únicamente el nivel concreto que el auditor necesita. Una clave "find-received" revela los pagos entrantes sin importes. Una clave "view-incoming" revela los pagos entrantes con importes, pero no el cambio. Una clave "view-balance" revela el saldo gastable para informes de cumplimiento sin desenmascarar transacciones individuales. Solo la clave "view-all", que el usuario guarda en privado, lo ve todo.

Para servicios como MoneroSwapper, que necesitan confirmar el depósito de un cliente sin enterarse del resto de su historial de billetera, la nueva estructura por niveles significa integraciones más limpias y una privacidad más sólida por defecto. El servicio de swap puede comprobar "enviaste la cantidad pactada a la dirección pactada" sin tener acceso al saldo global del cliente, a su patrón de cambios ni a otros ingresos. Esto importa porque cada byte de metadatos que un servicio que preserva la privacidad no recoge es un byte que no puede ser requerido por orden judicial, filtrado en una brecha o sonsacado mediante ingeniería social.

Si puedes describir una mejora de privacidad en una sola frase, casi seguro que es demasiado simple. Seraphis y Jamtis, juntos, son un sistema: pruebas, codificación, direcciones, jerarquía de claves y experiencia de usuario moviéndose en coordinación. Trátalos como un paquete, no como una lista de funcionalidades.

Ruta de migración: cómo preparar tu billetera

El hard fork de Seraphis no tiene fecha confirmada en el momento de redactar este artículo; el Monero Research Lab y el equipo principal son deliberadamente conservadores con los plazos de activación y prefieren "listo cuando esté listo" antes que ceñirse a un calendario. Los hard forks anteriores de Monero han dado entre dos y seis meses de margen, y Seraphis caerá casi con total seguridad en la parte alta de ese rango, dada su complejidad. Aquí tienes una lista práctica de preparación que sirve sea cual sea la semana exacta de activación.

1. Audita el formato de tu semilla. Si tu billetera todavía usa la semilla legacy de 25 palabras, plantéate migrar a una respaldada por Polyseed de 16 palabras antes de la actualización. Polyseed es compatible hacia adelante con los caminos de derivación de Jamtis; la semilla legacy exigirá un paso de conversión en la propia billetera el día del fork.
2. Actualiza tu software de billetera al menos dos veces antes del fork. Los equipos de Monero GUI, CLI, Feather Wallet y Cake Wallet suelen publicar varias versiones pre-fork. Sigue las notas oficiales de versión de Monero y el changelog de tu billetera durante el mes previo a la activación: no confíes solo en las actualizaciones automáticas, porque algunas billeteras dejan los cambios mayores detrás de una confirmación manual.
3. Practica una restauración completa desde semilla en un dispositivo de repuesto. Antes de cualquier actualización importante del protocolo, el control de riesgo más valioso es comprobar que la semilla que escribiste recupera realmente tus fondos. Levanta un Monero CLI o un Feather Wallet limpio en otra máquina, restaura desde semilla y confirma que el saldo coincide. Hazlo dos veces. Hazlo cada seis meses incluso fuera de las actualizaciones.
4. Identifica y reduce tu maraña de subdirecciones. Quien haya usado decenas de subdirecciones con fines organizativos (una por contraparte, una por comercio, etc.) tendrá una migración algo más compleja. Consolidar fondos en un conjunto más reducido antes del fork —y etiquetar cada una con claridad en la billetera— hace que el modelo mental post-fork sea muchísimo más simple.
5. Documenta a quién has compartido tu clave de visualización. Si la has compartido con un asesor, un exchange o una herramienta de auditoría, anota quién la tiene y por qué. Cuando Jamtis se active, casi seguro querrás rotar esas relaciones para usar las nuevas claves por niveles en lugar de la clave completa legacy.
6. Vigila las instrucciones de "barrido post-fork". Actualizaciones previas de Monero han exigido ocasionalmente "barrer" salidas del formato antiguo al nuevo antes de poder gastarlas. El equipo de Monero publicará instrucciones explícitas si Seraphis lo requiere; no actúes basándote en rumores de foros o redes sociales.

Para quienes usan servicios de swap sin KYC, el impacto operativo suele ser mínimo. Un servicio bien diseñado abstrae la transición de protocolo: tú entregas la dirección, él te entrega XMR y se encarga internamente del formato Seraphis o pre-Seraphis. MoneroSwapper, por ejemplo, trata la versión de protocolo de la dirección de destino como una decisión de enrutado, no como una complicación que deba pasarle al cliente. Los usuarios pueden seguir con el mismo flujo de trabajo de siempre.

Ejemplo práctico: recibir un swap bajo el nuevo modelo

Imagina un escenario típico de mediados de 2026, asumiendo que Seraphis ya ha activado para entonces. Un usuario en Madrid quiere cambiar Bitcoin por Monero sin KYC. Entra en un servicio de swap como MoneroSwapper, pega su dirección de recepción Jamtis (generada por una billetera actualizada como Feather o el Monero GUI oficial) y envía Bitcoin a la dirección de depósito que el servicio le proporciona.

Entre bambalinas, el servicio de swap enruta los bitcoins a través de su pool de liquidez, adquiere Monero y construye una transacción Seraphis enviando la cantidad pactada a la dirección Jamtis del usuario. La transacción incluye una prueba de composición, una prueba de pertenencia que se apoya en un conjunto de anonimato de 128 salidas (o mayor) y una salida codificada con Carrot que la billetera del usuario identifica en una sola pasada de escaneo. El usuario ve los fondos en su billetera dentro de la ventana habitual de confirmación de 10 a 20 minutos.

¿Qué cambió desde la perspectiva del usuario? Nada visible. ¿Qué cambió debajo del capó? El conjunto de anonimato creció un orden de magnitud, la codificación de la salida resiste ataques Janus a nivel de protocolo y el servicio de swap nunca recibió una clave que le permitiese aprender nada sobre la actividad Monero más amplia del usuario. El sistema hizo más trabajo de privacidad, de forma transparente. Ese es el objetivo de una actualización de protocolo bien ejecutada: invisible para el usuario y demostrablemente más sólida para el auditor.

Para quienes vienen de fuera del ecosistema Monero —bitcoiners curiosos sobre privacidad, o nuevos adoptantes de monedas privadas—, la era Seraphis será probablemente su primer contacto. Nunca sabrán cómo era la vida con firmas de anillo de dieciséis-entre-muchos, igual que los usuarios actuales rara vez recuerdan la era pre-RingCT, cuando los importes eran públicos en la cadena. Así deben sentirse los saltos de protocolo: una mejora silenciosa que se convierte en la nueva línea base.

Preguntas frecuentes

¿Cuándo se activarán Seraphis y Jamtis en la mainnet de Monero?

No hay fecha firme anunciada. El Monero Research Lab y el equipo principal han repetido que la activación depende de la finalización de las auditorías criptográficas, del endurecimiento de las librerías, de la integración en las principales implementaciones de billetera y de al menos un ciclo completo de testnet. Las estimaciones públicas de los contribuidores a finales de 2025 se movían entre finales de 2026 y mediados de 2027, pero la cultura del proyecto rechaza explícitamente el envío "por calendario" cuando hablamos de actualizaciones críticas en seguridad. Sigue las notas oficiales de versión de Monero y las actas de las reuniones del Monero Research Lab para conocer los plazos autorizados.

¿Mi dirección Monero actual seguirá funcionando tras la actualización?

Sí, durante un periodo de transición. Históricamente, los hard forks de Monero han incluido un manejo de direcciones retrocompatible para que los fondos enviados a direcciones legacy lleguen igualmente. A más largo plazo, el software de billetera animará a los usuarios a migrar a direcciones Jamtis y, llegado el momento, las nuevas billeteras podrían dejar de generar direcciones legacy por completo. No hay un "plazo límite" inmediato para los fondos almacenados en direcciones actuales, pero querrás actualizar tu software de billetera cerca de la fecha del fork.

¿Cambia Seraphis la emisión final (tail emission) o el calendario de suministro?

No. Seraphis es una actualización de la capa de transacciones. No toca la política monetaria. La emisión final de 0,6 XMR por bloque sigue inalterada. La curva total de emisión, la dinámica de la recompensa de bloque y el algoritmo de prueba de trabajo RandomX están separados de Seraphis y no se ven afectados por la actualización.

¿Romperá Seraphis la compatibilidad con billeteras hardware como Trezor y Ledger?

Los fabricantes de billeteras hardware tendrán que actualizar su firmware para soportar los nuevos formatos de prueba y los caminos de derivación de claves. Históricamente, tanto Trezor como Ledger han publicado actualizaciones de firmware para Monero alineadas con los hard forks, aunque a veces con un retraso de semanas o meses. Quien dependa de hardware wallets no debería actualizar el firmware del dispositivo a ciegas el día del fork: lo prudente es esperar a la confirmación explícita del fabricante de que el nuevo firmware soporta la versión activa del protocolo Monero, y mantener una billetera software de respaldo para cubrir la ventana de transición.

¿Cómo se compara Seraphis con los enfoques de otros proyectos de privacidad?

Zcash utiliza zk-SNARKs para transacciones completamente shielded, lo que ofrece una privacidad teórica más fuerte, pero históricamente exigió una ceremonia de configuración de confianza y tiene una adopción mucho menor (la mayoría del volumen Zcash es transparente). Las cadenas Mimblewimble como Grin emplean un modelo radicalmente distinto, basado en agregación de salidas, sacrificando algo de auditabilidad a cambio de compacidad. Seraphis se mantiene dentro del modelo existente de Monero —firmas de anillo y direcciones sigilosas— pero lleva el diseño hasta su máximo práctico. El compromiso es complejidad de ingeniería a cambio de no necesitar una configuración de confianza y de mantener una experiencia de usuario continua con la Monero de hoy.

¿Puedo recibir swaps a direcciones Jamtis en MoneroSwapper antes del fork?

No, porque las direcciones Jamtis aún no pueden generarse con las billeteras de producción actuales. Una vez se active el protocolo y billeteras principales como Monero GUI, Feather o Cake Wallet desplieguen el soporte Jamtis, los servicios de swap aceptarán el nuevo formato junto con las direcciones legacy durante la ventana de transición. Hasta entonces, tu dirección Monero actual sigue funcionando con normalidad para toda actividad de swap.

Conclusión

Seraphis y Jamtis son la apuesta de Monero por adelantarse a la curva del análisis en lugar de ir a remolque de ella. La actualización no es vistosa, no generará una narrativa de pump del precio y no cambiará drásticamente lo que el usuario hace en su día a día. Lo que sí hará es subir el suelo de privacidad de la red de forma significativa, dar al usuario un control mucho más fino sobre qué revela y a quién, y sentar las bases criptográficas para la próxima década de desarrollo Monero. Si tienes XMR o lo usas para pagos cotidianos que preservan la privacidad, dedica los próximos seis a doce meses a actualizar el formato de tu semilla, refrescar tus hábitos de software de billetera y verificar tu proceso de restauración. Cuando el fork llegue, quieres que sea un no-evento. Para empezar a usar Monero hoy mismo con un servicio de swap sin KYC ni cuentas que gestionará la transición a Seraphis de forma transparente, pásate por MoneroSwapper y cambia tu cripto actual por XMR en cuestión de minutos.