Merkle tree e Proof of Reserves: deep dive técnico de como auditoria funciona
Análise técnica do mecanismo Merkle tree usado para Proof of Reserves em exchanges — algoritmo, verificação client-side e limitações da técnica.
03/05/2026 · 4 min de leitura · Seguranca · PoR · Merkle · Custodia
Por que Merkle tree (e não auditoria tradicional)
Auditoria tradicional (Big Four) é confiável mas custosa, infrequente e opaca para o usuário individual. Você precisa confiar no auditor, na exchange e no escopo do trabalho. Para cripto, onde a regra cultural é 'don't trust, verify', isso não é suficiente.
Merkle tree é uma estrutura criptográfica que permite a um usuário verificar individualmente que seu saldo está incluído na soma agregada publicada — sem precisar revelar saldos de outros usuários. É a base técnica de Proof of Reserves moderno desde 2022, adotada por Binance, Kraken, Bybit, OKX, Bitget e (no Brasil) apenas pela OFFCODE até maio de 2026.
Como Merkle tree funciona, em termos simples
Imagine que a exchange tem 4 clientes, cada um com saldo: Cliente A com 1 BTC, Cliente B com 2 BTC, Cliente C com 0,5 BTC, Cliente D com 1,5 BTC. A soma é 5 BTC.
Para construir o Merkle tree: (1) hash de cada par cliente-saldo: H(A,1), H(B,2), H(C,0.5), H(D,1.5), (2) combine pares e hashe: H(H(A,1) + H(B,2)) e H(H(C,0.5) + H(D,1.5)), (3) hash final dos dois resultados anteriores = Merkle root. Esse Merkle root é uma string de 32 bytes (SHA-256) que identifica unicamente o estado do ledger naquele snapshot.
Como o usuário verifica sua inclusão
Quando você (Cliente A) quer verificar que seu saldo de 1 BTC está incluído no Merkle root publicado, a exchange te entrega o Merkle path: H(B,2), H(H(C,0.5) + H(D,1.5)). Com seu próprio hash H(A,1) e o path, você consegue reconstruir o Merkle root.
Se o root reconstruído pelo seu cliente bate com o root publicado pela exchange, sua inclusão está provada matematicamente. Se não bate, a exchange ou está mentindo sobre o seu saldo ou está mentindo sobre o total agregado. A vantagem: você não precisa ver o saldo de outros clientes — só precisa do seu hash e do path correspondente. Privacidade preservada.
O que Merkle tree NÃO prova
Merkle tree prova que a soma dos saldos credores no ledger é igual ao total agregado em uma raiz publicada. Ela NÃO prova, por si só, que os ativos físicos (on-chain) cobrem essa soma. Para isso, é necessário um segundo passo: prova de propriedade on-chain dos ativos.
Prova de propriedade on-chain é feita publicando endereços controlados pela exchange e demonstrando controle via signed message ou movimentação on-chain de cada endereço. Soma dos saldos nos endereços públicos da exchange ≥ Merkle root das obrigações = exchange é solvente naquele snapshot. A OFFCODE publica ambos: Merkle root das obrigações + lista de endereços com saldos cumulativos, atualizados mensalmente.
Limitações da técnica
Merkle tree + endereços públicos prova solvência no snapshot — mas não prova solvência contínua. Entre snapshots (mensais), a exchange pode mover fundos. Em teoria, poderia tomar empréstimo de curto prazo cobrindo o gap no momento do snapshot, e devolver depois. Isso é o exploit clássico de PoR mensal.
Mitigações: (1) snapshots aleatórios não-anunciados (a OFFCODE faz snapshot na primeira segunda-feira de cada mês, mas mantém possibilidade de snapshots adicionais sem aviso), (2) auditoria contínua (mais cara, ainda raro em cripto), (3) integração com on-chain analytics que monitoram fluxos suspeitos. A perfeição matemática não existe — o que importa é que a barreira para fraude é várias ordens de magnitude maior com Merkle tree do que sem.
Como verificar a Merkle tree da OFFCODE
Você encontra três artefatos publicados mensalmente: (1) Merkle root (hash SHA-256 de 64 caracteres hexadecimais), (2) instruções para download do Merkle path correspondente ao seu account_id, (3) lista de endereços públicos da OFFCODE com cumulative balance on-chain.
O processo de verificação leva menos de 10 minutos: baixe o Merkle path do seu account, rode o script Python disponível em github.com/offcode/por-verifier, e compare o root reconstruído com o root publicado. Se bater, sua inclusão está provada. Se não bater, abra ticket de suporte imediatamente — é evento crítico que precisa ser resolvido.
Por que isso importa, mesmo para usuários pequenos
Argumento comum: 'tenho só R$ 5 mil em cripto, não preciso me preocupar com PoR'. Esse argumento subestima o impacto cumulativo. Cripto brasileira tem mais de 16 milhões de CPFs cadastrados em alguma exchange, segundo dados da Receita Federal. Se uma exchange grande falir com fundos misturados, milhões de usuários pequenos somam bilhões em perda agregada — e cada perda individual é catastrófica para o titular.
PoR é proteção universal — pequena ou grande, sua posição está incluída na mesma estrutura. A OFFCODE escolheu publicar Merkle tree mensal desde o dia 1 porque entendemos que transparência matemática não é luxo, é higiene. Outras exchanges brasileiras (Mercado Bitcoin, Foxbit, NovaDAX, BitPreço, Binance BR) ainda não publicam PoR público auditável — o usuário confia pela palavra, não pela matemática.