</techgob>

Institutional Signer Kit · guía para quien no programa

Una municipalidad firma en Stellar sin tener nunca un XLM.

Esta guía explica qué propone el proyecto, por qué funciona, cómo están organizados sus datos, dónde corre cada pieza y cómo se planificó el trabajo. Cada sección abre en lenguaje llano; el detalle técnico queda en un desplegable para quien lo quiera.

Recorrido interactivo ↗ Video, 1:41 ↗ Repositorio ↗ Statement of Work ↗

El obstáculoUna entidad pública no puede comprar ni custodiar XLM, la moneda de la red Stellar, para pagar las comisiones de la red. Ahí mueren la mayoría de los pilotos.

La salidaEn Stellar, quien autoriza y quien paga pueden ser cuentas distintas. La municipalidad firma; un operador paga y no puede cambiar lo firmado.

La prueba de usoEl presupuesto participativo de Tocache y La Punta: la red rechaza cualquier paso que la norma no permite.

El problema

El piloto muere antes de hablar de tecnología

Toda red pública de blockchain cobra una pequeña comisión por cada operación, y la cobra en su propia moneda. En Stellar esa moneda es el XLM. Para pagarla, una municipalidad tendría que comprar XLM, custodiarlo y rendir cuentas de él.

Eso exige un proceso de contratación, una partida presupuestal, reglas para custodiar claves y rendición ante la Contraloría. Además choca con el principio de unidad de caja de la tesorería pública. El trámite para habilitar un pago de fracciones de centavo cuesta órdenes de magnitud más que el pago mismo.

El efecto se ve en carteras reales. En un taller conjunto con la Secretaría de Gobierno y Transformación Digital (SGTD), TechGob levantó 23 desafíos públicos de 25 entidades. Stellar fue la red recomendada en 2 de los 23. No se descartó por razones técnicas: se prefirieron redes privadas porque no obligan a la entidad a tener un activo.

Ejemplo concreto

Las dos municipalidades piloto gastan lo que se les asigna: Tocache ejecutó el 74,9 % de su presupuesto en 2025 y La Punta el 90,9 %. Lo que ninguna tiene es una cadena de evidencia que conecte lo que los vecinos acordaron en el presupuesto participativo con lo que efectivamente se hizo.

En Tocache esa evidencia es un PDF (formato de documento portátil) escaneado sin ninguna protección de integridad. En La Punta es un decreto digital con siete firmas válidas, pero sin sello de tiempo cualificado: cuando esos certificados venzan, probar cuándo se firmó será difícil.

La propuesta

Dos cosas que conviene no confundir

El proyecto entrega un componente reutilizable, el kit, y lo prueba sobre un caso real, el registro del presupuesto participativo. El kit es el producto; el caso municipal es la demostración de que funciona.

El kit · para cualquier entidad y cualquier builder

Cuatro piezas que permiten a una institución autorizar operaciones en Stellar con saldo cero, sin partida presupuestal y sin custodiar activos. Sirve igual para notarizar documentos, emitir credenciales o certificar un hito. Es código abierto bajo licencia Apache-2.0.

El registro · el caso que lo prueba

El ciclo del presupuesto participativo, obligatorio por ley, modelado paso a paso. La red acepta cada paso solo si el anterior está cumplido y si lo firma el cargo que la norma indica. Cada paso cumplido queda como un certificado que otro sistema puede exigir antes de actuar.

Las cuatro piezas del kit

Pieza	Qué garantiza a la entidad	Estado
1 · Firma por rol y ciclo	La clave pertenece al cargo y al período («Alcaldía, ciclo 2027»), no a una persona. Cuando cambia la autoridad, cambia la clave y la identidad del cargo se mantiene.	probada en testnet
2 · Operador con política restringida	Quien paga solo puede enviar las operaciones autorizadas, con tope de gasto y de frecuencia. No puede usar su rol de pagador para otra cosa.	no implementada · la financia esta etapa
3 · Trazabilidad del pago	Cada comisión pagada queda enlazada a la autorización firmada que la originó. Así se audita al operador.	probada con el verificador
4 · Autorización portátil	La autorización firmada se publica. Si el operador desaparece o se niega a enviarla, cualquier tercero puede hacerlo. El operador opera el registro; no lo controla.	probada en testnet

Cómo se firma sin XLM

La municipalidad firma, el operador paga

En la mayoría de las redes, quien envía una operación es también quien la paga y quien la autoriza: las tres cosas van juntas. Soroban, el motor de contratos de Stellar, permite separarlas. La autorización se firma aparte, como un documento, y otra cuenta la envía y paga la comisión.

El rol nunca envía ni paga: solo firma. Por eso su saldo puede ser cero. Si el operador no envía la autorización, cualquier otra cuenta puede hacerlo mientras no venza.

Cómo se demostró

El 4 de octubre de 2026, una cuenta de rol con saldo cero firmó dos autorizaciones para la misma operación. El operador envió la primera y pagó 13 677 stroops, es decir 0,0013677 XLM. Un tercero envió la segunda y también se confirmó. Cuando ese tercero intentó reenviar la primera, la red la rechazó: cada autorización sirve una sola vez. La cuenta del rol terminó la prueba con 0 XLM.

