Protegendo Entregáveis de Código de Agências com Prova em Blockchain

2026-10-08 timestamp git blockchain proof

Protegendo Entregas de Código de Agências com Prova em Blockchain

Elena administra uma pequena empresa de desenvolvimento com cinco pessoas. Onze meses atrás, ela fechou contrato com um cliente para um portal de atendimento: três marcos, preço fixo, faturamento na entrega. Os marcos um e dois correram bem. O marco três foi entregue numa sexta-feira de setembro — funcionalidades completas, testado, implantado no ambiente de staging do cliente. Então a fatura chegou, e o cliente sumiu.

Duas semanas depois, a resposta: “O módulo de relatórios nunca foi realmente entregue. Não vamos pagar a fatura final, e queremos um crédito pelo atraso.”

Elena tem evidências. Mais ou menos. Há uma thread de e-mails em que o próprio gerente de produto do cliente escreveu “parece bom, vamos testar na semana que vem”. Há uma pasta compartilhada no Google Drive com especificações exportadas. E há o repositório no GitHub — mais de 400 commits terminando exatamente quando ela diz que terminaram, com o módulo de relatórios sendo entregue seis semanas antes da fatura.

Nada disso é neutro. A thread de e-mails é uma guerra de capturas de tela. A pasta do Drive tem arquivos cujas datas de modificação o cliente pode (e questionou) contestar. O histórico do Git fica numa organização da qual o cliente é coproprietário, e datas de commit podem ser reescritas com um único git rebase e um force push. Numa disputa de pagamento, “temos logs internos” vale praticamente nada — é evidência que você produziu sobre si mesma, em sistemas que você controla.

Este artigo é um guia prático para agências que querem o oposto: um registro que nenhuma das partes controla, que não exige a boa vontade do cliente para ser verificado, e que sobrevive ao cliente mudar o repositório, o provedor de hospedagem ou a história.

A prova criptográfica de existência resolve exatamente esse problema. E desde 2026 você não precisa entender a criptografia para usá-la — a camada gerenciada faz o trabalho.

Por Que a Prova em Blockchain Importa para Agências (Não Só para Trolls de Patentes)

O timestamping em blockchain é arquivado na categoria “defesa contra patentes”, e é por isso que a maioria das agências o ignora até precisar dele. Mas trolls de patentes não são o risco diário de uma empresa de desenvolvimento. Clientes com problema de fluxo de caixa são.

Quatro situações concretas em que um registro de commits ancorado em Bitcoin se paga sozinho:

Disputas de pagamento. Você pode provar a data exata em que um marco foi commitado — não quando uma fatura foi enviada, não quando alguém disse “pronto” no Slack. A data é derivada de um bloco do Bitcoin, não do relógio do seu servidor nem do cliente.
Blindagem de responsabilidade. Discussões sobre scope creep geralmente giram em torno de quando algo foi acordado versus quando foi construído. Um registro imutável, por dia, do que existia em cada ponto do projeto permite mostrar que uma solicitação de mudança chegou depois da entrega, sem discutir o calendário de ninguém.
Proteção de portfólio e reuso. A maioria das agências mantém uma biblioteca de componentes — um módulo de autenticação, um adaptador de cobrança, uma integração de CMS — que aparece em uma dúzia de projetos de clientes. Provar que você o criou, e quando, protege você se um ex-cliente alegar que você copiou o código dele.
Confiança do cliente como diferencial. Um pacote de entrega que inclui um certificado verificável de autoria soa diferente numa negociação de procurement do que um que inclui um PDF que você mesmo gerou.

Isto não é primordialmente uma questão de patentes. Se você quer o ângulo de prior art — invalidar patentes amplas, proteger segredos comerciais antes do depósito — isso está coberto no post irmão sobre proteção de prior art para startups de software. Aqui vamos ficar na relação comercial.

Um Guia Prático: Configurando a Prova em Blockchain para Repositórios de Agências

A configuração inteira são cinco passos, e quatro deles são únicos. Nada aqui exige que seus desenvolvedores aprendam uma ferramenta nova ou mudem um único comando.

Passo 1 — Instale o GitHub App do Timestamp GIT

Instale o app nos repositórios que você usa para trabalho de clientes. No Modo Padrão, o GitHub App lê automaticamente o hash do commit HEAD de cada repositório monitorado e grava as provas num branch dedicado (no mesmo repositório ou num repositório sombra separado, você escolhe). Ele exige acesso somente leitura ao repositório de origem e acesso leitura-escrita ao repositório de destino onde as provas são gravadas.

