Proyecto CEPLAN V.01-Blockchain. Un registro que permite demostrar qué versión de un plan existe, quién la aprobó, cuándo, y que la evidencia no fue alterada, sin almacenar el documento en la cadena.
Un Estado planifica antes de gastar. En Perú, el Sistema Nacional de Planeamiento Estratégico obliga a que cada entidad formule un plan institucional articulado al plan sectorial, y un plan operativo articulado al institucional. De esa cadena depende que el presupuesto se ejecute contra objetivos vigentes.
La cadena se sostiene sobre registros que hoy no pueden probar su propia integridad. Una auditoría técnica del ecosistema encontró tres brechas concretas. Los registros son editables y sus bitácoras internas carecen de sellado oponible a terceros. La firma digital cualificada existe y está desplegada, pero no está acoplada a las transacciones del aplicativo: la aprobación jurídica del plan ocurre por fuera, por oficio y resolución publicada. Y las validaciones no siguen reglas de control de versiones, de modo que pueden coexistir versiones superpuestas de un mismo instrumento.
El efecto no es documental sino presupuestal. Cuando un plan operativo se aprueba huérfano de un plan institucional vigente, la cadena de resultados se rompe y el gasto queda amarrado a un objetivo que ya no rige. Cuando coexisten versiones superpuestas, el presupuesto se ejecuta contra planes derogados. Y el problema más difícil no es demostrar que un documento fue alterado —el sello de tiempo ya lo resuelve—, sino demostrar que ningún documento fue suprimido de la serie.
Hasta diciembre de 2024, operar una red soberana en el ecosistema exigía inmovilizar 2.000 AVAX por validador, una cifra sin vía de adquisición posible para una entidad pública sujeta a la ley de contrataciones. El upgrade Etna, mediante la propuesta ACP-77, eliminó ese requisito y lo sustituyó por una tarifa continua de orden operativo. Con este cambio, una entidad de gobierno puede presupuestar ese costo.
El reglamento de protección de datos personales, plenamente vigente desde marzo de 2025, incorporó la privacidad desde el diseño como obligación. El reglamento del marco de confianza digital, aprobado en noviembre de 2025, ordenó el terreno institucional. La separación entre datos fuera de cadena y prueba criptográfica en cadena dejó de ser una opción de diseño para convertirse en la única forma admisible de construir esto.
La barrera habitual de cualquier sistema de confianza digital es la identidad. CEPLAN ya tiene firma digital cualificada desplegada. El piloto no parte de cero: parte de una capa de identidad consolidada que hoy está subutilizada.
El programa de transformación digital del Estado peruano financiado por el BID mantiene abierta la línea de innovación digital bajo la cual este piloto es elegible, de modo que el escalamiento no compite por presupuesto ordinario escaso.
El 1 de agosto de 2026, mediante Resolución Jefatural N° D000012-2026-RENIEC/JNAC, se aprobaron los lineamientos del Documento Nacional de Identidad digital, con el mismo valor legal, eficacia jurídica y fuerza probatoria que el DNI físico, en cumplimiento del plazo fijado por el D.S. N° 098-2025-PCM, que creó el Marco de Identidad Digital del Estado Peruano. Los lineamientos describen una arquitectura descentralizada de emisor, titular y verificador, definen la credencial verificable como documento digital firmado criptográficamente por un emisor de confianza, y habilitan la divulgación selectiva: el ciudadano revela solo los datos estrictamente necesarios para cada trámite, autorizando con biometría o PIN.
Esos son, con otras palabras, los mismos componentes que este prototipo venía proponiendo: credencial verificable, identificador descentralizado y presentación selectiva. Hasta hace cinco semanas eran una decisión de diseño que había que defender ante la entidad; hoy son la política de identidad digital del Estado peruano. La emisión debía iniciarse dentro de los treinta días hábiles siguientes al 1 de agosto, de modo que el piloto llegaría exactamente cuando el ecosistema de identidad se está poniendo en marcha y aún no tiene casos de uso institucionales que lo ejerciten.
El principio de diseño es que la cadena no almacena planes, sino pruebas sobre ellos. El documento, sus anexos y los datos personales del firmante permanecen en el repositorio de la entidad. A la red viaja únicamente la huella criptográfica del documento, el evento, el actor identificado por un identificador descentralizado y el sello de tiempo. Si alguien altera una coma del plan almacenado fuera de cadena, su huella deja de coincidir con la registrada y la discrepancia es demostrable por cualquiera.
Sobre esa base, cinco contratos inteligentes convierten en condiciones técnicas las reglas que hoy se verifican a mano: registro de versiones, articulación obligatoria entre instrumentos, ciclo de aprobación, unicidad de la versión vigente por periodo y gobernanza de la red. El contrato de articulación es el núcleo: codifica que un plan operativo no puede aprobarse si su plan institucional padre no está vigente. La inconsistencia estratégica deja de ser posible por diseño, no por diligencia del revisor.
Lo que se vuelve inmutable no son los planes, sino la regla de articulación entre ellos. Eso distingue esta propuesta de un registro notarial genérico.
El nodo observador del órgano de control es permanente por mandato legal y no revocable, pero cada una de sus consultas queda inscrita en el mismo registro inmutable. El control conserva su potestad y pierde su opacidad.
La elección de Avalanche no fue arbitraria sino el resultado de una auditoría comparativa entre siete redes, y el método importa tanto como el resultado.
La pregunta que se evaluó no fue cuál es la mejor tecnología en abstracto, sino cuál es admisible para una entidad pública peruana. Eso obligó a jerarquizar los criterios en lugar de promediarlos. Dos son eliminatorios y binarios: la gobernanza soberana sobre el conjunto de validadores, porque la ley que crea el sistema de planeamiento otorga rectoría exclusiva a una sola entidad y esa rectoría no es delegable a un comité externo; y la admisibilidad del gasto bajo la normativa de contrataciones. Los demás —costo, portabilidad, estándares, madurez del ecosistema— son graduales: ponderan, no descalifican.
Con ese orden, cuatro de las siete plataformas evaluadas quedaron fuera por gobernanza antes de llegar a la evaluación económica. De ahí un resultado que sin el método parecería contradictorio: la configuración más barata de todo el cuadro está descartada, porque en esa red los validadores los gobierna un comité de permisionamiento ajeno a la entidad rectora.
Descartado el costo como criterio, lo que decide es la gobernanza. Avalanche resuelve de forma nativa y programable lo que la ley peruana exige: un contrato de gestión de validadores cuyo propietario único puede ser un multifirma de la entidad rectora, que controla el alta, la baja y el peso de cada validador. La alternativa soberana en el otro ecosistema exige que la entidad levante y orqueste una red nacional dedicada, asumiendo funciones de permisionamiento y soporte que hoy cumple una asociación regional. Es viable —hay un precedente en Brasil— pero es un proyecto institucional en sí mismo, no una plataforma sobre la cual pilotear. A eso se suman el ecosistema de herramientas maduro y una capacidad de mensajería entre cadenas sin equivalente nativo en la alternativa, relevante si el registro debe conversar mañana con otros dominios del Estado.
La conclusión es que Avalanche es la mejor opción disponible hoy para el Estado peruano en este tipo de registro, con una condición explícita —que se resuelva la admisibilidad del gasto en la tarifa de red—, y esa condición es justamente el cuarto hito de esta postulación.
En Perú, el sistema de planeamiento abarca 2.058 pliegos presupuestales que formulan y mantienen del orden de 6.200 instrumentos activos de forma simultánea. Esas 2.058 entidades son las que deben incorporarse a la red para registrar y validar sus instrumentos, y ahí está el techo natural del despliegue nacional.
Conviene precisar en qué calidad se incorporan, porque de ello depende el costo de escalar. Las entidades entran como nodos escritores y clientes del registro —emiten, consultan y acreditan—, no como validadores del consenso, que permanecen en un conjunto reducido bajo control de la entidad rectora. Por eso el crecimiento es por adhesión y no por reingeniería: incorporar la entidad número mil no cambia la arquitectura ni multiplica el costo de la red, porque el costo de infraestructura depende del número de validadores y no del número de participantes.
El patrón se repite fuera del planeamiento. El mismo diagnóstico —trazabilidad, inmutabilidad e interoperabilidad entre entidades que se validan mutuamente— apareció en otros desafíos levantados por TechGob y la SGTD en el taller de marzo, que forman parte de nuestro portafolio de proyectos: cuatro registros públicos distintos con una misma carencia estructural, que además se repite fuera de Perú, tal como lo indica nuestro trabajo de campo con el Laboratorio de Gobierno de Chile. Lo que se construya aquí no es un sistema para una entidad específica: es una implementación de referencia para una categoría de registro público que hoy no tiene solución estándar en el ecosistema.
Pliegos presupuestales que deben incorporarse a la red como nodos escritores.
Planes institucionales y operativos activos de forma simultánea en todo el Estado.
Otros desafíos con la misma carencia estructural, levantados en el taller de marzo.
El grant financia la implementación de referencia: los cinco contratos, la integración con la firma digital del Estado y el portal público de verificación. Los contratos se publican con licencia abierta, porque su valor para el ecosistema está en que otra entidad los reutilice, no en que sean propietarios.
Lo que TechGob monetiza no es el código sino la incorporación: el diseño de gobernanza de red, la integración con los sistemas legados de cada entidad, la adecuación normativa y la operación acompañada. El activo de la firma es su metodología, y esa metodología no se cede: se aplica. Cada entidad que se suma es una implantación, y cada país con sistema de planeamiento es una réplica.
La disciplina que hace posible ese segundo tiempo es una restricción de diseño autoimpuesta: la lógica de dominio no se acopla a componentes propietarios de ninguna plataforma. La gestión de validadores, el pago de gas y la mensajería entre cadenas viven en una capa de infraestructura separada de los cinco contratos.
Conviene decir con todas sus letras por qué eso conviene también a quien financia. Un registro público de integridad no se adopta por entusiasmo tecnológico sino por decisión administrativa, y ninguna entidad rectora firma una dependencia de plataforma que no pueda revertir: la reversibilidad no es una concesión al escepticismo ni el anuncio de una salida, es la condición que hace posible la firma y la que permite que el despliegue permanezca. Una implementación de referencia demostrablemente portable se adopta más veces que una cautiva, y cada adopción ocurre sobre la plataforma que llegó primero, que resolvió el camino institucional y que no obligó a nadie a apostar sin salida.
El 31 de marzo de 2026 se realizó en Lima el Taller internacional «Blockchain para resolver desafíos del sector público», organizado por la Presidencia del Consejo de Ministros a través de la Secretaría de Gobierno y Transformación Digital, diseñado por TechGob y financiado por Clarity DAO Protocol. La convocatoria exigía que cada entidad postulara con un equipo de dos personas con rango directivo —una del área de tecnologías y otra del área usuaria del problema— y que trabajara sobre un desafío real de su institución.
Por parte de CEPLAN postuló su especialista en transformación digital y su coordinador de sistemas administrativos transversales. El desafío que llevó al taller es el que este proyecto resuelve, y en la propia postulación manifestó su interés en desarrollarlo junto a TechGob. De la jornada salió además un acuerdo de trabajo con la Secretaría de Gobierno y Transformación Digital para buscar financiamiento que permita construir el prototipo.
Esto importa por una razón precisa: el problema no lo formuló el proveedor, lo formuló la entidad, y lo hizo por escrito ante su propio rector de gobierno digital. La contraparte no es un contacto generalista, sino los dos roles que deben concurrir para que una implantación de este tipo prospere: quien controla la plataforma y quien es dueño del proceso.
Evidencia: el taller, su organización y la participación de TechGob son verificables en el portal oficial del Estado peruano. El interés de CEPLAN consta en su formulario de postulación y en el acuerdo de trabajo con la Secretaría. Nuestro trabajo puede consultarse en techgob.cl.
Disponible en ceplan.govtechpe.work. Recorre el ciclo de vida completo del instrumento, el historial de trazabilidad y el control de accesos, con la advertencia explícita de que la red no está desplegada.
Criterios eliminatorios y graduales, modelos de costo íntegramente formulados y trazables, y una nota metodológica que documenta los errores corregidos durante el propio análisis, incluida la rectificación del requisito de stake tras Etna.
Modelo de datos dentro y fuera de cadena, cinco contratos con sus reglas, flujo de siete etapas y stack recomendado.
Mapeo artículo por artículo de las obligaciones de protección de datos a decisiones de arquitectura, e inventario de lo portable, lo que exige readaptación y lo que debe reemplazarse.
El proyecto exige tres capacidades que rara vez coinciden en un mismo equipo: capacidad técnica en contratos inteligentes e identidad descentralizada, dominio del marco normativo aplicable y experiencia de gestión pública capaz de conducir la adopción institucional, que es el ámbito en el que fracasa la mayoría de los pilotos GovTech.
Dirección del proyecto, habilitación normativa y gestión institucional. Doctora (c) en Filosofía. Especialista en investigación de usuario aplicada a desafíos de innovación pública, con foco en habilitación normativa y desarrollo de proyecto, y consultora estratégica en blockchain, visualización de datos y gobierno abierto. Ha promovido la investigación sobre la adopción de blockchain en entidades públicas, desarrollando trabajo conjunto con el Laboratorio de Gobierno del Ministerio de Hacienda de Chile y con la Secretaría de Gobierno y Transformación Digital del Perú, con la que TechGob coorganizó el taller del que surgió este proyecto. Conduce el pronunciamiento institucional sobre la admisibilidad del gasto y la relación con la entidad, que es la parte del proyecto que ninguna capacidad técnica puede sustituir.
Arquitectura, contratos inteligentes e infraestructura de red. Ejecutivo de tecnología con 29 años de experiencia, con trayectoria en Santander y Banmédica liderando estrategias DevOps, automatización y modernización de plataformas. Actualmente es CTO de HealthProof —identidad médica, interoperabilidad clínica y trazabilidad— y de CertiLink —certificación y validación digital—: dos dominios técnicamente análogos a este registro, donde el problema es el mismo, probar la integridad y el origen de un documento sin exponer su contenido. Es además CTO de NodoZero, iniciativa dedicada a acelerar la adopción de blockchain y Web3 mediante comunidades y eventos, que aporta capacidad de difusión en el ecosistema.
Su formación en la plataforma propuesta es directa: bootcamp de contratos inteligentes en Avalanche (2024) y bootcamp de capa uno sobre P-Chain (2025), que es exactamente la arquitectura que este piloto despliega, además de formación en Chainlink, Arbitrum, Stacks y SUI. Obtuvo el cuarto lugar en el Avalanche Private Edition Hackathon de 2024 con una solución de identidad y trazabilidad en salud.
Ambos integrantes comprometen el 80 % de su jornada a este proyecto durante los tres meses de ejecución, con el grant cubriendo una parte de ese costo y TechGob aportando la diferencia como coinversión. No es un dato menor en un equipo pequeño: la causa más frecuente de incumplimiento en pilotos de esta escala no es la dificultad técnica sino la dispersión del equipo entre iniciativas paralelas.
Despliegue de la capa uno con gestión de validadores bajo control exclusivo de la entidad rectora, condición derivada del mandato legal de rectoría exclusiva sobre el sistema de planeamiento.
Con validación automática de la articulación entre instrumentos y control de unicidad de la versión vigente, sobre instrumentos de tres a cinco sectores piloto.
Los mismos contratos recompilados y desplegados en una red alternativa con un cambio de código fuente acotado. No es un plan de migración: es la prueba de que la entidad no queda cautiva, que es la garantía sin la cual un rector público no firma, y la evidencia de que la implementación de referencia es reutilizable por otros gobiernos del ecosistema.
Gestionar que el Estado se manifieste formalmente sobre cómo una entidad pública puede sostener una tarifa de red denominada en un activo digital. La vía es la Subsecretaría de Política y Regulación Digital de la SGTD, que es la unidad que produce los informes técnicos sobre los que se sustentan las directivas del ente rector en materia de gobierno y confianza digital. Es trabajo de gestión institucional con costo real —expediente, sustento técnico, seguimiento del trámite— y por eso figura como hito presupuestado y no como supuesto.
La normativa peruana de contrataciones —desde abril de 2025, la Ley N° 32069 y su reglamento, que sustituyeron a la Ley N° 30225— no contempla un mecanismo expreso para que una entidad adquiera activos digitales, y la tarifa continua de validación se paga en el activo nativo de la red. La vía prevista es que la infraestructura se provea como servicio por el implementador, de modo que la entidad contrate un servicio de tecnología ordinario y no adquiera el activo.
Esa vía es razonable pero no está confirmada, e implica dos dimensiones que conviene no confundir. La primera es de política: si sostener una infraestructura de confianza digital cuya tarifa se denomina en un activo digital es admisible dentro del marco de gobierno y confianza digital, materia sobre la cual la SGTD tiene rectoría y autoridad técnico-normativa. Ese es el plano donde interviene la Subsecretaría de Política y Regulación Digital y donde la respuesta puede ser general. La segunda es de contratación: cómo se estructura y adjudica ese servicio en un caso concreto, lo que corresponde a la oficina de administración de la entidad y, en su ámbito, al organismo especializado en contrataciones públicas. El hito 4 aborda la primera, que es la que desbloquea a todos, y deja encaminada la segunda.
Declaramos este riesgo por adelantado porque su resolución determina el modelo de operación de largo plazo, y porque un piloto que lo oculta traslada el problema a la entidad en el peor momento posible: cuando ya hay software funcionando y nadie puede pagar la red que lo sostiene.
El piloto se ejecuta en red de pruebas, no en red principal. Dado que el objetivo es demostrar gobernanza, identidad, validación y operación de la capa uno, no es necesario asumir desde el inicio costos irreversibles de red principal. El piloto reproduce la arquitectura y los componentes esenciales previstos para la red productiva, utilizando una configuración de pruebas equivalente, lo que permite probar consenso, validadores, gobernanza, contratos, interfaces, flujos de identidad, integración, observabilidad y operación de nodos: la misma implementación de capa uno soberana y el mismo modelo de gobernanza y validación.
La razón no es presupuestal sino de consistencia: mientras el Estado no se haya pronunciado sobre la admisibilidad del gasto en la tarifa de red, comprometer fondos en ella sería contradecir el propio hito 4. Se demuestra primero y se paga después de que exista respuesta.
Dos precisiones que preferimos declarar antes de que las pregunten. La integración con la firma digital del Estado queda simulada en la capa de aplicación: el objetivo es demostrar el límite de integración, mientras su implementación real depende del entorno y las credenciales que provea la entidad, por lo que comprometer un plazo sobre una dependencia que no controlamos sería comprometer una fecha que no podemos sostener. Y el monto solicitado cubre una fracción del esfuerzo comprometido: la diferencia la aporta TechGob como coinversión en especie.
Es un presupuesto de ejecución, no un calendario de desembolsos: el Mini Grant se entrega en un pago único, de modo que los hitos operan como compromisos de entrega verificables y no como condiciones de pago. Cada partida indica su grado de verificación, para que el lector distinga qué cifra está confirmada y cuál debe cotizarse antes de usarse para decidir.
| # | Partida | Detalle | USD | Estatus |
|---|---|---|---|---|
| 1 | Dirección, investigación de usuario y gestión institucional | Levantamiento con las áreas usuarias de CEPLAN; expediente y sustento técnico ante la SSPRD; interlocución con RENIEC sobre el marco de identidad digital; conducción del proyecto | 3.600 | Definido |
| 2 | Arquitectura, desarrollo e integración | Capa uno soberana y gestión de validadores; cinco contratos en Solidity; frontend e integración; capa de identidad; prueba de reversibilidad; releases y documentación | 3.600 | Definido |
| 3 | Infraestructura de nodos | Tres instancias de máquina virtual (4 vCPU / 8 GB) durante 4 meses, con un mes de margen posterior al cierre | 600 | A COTIZAR |
| 4 | Viaje a Lima | Una persona, una semana, agendado contra la presentación del expediente institucional | 1.600 | A COTIZAR |
| 5 | Contingencia | Variación de precios, riesgo cambiario y margen de infraestructura | 600 | Definido |
| Total | 10.000 |
Tres validadores, no cinco. El conjunto de validadores del piloto se reduce a tres, suficiente para demostrar lo único que hay que demostrar en esta etapa: que el alta, la baja y el cambio de peso de un validador los decide la entidad rectora a través del contrato de gestión, y nadie más. La configuración de cinco corresponde al dimensionamiento de producción y se documenta como tal, sin operarla.
Infraestructura. Se presupuestan instancias de piloto, del orden de USD 50 por nodo al mes. La auditoría de plataformas trabaja con un supuesto de USD 220 por nodo validador al mes, marcado en el modelo como estimación a cotizar, correspondiente a un validador de producción con requisitos superiores de disponibilidad y almacenamiento. Es la primera cotización que debe cerrarse.
Sin tarifa de red. El piloto corre en red de pruebas, donde el costo de operar un nodo se cubre con el faucet del propio entorno y los tokens carecen de valor.
Viaje. Referencia: pasaje Santiago–Lima ida y vuelta ~450, siete noches ~550, viáticos ~400, traslados ~200.
| Concepto | Personas-mes |
|---|---|
| Esfuerzo comprometido (2 personas × 3 meses al 80 %) | 4,8 |
| Esfuerzo cubierto por el grant | ~3,0 |
| Coinversión de TechGob | ~1,8 |
La diferencia la aporta TechGob, junto con los activos ya producidos y no imputados a este presupuesto: el prototipo navegable publicado, la auditoría comparativa de plataformas con sus modelos de costo, la arquitectura técnica y la hoja de ruta normativa. Se declaran como inversión previa que acredita capacidad de ejecución, no como partidas a financiar. Ambos integrantes reciben la misma asignación: el proyecto no es un desarrollo con acompañamiento institucional accesorio, sino dos frentes de igual peso.
| Mes | Trabajo técnico | Trabajo institucional | Entregable |
|---|---|---|---|
| 1 | Capa uno con Subnet-EVM y gestión de validadores con propietario multifirma. Inicio de los cinco contratos | Investigación de usuario con las áreas usuarias. Preparación del expediente ante la SSPRD | Red soberana operativa |
| 2 | Cierre de los cinco contratos con pruebas y eventos. Frontend e integración sobre el prototipo existente. Capa de identidad | Presentación del expediente. Viaje a Lima. Interlocución técnica con RENIEC | Los cinco contratos de extremo a extremo |
| 3 | Recompilación a fork Berlin/London, adaptación al patrón de metatransacciones, despliegue en red alternativa. Releases y documentación | Seguimiento del trámite y respuesta a observaciones | Reversibilidad demostrada y expediente presentado |
Rango de las tareas técnicas: de 8 a 12 semanas de una persona a tiempo completo —capa uno y validadores, 1 a 2 semanas; cinco contratos, 3 a 4; frontend e integración, 2 a 3; reversibilidad, 1 a 2; releases, 1—. El cronograma toma el extremo superior.
Sobre el hito institucional. Su cumplimiento comprende la presentación formal del expediente y el seguimiento del trámite, que están bajo control del equipo. El plazo de respuesta de la administración no lo está, y por eso el compromiso se define por la gestión acreditada y no por la fecha de emisión del pronunciamiento.
El 1 de agosto de 2026 el Estado peruano aprobó los lineamientos del DNI digital mediante Resolución Jefatural N° D000012-2026-RENIEC/JNAC, con arquitectura de emisor, titular y verificador, credenciales verificables y divulgación selectiva. Esto ubica al piloto sobre el marco de identidad vigente en lugar de sobre una propuesta de diseño propia.
La distinción importa: el piloto entrega la especificación de integración con la identidad oficial y la relación institucional que la habilita, que es precisamente lo que convierte a la fase siguiente en ejecutable.
Este Mini Grant financia la prueba, no el despliegue. El paso siguiente está definido desde ahora.
Destinatario. El programa infraBUIDL de la Avalanche Foundation, que combina financiamiento directo por adelantado con financiamiento por hitos, sin tramos fijos y con montos determinados caso por caso según complejidad, importancia estratégica e innovación. Es el programa dimensionado para lo que viene, y este piloto produce exactamente los tres insumos que su comité evalúa: una implementación funcionando, demanda institucional acreditada y un equipo con entregas verificables.
Contenido. Integración productiva con Firma Perú y con el DNI digital; despliegue en red principal, condicionado al pronunciamiento sobre admisibilidad del gasto que este piloto gestiona; incorporación de las primeras entidades como nodos escritores; y el paquete reutilizable —contratos, modelo de gobernanza y ruta normativa— publicado para que otro gobierno de la región lo reutilice.
El orden propuesto se justifica en que postular hoy a un programa de escala mayor sin implementación ni pronunciamiento sería pedir financiamiento para una promesa. Postular después, con ambos en la mano, es pedir financiamiento para una expansión.
Project CEPLAN V.01-Blockchain. A registry that makes it possible to prove which version of a plan exists, who approved it, when, and that the evidence was not altered — without storing the document on the chain.
A State plans before it spends. In Peru, the National Strategic Planning System requires every entity to produce an institutional plan aligned to its sector plan, and an operational plan aligned to the institutional one. Whether the budget is executed against objectives that are actually in force depends on that chain.
The chain rests on records that today cannot prove their own integrity. A technical audit of the ecosystem found three specific gaps. Records are editable and their internal logs lack sealing that is enforceable against third parties. The qualified digital signature exists and is deployed, but it is not coupled to the application's transactions: legal approval of the plan happens outside it, by official letter and published resolution. And validations do not follow version-control rules, so overlapping versions of the same instrument can coexist.
The effect is not documentary but budgetary. When an operational plan is approved with no institutional plan in force above it, the results chain breaks and spending stays tied to an objective that no longer applies. When overlapping versions coexist, the budget is executed against repealed plans. And the harder problem is not proving that a document was altered — the timestamp already solves that — but proving that no document was removed from the series.
Until December 2024, running a sovereign network in the ecosystem required locking up 2,000 AVAX per validator — a figure with no possible acquisition route for a public entity subject to procurement law. The Etna upgrade, through ACP-77, removed that requirement and replaced it with a continuous fee of operational magnitude. With that change, a government entity can budget the cost.
The personal data protection regulation, fully in force since March 2025, made privacy by design an obligation. The digital trust framework regulation, approved in November 2025, settled the institutional ground. The separation between off-chain data and on-chain cryptographic proof stopped being a design option and became the only admissible way to build this.
The usual barrier for any digital trust system is identity. CEPLAN already has a qualified digital signature deployed. The pilot does not start from zero: it starts from a consolidated identity layer that is currently underused.
Peru's IDB-financed digital transformation programme keeps open the digital innovation line under which this pilot is eligible, so scaling does not compete for scarce ordinary budget.
On 1 August 2026, through Resolución Jefatural No. D000012-2026-RENIEC/JNAC, Peru approved the guidelines for the digital National Identity Document, granting it the same legal value, legal effect and evidentiary force as the physical ID, in compliance with the deadline set by Supreme Decree No. 098-2025-PCM, which created the Digital Identity Framework of the Peruvian State. The guidelines describe a decentralised architecture of issuer, holder and verifier, define the verifiable credential as a digital document cryptographically signed by a trusted issuer, and enable selective disclosure: the citizen reveals only the data strictly necessary for each procedure, authorising with biometrics or a PIN.
Those are, in other words, the same components this prototype had been proposing: verifiable credential, decentralised identifier and selective presentation. Five weeks ago they were a design decision that had to be defended before the entity; today they are the digital identity policy of the Peruvian State. Issuance was due to begin within thirty working days of 1 August, so the pilot would arrive exactly as the identity ecosystem comes online and before it has institutional use cases exercising it.
The design principle is that the chain does not store plans, but proofs about them. The document, its annexes and the signer's personal data remain in the entity's repository. Only the document's cryptographic fingerprint, the event, the actor identified by a decentralised identifier and the timestamp travel to the network. If anyone alters a comma of the plan stored off-chain, its fingerprint stops matching the recorded one and the discrepancy is demonstrable by anyone.
On that basis, five smart contracts turn into technical conditions the rules that are checked by hand today: version registration, mandatory alignment between instruments, approval cycle, uniqueness of the version in force per period, and network governance. The alignment contract is the core: it encodes that an operational plan cannot be approved if its parent institutional plan is not in force. Strategic inconsistency stops being possible by design, not by the reviewer's diligence.
What becomes immutable is not the plans but the alignment rule between them. That is what distinguishes this proposal from a generic notarisation registry.
The observer node of the oversight body is permanent by legal mandate and not revocable, yet each of its queries is written to the same immutable record. Oversight keeps its power and loses its opacity.
Choosing Avalanche was not arbitrary but the result of a comparative audit across seven networks, and the method matters as much as the result.
The question evaluated was not which technology is best in the abstract, but which is admissible for a Peruvian public entity. That forced us to rank the criteria instead of averaging them. Two are eliminatory and binary: sovereign governance over the validator set, because the law creating the planning system grants exclusive authority to a single entity and that authority cannot be delegated to an external committee; and the admissibility of the expenditure under procurement law. The rest — cost, portability, standards, ecosystem maturity — are gradual: they weigh, they do not disqualify.
Under that order, four of the seven platforms evaluated were ruled out on governance before reaching the economic assessment. Hence a result that without the method would look contradictory: the cheapest configuration in the whole table is discarded, because on that network the validators are governed by a permissioning committee external to the governing entity.
With cost ruled out as the deciding criterion, what decides is governance. Avalanche natively and programmatically solves what Peruvian law requires: a validator management contract whose sole owner can be a multisig of the governing entity, controlling the addition, removal and weight of every validator. The sovereign alternative in the other ecosystem requires the entity to stand up and orchestrate a dedicated national network, taking on permissioning and support functions currently performed by a regional association. It is feasible — there is a precedent in Brazil — but it is an institutional project in itself, not a platform to pilot on. Add to that a mature tooling ecosystem and a cross-chain messaging capability with no native equivalent in the alternative, relevant if the registry must talk to other State domains tomorrow.
The conclusion is that Avalanche is the best option available today for the Peruvian State in this class of registry, with one explicit condition — that the admissibility of the network fee expenditure be resolved — and that condition is precisely the fourth milestone of this application.
In Peru, the planning system spans 2,058 budget units that produce and maintain on the order of 6,200 instruments active at the same time. Those 2,058 entities are the ones that must join the network to register and validate their instruments, and that is the natural ceiling of a national rollout.
It is worth being precise about the capacity in which they join, because the cost of scaling depends on it. Entities join as writer nodes and clients of the registry — they issue, query and evidence — not as consensus validators, which remain a small set under the control of the governing entity. That is why growth happens by accession and not by re-engineering: onboarding the thousandth entity does not change the architecture or multiply the network's cost, because infrastructure cost depends on the number of validators, not on the number of participants.
The pattern repeats beyond planning. The same diagnosis — traceability, immutability and interoperability between entities that validate one another — appeared in other challenges surfaced by TechGob and the SGTD at the March workshop, which form part of our project portfolio: four distinct public registries with the same structural gap, which moreover repeats outside Peru, as our field work with Chile's Laboratorio de Gobierno indicates. What is built here is not a system for one entity: it is a reference implementation for a category of public registry that today has no standard solution in the ecosystem.
Budget units that must join the network as writer nodes.
Institutional and operational plans active simultaneously across the State.
Other challenges with the same structural gap, surfaced at the March workshop.
The grant funds the reference implementation: the five contracts, integration with the State digital signature and the public verification portal. The contracts are published under an open licence, because their value to the ecosystem lies in another entity reusing them, not in their being proprietary.
What TechGob monetises is not the code but the onboarding: network governance design, integration with each entity's legacy systems, regulatory adaptation and supported operation. The firm's asset is its methodology, and that methodology is not transferred: it is applied. Every entity that joins is a deployment, and every country with a planning system is a replication.
The discipline that makes that second stage possible is a self-imposed design constraint: the domain logic is not coupled to proprietary components of any platform. Validator management, gas payment and cross-chain messaging live in an infrastructure layer separate from the five contracts.
It is worth spelling out why that also suits whoever funds it. A public integrity registry is not adopted out of technological enthusiasm but by administrative decision, and no governing entity signs up to a platform dependency it cannot reverse: reversibility is not a concession to scepticism nor the announcement of an exit, it is the condition that makes the signature possible and the one that lets the deployment stay. A demonstrably portable reference implementation gets adopted more often than a captive one, and each adoption happens on the platform that arrived first, that solved the institutional path, and that did not force anyone to bet without a way out.
On 31 March 2026 the international workshop «Blockchain to solve public sector challenges» took place in Lima, organised by the Presidency of the Council of Ministers through the Secretariat of Digital Government and Transformation, designed by TechGob and funded by Clarity DAO Protocol. The call required each entity to apply with a two-person team at management level — one from the technology area and one from the area that owns the problem — and to work on a real challenge of its own institution.
CEPLAN applied with its digital transformation specialist and its coordinator of cross-cutting administrative systems. The challenge it brought to the workshop is the one this project solves, and in the application itself it stated its interest in developing it together with TechGob. The session also produced a working agreement with the Secretariat of Digital Government and Transformation to seek funding to build the prototype.
This matters for a precise reason: the problem was not framed by the vendor, it was framed by the entity, and it did so in writing before its own digital government authority. The counterpart is not a general contact but the two roles that must come together for a deployment of this kind to prosper: the one who controls the platform and the one who owns the process.
Evidence: the workshop, its organisation and TechGob's participation are verifiable on the official portal of the Peruvian State. CEPLAN's interest is on record in its application form and in the working agreement with the Secretariat. Our work can be reviewed at techgob.cl.
Available at blockchain.govtechpe.work. It walks through the full life cycle of the instrument, the traceability history and access control, with the explicit disclaimer that no network is deployed.
Eliminatory and gradual criteria, fully formula-driven and traceable cost models, and a methodological note documenting the errors corrected during the analysis itself, including the rectification of the stake requirement after Etna.
On-chain and off-chain data model, five contracts with their rules, a seven-stage flow and a recommended stack.
Article-by-article mapping of data protection obligations to architecture decisions, and an inventory of what is portable, what needs readaptation and what must be replaced.
The project demands three capabilities that rarely coincide in one team: technical capacity in smart contracts and decentralised identity, command of the applicable regulatory framework, and public management experience able to drive institutional adoption — the area where most GovTech pilots fail.
Project direction, regulatory enablement and institutional management. PhD candidate in Philosophy. Specialist in user research applied to public innovation challenges, focused on regulatory enablement and project development, and strategic consultant in blockchain, data visualisation and open government. She has led research on blockchain adoption in public entities, working with the Laboratorio de Gobierno of Chile's Ministry of Finance and with Peru's Secretariat of Digital Government and Transformation, with which TechGob co-organised the workshop this project came from. She leads the institutional pronouncement on the admissibility of the expenditure and the relationship with the entity — the part of the project no technical capability can substitute.
Architecture, smart contracts and network infrastructure. Technology executive with 29 years of experience, with a track record at Santander and Banmédica leading DevOps, automation and platform modernisation strategies. He is currently CTO of HealthProof — medical identity, clinical interoperability and traceability — and of CertiLink — digital certification and validation: two domains technically analogous to this registry, where the problem is the same, proving the integrity and origin of a document without exposing its content. He is also CTO of NodoZero, an initiative dedicated to accelerating blockchain and Web3 adoption through communities and events, which brings ecosystem outreach capacity to the project.
His training on the proposed platform is direct: Avalanche smart contracts bootcamp (2024) and layer-one bootcamp on the P-Chain (2025), which is exactly the architecture this pilot deploys, along with training in Chainlink, Arbitrum, Stacks and SUI. He placed fourth in the 2024 Avalanche Private Edition Hackathon with an identity and traceability solution in healthcare.
Both members commit 80 % of their working time to this project over the three months of execution, with the grant covering part of that cost and TechGob contributing the difference as co-investment. That is not a minor detail in a small team: the most frequent cause of failure in pilots of this scale is not technical difficulty but the team's dispersion across parallel initiatives.
Deployment of the layer one with validator management under the exclusive control of the governing entity, a condition derived from its legal mandate of exclusive authority over the planning system.
With automatic validation of alignment between instruments and uniqueness control of the version in force, over instruments from three to five pilot sectors.
The same contracts recompiled and deployed on an alternative network with a bounded source-code change. It is not a migration plan: it is proof that the entity is not captive — the guarantee without which a public authority does not sign — and evidence that the reference implementation is reusable by other governments in the ecosystem.
Securing a formal statement from the State on how a public entity may sustain a network fee denominated in a digital asset. The route is the Sub-secretariat of Digital Policy and Regulation of the SGTD, the unit that produces the technical reports underpinning the directives of the governing authority on digital government and digital trust. It is institutional management work with a real cost — case file, technical justification, follow-up of the procedure — and that is why it appears as a budgeted milestone and not as an assumption.
Peruvian procurement law — since April 2025, Law No. 32069 and its regulation, which replaced Law No. 30225 — provides no express mechanism for an entity to acquire digital assets, and the continuous validation fee is paid in the network's native asset. The intended route is for the infrastructure to be provided as a service by the implementer, so the entity contracts an ordinary technology service and does not acquire the asset.
That route is reasonable but unconfirmed, and it involves two dimensions worth not conflating. The first is policy: whether sustaining a digital trust infrastructure whose fee is denominated in a digital asset is admissible within the digital government and digital trust framework, a matter over which the SGTD holds authority and technical-normative competence. That is where the Sub-secretariat of Digital Policy and Regulation comes in, and where the answer can be general. The second is procurement: how that service is structured and awarded in a specific case, which falls to the entity's administration office and, within its remit, to the specialised public procurement body. Milestone 4 addresses the first, which is what unblocks everyone, and leaves the second under way.
We declare this risk upfront because its resolution determines the long-term operating model, and because a pilot that hides it hands the problem to the entity at the worst possible moment: when the software is already running and no one can pay for the network that sustains it.
The pilot runs on a test network, not on mainnet. Since the goal is to demonstrate governance, identity, validation and layer-one operation, there is no need to take on irreversible mainnet costs from the outset. The pilot reproduces the architecture and the essential components envisaged for the production network using an equivalent test configuration, which allows consensus, validators, governance, contracts, interfaces, identity flows, integration, observability and node operation to be tested: the same sovereign layer-one implementation and the same governance and validation model.
The reason is not budgetary but one of consistency: while the State has not ruled on the admissibility of the network fee expenditure, committing funds to it would contradict milestone 4 itself. Demonstrate first; pay once there is an answer.
Two clarifications we prefer to declare before they are asked. Integration with the State digital signature is simulated at the application layer: the goal is to demonstrate the integration boundary, while its real implementation depends on the environment and credentials the entity provides, so committing to a deadline on a dependency we do not control would mean committing to a date we cannot hold. And the amount requested covers a fraction of the effort committed: TechGob contributes the difference as in-kind co-investment.
This is an execution budget, not a disbursement schedule: the Mini Grant is paid as a single amount, so the milestones operate as verifiable delivery commitments and not as payment conditions. Each line indicates its level of verification, so the reader can tell which figure is confirmed and which must be quoted before being used to decide.
| # | Line item | Detail | USD | Status |
|---|---|---|---|---|
| 1 | Direction, user research and institutional management | Fieldwork with CEPLAN's user areas; case file and technical justification before the SSPRD; engagement with RENIEC on the digital identity framework; project direction | 3,600 | Defined |
| 2 | Architecture, development and integration | Sovereign layer one and validator management; five Solidity contracts; frontend and integration; identity layer; reversibility test; releases and documentation | 3,600 | Defined |
| 3 | Node infrastructure | Three virtual machine instances (4 vCPU / 8 GB) for 4 months, including one month of margin after closing | 600 | TO QUOTE |
| 4 | Travel to Lima | One person, one week, scheduled against the submission of the institutional case file | 1,600 | TO QUOTE |
| 5 | Contingency | Price variation, currency risk and infrastructure margin | 600 | Defined |
| Total | 10,000 |
Three validators, not five. The pilot's validator set is reduced to three, enough to demonstrate the only thing that must be demonstrated at this stage: that adding, removing and reweighting a validator is decided by the governing entity through the management contract, and by no one else. The five-validator configuration corresponds to production sizing and is documented as such, without being operated.
Infrastructure. Pilot-grade instances are budgeted, on the order of USD 50 per node per month. The platform audit works with an assumption of USD 220 per validator node per month, flagged in the model as an estimate to be quoted, corresponding to a production validator with higher availability and storage requirements. This is the first quote that must be closed.
No network fee. The pilot runs on a test network, where the cost of operating a node is covered by the environment's own faucet and the tokens have no value.
Travel. Reference: Santiago–Lima return flight ~450, seven nights ~550, per diem ~400, local transport ~200.
| Item | Person-months |
|---|---|
| Effort committed (2 people × 3 months at 80 %) | 4.8 |
| Effort covered by the grant | ~3.0 |
| TechGob co-investment | ~1.8 |
The difference is contributed by TechGob, together with the assets already produced and not charged to this budget: the published working prototype, the comparative platform audit with its cost models, the technical architecture and the regulatory roadmap. These are declared as prior investment evidencing capacity to execute, not as line items to be funded. Both members receive the same allocation: this is not a development project with incidental institutional support, but two fronts of equal weight.
| Month | Technical work | Institutional work | Deliverable |
|---|---|---|---|
| 1 | Layer one with Subnet-EVM and validator management with multisig owner. Start of the five contracts | User research with the user areas. Preparation of the case file for the SSPRD | Sovereign network operating |
| 2 | Completion of the five contracts with tests and events. Frontend and integration over the existing prototype. Identity layer | Submission of the case file. Travel to Lima. Technical engagement with RENIEC | The five contracts end to end |
| 3 | Recompilation to the Berlin/London fork, adaptation to the meta-transaction pattern, deployment on an alternative network. Releases and documentation | Follow-up of the procedure and response to observations | Reversibility demonstrated and case file submitted |
Range of the technical tasks: 8 to 12 weeks of one person full time — layer one and validators, 1 to 2 weeks; five contracts, 3 to 4; frontend and integration, 2 to 3; reversibility, 1 to 2; releases, 1. The schedule takes the upper end of the range.
On the institutional milestone. Its fulfilment comprises the formal submission of the case file and the follow-up of the procedure, both under the team's control. The administration's response time is not, and that is why the commitment is defined by evidenced management and not by the date the pronouncement is issued.
On 1 August 2026 the Peruvian State approved the digital ID guidelines through Resolución Jefatural No. D000012-2026-RENIEC/JNAC, with an issuer–holder–verifier architecture, verifiable credentials and selective disclosure. This places the pilot on the identity framework in force rather than on a design proposal of our own.
The distinction matters: the pilot delivers the specification for integration with the official identity framework and the institutional relationship that enables it, which is precisely what makes the next phase executable.
This Mini Grant funds the proof, not the rollout. The next step is defined from now.
Target programme. The Avalanche Foundation's infraBUIDL programme, which combines direct upfront funding with milestone-based funding, without fixed tiers and with amounts determined case by case according to complexity, strategic importance and innovation. It is the programme sized for what comes next, and this pilot produces exactly the three inputs its committee evaluates: a working implementation, evidenced institutional demand, and a team with verifiable deliveries.
Content. Production integration with Firma Perú and the digital ID; mainnet deployment, conditional on the pronouncement on admissibility of the expenditure that this pilot pursues; onboarding of the first entities as writer nodes; and the reusable package — contracts, governance model and regulatory roadmap — published so another government in the region can reuse it.
The proposed order is justified because applying today to a larger programme without an implementation or a pronouncement would be asking for funding for a promise. Applying afterwards, with both in hand, is asking for funding for an expansion.