Detalle técnico entradas de autorización, nonce, reservas, passkeys

En Soroban, la autorización de una invocación es una entrada de autorización que se firma por separado del sobre de la transacción. La documentación de Stellar lo describe así: «Auth-entry signing decouples authorization from transaction submission» (Stellar Development Foundation, s. f.-a). El contrato pide la firma con rol.require_auth().

Un solo uso. Cada entrada lleva un nonce, un número que la red marca como consumido. Reenviarla da Error(Auth, ExistingValue).
Plazo acotado. La entrada vence en 720 ledgers o menos, alrededor de una hora. Es el equivalente de una delegación de firma acotada en objeto y en tiempo.
Cuenta con saldo cero. Una cuenta clásica de Stellar necesita una reserva mínima para existir. El operador la paga mediante reservas patrocinadas, que permiten que una cuenta pague la reserva de otra (Stellar Development Foundation, s. f.-c). El rol firma su creación una sola vez y nunca recibe XLM.
Rotación por ciclo con passkey. La alternativa es una cuenta de contrato controlada por una passkey, la misma tecnología de huella digital o reconocimiento facial del teléfono. Stellar verifica esas firmas de forma nativa desde el Protocolo 21 (Stellar Development Foundation, 2024). El 5 de octubre se probó la rotación: la passkey del ciclo 1 autorizó el cambio a la del ciclo 2, y desde entonces la vieja fue rechazada. La dirección del cargo no cambió.
Traspaso de operador. Cambiar de operador es un cambio de configuración, no una migración: el nuevo operador asume el patrocinio de la reserva en una transacción que firman los dos, y el contrato y la clave del rol no se tocan. Probado el 5 de octubre.

La lógica del registro

La red no guarda documentos: guarda en qué paso está el proceso

El presupuesto participativo es un proceso con pasos que la ley ordena: primero la ordenanza, después la convocatoria, después el taller, y así. El registro modela ese orden como una máquina de estados: catorce transiciones, cada una con su evento, su firmante, su documento y su regla.

La pieza clave son las guardas: condiciones que el contrato verifica antes de aceptar un paso. Si la condición no se cumple, la operación falla en la red. Esa es la diferencia con un archivo o una base de datos común: un error no se detecta después, se impide antes.

El ciclo es único por municipalidad y año fiscal; los proyectos son varios dentro del ciclo y nacen del acta (T6). Esta etapa construye la fila superior. La fila inferior está especificada y corresponde a la iteración siguiente.

Ejemplo concreto: la clave única del ciclo

Dos municipalidades distintas pueden emitir una ordenanza con el mismo número el mismo año. Por eso la clave del ciclo combina tres datos: código territorial, número de norma y año fiscal. El ciclo de Tocache es 2210 : 001-2026-MPT : 2027. Si alguien intenta abrirlo dos veces, la guarda G2 lo rechaza.

Otro caso: la guarda G7 no rechaza un acto anterior a la vigencia de la norma; lo acepta con una alerta. El registro documenta hechos, no dictamina su legalidad. Rechazar ese acto dejaría la serie incompleta, y una serie incompleta sirve menos a un auditor que una serie completa con alertas.

Detalle técnico las catorce transiciones y las guardas

La especificación completa está en docs/maquina-estados.md, derivada artículo por artículo de la Ley N.° 28056, el Decreto Supremo (D.S.) N.° 142-2009-EF, el Instructivo N.° 001-2010-EF/76.01 y las normas locales de Tocache y La Punta. El recorrido interactivo la presenta en ocho hitos.

Guarda	Qué impide	En esta etapa
G1	Cualquier paso sin un ciclo abierto	se construye
G2	Abrir dos veces el mismo ciclo	se construye
G6	Confiar en la fecha declarada: se compara con la hora de la red y se marca si es retroactivo	se construye
G7	Perder actos previos a la vigencia: se aceptan con alerta	se construye
G8	Que una misma clave represente al comité de vigilancia y al consejo de coordinación local	se construye
G9	Firmar sin el quórum del comité (tres de cuatro)	siguiente iteración
G10	Puntajes inválidos: el contrato recalcula los trece criterios, de 13 a 71 puntos	se construye
G11	Incorporar al presupuesto sin código único de inversiones	siguiente iteración
G12	Cerrar un ciclo sin que el siguiente esté abierto	siguiente iteración

La especificación admite dos formas de abrir el ciclo. En Tocache, una sola ordenanza aprueba el reglamento, convoca y fija el cronograma. En La Punta, una ordenanza marco delega la convocatoria anual en un decreto de alcaldía. El contrato trata ambas como caso normal.

Cada paso cumplido producirá un certificado de hito: una consulta de solo lectura que responde si el paso existe, con qué documento, qué cargo lo firmó y en qué momento. Otro contrato puede negarse a actuar si el certificado no existe. Es el eslabón entre un acto administrativo verificable y un desembolso.

Arquitectura de datos

De un PDF de cuatro megabytes a 32 bytes en la cadena

