Protegiendo los entregables de código de agencias con prueba en blockchain

2026-10-08 timestamp git blockchain proof

Proteger los entregables de código de una agencia con prueba en blockchain

Elena dirige un taller de desarrollo de cinco personas. Hace once meses firmó con un cliente un portal de cliente: tres hitos, precio fijo, facturación contra entrega. Los hitos uno y dos salieron bien. El hito tres se entregó un viernes de septiembre: funcionalidad completa, probado, desplegado en el entorno de staging del cliente. Luego llegó la factura, y el cliente se quedó en silencio.

Dos semanas después, la respuesta: “El módulo de informes nunca se entregó realmente. No vamos a pagar la factura final, y queremos un crédito por el retraso.”

Elena tiene pruebas. Más o menos. Hay un hilo de correo donde el propio product manager del cliente escribió “se ve bien, lo probaremos la semana que viene”. Hay una carpeta compartida de Google Drive con especificaciones exportadas. Y está el repositorio de GitHub: más de 400 commits que terminan exactamente cuando ella dice que terminaron, con el módulo de informes entregado seis semanas antes de la factura.

Nada de eso es neutral. El hilo de correo es una guerra de capturas de pantalla. La carpeta de Drive tiene archivos cuyas fechas de modificación el cliente puede (y cuestionó). El historial de Git vive en una organización que el cliente coposee, y las fechas de commit se pueden reescribir con un solo git rebase y un force push. En una disputa de pago, “tenemos logs internos” vale más o menos nada: son pruebas que tú produjiste sobre ti mismo, en sistemas que tú controlas.

Este artículo es un manual práctico para agencias que quieren lo contrario: un registro que ninguna de las partes controla, que no requiere la buena voluntad del cliente para verificarse, y que sobrevive a que el cliente cambie el repositorio, el proveedor de hosting o la versión de los hechos.

La prueba criptográfica de existencia resuelve exactamente este problema. Y desde 2026 no necesitas entender la criptografía para usarla: la capa gestionada hace el trabajo.

Por qué la prueba en blockchain importa a las agencias (no solo a los trolls de patentes)

El sellado de tiempo en blockchain se archiva bajo “defensa de patentes”, y por eso la mayoría de las agencias lo ignoran hasta que lo necesitan. Pero los trolls de patentes no son el riesgo diario de un taller de desarrollo. Los clientes con un problema de flujo de caja sí lo son.

Cuatro situaciones concretas en las que un registro de commits anclado en Bitcoin se paga solo:

Disputas de pago. Puedes demostrar la fecha exacta en que se hizo commit de un hito, no cuándo se envió una factura, no cuándo alguien dijo “hecho” en Slack. La fecha se deriva de un bloque de Bitcoin, no del reloj de tu servidor ni del del cliente.
Blindaje de responsabilidad. Las discusiones por scope creep suelen girar en torno a cuándo se acordó algo frente a cuándo se construyó. Un registro inmutable, por día, de lo que existía en cada punto del proyecto te permite mostrar que una solicitud de cambio llegó después de la entrega, sin discutir sobre el calendario de nadie.
Protección de portafolio y reutilización. La mayoría de las agencias tienen una librería de componentes —un módulo de auth, un adaptador de facturación, una integración de CMS— que aparece en una docena de proyectos de clientes. Demostrar que lo creaste tú, y cuándo, te protege si un ex cliente afirma que le levantaste su código.
La confianza del cliente como característica. Un paquete de entrega que incluye un certificado verificable de autoría se lee distinto en una negociación de compras que uno que incluye un PDF que generaste tú mismo.

Esto no es principalmente una historia de patentes. Si quieres el ángulo de prior art —invalidar patentes amplias, proteger secretos comerciales antes de presentar—, está cubierto en el artículo hermano sobre protección de prior art para startups de software. Aquí nos quedamos en la relación comercial.

Un manual práctico: configurar la prueba en blockchain para repositorios de agencia

Toda la configuración son cinco pasos, y cuatro de ellos son únicos. Nada de esto requiere que tus desarrolladores aprendan una herramienta nueva ni que cambien un solo comando.

Paso 1 — Instalar la GitHub App de Timestamp GIT

Instala la app en los repositorios que usas para trabajo de clientes. En modo Standard, la GitHub App lee el hash del commit HEAD de cada repositorio monitorizado automáticamente y escribe las pruebas en una rama dedicada (en el mismo repo o en un repo sombra separado, tú eliges). Requiere acceso de solo lectura al repo de origen y acceso de lectura-escritura al repo de destino donde aterrizan las pruebas.

Hazlo una vez, al inicio del proyecto, no después de que empiece la disputa. Un sello de tiempo creado durante un desacuerdo vale una fracción de uno creado durante la entrega normal.

