Los libros contables no deberían ser editables después del cierre.
Siigo, como casi todos los ERP modernos, es un sistema mutable por diseño. Los asientos pueden corregirse, recategorizarse, revertirse. Esta flexibilidad es útil durante el período; se vuelve un problema conceptual una vez que el período cierra. Si la verdad del pasado depende de quién tiene acceso de escritura hoy, no hay verdad verificable sobre el pasado — hay solo la versión actualmente vigente.
Esta es una propiedad estructural de los ERP, no un defecto de implementación. En la mayoría de los casos la confianza en los números proviene de auditores externos, firmas que revisan muestras, y la reputación del contador. Funciona. Pero depende de confiar en una cadena humana — y esa cadena no escala cuando los inversionistas están en otra jurisdicción.
Un ancla mensual en Base rompe esa dependencia: cualquier modificación posterior se vuelve criptográficamente detectable.
Para un fondo inmobiliario que administra capital de terceros, la diferencia entre “confíe en nosotros” y “verifíquelo usted mismo” es la diferencia entre un pitch deck y una infraestructura de transparencia.
Un hash al mes. 16+ meses anclados. Reproducible.
Cada primer día del mes, un proceso automático lee todas las filas contables del período anterior desde el ERP. Las ordena, las serializa en un formato canónico (JSON determinista, sin espacios, claves ordenadas), y calcula el hash SHA-256 de cada fila. Esos hashes se agrupan por inmueble en un árbol de Merkle —la misma estructura que usan Bitcoin y Ethereum para verificar transacciones— y se consolidan en una sola raíz. Esa raíz, un número de 64 caracteres hexadecimales, se publica en la blockchain de Base (Layer 2 de Coinbase).
El costo de anclar un mes completo en mainnet es inferior a cinco centavos de dólar. Un año entero cuesta menos que un café. La verificación es gratuita: cualquiera puede descargar el snapshot, recalcular el árbol, y comparar la raíz con lo publicado en cadena. Si coincide, los datos no han cambiado. Si no coincide, algo se alteró.
Antes de escalar: cuatro condiciones que el piloto debe satisfacer.
El ancla contable es una herramienta poderosa, pero solo si cumple cuatro condiciones antes de convertirse en un producto externo. Las llamamos compuertas:
(i) Reproducibilidad. Cualquier tercero debe poder descargar el snapshot de un período, ejecutar el mismo algoritmo de hashing, y obtener la misma raíz que está publicada en cadena. Si el proceso depende de un estado interno o de un orden no documentado, no es verificable —es solo una firma digital opaca. El piloto cumple esta condición: el snapshot JSON y el código de derivación son públicos.
(ii) Robustez. El proceso debe funcionar de forma autónoma, sin intervención manual, mes tras mes. Fallas silenciosas —un mes que no se ancla, un snapshot que no se genera— invalidan la cadena de confianza. El piloto usa APScheduler con ejecución el primer día de cada mes. Trece períodos consecutivos sin fallas.
(iii) Auditabilidad. Un auditor externo debe poder revisar el proceso completo sin asistencia del equipo técnico de Duppla. Esto incluye documentación del esquema de hashing, acceso al snapshot, y la capacidad de verificar contra la blockchain sin herramientas propietarias. La auditoría interna de seguridad pasó (abril 2026); la externa con firma especializada sigue abierta.
(iv) Viabilidad económica. El costo de operar el ancla a escala de producción —cientos de inmuebles, miles de filas— debe ser marginal comparado con el costo de una auditoría tradicional. A menos de cinco centavos por mes en mainnet, esta condición está resuelta desde el primer día.
Las cuatro están resueltas. El sistema opera en producción en Base mainnet desde abril 2026.