Gobernanza abierta para comunidades, ONG y movimientos
Una voz para cada persona. No para cada moneda.
Henosis permite a una comunidad demostrar que cada miembro es una persona real y votar en secreto, sin que nadie sepa quién votó qué. Sin nombres, sin números, sin perfiles. Las decisiones se toman donde corresponde: lo más cerca posible de la gente.
No hay token. Nunca.
Arrastra para girar. Haz clic en un nodo o en un módulo abajo.
Para quién
Para cualquier grupo que necesite decidir en conjunto sin exponer a sus miembros. Henosis nació en la comunidad Shib y se concibió primero como la capa de gobernanza de SHIB OS; está construido para todos.
Minorías y comunidades perseguidas
Organizarse y votar sin una lista de miembros que pueda ser incautada. A la cadena solo van pruebas, nunca datos personales. Nadie, ni siquiera quienes organizan, sabe quién votó qué.
ONG y organizaciones de ayuda
Deja que las personas a las que sirves decidan por sí mismas: registra la ayuda mutua como karma, reparte bienes escasos mediante una lotería verificable y mantén las decisiones en el nivel local, donde está el conocimiento.
Diáspora y comunidades transfronterizas
Los ámbitos de lo local a lo global permiten que una comunidad repartida entre países decida en cada nivel, con el pasaporte de cualquier Estado emisor como prueba de ser persona.
Movimientos que rechazan el poder del dinero
Una persona, un voto. La influencia no se puede comprar, bloquear en staking, delegar a una ballena ni heredar mediante un token. Las reglas son abiertas, el código será público y no hay propietario.
Cómo funciona
Un diseño por capas. Cuatro módulos centrales se apoyan en un registro de ámbitos y una constitución; una capa de IA fuera de la cadena solo puede asesorar.
- M1 Identidad
- El teléfono lee el chip de un pasaporte o documento de identidad por NFC y demuestra en conocimiento cero, en el propio teléfono, que el documento es auténtico. En la cadena solo quedan la prueba, un nullifier y un compromiso. Ningún nombre, número ni fecha de nacimiento sale del teléfono. Otras vías de admisión (aval de miembros verificados, eventos presenciales) están diseñadas para personas sin documento electrónico.
- M2 Karma
- El karma registra la ayuda y el servicio a la comunidad. Solo se concede cuando ambas partes confirman, tiene un tope por persona y época, y decae con el tiempo. No puede transferirse, venderse ni delegarse. Hacia fuera solo se muestran pruebas de umbral, nunca un historial individual.
- M3 Lotería
- Una participación base por persona, participaciones extra por karma, una baliza pública de aleatoriedad y un sorteo verificable. Se usa para asignaciones entre personas igualmente cualificadas y para elegir al azar a revisores y verificadores.
- M4 Votación
- Los miembros se unen a un grupo de época con su identidad y votan con una prueba de pertenencia al grupo. Un nullifier por miembro y propuesta impide el doble voto; el voto puede cambiarse mientras la ventana esté abierta. La versión 1 trae un voto secreto por commit-reveal; etapas posteriores añaden recuentos cifrados y un diseño en el que un voto comprado o forzado no puede demostrarse.
- M5 Ámbitos
- Un ámbito tiene un ámbito superior, un grupo de identidad, sus propios parámetros y una lista de competencias. Las competencias solo suben, cedidas desde abajo, y nunca pueden tomarse desde arriba. Cuatro garantías no pueden desactivarse: una persona un voto, anonimato del voto, salida unilateral y decisiones solo sobre uno mismo.
- M6 Constitución
- Los derechos fundamentales son inmutables en el protocolo. Las demás reglas solo cambian con una mayoría cualificada en varios ámbitos y un bloqueo temporal. Un órgano elegido al azar y limitado en el tiempo puede pausar módulos concretos en una emergencia; nunca puede mover fondos ni cambiar reglas.
- M7 Asesoría de IA
- La capa de asesoría funciona fuera de la cadena con modelos de distintos operadores, al menos uno con pesos abiertos. Cada lado de una decisión recibe su propio argumento; los hechos con fuentes se separan de la valoración. Los prompts, las versiones de los modelos y las salidas se hashean y se referencian en la cadena. Sin claves, sin derechos de ejecución, sin acceso a pagos.
- M8 Operaciones
- Firmas de umbral o MPC para cada rol operador, auditorías externas y verificación formal antes de la red principal, actualizaciones solo mediante el procedimiento constitucional con bloqueo temporal. Los sistemas de firma y de prueba son intercambiables para poder adoptar esquemas poscuánticos. Los usuarios no necesitan gas: un relayer financiado por un fondo comunitario envía las transacciones.
El dinero queda aparte
Henosis no tiene token, ni comisiones, ni tesorería, ni propietario. El peso del voto nunca puede comprarse, bloquearse en staking ni delegarse a la cartera más rica. Es una regla del protocolo, no una promesa.
Una comunidad que usa Henosis puede seguir necesitando dinero: para donaciones, para pagar a quienes hacen el trabajo, para ayuda que debe llegar rápido a alguien. Para eso puede usar la moneda que elija, incluida una criptomoneda en una cadena como Shibarium, como segunda opción junto al dinero bancario. Esa decisión es de la propia comunidad, tomada mediante su propia gobernanza, y nunca toca el voto.
Abierto a otras cadenas
Henosis se construye primero para Shibarium. Sus interfaces son neutrales respecto a la cadena y se proponen como borrador de ERC, de modo que cualquier cadena que comparta la visión descentralizada de Ryoshi y de los cypherpunks, sin propietario, sin guardianes y con privacidad por defecto, puede ejecutarlo.
Los resultados se leen entre cadenas mediante pruebas de estado, nunca mediante puentes de activos ni relayers con veto.
Principios
- P1
Una persona, un voto
El peso del voto está ligado a una persona verificada, nunca a la posesión de tokens.
- P2
La influencia no está en venta
El karma y las participaciones de lotería están ligados al alma; no hay tokens de gobernanza transferibles.
- P3
Subsidiariedad
Cada decisión se toma en el nivel más bajo capaz de resolverla.
- P4
Homeostasis en lugar de maximización
Topes, decaimiento y saturación son parámetros obligatorios de cada módulo.
- P5
Descentralización y redundancia
Sin claves únicas, sin autoridad central, varios operadores independientes.
- P6
Privacidad por defecto
A la cadena solo van pruebas y nullifiers, nunca datos personales en claro.
- P7
Constitución antes que mayoría
Los derechos fundamentales no se someten a votación.
- P8
La IA asesora, nunca decide
Los componentes de IA no tienen claves ni derechos de ejecución.
- P9
Shibarium, SHIB OS y Zama primero
Cada elección tecnológica comprueba primero una solución basada en Shibarium, SHIB OS o Zama.
- P10
Quien asume el riesgo decide
Un riesgo que recae en una persona es decisión de esa persona; un riesgo que recae en todos lo decide la gobernanza vinculante.
- P11
Nada de criptografía casera
Solo bloques estandarizados o revisados públicamente, combinados, implementados y auditados externamente.
Reglas fijas
- Sin claves de administrador, sin propietario en ningún contrato. Actualizaciones solo mediante el procedimiento constitucional.
- Sin votación ponderada por tokens, sin acoplamiento a staking ni validadores, sin lógica de quema ni comisiones en el protocolo.
- Sin puentes como componente obligatorio. Los resultados se leen entre cadenas mediante pruebas de estado, no mediante puentes de activos ni relayers con veto.
Estado Octubre de 2026
| Módulo | Estado |
|---|---|
| M1 Identidad | Construido Registro en conocimiento cero para los esquemas de firma de pasaportes habituales, autenticación de chip, registros de certificados con bloqueo temporal y objeción. Aplicación móvil en desarrollo. |
| M4 Votación, etapa 1 | Construido Pertenencia anónima por época, propuestas y cambio de voto; una variante con recuento en claro y otra cifrada con FHE (Zama). Siguiente: voto secreto por commit-reveal. |
| M5 Registro de ámbitos | Prototipo |
| M2, M3, M6, M7, M8 | Solo diseño Aún sin código. |
Aún no listo para uso real
- Demostrado solo en una red de pruebas: el flujo completo (registrar, unirse, proponer, votar, contar) se ejecutó en Celo Sepolia con documentos sintéticos.
- Todas las claves de prueba proceden por ahora de configuraciones locales de una sola parte. Aún falta una ceremonia multiparte.
- Todavía sin auditoría externa, sin relayer y sin aplicación móvil publicada.
- Nada está desplegado en la red principal de Shibarium ni en la red de pruebas Puppynet. Red principal solo tras una auditoría externa.
Primer caso de uso: una votación sombra no vinculante, basada en personas, para la comunidad Shib, hasta que la comunidad decida otra cosa.
Hoja de ruta hasta la versión 1
- Nov 2026
Nullifier por cadena (v2), todas las instancias con claves nuevas, revisión ciega
- Nov 2026
Votación v2: voto secreto por commit-reveal, abstención, quórum obligatorio, reglas modificables por votación, adhesión privada
- Nov–dic 2026
Relayer de referencia, alojamiento de claves, aplicación de extremo a extremo en la red de pruebas
- Dic 2026
Congelación, paquete de auditoría, inicio de las auditorías
- Ene–feb 2027
Corrección tras auditoría, ceremonia de configuración confiable
- Feb–mar 2027
Versión 1 en la red principal de Shibarium, ERC presentado, código público
Después de la versión 1: recuento cifrado (FHE), karma, lotería, constitución y asesoría de IA.
Documentación
- Visión general de la arquitecturaCapas, módulos M1 a M8, modelo de amenazas (en inglés)
- InterfacesTres interfaces neutrales para la prueba de persona por ámbito (en inglés)
- Borrador de ERC«Scoped Proof of Personhood» (no presentado, en inglés)
- Hoja de rutaHitos hasta la versión 1 (en inglés)
Contacto
General
Seguridad
¿Has encontrado una vulnerabilidad? Escribe a security@henosis.now antes de hacerla pública. Consulta security.txt.