Paso 2 — Deja que el anclaje nocturno ocurra

No hay un paso por commit. Los hashes de commit se detectan vía webhooks y se encolan en memoria. Cada noche, un worker agrupa todo lo pendiente, construye archivos manifest por repositorio, construye un árbol de Merkle y ancla la raíz de Merkle en la blockchain de Bitcoin a través del protocolo OpenTimestamps usando calendarios públicos.

La confirmación de Bitcoin normalmente tarda unas tres horas, así que las pruebas se escriben de vuelta unas horas después de que se ejecuta el lote. Desde tu lado: haces push del código, y a la mañana siguiente el trabajo del día anterior está anclado.

Paso 3 — Pon la insignia de verificación en la cara del cliente (con educación)

Hay insignias embebibles disponibles para tu README y para los informes de entrega. Cualquiera con el enlace puede verificar el sello de tiempo a través de la página de estado pública: sin cuenta, sin login.

# Get ready-made badge markdown for your delivery report or README
curl -s https://timestampgit.dev/api/badgeLink/your-agency/client-portal

La insignia es un fragmento compatible con Shields.io, así que se inserta en un README, una página de Notion o el PDF que envías con una factura. En repositorios privados, la URL de estado lleva un HMAC cifrado para que solo las personas autorizadas puedan leer el estado: la prueba en sí sigue siendo pública y verificable, los metadatos no se filtran.

Paso 4 — Exporta certificados y libros de auditoría en los hitos

En cada hito, saca la documentación y adjúntala a la factura.

# Full audit ledger as CSV — every anchored commit, every date
curl -s -o audit-client-portal.csv \
  "https://timestampgit.dev/api/audit/your-agency/client-portal"

# Per-day PDF certificate — include with the handover pack
curl -s -o certificate-2026-09-30.pdf \
  "https://timestampgit.dev/api/report/your-agency/client-portal/2026-09-30"

La página de estado del repositorio te da los mismos datos visualmente: longevidad de la prueba, fecha de anclaje más temprana, regularidad diaria, el bloque de Bitcoin y la transacción detrás de cada anclaje, un mapa de calor de calendario, y el CSV y PDF descargables. El endpoint /api/statusSummary/{user}/{repo} devuelve un resumen combinado si quieres canalizarlo a un dashboard interno.

Paso 5 — (Opcional) Modo Enterprise ZK para clientes sensibles

Algunos contratos de clientes —defensa, fintech, cualquier cosa con una cláusula estricta de PI— prohíben el acceso de terceros al código fuente. El modo Enterprise ZK aborda eso: una GitHub Action de 12 líneas se ejecuta dentro de tu infraestructura y solo envía hashes de commit a la API de Timestamp GIT. Tu código fuente nunca sale de tu entorno, y solo el repositorio de destino necesita acceso de escritura.

Opcional: Docker autoalojado

Si un cliente requiere operación air-gapped o residencia de datos en tu propio hardware, Timestamp GIT se distribuye como imagen Docker. El archivo Compose de inicio rápido:

services:
  timestampgit:
    image: rue1401/timestampgit:prod
    ports:
      - "8080:8080"
    volumes:
      - ./data:/app/data
    restart: unless-stopped
  valkey:
    image: valkey/valkey:8
    restart: unless-stopped

docker compose pull
docker compose up -d
docker compose logs -f timestampgit

La app está en http://localhost:8080. Un asistente de configuración en el primer arranque te guía por la conexión de la GitHub App y la configuración de la instancia. Se puede solicitar una licencia de demo por tiempo limitado para evaluación desde la página de licencia de Docker.

Qué evitar al usar prueba en blockchain para trabajo de clientes

Cinco errores que cometen las agencias aquí, en orden aproximadamente descendente de frecuencia:

Confiar solo en los logs internos de Git. Son editables, están almacenados en infraestructura que tú o el cliente controláis, y en una auditoría se descartan por interesados. Una fecha de commit de GitHub es una afirmación; un hash de commit dentro de un bloque de Bitcoin es una prueba.
Intentar hacer el protocolo a mano. Puedes manejar tú mismo la maquinaria subyacente de OpenTimestamps con herramientas CLI y tus propios envíos a calendarios: es la forma difícil, necesita un flujo de trabajo por commit que tus desarrolladores olvidarán, y produce exactamente el resultado que quieres con unas cien veces más mantenimiento. La capa gestionada existe para que nadie de tu equipo tenga que pensar nunca en ello.
Sellar el tiempo solo al final del proyecto. Una única prueba al final del proyecto dice “esto existía en la fecha X”. Una cadena nocturna dice “este commit existía en esta fecha, y aquel commit en aquella fecha, de principio a fin”. Cuando un cliente disputa una cronología en lugar de un entregable, la granularidad es todo el caso.
Quedarte la prueba para ti. Una prueba que la otra parte no puede comprobar es una prueba que disputará. Pon la insignia en el README, envía el enlace de estado, adjunta el certificado PDF.
Ignorar los requisitos de privacidad del cliente. Si el contrato prohíbe el acceso de terceros al código, usa el modo Enterprise ZK o autoaloja. No asumas en silencio que “solo hashes” satisface una cláusula que dice “ningún tercero”.

