Reconciliação de gravames: o requisito de privacidade que sobrevive à troca de tecnologia

Em novembro de 2025, o Banco Central comunicou aos participantes do piloto do DREX que a infraestrutura de registro distribuído seria desligada e que o projeto seguiria "agnóstico de tecnologia". A primeira entrega da nova fase, prevista para o segundo semestre de 2026, tem escopo bem mais estreito e bem mais concreto: reconciliação de gravames — permitir que um ativo registrado em instituições diferentes seja usado como garantia de crédito sem ambiguidade sobre quem tem o quê.

A leitura predominante foi que aquilo era um veredito sobre blockchain. Passei quase uma década construindo uma e tenho um interesse óbvio no assunto, então vou evitar defendê-la aqui. Meu argumento é outro, e no fundo é mais incômodo:

A dificuldade central do piloto não era uma dificuldade da tecnologia — e por isso ela não vai embora junto com ela.

Quem construir a camada de gravames herda o mesmo requisito, sob outra forma. Vale nomeá-lo enquanto o desenho ainda está aberto.

1. O que reconciliação de gravames é, estruturalmente

O problema de negócio é conhecido. O mesmo ativo pode ser dado em garantia a mais de um credor. Os registros vivem em instituições diferentes — bancos, financeiras, corretoras, registradoras, cartórios, 27 Detrans. Ninguém tem a foto completa. O credor não consegue verificar com rapidez e certeza se o ativo já está comprometido, e o crédito fica mais lento e mais caro por causa disso.

Retire o vocabulário financeiro e olhe a forma do problema: impedir que o mesmo ativo seja gasto duas vezes por partes que não compartilham banco de dados e não têm motivo para confiar umas nas outras.

Isso é prevenção de gasto duplo. É um problema antigo de sistemas distribuídos, e não precisa de token nenhum, nem de rede, nem de consenso probabilístico para ser exatamente esse problema. O que muda entre uma implementação e outra é quem detém a autoridade sobre a ordem dos eventos, e o que cada participante aprende no caminho.

A escolha do Banco Central para 2026 resolve a primeira parte por centralização: uma infraestrutura central concilia os registros. É uma decisão defensável, e volto a ela no fim. A segunda parte — o que cada participante aprende — é o assunto deste texto.

2. O Brasil já opera um registro nacional de gravames

Essa discussão costuma ser tratada como especulação sobre um sistema futuro. Não é. O Brasil opera há anos um registro nacional de gravames em escala, e ele é um bom lugar para observar o requisito funcionando na prática.

O Sistema Nacional de Gravames concentra as restrições financeiras sobre veículos dados em garantia em operações de crédito em todo o país, e é operado pela B3, pelo braço herdado da Cetip. O fluxo é simples: a instituição credora registra o gravame ao financiar o veículo; ao avaliar uma nova operação, consulta a base e recebe, em tempo real, se há restrição; ao quitar, dá baixa.

Duas observações sobre esse desenho.

A primeira é que ele já é, sem usar a expressão, prevenção de gasto duplo — a própria descrição do serviço aponta que a consulta em tempo real impede que um veículo já gravado seja usado como garantia em outra operação. O problema que o DREX agora chama de reconciliação de gravames tem uma implementação nacional em produção, 24 horas por dia, integrada aos Detrans.

A segunda é mais interessante. A consulta não devolve apenas se existe restrição: devolve qual é o agente credor.

No crédito de veículos isso tem função legítima. Quem vai negociar um veículo alienado precisa saber com quem quitar. É informação operacionalmente necessária, e o registro está certo em fornecê-la nesse contexto.

Mas repare no que a propriedade significa em termos de informação: cada consulta entrega a um concorrente a identidade da instituição que financiou aquele cliente. Para financiamento de veículo, com ticket padronizado e mercado maduro, o mercado aceitou esse custo há muito tempo — e o benefício sistêmico de reduzir fraude compensou largamente.

A pergunta que a fase 3 do DREX levanta não é sobre o SNG, que funciona e resolveu um problema real. É sobre o que acontece quando esse modelo se generaliza para outras classes de ativo — recebíveis pulverizados, direitos creditórios, cotas de fundos fechados, garantias de operações estruturadas — onde a identidade do credor e a existência da avaliação são informação competitiva sensível, e não um dado operacional necessário.

3. O vazamento não está no registro. Está na consulta.

Aqui está a parte que não vi discutida publicamente, e que considero o requisito mais importante a nomear.

Num registro central de gravames, o dado mais valioso não é o registro. É o log de consultas.

Toda vez que uma instituição pergunta "o ativo X está gravado?", ela informa ao operador central que está avaliando crédito contra X — e, por extensão, contra o titular de X. A resposta é indiferente. A pergunta já entregou a informação.