Ningún documento se guarda en la blockchain. El PDF sigue en el portal de la municipalidad. A la red van dos cosas. Un registro legible: qué paso del proceso ocurrió, de qué ciclo, en qué fecha, qué cargos debían firmarlo y si se registró tarde. Y un sello: la huella, un código de 32 bytes calculado con el estándar público SHA-256 (algoritmo de huella segura de 256 bits), que no revela el contenido pero cambia por completo si se altera un solo carácter.

Cifras reales de la ordenanza 001-2026-MPT de Tocache, tomadas del validador del repositorio. Las dos barras lima son lo único que llega a la red. La escala es logarítmica: en escala lineal, la barra del compromiso no se vería.

Cómo se verá: el registro se lee, el sello lo respalda

El verificador ciudadano, que es el entregable 4 de la etapa financiada, mostrará cada paso en dos zonas. A la izquierda, lo que dice el registro, en lenguaje llano. A la derecha, el sello: no se lee, se comprueba.

Maqueta del verificador para el primer paso del ciclo de Tocache: a la izquierda el registro legible con fecha del acto, firmas exigidas, documento de sustento y alertas; a la derecha el sello con la huella del registro y la huella del PDF, y una zona para comprobar una copia propia del documento. — Maqueta con los datos reales de la Ordenanza Municipal N.° 001-2026-MPT. Los datos de la transacción en la red aparecen como pendientes porque este paso todavía no se ha sellado; la razón se explica más abajo.

Quién lo comprueba

La mayoría de los vecinos nunca va a verificar un documento, y no tiene por qué. Lo que importa es que verificar sea barato para quienes ya tienen la obligación de hacerlo. La transparencia funciona cuando la información entra en las rutinas de decisión que esos actores ya tienen (Fung et al., 2007).

Quién	Cómo	Disponible
Cualquier vecino	Arrastra al verificador el PDF descargado del portal. Su navegador calcula la huella en el propio equipo, sin enviar el archivo a ningún lado (Mozilla, s. f.), y le muestra qué se registró y si coincide.	entregable 4
Comité de vigilancia, órgano de control institucional, Contraloría, prensa	Lo mismo, como parte del informe del comité o de la auditoría, o directamente contra la red, sin pasar por la página de TechGob.	entregable 4
Personal técnico	Reproduce todo con herramientas estándar y el código abierto.	hoy

Qué garantiza el sello, y qué no

El sello garantiza que un documento no cambió después de registrarse. No garantiza que se haya registrado el documento correcto. La archivística distingue las dos cosas: la autenticidad es que un documento sea lo que dice ser y no haya sido alterado; la fiabilidad es que pueda dar cuenta de los hechos a los que se refiere (Duranti, 2001). Blockchain resuelve la primera, pero «does not guarantee reliability of information in the first place» (Lemieux, 2016). En la literatura técnica se conoce como el problema del oráculo: la red funciona sin que haya que confiar en nadie, pero lo que recibe desde afuera sí exige confianza (Caldarelli, 2020).

Garantía	¿La da el sistema?	Por qué medio
Integridad posterior: el archivo no cambió después de sellarse	sí	Criptográfico: la huella
Origen: el archivo sellado es el que publicó la entidad	solo si se controla el registro	Procedimental en Tocache. En La Punta, en parte criptográfico: su decreto trae siete firmas digitales
Veracidad o legalidad del contenido	nunca	Por diseño: el registro documenta hechos y no dictamina su legalidad (guarda G7)

Si se sella un archivo equivocado, la cadena lo protege igual de bien. Y desde ese día el documento auténtico parecería el alterado: un sello mal puesto no solo deja de proteger, sino que pone la protección en contra de la verdad. Por eso el punto crítico del sistema no es la red, sino el momento del registro.

El caso real: la inconsistencia número 1 de la ordenanza de Tocache

El validador numera cada problema que encuentra en un documento como una inconsistencia, de la INC-01 a la INC-16 en este caso. La número 1 es la única bloqueante. El 16 de septiembre de 2026, el operador de ingesta registró la ordenanza con una huella calculada sobre una copia que le habían enviado, y lo declaró así: huella_coincide_con_fuente: false, sin fecha de descarga del portal y con un solo revisor.

La regla del esquema impide sellar si no se cumplen tres condiciones a la vez: que la huella venga de la fuente oficial, que la hayan revisado al menos dos personas y que no quede ninguna inconsistencia bloqueante. Esta carga no cumple ninguna de las tres, y el expediente quedó en estado observado.

El 3 de octubre llegó por otro canal un segundo PDF de la misma ordenanza. Pesa 4 290 931 bytes; la copia registrada, 4 283 322. Las huellas no coinciden. Los datos extraídos de ambos son los mismos, pero los archivos no. Qué los diferencia: SIN DATO. La huella dice que algo cambió, nunca qué cambió. Y ninguno de los dos está certificado como la descarga directa del portal oficial.

El sistema detuvo a su propio equipo antes de sellar algo que no podía respaldar. Hay que decirlo con precisión: la regla no descubrió la diferencia por sí sola; convirtió en bloqueo la declaración honesta del operador, y una comprobación posterior con otro archivo la confirmó.