Faça isso uma vez, no início do contrato, não depois que a disputa começar. Um timestamp criado durante uma discordância vale uma fração de um criado durante a entrega normal.

Passo 2 — Deixe a ancoragem noturna acontecer

Não há passo por commit. Os hashes de commit são detectados via webhooks e enfileirados em memória. A cada noite, um worker agrupa tudo o que está pendente, monta arquivos de manifesto por repositório, constrói uma árvore de Merkle e ancora a raiz de Merkle na blockchain do Bitcoin através do protocolo OpenTimestamps usando calendários públicos.

A confirmação do Bitcoin normalmente leva cerca de três horas, então as provas são gravadas algumas horas depois da execução do lote. Do seu lado: você faz push do código, e na manhã seguinte o trabalho do dia anterior está ancorado.

Passo 3 — Coloque o selo de verificação na cara do cliente (educadamente)

Selos incorporáveis estão disponíveis para o seu README e para relatórios de entrega. Qualquer pessoa com o link pode verificar o timestamp pela página pública de status — sem conta, sem login.

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

O selo é um snippet compatível com Shields.io, então ele entra num README, numa página do Notion ou no PDF que você envia com uma fatura. Em repositórios privados, a URL de status carrega um HMAC criptografado para que só pessoas autorizadas possam ler o status — a prova em si permanece pública e verificável, os metadados não vazam.

Passo 4 — Exporte certificados e livros de auditoria nos marcos

Em cada marco, puxe a papelada e anexe à fatura.

# 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"

A página de status do repositório dá os mesmos dados visualmente: longevidade da prova, data da ancoragem mais antiga, regularidade diária, o bloco e a transação do Bitcoin por trás de cada ancoragem, um mapa de calor de calendário, e o CSV e o PDF para download. O endpoint /api/statusSummary/{user}/{repo} retorna um resumo combinado se você quiser canalizá-lo para um dashboard interno.

Passo 5 — (Opcional) Modo Enterprise ZK para clientes sensíveis

Alguns contratos de clientes — defesa, fintech, qualquer coisa com cláusula rígida de PI — proíbem acesso de terceiros ao código-fonte. O modo Enterprise ZK resolve isso: uma GitHub Action de 12 linhas roda dentro da sua infraestrutura e envia apenas hashes de commit para a API do Timestamp GIT. Seu código-fonte nunca sai do seu ambiente, e só o repositório de destino precisa de acesso de escrita.

Opcional: Docker auto-hospedado

Se um cliente exige operação air-gapped ou residência de dados no seu próprio hardware, o Timestamp GIT é distribuído como imagem Docker. O arquivo Compose de início 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

O app fica em http://localhost:8080. Um assistente de configuração na primeira inicialização guia você pela conexão do GitHub App e pela configuração da instância. Uma licença de demonstração por tempo limitado para avaliação pode ser solicitada na página de licença Docker.

O Que Evitar ao Usar Prova em Blockchain para Trabalho de Clientes

Cinco erros que as agências cometem aqui, em ordem aproximadamente decrescente de frequência:

Confiar apenas nos logs internos do Git. Eles são editáveis, ficam armazenados em infraestrutura que você ou o cliente controla, e numa auditoria são descartados como autointeressados. Uma data de commit do GitHub é uma alegação; um hash de commit dentro de um bloco do Bitcoin é evidência.
Tentar fazer o protocolo na mão. Você pode operar a maquinaria subjacente do OpenTimestamps por conta própria com ferramentas de CLI e suas próprias submissões a calendários — é o caminho difícil, exige um fluxo de trabalho por commit que seus desenvolvedores vão esquecer, e produz exatamente o resultado que você quer com cerca de cem vezes mais manutenção. A camada gerenciada existe para que ninguém na sua equipe precise pensar nisso.
Fazer timestamping só no fim do projeto. Uma única prova de fim de projeto diz “isto existia na data X”. Uma cadeia noturna diz “este commit existia nesta data, e aquele commit naquela data, do início ao fim”. Quando um cliente contesta uma linha do tempo em vez de uma entrega, a granularidade é o caso inteiro.
Guardar a prova só para você. Uma prova que o outro lado não consegue checar é uma prova que ele vai contestar. Coloque o selo no README, envie o link de status, anexe o certificado em PDF.
Ignorar os requisitos de privacidade do cliente. Se o contrato proíbe acesso de terceiros ao código, use o modo Enterprise ZK ou auto-hospede. Não presuma em silêncio que “apenas hashes” satisfaz uma cláusula que diz “nenhum terceiro”.