Agregue essas consultas por alguns meses e o que se forma não é um histórico: é um mapa em tempo real do pipeline de crédito do sistema financeiro. Quem está avaliando quem, com que frequência, em que setores, em que velocidade, antes de qualquer operação ser fechada.

Vale insistir na distinção, porque ela é o coração do problema. Um registro de gravames guarda o que aconteceu. Um log de consultas revela o que está sendo pensado. A segunda informação é mais valiosa que a primeira, e ela não é gerada pelo dado — é gerada pelo ato de perguntar. Nenhuma política de acesso ao conteúdo do registro protege contra isso, porque não é o conteúdo que está sendo exposto.

Há dois efeitos derivados.

A resposta também vaza. "Sim, está gravado, e o credor é o banco B" conta ao banco A algo sobre a relação comercial de B com aquele cliente, num momento em que A está decidindo se compete por ela.

E há concentração. Um registro que conhece todos os ônus sobre todos os ativos relevantes do país, mais o histórico de quem consultou o quê, é a base de dados mais valiosa do sistema financeiro brasileiro reunida num ponto. Isso é uma afirmação sobre superfície de ataque e sobre risco de custódia de informação, não sobre a idoneidade de qualquer operador.

Uma ressalva necessária, e ela é sincera: o desenho da fase 3 não é público. Não estou criticando uma implementação que não vi. Estou descrevendo um requisito que qualquer implementação centralizada desse tipo enfrenta, e que é muito mais barato endereçar antes de a arquitetura estar congelada do que depois.

4. Dois eixos de privacidade, e a confusão que derrubou o piloto

O relatório da primeira fase do piloto do DREX, publicado pelo Banco Central em fevereiro de 2025, concluiu que as soluções de privacidade testadas garantiram o anonimato das transações inclusive perante o próprio Banco Central, e que, com isso, supervisão, bloqueio de saldos e cumprimento de ordem judicial se tornavam inviáveis.

Aquilo foi lido no mercado como uma limitação de blockchain. Acho que é uma leitura imprecisa, e a imprecisão é justamente o que torna o problema transferível.

As soluções testadas eram tecnicamente sérias, várias delas com criptografia de primeira linha. Elas falharam porque foram construídas sobre uma definição de privacidade herdada das redes públicas, onde privacidade significa proteção contra todos: o vizinho, o concorrente, o Estado. Nessa tradição, esconder de todo mundo é a definição de vitória.

Numa infraestrutura regulada, a mesma definição é derrota. Porque existe ali um terceiro que não é um par. O supervisor não é um bisbilhoteiro opcional cuja curiosidade se combate — é uma entidade com mandato legal, que precisa ver o sistema, bloquear quando a Justiça determina, e seguir o dinheiro quando a lei exige. "O sistema não tem como ver" não é uma resposta aceitável a uma ordem judicial.

Ou seja: o piloto não descobriu um limite da criptografia. Descobriu um erro de especificação de requisito. E erro de requisito atravessa qualquer troca de stack — é por isso que ele reaparece, do outro lado, num registro central que vê a intenção de todo mundo.

Separar os dois eixos resolve a confusão:

• Privacidade horizontal — os pares não se enxergam. Meu concorrente não mapeia minha carteira, meu fornecedor não lê meu caixa, o operador da infraestrutura não aprende meu pipeline.
• Transparência vertical — quem tem mandato legal vê tudo. Não por quebra, não por exceção operacional, não por pedido formal com prazo de resposta: por desenho.

O piloto otimizou o primeiro eixo até zerar o segundo. Um registro central otimiza o segundo e trata o primeiro como consequência aceitável. Nenhum dos dois é o requisito.

5. A assimetria que torna os dois eixos compatíveis

A objeção natural é que esses dois eixos são contraditórios. Não são, e a peça que os conecta é antiga e bem entendida: visibilidade sem poder de assinatura.

A ilustração mais limpa vem do padrão BIP-32, de carteiras determinísticas hierárquicas. De uma semente deriva-se uma árvore de chaves. Quem possui a chave pública estendida consegue derivar todos os identificadores filhos daquela árvore — enxerga o conjunto inteiro, reconhece cada elemento — e não consegue produzir uma única assinatura. É a chave do extrato, não a chave do cofre.

Essa propriedade não é uma propriedade de blockchain. É uma propriedade de derivação de chaves sobre curvas elípticas, e ela funciona igualmente bem dentro de um Postgres, num sistema centralizado, sem bloco, sem consenso e sem rede.

Aplicada a um registro de ônus, a forma é esta. Os identificadores de gravame de um mesmo titular são derivados hierarquicamente, de modo que cada credor reconhece apenas a relação de que participa e não consegue ligar um registro ao outro. Quem detém a chave estendida daquele titular reconhece a árvore inteira — todos os ônus, todo o histórico — e não consegue constituir, alterar ou baixar nada.