Cómo se controla el momento del registro

El diseño no inventa una lógica de control nueva: aplica en ese punto las normas de control interno del Estado peruano y las vuelve verificables por un programa. La Norma 3.2 de la Contraloría General de la República exige que la segregación de funciones contribuya «a reducir los riesgos de error o fraude», y la Norma 3.8, que los procesos estén «debidamente documentados» (Contraloría General de la República, 2006).

Control	Estado	Qué protege
Nada se sella sin las tres condiciones: huella de la fuente oficial, dos revisores, ninguna inconsistencia bloqueante	existe	Que se selle algo que no cumple el procedimiento
La huella se calcula sobre la descarga directa del portal oficial, con su fecha de descarga	entregable 3	El origen del archivo
Doble registro por dos personas con cargos distintos	entregable 3	El error individual: es la separación de funciones de la Norma 3.2
El verificador compara contra el archivo vigente del portal	entregable 4	Que la entidad reemplace después el archivo publicado sin que nadie lo note

El riesgo no es igual en los dos pilotos. El decreto de La Punta trae siete firmas digitales, que permiten verificar su origen en la propia ingesta. La ordenanza de Tocache es un escaneo sin firma digital: su origen solo se sostiene en el portal y en la revisión humana. El momento del registro es más frágil justo donde la evidencia de partida es más débil, y por eso existen dos perfiles de ingesta.

Si igual hay que confiar en quien registra, ¿para qué la cadena? Porque la confianza pasa a ser puntual y no continua: se deposita en un acto con fecha y firmante, no en años de custodia de un archivo que cualquiera con acceso al portal podría reemplazar. Hoy el portal muestra la ordenanza de Tocache con fecha 4 de marzo, después del taller del 25 de febrero, y no ofrece ninguna garantía de que el archivo sea el original. El registro no resuelve la fiabilidad, pero reemplaza «ninguna garantía» por «una garantía acotada, con responsables».

Una advertencia práctica

La huella compara archivos, no textos. Dos copias de la misma ordenanza pueden dar huellas distintas si una se volvió a guardar, a comprimir o a escanear, como muestra el caso de arriba. Por eso la comprobación solo vale sobre la descarga del portal oficial, y el verificador debe explicarlo cuando no hay coincidencia, en lugar de sugerir que hubo fraude.

Las demás inconsistencias de la ordenanza son alertas útiles para la propia municipalidad: el cronograma fija la remisión al Ministerio de Economía y Finanzas (MEF) en la III semana de febrero en el Anexo 1 y el 31 de marzo en la convocatoria; y la matriz de priorización no define cómo desempatar.

La regla de admisión: qué puede entrar a la cadena

Cada campo del esquema de datos declara, por escrito y verificable por código, dónde puede ir. La regla de fondo: solo se ancla lo que la ley ya obliga a publicar.

Valor	Significado	Ejemplo
cadena	Forma parte de lo comprometido en la red	La transición (T0), el ciclo, la fecha del acto
cadena_huella	Solo se ancla la huella del documento referido	El PDF de la ordenanza; el informe de sustento
fuera_de_cadena	Se conserva en el equipo del operador; nunca se publica	Datos de trabajo de la ingesta
prohibido	No puede existir en el registro	Cualquier documento de identidad

Detalle técnico validación en dos capas, compromiso canónico, protección de datos

Capa 1, esquema. Un esquema JSON (formato estándar de datos estructurados) de 1 451 líneas comprueba tipos, valores permitidos y campos obligatorios. Rechaza cualquier campo no declarado.
Capa 2, semántica. Reglas que un esquema no puede expresar: que el puntaje total sea la suma de los criterios, que no haya empates sin motivo, que no aparezcan nombres de campo que sugieran datos personales, incluso anidados.
Compromiso canónico. La carga admitida se ordena de una forma única antes de calcular su huella. Así, dos personas que la calculen por separado obtienen el mismo resultado: ef397780…b455 para la ordenanza de Tocache.
Privacidad por defecto. Un campo sin regla de admisión se trata como fuera_de_cadena. Un olvido del desarrollador no termina publicando un dato.
Nunca la huella de un dato personal. Ni de un Documento Nacional de Identidad (DNI), ni transformado: la huella de un dato con pocos valores posibles se revierte probando todos.
Versiones públicas. Las plantillas de Tocache incluyen columna de DNI. De esos documentos se ancla la versión sin esa columna.

El marco es la Ley N.° 29733 y su reglamento, el D.S. N.° 016-2024-JUS (Ministerio de Justicia y Derechos Humanos, 2024). El registro no reemplaza la evaluación de protección de datos que corresponde a cada entidad.

Hay siete casos de prueba de la ingesta; uno de ellos introduce a propósito un documento de identidad en un proyecto ficticio, y debe fallar. Si algún día pasa, la regla está rota.

Dónde vive y cómo se despliega

Cinco lugares, y quién opera cada uno

«Desplegar» significa poner el código a funcionar en el lugar donde se usa. Este proyecto tiene piezas en cinco lugares distintos, y conviene saber cuál cambia cuando alguien modifica algo.