Como o Timestamp GIT se Encaixa no Fluxo de Trabalho da Sua Agência

O objetivo de design é que o timestamping seja invisível até você precisar dele:

Zero configuração para desenvolvedores. Instale o GitHub App uma vez. Todo commit num repositório monitorado é enfileirado automaticamente; o lote roda à noite. Nenhum comando novo, nada para instalar nas máquinas dos desenvolvedores.
Arquitetura zero-knowledge. O Timestamp GIT nunca vê, copia ou armazena seu código-fonte. Ele carimba hashes de commit. A impressão digital do passo um é um hash unidirecional do estado do repositório — nada sobre sua implementação é recuperável a partir dela.
Verificação independente de fornecedor. A prova é um recibo .ots ancorado no Bitcoin. A verificação depende de SHA-256 e dos dados de blocos do Bitcoin — nenhum formato proprietário. Qualquer pessoa pode baixar o recibo e verificá-lo com ferramentas padrão do OpenTimestamps contra a blockchain, mesmo que o Timestamp GIT desapareça amanhã. Há um passo a passo em como verificar o timestamp em Bitcoin de um repositório Git.
Pontos de integração que se encaixam na papelada da agência. Uma API REST para status, CSV de auditoria e certificados em PDF; selos incorporáveis para READMEs e documentos de entrega; uma página pública de status que os clientes podem favoritar.
Preços que acompanham a escala da agência. Open Source (grátis) para repositórios públicos, Pro Agency a $49/mês para repositórios privados, Enterprise ZK a $199/mês quando um contrato exige isolamento. Detalhes na página de preços.

Para equipes que querem a mecânica em vez do guia prático, a peça técnica complementar é timestamping automatizado de Git: como um GitHub App ancora cada commit.

Perguntas Frequentes

Preciso mudar como meus desenvolvedores fazem commit de código?

Não. Uma vez que o GitHub App do Timestamp GIT esteja instalado num repositório, todo commit é detectado automaticamente e seu hash é enfileirado para a ancoragem noturna no Bitcoin. Os desenvolvedores continuam usando seu fluxo de trabalho normal do Git, sem comandos ou ferramentas extras.

Os clientes podem verificar a prova por conta própria?

Sim. Você pode incorporar um selo de verificação no seu README ou relatório de entrega que aponta para uma página pública de status. Os clientes também podem baixar o arquivo de recibo .ots e verificá-lo de forma independente contra a blockchain do Bitcoin usando ferramentas padrão do OpenTimestamps.

E se um cliente exigir que nenhum terceiro jamais veja o código?

Use o modo Enterprise ZK, em que uma GitHub Action de 12 linhas roda na sua infraestrutura e envia apenas hashes de commit para a API do Timestamp GIT. Seu código-fonte nunca sai do seu ambiente. Como alternativa, você pode auto-hospedar o Timestamp GIT usando a imagem Docker fornecida para controle total.

Quanto tempo leva para um commit ser ancorado no Bitcoin?

Os hashes de commit são agrupados diariamente e ancorados num bloco do Bitcoin via protocolo OpenTimestamps. A confirmação do Bitcoin normalmente leva cerca de três horas, após o que a prova é imutável e verificável.

Isso substitui um contrato?

Não. Isso substitui a parte mais fraca de uma disputa contratual: o registro factual do que existia quando. Seu contrato determina quem deve o quê; o timestamp determina o que era verdade numa determinada data.

Conclusão

A disputa de Elena se resolveu como essas costumam se resolver — um pagamento parcial e um cliente perdido. A parte frustrante não foi o dinheiro. Foi que ela estava certa e não tinha como demonstrar isso de uma forma que um terceiro aceitasse.

É essa lacuna que a prova em blockchain fecha para as agências. Não a guerra de patentes, não o futuro abstrato — a terça-feira comum em que um cliente decide que a fatura é opcional, e sua única defesa é um registro que nenhum de vocês dois pode editar.

Instale o GitHub App do Timestamp GIT nos repositórios dos seus clientes, deixe a ancoragem noturna rodar, e anexe o certificado à sua próxima fatura. Leva cerca de dez minutos uma vez, e muda o tom de toda conversa de entrega depois disso.

Posts relacionados

Protegendo Entregáveis de Código de Agências com Prova em Blockchain