La gobernanza de una comunidad descentralizada no consiste únicamente en determinar quién puede votar.
También debe responder preguntas más difíciles: ¿cómo se demuestra una identidad sin entregar documentos personales?, ¿cómo se evita que una gran fortuna compre toda la influencia?, ¿quién puede crear propuestas?, ¿cómo se auditan los resultados? y ¿cómo se conserva un historial verificable de participación?
Con estas preguntas como punto de partida, xolosArmy está desarrollando una arquitectura comunitaria alrededor de RMZ, el protocolo de alias de eCash, Chronik y una serie de servicios públicos de código abierto.
La tesis del proyecto puede resumirse mediante una de sus máximas:
XEC es el dinero. RMZ es la llave. La cultura es la red.
RMZ no busca sustituir a XEC como moneda del ecosistema. Dentro de este modelo, funciona como una credencial mínima de pertenencia y como puerta de acceso a determinados mecanismos comunitarios.
La diferencia es importante: una cosa es el dinero utilizado para transferir valor y otra la credencial empleada para participar en una institución.
¿Qué es la Asamblea RMZ?
La RMZ Assembly API es un backend desarrollado con TypeScript y Express para gestionar votaciones fuera de la cadena cuya elegibilidad se deriva de información verificable en eCash.
La regla básica del MVP establece que una persona participante necesita controlar una wallet, poseer al menos un átomo de RMZ y utilizar un alias .xec confirmado que apunte a la misma dirección.
El diseño también permite votar nuevamente mientras la propuesta permanezca abierta. Cuando se realiza el conteo, solamente se considera el voto válido más reciente relacionado con cada alias normalizado.
Esto permite corregir una decisión sin generar votos efectivos duplicados. Los registros anteriores permanecen como parte del historial, pero son sustituidos electoralmente por la última elección válida.
La regla puede expresarse así:
Un alias .xec confirmado equivale a un voto efectivo.
La API expone rutas públicas para consultar propuestas, resultados, votos y archivos de auditoría. También cuenta con procesos separados para comprobar elegibilidad, preparar un desafío de firma y presentar el voto.
No es “un token, un voto”
Una diferencia fundamental frente a muchas organizaciones autónomas descentralizadas es que el peso electoral no aumenta con la cantidad de RMZ acumulada.
La primera propuesta configurada en el repositorio exigía:
- posesión de RMZ;
- un mínimo de un átomo;
- alias confirmado;
- un voto por alias.
Su configuración establece explícitamente que la unidad de voto es el alias, que cada alias dispone de un voto y que solamente se considera la última elección válida antes del cierre.
Una wallet con un millón de unidades de RMZ no recibe, por ese solo hecho, un millón de veces más poder que otra que cumpla el requisito mínimo.
La cantidad de RMZ funciona como condición de acceso, no como multiplicador automático de influencia.
El modelo intenta separar dos conceptos que frecuentemente aparecen mezclados:
- Propiedad económica: cuánto capital o cuántos tokens controla una dirección.
- Participación política: qué capacidad tiene una identidad para intervenir en una decisión comunitaria.
Sin embargo, esta separación no elimina todos los problemas. Un alias .xec no equivale necesariamente a una persona única. Un mismo individuo podría controlar varias wallets, adquirir RMZ en cada una y registrar diferentes alias.
El sistema reduce la plutocracia basada directamente en balances, pero todavía no ofrece una prueba de humanidad ni una defensa completa contra ataques Sybil.
Tres capas: identidad, participación y reputación
La Gobernanza RMZ está organizada alrededor de tres componentes relacionados, pero independientes.
1. Identidad soberana mediante alias .xec
El participante no necesita publicar su nombre legal. Puede utilizar una identidad legible asociada con una wallet, por ejemplo:
El servicio alias-proxy-api indexa los alias registrados en eCash y permite comprobar qué dirección está vinculada con cada nombre.
Su función no se limita a consultar Chronik en tiempo real. El servicio conserva un snapshot local del índice de alias confirmados. Al iniciarse, intenta cargar ese archivo para responder inmediatamente, incluso antes de completar una nueva exploración de la blockchain.
Las actualizaciones están diseñadas para fallar de manera segura: el índice activo solamente se sustituye después de que una exploración completa termina y el nuevo snapshot se escribe correctamente. Si Chronik queda temporalmente fuera de servicio, la caché anterior se conserva.
Esta decisión añade continuidad operativa. Una interrupción del endpoint no debería borrar repentinamente las identidades que ya habían sido verificadas.
No significa que el servicio pueda permanecer indefinidamente desconectado. Significa que una falla temporal no destruye inmediatamente el último estado válido conocido.
2. Participación mediante votos firmados
La Asamblea utiliza un flujo de desafío y respuesta.
Primero, el participante solicita preparar el voto. El servidor genera un identificador, un desafío, un nonce y un mensaje con vigencia de diez minutos.
Ese mensaje incluye:
- dominio y aplicación;
- red de eCash;
- identificador y hash de la propuesta;
- alias;
- wallet;
- opción elegida;
- identificadores del voto y del desafío;
- nonce;
- fecha de emisión y expiración.
La inclusión del hash de la propuesta busca vincular la firma con una versión concreta del documento, mientras el nonce y la expiración reducen la posibilidad de reutilizar indefinidamente el mismo mensaje.
Después de recibir la firma, el servidor vuelve a verificar que:
- el desafío exista, no haya expirado y no haya sido utilizado;
- el mensaje coincida exactamente con el preparado;
- la propuesta exista y continúe abierta;
- la opción seleccionada sea válida;
- el alias corresponda con la wallet;
- la wallet posea RMZ;
- la firma sea válida;
- la llave pública derive en la dirección presentada.
Cuando las comprobaciones se completan, el voto y su evidencia de elegibilidad se añaden al registro electoral y al archivo de auditoría.
Este punto modifica el estado descrito en la documentación inicial: la verificación criptográfica ya aparece implementada en el código actual. La firma no convierte automáticamente al sistema en seguro o descentralizado, pero sí elimina una de las carencias más importantes de la primera versión.
3. Reputación basada en evidencia
La rmz-reputation-api combina información procedente de tres fuentes:
- el servicio de alias;
- la Asamblea RMZ;
- el Chronik utilizado para consultar la posesión del token.
La respuesta no se limita a mostrar una puntuación abstracta. Incluye las fuentes consultadas, el registro del alias, la evidencia de posesión de RMZ y la participación encontrada en la Asamblea.
A partir de esos datos genera distintivos públicos como:
Cada medalla tiene condiciones específicas. “Primer Votante RMZ”, por ejemplo, exige la existencia de un voto efectivo. “Ciudadano xolosArmy” requiere simultáneamente identidad confirmada, posesión de RMZ y participación electoral.
La reputación no se asigna únicamente mediante la decisión subjetiva de un administrador. Se deriva de acciones que los servicios pueden consultar y documentar.
Tampoco aumenta actualmente el peso del voto. Acumular más badges no concede automáticamente más poder electoral. La reputación describe una trayectoria verificable, mientras la regla de conteo continúa siendo un alias y un voto.
Esta separación evita que la reputación se transforme inmediatamente en una aristocracia digital, aunque en el futuro la comunidad deberá decidir si algunos roles operativos requieren historial, antigüedad o niveles adicionales de responsabilidad.
Una interfaz para conectar identidad y wallet
El repositorio de eCash México integra estos componentes dentro de un panel de identidad RMZ.
La interfaz utiliza WalletConnect, solicita direcciones de eCash, declara compatibilidad con firma de mensajes y consulta tanto la API de reputación como los resultados y votos de la Asamblea.
El panel puede mostrar las medallas obtenidas y la evidencia que las respalda: transacción del alias, altura de bloque, cantidad de átomos de RMZ y datos del voto efectivo. También comprueba que la reputación consultada corresponda con la wallet conectada, en lugar de mostrar indiscriminadamente la identidad de otra dirección.
La experiencia propuesta puede resumirse así:
- conectar Tonalli u otra wallet compatible;
- obtener la dirección de eCash;
- comprobar el alias .xec;
- verificar la posesión de RMZ;
- consultar la reputación;
- preparar un voto;
- firmar el mensaje;
- enviar la firma;
- revisar resultados y auditoría.
La meta no es pedir al usuario que confíe ciegamente en una etiqueta dentro de una base de datos, sino mostrarle la evidencia utilizada para determinar su identidad, acceso y participación.
La primera propuesta: ratificar el MVP
La primera propuesta incluida en el repositorio fue:
Su finalidad era aprobar la dirección de la fase B3: votaciones firmadas fuera de la cadena, resultados públicos y registros accesibles para auditoría.
La consulta fue configurada del 5 de junio al 5 de julio de 2026 con tres opciones: sí, no y abstención. La definición también especificaba que los votos no constituirían transacciones on-chain.
La fecha de cierre ya pasó. Sin embargo, la configuración de una propuesta no debe confundirse con la publicación de un resultado ratificado. Para afirmar un desenlace sería necesario consultar el archivo operativo completo de votos y reproducir el conteo.
Este enfoque evita que cada participación requiera una transacción, una comisión y espacio permanente en la blockchain. eCash se utiliza para demostrar la identidad vinculada, la posesión de RMZ y la existencia del alias; la capa de Asamblea administra el proceso electoral.
Gobernanza verificable no significa gobernanza completamente on-chain
El modelo utiliza evidencia on-chain para comprobar:
- dirección de la wallet;
- propiedad de RMZ;
- registro y estado del alias;
- transacción y bloque de confirmación.
Pero los votos se almacenan y cuentan fuera de la cadena.
Esto puede ofrecer una experiencia más económica, rápida y flexible. También facilita corregir un voto antes del cierre sin publicar varias transacciones permanentes.
A cambio, introduce responsabilidades para los operadores:
- mantener el servidor disponible;
- proteger la integridad de los archivos;
- evitar la supresión selectiva de votos;
- conservar los registros;
- publicar la auditoría completa;
- permitir que terceros reproduzcan los resultados.
La transparencia del código es necesaria, pero no suficiente. Un repositorio abierto permite revisar las reglas; no demuestra por sí mismo que la instancia operativa está ejecutando exactamente ese código ni que publicó todos los registros recibidos.Por esa razón, una gobernanza verificable requiere algo más que software abierto: necesita exportaciones firmadas, hashes, copias independientes y observadores capaces de reproducir el conteo.
Estado actual: más que un esqueleto, menos que una institución terminada
La arquitectura ya contiene componentes funcionales:
- verificación de elegibilidad;
- generación de desafíos;
- mensajes vinculados con la propuesta;
- verificación de firmas;
- recepción de votos;
- sustitución mediante voto posterior;
- resultados públicos;
- auditoría en formato JSONL;
- cálculo de reputación;
- continuidad del índice de alias mediante snapshots.
No obstante, continúa siendo un MVP.
Las propuestas se cargan desde archivos JSON y los votos se añaden a archivos JSONL. El conteo vuelve a leer esos registros y selecciona el voto válido más reciente de cada alias.
Los desafíos de firma permanecen en memoria. Si el proceso se reinicia, los desafíos pendientes desaparecen y deben prepararse nuevamente.
No se observa todavía una base de datos transaccional, un protocolo de replicación entre operadores, una red de testigos independientes ni una solución completa contra identidades múltiples.
La conclusión correcta no es que el sistema esté vacío, pero tampoco que esté listo para administrar tesorerías, fondos públicos o decisiones irreversibles.
Actualmente debe entenderse como un laboratorio funcional de gobernanza comunitaria.
Los desafíos que deberá resolver
Resistencia frente a identidades múltiples
Un alias por voto evita que el balance determine directamente la influencia, pero no impide que una persona registre varios alias.
La comunidad deberá decidir si desea introducir costos de registro, antigüedad mínima, reputación histórica, invitaciones, avales o alguna forma adicional de prueba de unicidad.
Cada solución implica concesiones. Una verificación demasiado débil facilita ataques Sybil; una demasiado invasiva puede destruir la privacidad y excluir participantes legítimos.
Persistencia y reproducción independiente
Los archivos JSONL son fáciles de inspeccionar y exportar, pero una operación sensible necesita garantías adicionales.
Cada propuesta debería producir un paquete auditable que contenga:
- definición y hash de la propuesta;
- votos recibidos;
- firmas;
- evidencia de elegibilidad;
- orden temporal;
- votos sustituidos;
- resultado calculado;
- hash final del conjunto.
Un tercero debería poder descargar ese paquete, ejecutar un verificador independiente y obtener exactamente el mismo resultado.
Endurecimiento criptográfico
La firma ya se encuentra implementada, pero deberá someterse a revisión independiente.
Será necesario comprobar compatibilidad entre wallets, tratamiento de direcciones, protección contra replay, expiración de desafíos, normalización de alias, cambios de propietario del alias y comportamiento ante reorganizaciones o inconsistencias en los servicios de evidencia.
Una prueba funcional de firma no equivale a una auditoría de seguridad.
Gobernanza de las propias reglas
También debe existir un mecanismo para decidir quién puede:
- crear propuestas;
- modificar requisitos;
- definir quórums;
- cancelar una consulta;
- resolver una impugnación;
- actualizar el software;
- administrar los dominios y servicios.
Un sistema no se vuelve descentralizado únicamente porque sus participantes usan wallets. También importa quién controla la agenda, el servidor, los repositorios, los registros y las reglas electorales.
Continuidad operativa
Los servicios de alias, reputación, Asamblea y Chronik deberían poder desplegarse por operadores independientes.
El código abierto permite hacerlo en teoría, pero la descentralización operativa necesita documentación reproducible, backups, imágenes de despliegue, variables claramente definidas y procedimientos de recuperación.
La redundancia no existe hasta que otra persona puede levantar el sistema sin depender de instrucciones privadas.
Privacidad y auditoría
Los votos y registros del MVP están diseñados para ser públicos. La propia documentación advierte que no deben enviarse datos privados que posteriormente aparezcan en archivos JSON o JSONL.
La transparencia debe limitarse a la evidencia necesaria. Una auditoría pública no requiere exponer nombres legales, ubicaciones, correos o información que permita acosar a los participantes.
¿Qué aporta este modelo a eCash?
La Gobernanza RMZ no pretende reemplazar el consenso de eCash, modificar las reglas del nodo Bitcoin ABC ni gobernar directamente el protocolo.
Su ámbito inicial es comunitario:
- ratificar etapas de desarrollo;
- reconocer participación;
- coordinar ciudadanos y guardianes;
- documentar decisiones;
- construir reputación;
- establecer mecanismos de rendición de cuentas.
Sin embargo, también funciona como laboratorio para problemas relevantes en todo el ecosistema:
- identidad soberana;
- representación sin plutocracia directa;
- reputación portable;
- auditoría pública;
- continuidad de infraestructura;
- transparencia institucional.
En un contexto donde la comunidad discute financiamiento, dependencia de actores centrales y ausencia de información verificable, RMZ propone una respuesta práctica: convertir identidad, pertenencia y participación en evidencia que otros puedan consultar.
No soluciona por sí mismo los problemas de gobernanza de eCash. Pero demuestra que es posible experimentar con instituciones comunitarias sin reducirlas a una encuesta en redes sociales, una base de datos privada o una votación proporcional al tamaño de la fortuna.
Una gobernanza que deberá ganarse su legitimidad
Publicar código no convierte automáticamente a un proyecto en legítimo.
Tampoco un token, un alias, una firma o una votación garantizan una comunidad democrática.
La legitimidad deberá construirse mediante reglas claras, participación plural, resultados reproducibles, límites conocidos, operación transparente y capacidad para corregir errores públicamente.
RMZ plantea una dirección relevante: que la identidad no dependa de una plataforma centralizada, que la reputación no dependa exclusivamente de un moderador y que el voto no dependa automáticamente del tamaño de una fortuna.
El código actual demuestra avances concretos, especialmente en elegibilidad, firmas y auditoría. Los desafíos pendientes se encuentran ahora en un nivel más difícil: unicidad, replicación, seguridad operativa y legitimidad social.
La arquitectura establece una tesis verificable:
La gobernanza soberana no consiste en pedir confianza. Consiste en diseñar sistemas donde identidad, participación y resultados puedan comprobarse.