Hoy el recorrido muestra evidencia registrada en el repositorio. En la cuarta semana de la etapa financiada pasa a leer la red en vivo (flecha punteada), sin necesidad de un servidor propio.

Lugar	Qué contiene	Quién lo cambia	Cómo se actualiza
Repositorio GitHub	Todo el código, la especificación, el plan y la evidencia. Es la fuente de verdad.	Cualquiera del equipo propone; Kevin revisa e integra	Propuesta de cambio (pull request) y aprobación
Integración continua	Comprobaciones automáticas: los validadores y sus casos de prueba	Nadie a mano	Corre sola con cada propuesta de cambio
Stellar testnet	Los contratos ya compilados y las transacciones	Desarrollo	Compilar y desplegar con la herramienta de Stellar
Equipo del operador	Los scripts del kit y las claves del operador	El operador: hoy TechGob, después el laboratorio de la SGTD	Las claves nunca entran al repositorio
Cloudflare Pages	El recorrido en signerkit.govtechpe.work	Dueña de producto	Subir la carpeta `demo/`; no se actualiza solo al cambiar el repositorio

Detalle técnico red de pruebas, compilación, comprobaciones automáticas

Testnet, no mainnet. La red de pruebas de Stellar funciona igual que la principal, pero sus monedas no tienen valor. Se reinicia aproximadamente una vez por trimestre y borra sus datos, con aviso de al menos dos semanas (Stellar Development Foundation, s. f.-d). Por eso cada prueba está automatizada y fechada: si un enlace deja de funcionar, se rehace en minutos.
Contratos. Están escritos en Rust y se compilan a WebAssembly antes de desplegarse. Hay dos en la red: el contrato de ejemplo CDGCV3TD…BL27 y la cuenta de rol con passkey CD7T3FZ4…MGUY. El contrato del registro del ciclo es el objeto de esta etapa.
Scripts del kit. Están en Python y leen las claves desde el almacén local de la herramienta de Stellar. Ninguna clave privada está en el repositorio.
Comprobaciones automáticas. Dos trabajos en GitHub Actions: el contrato de datos con sus siete casos y el verificador; y el plan de sprint con once casos. Todos pasan. El paso a mainnet requiere antes una auditoría externa, según el registro de decisión de arquitectura ADR-001 (Architecture Decision Record).
El sitio. Un solo archivo HTML (el formato de las páginas web), sin servidor, con cabeceras de seguridad que solo permiten cargar tipografías de Google.

Qué está probado hoy

Lo hecho, con evidencia, y lo que falta

Al 6 de octubre de 2026. Cada cifra se puede comprobar en el repositorio o en el explorador de la red.

3 / 4

piezas del kit probadas

transacciones registradas en testnet

0 / 6

guardas del ciclo ejecutadas en la red

1 / 9

pasos del ciclo con ingesta validada sobre un documento real

Hecho, autofinanciado

Máquina de estados derivada de la norma; contrato de datos con reglas por campo; validador en dos capas; análisis de los documentos de ambas municipalidades; firma sin XLM, traspaso de operador y rotación con passkey en testnet; verificador de conformidad; recorrido interactivo y video. Unas 45 horas de diseño más el desarrollo de la prueba de concepto.

Pendiente, lo financia esta etapa

El operador con política restringida (pieza 2); el contrato del registro con sus guardas; la ingesta de los dos tipos de documento; el verificador ciudadano en vivo; la investigación de usuario con ambas municipalidades; y la medición del costo real de comisiones por ciclo.

Planificación

Cuatro sprints, del 5 de octubre al 22 de enero

El trabajo se organiza en sprints, numerados de S00 a S03: períodos cortos con un objetivo, una capacidad en horas y un resultado comprobable al final. El plan no está escrito en prosa sino como datos que un programa valida: si las horas no suman, si un día cae en feriado o si una tarea depende de otra que va después, la comprobación automática falla. Los montos están en dólares estadounidenses (USD).

Dibujado a escala de días. S01 no tiene desarrollo comprometido: es el tiempo que toma la revisión de la postulación. El inicio de S02 depende de la resolución.

La etapa financiada: 30 días, cuatro entregables, numerados de E1 a E4

Semana 1 · E1Signer Kit v1

Firma para cualquier contrato
Operador con lista permitida, tope de gasto y registro de rechazos
Guías de instalación y de uso

Se comprueba siUn rol con 0 XLM autoriza una operación en otro contrato, y el operador rechaza tres violaciones de política.

Semana 2 · E2Registro del ciclo T0–T8

Contrato con seis guardas
Las dos formas de abrir el ciclo
Certificado de hito
Política de costo de almacenamiento

Se comprueba siEl ciclo 2027 de Tocache se abre en la red, y un paso omitido y un ciclo duplicado son rechazados.

Semana 3 · E3Ingesta v2 e investigación

Documentos escaneados y nativos digitales
Cinco ciclos de La Punta y Tocache 2027
Sesiones en terreno con ambas oficinas de planeamiento

Se comprueba siDos claves de rol distintas, cada una con 0 XLM, firman los pasos de ambas municipalidades.

Semana 4 · E4Verificador y medición