Cómo encaja Timestamp GIT en el flujo de trabajo de tu agencia

El objetivo de diseño es que el sellado de tiempo sea invisible hasta que lo necesites:

Cero configuración para los desarrolladores. Instala la GitHub App una vez. Cada commit a un repositorio monitorizado se encola automáticamente; el lote se ejecuta cada noche. Sin comandos nuevos, nada que instalar en las máquinas de los desarrolladores.
Arquitectura de conocimiento cero. Timestamp GIT nunca ve, copia ni almacena tu código fuente. Sella hashes de commit. La huella del primer paso es un hash unidireccional del estado del repositorio: nada de tu implementación es recuperable a partir de ella.
Verificación independiente del proveedor. La prueba es un recibo .ots anclado en Bitcoin. La verificación depende de SHA-256 y de los datos de bloques de Bitcoin, sin formato propietario. Cualquiera puede descargar el recibo y comprobarlo con herramientas estándar de OpenTimestamps contra la blockchain, incluso si Timestamp GIT desapareciera mañana. Hay un recorrido paso a paso en cómo verificar el sello de tiempo en Bitcoin de un repositorio de Git.
Puntos de integración que encajan con el papeleo de una agencia. Una API REST para estado, CSV de auditoría y certificados PDF; insignias embebibles para READMEs y documentos de entrega; una página de estado pública que los clientes pueden guardar en favoritos.
Precios que encajan con la escala de una agencia. Open Source (gratis) para repositorios públicos, Pro Agency a 49 $/mes para repos privados, Enterprise ZK a 199 $/mes cuando un contrato exige aislamiento. Detalles en la página de precios.

Para equipos que quieren la mecánica en lugar del manual, la pieza técnica complementaria es sellado de tiempo automatizado de Git: cómo una GitHub App ancla cada commit.

FAQ

¿Necesito cambiar cómo mis desarrolladores hacen commit del código?

No. Una vez que la GitHub App de Timestamp GIT está instalada en un repositorio, cada commit se detecta automáticamente y su hash se encola para el anclaje nocturno en Bitcoin. Los desarrolladores siguen usando su flujo de trabajo normal de Git sin comandos ni herramientas extra.

¿Pueden los clientes verificar la prueba ellos mismos?

Sí. Puedes embeber una insignia de verificación en tu README o informe de entrega que enlaza a una página de estado pública. Los clientes también pueden descargar el archivo de recibo .ots y verificarlo de forma independiente contra la blockchain de Bitcoin usando herramientas estándar de OpenTimestamps.

¿Y si un cliente exige que ningún tercero vea nunca el código?

Usa el modo Enterprise ZK, donde una GitHub Action de 12 líneas se ejecuta en tu infraestructura y solo envía hashes de commit a la API de Timestamp GIT. Tu código fuente nunca sale de tu entorno. Alternativamente, puedes autoalojar Timestamp GIT usando la imagen Docker proporcionada para tener control total.

¿Cuánto tarda un commit en anclarse en Bitcoin?

Los hashes de commit se agrupan a diario y se anclan en un bloque de Bitcoin mediante el protocolo OpenTimestamps. La confirmación de Bitcoin normalmente tarda unas tres horas, tras lo cual la prueba es inmutable y verificable.

¿Esto reemplaza a un contrato?

No. Reemplaza la parte más débil de una disputa contractual: el registro fáctico de qué existía y cuándo. Tu contrato determina quién debe qué; el sello de tiempo determina qué era verdad en una fecha dada.

Conclusión

La disputa de Elena se resolvió como suelen resolverse estas cosas: un pago parcial y un cliente perdido. La parte frustrante no fue el dinero. Fue que ella tenía razón y no tenía forma de demostrarlo que un tercero aceptara.

Esa es la brecha que la prueba en blockchain cierra para las agencias. No la guerra de patentes, no el futuro abstracto: el martes corriente en que un cliente decide que la factura es opcional, y tu única defensa es un registro que ninguno de los dos puede editar.

Instala la GitHub App de Timestamp GIT en tus repositorios de clientes, deja que el anclaje nocturno se ejecute, y adjunta el certificado a tu próxima factura. Tarda unos diez minutos una vez, y cambia el tono de cada conversación de entrega a partir de entonces.

Protegiendo los entregables de código de agencias con prueba en blockchain