DREX, Blockchain e Assinatura Digital: O Que Cada Um Resolve (e O Que Não)
Com o avanço do DREX — o real digital do Banco Central — voltou com força a pergunta que ronda todo projeto de contratos: "não deveríamos assinar isso no blockchain?". A resposta séria exige separar três coisas que usam a mesma criptografia para resolver problemas diferentes: a moeda programável que liquida obrigações, o registro distribuído que ancora fatos no tempo, e a assinatura que vincula uma pessoa identificada a um documento. Este guia desmonta a confusão — sem hype e sem pânico — e mostra onde as tecnologias se complementam de verdade.
Três tecnologias, três perguntas
| Tecnologia | Pergunta que responde | O que NÃO responde |
|---|---|---|
| DREX / moeda programável | "Como liquidar esta obrigação automaticamente, com segurança?" | Quem se obrigou, e a quê — isso é o contrato |
| Blockchain / DLT | "Como partes que não confiam entre si concordam sobre um registro?" | Quem é a pessoa por trás de uma chave — não há CPF no hash |
| Assinatura digital | "Quem se obrigou a este documento, e ele mudou desde então?" | Consenso distribuído — nem precisa: as partes do contrato se conhecem |
Repare no ponto estrutural: num contrato, as partes se conhecem e se identificam — é a premissa do negócio. O problema que o blockchain resolve (consenso sem confiança mútua, sem autoridade central) simplesmente não é o problema de assinar um contrato. Já os problemas da assinatura — autoria identificada, integridade, tempo — têm solução madura, com jurisprudência: os níveis da Lei 14.063/2020, do clique ao ICP-Brasil.
A mesma matemática, vínculos opostos
A confusão nasce de uma coincidência técnica real: transações de blockchain são assinadas com criptografia assimétrica — a mesma da assinatura de documentos. A diferença é o que a chave representa:
- No blockchain, a chave autentica uma carteira: prova que quem moveu o ativo controlava aquele endereço. Pseudônima por desenho; transferível de fato — quem tem a seed, tem a carteira.
- Na assinatura com ICP-Brasil, a chave está vinculada a um titular: um certificado, emitido após verificação de identidade por uma Autoridade Certificadora, amarra a chave a uma pessoa física ou jurídica — com presunção legal de veracidade (MP 2.200-2/2001).
- Na assinatura avançada, o vínculo é a trilha: OTP no canal do titular, biometria com prova de vida, IP, geolocalização — evidências de que aquela pessoa praticou aquele ato.
O que o hash on-chain resolve bem (crédito onde é devido)
Ancorar o hash de um documento numa blockchain pública tem um mérito técnico real: prova de anterioridade forte e independente — aquele conteúdo existia naquele bloco, e nenhuma parte pode retroagir isso. É uma forma legítima de carimbo de tempo descentralizado, e para casos como prova de autoria intelectual tem seu lugar.
Mas repare no que sobrou de fora: quem. O hash prova que o documento existia; não prova que alguém se obrigou a ele. Integridade e tempo, sem autoria, não fazem um contrato. No modelo da SignDocs, os mesmos dois problemas são resolvidos com criptografia padrão — hash SHA-256 amarrado ao carimbo de hora do servidor numa trilha append-only, com o pacote de evidências (.p7m) verificável de forma independente no verificador público — junto com a camada de autoria que o blockchain não tem. (E sobre carimbo de tempo em geral, nossa posição honesta está em carimbo do tempo e prova temporal.)
DREX: a liquidação programável — e o contrato que continua sendo contrato
O DREX, em desenvolvimento pelo Banco Central por meio de fases de piloto, é o real em forma tokenizada sobre tecnologia de registro distribuído. Sua promessa central para contratos é o delivery-versus-payment: a transferência do ativo e o pagamento acontecem atomicamente — ou os dois, ou nenhum. Para uma compra e venda de veículo ou imóvel, isso ataca o risco real ("paguei e não recebi").
O que o DREX não muda: a obrigação continua nascendo de um contrato entre pessoas identificadas. O smart contract executa o combinado; o documento assinado é o combinado — incluindo tudo que código não captura: exceções, garantias, força maior, foro. Quando a automação falhar ou fizer o inesperado, é o documento assinado que dirá quem responde. O desenho maduro é o par: assinatura com validade jurídica na camada da obrigação, automação na camada da execução — e, entre as duas, os webhooks que já hoje disparam a execução no seu sistema quando o contrato conclui.
Por que a SignDocs não usa blockchain (e diz isso com tranquilidade)
Porque os requisitos da assinatura de documentos — integridade verificável, autoria identificada, prova de tempo, verificação por terceiros — são atendidos com ferramentas padrão, maduras e baratas: PAdES/CAdES, ICP-Brasil, trilha append-only, verificador público. Adicionar uma blockchain a esse desenho acrescentaria custo de rede, complexidade operacional e uma camada de identidade a reconstruir — sem adicionar prova que o modelo atual não tenha. Tecnologia se escolhe pelo problema, não pela manchete. Se a ancoragem on-chain um dia virar exigência concreta dos nossos clientes, ela entraria como complemento de carimbo de tempo — nunca como substituto da camada de identidade.
Perguntas Frequentes
O que é o DREX e o que ele tem a ver com contratos?
O DREX é o projeto de moeda digital do Banco Central do Brasil — o real em forma tokenizada, operando sobre tecnologia de registro distribuído (DLT), em desenvolvimento por meio de fases de piloto com instituições participantes. A conexão com contratos vem dos smart contracts: no desenho do DREX, operações como uma compra e venda com pagamento condicionado podem ser programadas para liquidar automaticamente (o famoso delivery-versus-payment). Ou seja: o DREX toca a LIQUIDAÇÃO da obrigação. O contrato jurídico entre as partes — o documento que descreve a obrigação, assinado por pessoas identificadas — continua existindo e continua precisando de assinatura com validade jurídica. As duas camadas se complementam; nenhuma substitui a outra.
Registrar o hash de um documento no blockchain equivale a assiná-lo?
Não — e essa é a confusão mais comum do tema. Ancorar um hash on-chain prova duas coisas com força: que aquele conteúdo exato existia naquele momento (anterioridade) e que não foi alterado desde então (integridade). O que ele não prova é QUEM se obrigou: um hash não tem CPF. A assinatura de um documento exige o vínculo entre o ato criptográfico e uma pessoa identificada — e esse vínculo é exatamente o que uma infraestrutura de identidade fornece: na assinatura qualificada, o certificado ICP-Brasil emitido após verificação de identidade; na avançada, a trilha de autenticação (OTP, biometria com prova de vida) amarrada ao ato. Blockchain resolve integridade e tempo; identidade é outro problema.
Mas as transações no blockchain não são assinadas digitalmente?
São — com a mesma criptografia assimétrica da assinatura de documentos, e é daí que vem a confusão. A diferença está no que a chave representa. No blockchain, a chave privada autentica uma CARTEIRA: prova que quem moveu o ativo controlava aquele endereço — pseudônimo por desenho, transferível de fato (quem tem a seed controla a carteira). Na assinatura de documentos com ICP-Brasil, a chave está vinculada por um certificado a uma PESSOA física ou jurídica identificada, com presunção legal (MP 2.200-2/2001). Mesma matemática, vínculos opostos: uma aponta para um endereço; a outra, para um titular.
Um contrato 'assinado no blockchain' vale juridicamente no Brasil?
Pode valer — pelo mesmo art. 10, §2º da MP 2.200-2/2001 que admite qualquer meio de comprovar autoria e integridade aceito pelas partes. O registro on-chain cobre bem a integridade e a anterioridade; a autoria é o elo frágil: será preciso provar, por outros meios, que a carteira que assinou pertencia àquela pessoa naquele momento. Compare com os caminhos estabelecidos: assinatura qualificada (ICP-Brasil) com presunção legal, ou avançada com trilha de auditoria completa. Na prática, quem 'assina no blockchain' acaba reconstruindo, com mais esforço e menos jurisprudência, o que a assinatura eletrônica madura já entrega pronto.
Smart contract substitui o contrato jurídico?
Não — são camadas diferentes da mesma relação. O smart contract é código que executa condições: se X acontecer, transfira Y. Ele automatiza a EXECUÇÃO, e faz isso muito bem. O contrato jurídico é a manifestação de vontade que cria a obrigação — incluindo tudo que código não captura: exceções, força maior, interpretação, foro. Quando o smart contract falha ou faz o inesperado (bugs acontecem), é o contrato jurídico assinado que diz quem responde. O desenho maduro, inclusive no contexto DREX, é o par: documento assinado com validade jurídica descrevendo a obrigação + automação executando o combinado.
A SignDocs usa blockchain?
Não — por escolha de arquitetura, não por atraso. Os problemas que o blockchain resolve (consenso entre partes que não confiam entre si, resistência a censura) não são os problemas da assinatura de documentos. O que a assinatura exige — integridade verificável, autoria identificada, prova de tempo, verificação independente — é entregue com criptografia padrão: hash SHA-256, assinaturas no padrão PAdES/CAdES, certificados ICP-Brasil, trilha de auditoria append-only e um verificador público aberto a qualquer pessoa. Ferramentas maduras, jurisprudência consolidada, custo por documento sem taxa de rede. Se um dia a ancoragem on-chain se tornar exigência real dos nossos clientes, ela seria um complemento de carimbo de tempo — não uma substituição da camada de identidade.
Contratos com validade jurídica hoje — prontos para a automação de amanhã
Assinatura do clique ao ICP-Brasil, trilha de evidências verificável e webhooks que disparam a execução no seu sistema quando o contrato conclui. A camada da obrigação, resolvida.
Comece grátis Falar com o time comercial