Verificador ciudadano en vivo
Costo real de comisiones por paso y por ciclo
Video actualizado y nota de preparación para mainnet

Se comprueba siUn revisor externo verifica un paso por municipalidad sin ayuda de TechGob.

El punto de control

Al final de la semana 2 se decide. Si las pruebas de las guardas no pasan, se activa el plan B: el registro se reduce a T0–T4 con cuatro guardas y el certificado de hito, y el resto pasa a la iteración siguiente. Los entregables 1 y 4 no se recortan. La regla es reducir alcance antes que entregar algo que no funciona.

Presupuesto

Entregable	Desarrollo	Producto e institucional	Costos directos	Total
E1 · Signer Kit v1	35 h	5 h	—	USD 800
E2 · Registro del ciclo	40 h	10 h	—	USD 1 000
E3 · Ingesta e investigación	25 h	35 h	USD 600 terreno	USD 1 800
E4 · Verificador y medición	20 h	20 h	—	USD 800
Transversal	—	—	USD 600 infraestructura y contingencia	USD 600
Total	120 h	70 h	USD 1 200	USD 5 000

Tarifa única de USD 20 por hora para todo el equipo. Las comisiones de la red de pruebas no son una partida: las paga el operador. El trabajo previo autofinanciado no se carga a esta etapa.

Detalle técnico cómo se calcula la capacidad de un sprint

Con el sprint S00 como ejemplo, publicado en planning/sprint_S00_preparacion_postulacion.json:

Tres días hábiles (5, 6 y 7 de octubre; el 8 es feriado por el Combate de Angamos) a siete horas: 21 horas brutas.
Se descuentan las reuniones del método: planificación, reuniones diarias, revisión y retrospectiva, 3 horas. Quedan 18 horas netas.
Se reserva un colchón del 17 % para imprevistos, 3 horas. Se comprometen 15 horas en tres historias de usuario.
El plan diario asigna esas horas día por día, y la comprobación automática verifica que cuadren con las estimaciones y que ningún día supere su capacidad.

Historias de usuario

Qué debe poder hacer alguien, y cómo se sabe que lo logró

Una historia de usuario (HU) describe un resultado desde el punto de vista de quien lo usa, no una tarea técnica. Cada una lleva criterios de aceptación (CA) escritos en tres partes: dado un punto de partida, cuando ocurre algo, entonces debe verse un resultado concreto. Si el resultado no se ve, la historia no está terminada, aunque el código exista.

HU-00Repositorio público con el trabajo ya diseñado

publicado

Para que un evaluador pueda revisar lo diseñado sin pedir acceso ni explicaciones.

CA-00-1

dadoUn clon limpio del repositorio

cuandoUn tercero sigue el README, el archivo de instrucciones del repositorio

entoncesEjecuta el validador y obtiene los siete casos con su resultado esperado

integración continua en verde

CA-00-2

dadoEl repositorio publicado

cuandoSe revisa su contenido

entoncesIncluye esquema, validador, casos de prueba, máquina de estados y licencia abierta

Apache-2.0

HU-01Firma sin XLM en la red de pruebas

evidencia en testnet

Para demostrar que una entidad puede autorizar sin poseer el activo, antes de pedir financiamiento para el resto.

CA-01-1

dadoUna clave de rol sin saldo, un operador con saldo y una autorización A firmada

cuandoEl operador envía A y paga la comisión

entoncesLa transacción se confirma y el explorador lo muestra

8ba16039…7e5f ↗

CA-01-2

dadoUna segunda autorización B, del mismo rol, para la misma operación

cuandoUna tercera cuenta, distinta del operador, envía B

entoncesSe confirma: quien envía no necesita ser el operador

fb284c5b…b8dd ↗

CA-01-3

dadoLa autorización A, ya usada

cuandoSe intenta enviar otra vez

entoncesLa red la rechaza: la autorización es de un solo uso

ac8f406c…0542 ↗

HU-02Video de demostración

publicado · 1:41

Para que un evaluador entienda el problema y la solución en menos de dos minutos.

CA-02-1

dadoLa prueba de concepto funcionando

cuandoSe graba el video

entoncesMuestra el problema, la firma sin XLM, el enlace al explorador y la verificación por un tercero

youtu.be ↗

Las historias de la etapa financiada se escriben con el mismo formato al iniciar el sprint S02. Sus criterios de aceptación ya están comprometidos en el Statement of Work, por entregable. Algunos ejemplos:

Entregable	Criterio de aceptación comprometido
E1	El operador rechaza, dejando registrado el motivo, un contrato no permitido, una función no permitida y una operación que supera el tope de gasto.
E2	Las pruebas fallan en la red para: paso omitido, ciclo duplicado, paso sin ciclo, firmante equivocado, misma clave para comité y consejo, y puntaje fuera de escala.
E3	Los cinco ciclos publicados de La Punta se ingieren sin excepciones manuales; cualquier rechazo se explica por una regla del validador.
E4	En el recorrido, las guardas cambian de «especificadas, contrato no desplegado» a «ejecutadas en testnet», cada una enlazada a su transacción.

Detalle técnico definición de terminado

