KVoice es un sistema de voto verificable: identidad, censo, credencial ciega, urna cifrada, anti-doble-voto, árbol Merkle y notario en cadena. El mismo motor sirve a una comunidad de vecinos y a un proceso de escala estatal.
La arquitectura canónica de KVoice separa roles que otras plataformas mezclan. Eso no es estética: es la condición para que el voto sea secreto y el recuento sea comprobable.
Capas reales del producto: app, API en Barcelona, Postgres con RLS, lotes Merkle y notario Telos.
| Capa | Qué construimos |
|---|---|
| Cliente | App Angular 22 + Ionic 9 + Capacitor 7. El voto se cifra en el dispositivo. Cliente Chaum en TypeScript. |
| API | FastAPI en k3s Barcelona, 2 réplicas, filesystem de solo lectura. Multi-tenant desde el primer request. |
| Identidad | Firebase Auth (email, Google, passkey) para comunidades y empresas. Adaptadores Cl@ve, DNIe, FNMT y eIDAS Wallet para sector público. SSO SAML/OIDC (Google Workspace, Microsoft Entra, Okta) para empresas. |
| Datos | Postgres 16 con Row Level Security. Roles kvoice_owner / kvoice_app. Logs append-only. Censo con snapshot al abrir. |
| Motor de privacidad | Interfaz PrivacyEngine intercambiable: CommitmentEngine (HMAC + nullifier + commitment), firma ciega Chaum RSA-FDH 2048, y SemaphoreEngine (pruebas ZK) para anonimato fuerte. |
| Urna secreta | SealedBox NaCl (X25519 + XSalsa20-Poly1305). Shamir GF(2⁸). Umbral de custodios 2/3, 3/5, 4/7 o 5/9. La urna no ve el user_id. |
| Integridad | Árbol Merkle SHA-256 con domain separation, prueba de inclusión, anclaje de la raíz y resultado firmado. |
| Notario Telos | Cuentas kvoiceanchor y kvoicetally: solo hashes, raíces Merkle y firmas. El votante no tiene wallet. Multisig de operadores. |
| IA | AVA resume reglamentos y comentarios agregados. No toca el voto individual, no recomienda y no lee el censo. |
Doce procesos. Cada uno tiene un responsable, un input y un output. Si uno falla de forma silenciosa, el recuento no es auditable.
El emisor no ve el voto. La urna no ve la identidad. Telos no ve ni uno ni otro.
Cada organización es un tenant. La sesión declara SET LOCAL app.current_tenant_id. RLS rechaza cualquier fila de otro tenant. Roles: super_admin, tenant_admin, creator, voter, auditor, observer.
eligible_voters)Solo quien está en el censo recibe credencial. El censo se fija al abrir (eligible_count_at_open). Objetivo de diseño: impedir altas, bajas o cambios a mitad de escrutinio — el ataque clásico de “añadir amigos a la lista”.
En voto secreto se genera un par de claves de urna. La privada se parte con Shamir GF(2⁸). Umbrales configurables: 2/3, 3/5, 4/7, 5/9. Un solo operador no puede abrir la urna. El plaintext no se persiste; la clave se purga de RAM tras el unseal.
Al publicar se envían invitaciones con token de un solo uso (/votar/{token}). El votante se autentica: email, Google, passkey; en empresas SSO; en sector público Cl@ve, DNIe, FNMT o eIDAS. La identidad decide si puedes votar, no qué votas.
Quórum y mayoría son reglas de validez, no de recuento: none, min_votes o min_percent_eligible, más mayoría sobre preguntas single_choice formales. El recuento se publica siempre; la validez es un banner comprobable.
Sin ceguera, el servidor que comprueba el censo puede correlacionar “a este usuario le di este token” con “este token votó B”. Eso rompe el secreto aunque el voto vaya cifrado. Por eso el cliente pide una firma ciega.
Dos puertas distintas. Correlacionarlas exigiría colusión emisor–urna más ruptura del cegado.
El nullifier de este modo no se deriva del user_id (eso reidentifica), sino de la credencial anónima:
En el modo abierto (votaciones no secretas) el motor es CommitmentEngine:
El voto secreto se cifra antes de salir del teléfono. El backend guarda ciphertext. La urna no necesita saber la opción para rechazar un segundo voto: le basta el nullifier único.
El cliente toma la election_pk anclada en el manifiesto, cifra con SealedBox y construye el commitment sobre el ciphertext (no sobre el texto en claro). El modelo de votación contempla single_choice, multi_choice, ranking y budget.
Índice único sobre nullifier activo. Si revote_enabled, las filas anteriores quedan superseded=true; solo cuenta una. El segundo depósito con el mismo nullifier se rechaza. Eso es “una persona, un voto” en el plano criptográfico, no un honor system.
Shamir: con k partes se reconstruye; con k−1 la clave es información-teóricamente inútil. Nadie “abre un poco”.
Cada voto válido entra en un lote. El scheduler (cada 60 s) calcula la raíz y la ancla. Domain separation para no confundir hoja y nodo interno — el ataque clásico de segunda preimagen en Merkle-Damgård:
Cambiar un voto altera la raíz. La raíz anclada es la prueba pública de que el lote existió así.
En Telos no viaja el censo ni la opción. Viajan merkle_root, voting_id, batch_id, recuento de hojas. El votante no tiene wallet. Darle una cuenta en cadena a cada persona haría el voto seudónimo y correlacionable: exactamente lo que hay que evitar en unas elecciones.
Al cerrar, los custodios aportan shares. Con el umbral se reconstruye la clave de mesa, se descifran los sealed boxes y se cuenta. La clave no se guarda. El log de auditoría es append-only: un trigger de Postgres impide UPDATE/DELETE.
El recuento canónico se hashea y se firma. Cualquier observador puede bajar commitments, recomputar la raíz, compararla con el anclaje y contrastar el result_hash. Si alguien “ajusta” un 2% a última hora, la huella no cuadra.
Las claves públicas de firma de actas están publicadas. Tres herramientas en este mismo sitio:
PDF firmado. Comprueba la firma sin pasar por nuestra API ciega.
Verificar un recuentoRecalcula el tally v2 y el result_hash.
Verificar una clave de mesaPin de election_pk y del emisor Chaum contra el manifiesto anclado.
GET /v1/votings/{id}/votes/{cid}/proof — camino hoja → raíz.
La página Trust Layer detalla las ocho capas de seguridad (identidad, elegibilidad, nullifier, privacidad, inmutabilidad, recuento, auditoría, ZK futuro).
Un proceso estatal no es “la misma app con más usuarios”. Es el mismo motor de urna con censo oficial, identidad reconocida por el Estado, custodios externos y recálculo público.
Millones de registros, corte de censo, mesas y colegios. El modelo eligible_voters + snapshot al abrir es el mismo patrón; el adaptador de entrada es el censo electoral, no un CSV de una comunidad de vecinos.
Firebase basta para una asociación. Un proceso estatal exige Cl@ve, DNIe, FNMT o la wallet eIDAS. La API ya aísla identidad detrás de AuthBackend: se cambia el adaptador, no el recuento.
Shamir + custodios externos (administración, interventores, notaría, auditor). En un proceso oficial el umbral no puede vivir en un único servidor de una empresa.
Rol observer / auditor, actas firmadas, raíces ancladas, verificadores en kvoice.org.es. Un interventor no necesita acceso al panel: necesita pruebas.
GDPR / LOPDGDD y derecho al olvido son incompatibles con “cada voto es una transacción con nombre”. Por eso Telos es notario de hashes, no padrón.
Un anclaje por minuto agrupa decenas de miles de votos. Postgres indexa (tenant_id, voting_id). La API es stateless con HPA. Así se escala a picos nacionales sin saturar una blockchain con un tx por votante.
El módulo de sector público incluye evaluación de impacto (DPIA), categorización ENS y criptografía revisable por terceros. Sin eso no hay urna de confianza para una administración.
La urna, el censo, los interventores y las pruebas Merkle están pensados para un proceso vinculante. Las elecciones oficiales las convoca el Estado (LOREG / Junta Electoral); KVoice construye la capa técnica que ese proceso necesita.
El mismo motor. Distinto censo y distinta identidad. Si hoy decidís con un grupo de WhatsApp o un Excel, el recuento no resiste una impugnación.
Juntas LPH, derramas, obras, cambio de estatutos, elección de presidente y administrador.
Elección de junta, presupuestos, sedes, altas de secciones, sanciones internas.
Asambleas de clubes, reglamento, calendario, votos ponderados por estamento.
Juntas de accionistas, comités, planes de igualdad, consultas de ERTE, anexiones.
Convenios, huelga, afiliación, congresos, delegación de voto.
Asamblea, excedente, admisión de socios, consejo rector.
Decano, presupuestos, códigos deontológicos (abogados, médicos, arquitectos, periodistas).
Claustro, consejo de estudiantes, elección de delegados, actividades del centro.
Patronato, asamblea de socios, líneas estratégicas, destinos de fondos.
Candidaturas, listas, congresos. Identidad fuerte + urna ciega.
Consultas vecinales, presupuestos participativos, consejos de barrio, elección de órganos locales.
Acuerdos entre municipios, planes comarcales, elección de órganos compartidos.
Consultas ciudadanas y procesos electorales de escala autonómica y estatal: mismo motor, censo e identidad públicos.
Turnos de agua, derramas de canal, junta de gobierno.
Proyectos de reparcelación, derramas, representantes ante el ayuntamiento.
Gastos comunes, horarios, obras, elección de gerente.
Prestaciones, consejo, cambios estatutarios con censo cerrado.
Plenos, comités, elección de presidente y vocales.
Mayordomía, presupuestos de fiesta, admisión de hermanos.
Residencias de mayores, colivings, campus: normas y presupuestos comunes.
Pactos de socios, ampliación de capital, nombramiento de consejeros.
Polígonos industriales: vigilancia, accesos, derramas de urbanización.
Protocolos internos, elección de jefaturas, comisiones clínicas.
Línea editorial, consejo, admisión de socios de la cooperativa.
Así queda escrito un proceso certificado: censo, urna, recibo y anclaje.
Ejemplo: ¿Aprobar el presupuesto comunitario 2026?
Gratis para comunidades pequeñas. Business para SSO, API y procesos grandes. El Trust Layer es el mismo.