E o detentor não precisa ser um só. Cada regulador pode manter o seu, cada instituição o seu no escopo do que lhe cabe. O resultado é que a visibilidade também se distribui: para um titular qualquer, poucas entidades enxergam o conjunto completo, e nenhuma enxerga o conjunto completo de todos.

Descrevi esse arranjo em detalhe num artigo escrito em 2024 com o professor Henrique Gomes de Moura, da UnB, no contexto de uma Rede de Responsabilidade Regulada. Faço questão de registrar o que ele não era: nenhuma primitiva criptográfica nova. Carteira hierárquica é padrão de 2012, endereço furtivo já rodava havia anos, oráculo é padrão de manual. A contribuição, se houver uma, foi o arranjo de quem-vê-o-quê. É disso que se trata aqui também.

6. O ferramental, e o que cada peça custa

Nada do que segue exige registro distribuído. Todas são técnicas aplicáveis a um registro central, e ordenei por custo crescente.

Acumuladores de Merkle com prova de exclusão

O registro publica periodicamente uma raiz criptográfica do seu estado. Uma instituição prova que seu registro está incluído — ou, o que importa mais aqui, que um ativo não está gravado — sem precisar confiar na palavra do operador. Barato, bem compreendido, e resolve o problema de auditabilidade sem exigir que ninguém veja o conteúdo alheio.

Compromissos de Pedersen

O registro guarda um compromisso ao valor do ônus em vez do valor. O mundo vê o compromisso, não o número. Como os compromissos se somam entre si, é possível provar que a soma dos gravames sobre um ativo não excede seu valor sem revelar nenhuma das parcelas. E quem detém o segredo de abertura lê o número — o que dá ao supervisor exatamente o que ele precisa e a mais ninguém. Custo: operações de curva elíptica, ordens de magnitude mais baratas que provas de conhecimento zero de propósito geral.

Interseção privada de conjuntos (PSI)

A instituição descobre se o ativo X pertence ao conjunto de ativos gravados sem revelar X ao operador e sem aprender o resto do conjunto. É, literalmente, a consulta de gravame com os metadados protegidos. Está em produção há anos em outros setores. Custo: rodadas de comunicação e trabalho proporcional ao tamanho do conjunto, mitigável com pré-computação e particionamento por faixa de identificador.

Recuperação privada de informação (PIR)

Consultar um registro sem que o servidor aprenda qual linha foi pedida. É a resposta mais direta ao problema da seção 3. Custo alto no caso de servidor único; substancialmente menor em esquemas de múltiplos servidores que não conluiem — o que é viável precisamente quando a infraestrutura tem mais de um operador, arranjo que o mercado brasileiro de registradoras já tem.

Custódia limiar da chave do supervisor

A capacidade de abrir os compromissos ou de percorrer a árvore de um titular é fragmentada, de modo que nenhuma pessoa sozinha dentro do operador central consiga desanonimizar qualquer coisa. Padrão, barato, e endereça o risco de concentração sem mudar a arquitetura.

Devo uma honestidade sobre essa lista: nenhuma dessas peças é gratuita, e o custo é a razão pela qual elas não são o padrão. PIR de servidor único ainda é caro. PSI exige repensar o protocolo de consulta, não só adicionar uma biblioteca. Compromissos exigem decidir quem guarda a chave de abertura, o que é uma questão de governança antes de ser técnica.

O que defendo não é que sejam baratas. É que o custo delas seja uma decisão registrada, e não uma omissão — que alguém tenha olhado o requisito, calculado o preço e escolhido, em vez de o requisito nunca ter entrado na especificação.

7. O que "agnóstico de tecnologia" deveria significar

A escolha do Banco Central é defensável, e não digo isso por diplomacia. Com um sistema financeiro nas costas, uma entrega centralizada que funciona vale mais que uma arquitetura distribuída elegante que não sai do laboratório. O piloto tinha quatro anos e não convergia. Cortar escopo para entregar é engenharia, não recuo.

Mas "agnóstico de tecnologia" corta para os dois lados. Se o requisito é agnóstico de tecnologia, o defeito também é.

O relatório de fevereiro de 2025 foi lido como um veredito sobre blockchain. Ele era um veredito sobre uma especificação de requisito: privacidade foi definida como proteção contra todos, num arranjo em que existe um terceiro com mandato legal que não é um par. Trocar o registro distribuído por um registro central não corrige essa especificação. Move o vazamento do conteúdo para a consulta, dos participantes para o operador, e do histórico para a intenção — que é a informação mais valiosa das três.

O ferramental para tratar isso existe, é público, tem revisão por pares de mais de uma década, e não depende de nenhuma aposta tecnológica. O que ele exige é que o requisito seja escrito.

A camada de gravames do DREX está sendo desenhada agora. É o momento mais barato que vai existir para colocar essa linha na especificação.