Además de sus criterios propios, toda historia cumple la misma definición de terminado:

Se reproduce desde un clon limpio siguiendo el README.
No hay claves ni secretos en el código.
Ninguna salida contiene datos personales.
Cada enlace citado abre y muestra lo que el texto afirma. Donde el repositorio no registra un valor, dice SIN DATO en lugar de estimarlo.
La integración continua está en verde.

Roles y gobernanza

Quién decide qué construir, y quién decide cómo

Nadinne Canto Novoa · dueña de producto

Define el alcance, prioriza el trabajo y acepta los entregables. Diseñó la máquina de estados a partir del marco normativo, el contrato de datos y la especificación funcional. Lleva la relación con las instituciones.

Kevin Alexander Soto Burgos · desarrollo

Arquitectura técnica, revisión de implementabilidad de la especificación, implementación en Soroban, separación entre firmante y pagador, ingesta y verificador. Revisa e integra los cambios al repositorio.

Cómo cambia la especificación. Quien implementa puede y debe proponer cambios cuando algo no es implementable. La propuesta se hace en el repositorio, explicando qué no funciona y qué alternativa se propone; la dueña de producto la aprueba o la rechaza. Las reglas que vienen de la norma no se abandonan por conveniencia técnica: si una guarda no se puede implementar como está escrita, se busca otra forma de cumplirla.

Contrapartes. La SGTD y su Red Nacional de Laboratorios de Innovación Digital, la Municipalidad Provincial de Tocache y la Municipalidad Distrital de La Punta. Aportan el caso de uso y la validación en terreno; no son responsables del código.

Un especialista en tokenización se incorpora en la segunda iteración.

Riesgos

Lo que puede salir mal, y qué se hace

Riesgo	Prob.	Impacto	Mitigación
Retraso en documentos municipales: constancia de publicación, actas sin columna de DNI	media	medio	Se solicitan al inicio del sprint. Los pasos sin documento se informan como pendientes y nunca se completan con supuestos.
Costo de almacenamiento en la red subestimado	media	alto	La política de almacenamiento es parte de E2 y su costo se mide en E4.
Reinicio trimestral de la red de pruebas	media	bajo	Cada prueba está automatizada y fechada; se rehace en minutos.
Un operador único concentra poder	baja	alto	Las autorizaciones se publican y cualquiera puede enviarlas; el traspaso de operador ya está probado.
Datos personales llegan a la cadena	baja	alto	Regla de admisión por campo, privacidad por defecto, validación en dos capas y un caso de prueba que debe fallar.
Una guarda no es implementable tal como está escrita	baja	medio	Cambio propuesto en el repositorio y aprobado por la dueña de producto.

Cuándo se volvería atrás

La decisión de usar contratos inteligentes, y no solo las funciones básicas de Stellar, tiene condiciones escritas para revertirla: que no se obtenga una auditoría antes de mainnet, que no se pueda garantizar el costo de almacenamiento a diez o veinte años, o que el volumen real sea tan bajo que la firma múltiple nativa con revisión humana baste.

Después de esta etapa

Primero se vuelve verificable la decisión; después se mueve el valor

La segunda iteración (USD 8 000, seis semanas) completa el nivel proyecto del ciclo y agrega el primer caso donde el patrón entrega algo persona por persona.

Nivel proyecto, T9 a T13

Incorporación al presupuesto con código único de inversiones, vigilancia, sustitución con sus siete reglas, rendición de cuentas y cierre.

Un registro no transferible por proyecto

Cada proyecto priorizado recibe un registro en la red que representa el compromiso, su estado y sus pruebas. No es una criptomoneda.

Firma múltiple del comité

Tres de cuatro miembros del comité de vigilancia firman juntos, con la guarda G9.

Programa del Vaso de Leche

Entregas mensuales atestiguadas por los comités del programa, sin mover un sol en la cadena y sin tocar el padrón de beneficiarias.

En las dos primeras etapas TechGob paga las comisiones. Después, el rol de operador pasa al laboratorio de innovación de la SGTD, y el traspaso ya probado lo convierte en un cambio de configuración. El camino a mainnet pasa por una auditoría externa.

Glosario

Los términos, en una línea cada uno

Blockchain o cadena: Un registro compartido por muchas computadoras independientes, donde lo escrito no se puede borrar ni modificar en silencio.
Stellar: Una red blockchain pública, diseñada originalmente para pagos.
Soroban: El motor de contratos inteligentes de Stellar.
Contrato inteligente: Un programa que vive en la red y ejecuta reglas sin que nadie pueda saltárselas.
XLM: La moneda propia de Stellar, con la que se pagan las comisiones.
Comisión: Lo que cobra la red por procesar una operación.
Stroop: La unidad mínima de XLM: un XLM son diez millones de stroops.
Testnet y mainnet: La red de pruebas, sin valor económico, y la red principal.
Ledger: Cada bloque de operaciones que la red confirma; en Stellar se cierra uno cada pocos segundos.
Huella o hash (SHA-256): Un código de 32 bytes que identifica un archivo. Si cambia un carácter del archivo, la huella cambia por completo.
Clave de rol: La clave que pertenece a un cargo y un período, no a una persona.
Autorización firmada: La firma del cargo sobre una operación concreta, separada del envío y del pago.
Nonce: Un número de un solo uso que impide reutilizar una autorización.
Operador o relayer: La cuenta que envía las operaciones a la red y paga sus comisiones.
Reserva patrocinada: El saldo mínimo que una cuenta necesita para existir, pagado por otra cuenta.
Passkey: Una credencial guardada en el teléfono o computador que se usa con huella digital o reconocimiento facial.
XDR: El formato en que Stellar escribe transacciones y autorizaciones para que cualquiera las lea.
Máquina de estados: Un modelo que define los pasos posibles de un proceso y en qué orden se permiten.
Guarda: Una condición que el contrato comprueba antes de aceptar un paso.
Inconsistencia (INC): Un problema que el validador encuentra en un documento; cada una lleva un número y una severidad: bloqueante, alerta o informativa.
Autenticidad y fiabilidad: Que un documento no haya sido alterado, y que dé cuenta correctamente de los hechos. El sello garantiza la primera, no la segunda.
Ingesta: El proceso de leer un documento oficial, extraer sus datos y validarlos antes de registrarlo.
Compromiso: La huella de los datos admitidos de un documento; es lo que se ancla en la red.
Costo de almacenamiento (renta de estado): Lo que la red cobra por mantener datos guardados en un contrato a lo largo del tiempo.
Repositorio: El lugar donde vive el código, con todo su historial de cambios.
Pull request y merge: Una propuesta de cambio al repositorio, y el acto de incorporarla una vez revisada.
Integración continua: Comprobaciones automáticas que corren cada vez que alguien propone un cambio.
Sprint: Un período corto de trabajo con objetivo, capacidad en horas y resultado comprobable.

Fuentes

Referencias

Caldarelli, G. (2020). Understanding the blockchain oracle problem: A call for action. Information, 11(11), 509. https://doi.org/10.3390/info11110509
Congreso de la República del Perú. (2003). Ley N.° 28056, Ley Marco del Presupuesto Participativo. https://cdn.www.gob.pe/uploads/document/file/1324460/2018%20Ley%20Marco%20del%20Presupuesto%20Participativo.pdf
Contraloría General de la República. (2006). Normas de control interno (Resolución de Contraloría N.° 320-2006-CG). https://cdn.www.gob.pe/uploads/document/file/2914323/Normas%20de%20Control%20Interno%2C%20aprobadas%20por%20R.C.%20N%C2%B0%20320-2006-CG%20de%2030.OCT.2006%2C%20publicada%20el%2003.NOV.2006.pdf
Duranti, L. (2001). The long-term preservation of authentic electronic records [Ponencia]. 27th International Conference on Very Large Data Bases, Roma. https://www.interpares.org/display_file/ip1_dissemination_cs_duranti_vldb_2001.pdf
Fung, A., Graham, M., & Weil, D. (2007). Full disclosure: The perils and promise of transparency. Cambridge University Press. https://ash.harvard.edu/wp-content/uploads/2007/01/Full_Disclosure.pdf
Lemieux, V. L. (2016). Trusting records: Is blockchain technology the answer? Records Management Journal, 26(2), 110–139. https://doi.org/10.1108/RMJ-12-2015-0042
Ministerio de Justicia y Derechos Humanos. (2024). Decreto Supremo N.° 016-2024-JUS, que aprueba el Reglamento de la Ley N.° 29733, Ley de Protección de Datos Personales. https://www.gob.pe/institucion/anpd/normas-legales/6554453-16-2024-jus
Mozilla. (s. f.). SubtleCrypto: digest() method. MDN Web Docs. https://developer.mozilla.org/docs/Web/API/SubtleCrypto/digest
National Institute of Standards and Technology. (2015). Secure Hash Standard (SHS) (FIPS PUB 180-4). https://csrc.nist.gov/pubs/fips/180-4/upd1/final
Stellar Development Foundation. (s. f.-a). Signing Soroban contract invocations. Stellar Docs. https://developers.stellar.org/docs/build/guides/transactions/signing-soroban-invocations
Stellar Development Foundation. (s. f.-b). Smart contract authorization. Stellar Docs. https://developers.stellar.org/docs/learn/encyclopedia/security/authorization
Stellar Development Foundation. (s. f.-c). Sponsored reserves. Stellar Docs. https://developers.stellar.org/docs/build/guides/transactions/sponsored-reserves
Stellar Development Foundation. (s. f.-d). Networks. Stellar Docs. https://developers.stellar.org/docs/networks
Stellar Development Foundation. (s. f.-e). Instawards: Official rules. SCF Handbook. https://stellar.gitbook.io/scf-handbook/scf-awards/instawards/official-rules
Stellar Development Foundation. (2024, 18 de junio). Protocol 21 is live on Stellar mainnet. https://stellar.org/blog/developers/protocol-21-is-live-on-stellar-mainnet
TechGob. (2026). Institutional Signer Kit [Repositorio de software, Apache-2.0]. GitHub. https://github.com/techgob/institutional-signer-kit