· four exchange APIs · rebuilt daily
Um relatório de prova de reservas de uma exchange depende de uma estrutura de dados de árvore de Merkle. A exchange hash os saldos individuais das contas dos usuários em nós folha. Essas folhas hash juntas em pares repetidamente até produzir uma única raiz de Merkle.
A exchange publica a raiz de Merkle ao lado de endereços de carteira públicos. Você pode verificar seu saldo hashizando seu ID de conta individual e saldo com hashes de branch intermediários até a raiz. Isso confirma que seu saldo foi incluído na soma final gerada pela exchange para aquela altura de bloco exata.
Uma árvore de Merkle válida prova dois fatos específicos. Primeiro, prova que a exchange criou uma estrutura de dados contendo seu saldo específico. Segundo, prova que a exchange possui chaves privadas capazes de assinar uma mensagem a partir de carteiras públicas contendo uma quantidade de ativos. Não verifica se esses ativos são desembaraçados, nem confirma se a exchange omitiu saldos de usuários da árvore antes de gerar o hash da raiz.
Where this goes wrong
Uma exchange pode forjar uma prova de reservas aprovada criando sub-contas internas com grandes saldos negativos. Se a árvore de Merkle compensa uma conta negativa oculta de 5.000 BTC contra 10.000 BTC em depósitos de usuários, a soma de passivos publicada aparece como 5.000 BTC, tornando uma exchange subcolateralizada parecer totalmente solvente no papel.
A solvência requer que os ativos totais excedam os passivos totais. Os endereços na corrente verificam apenas o lado de ativos da equação.
Um balanço completo requer a auditoria de três categorias distintas de passivos: depósitos spot de usuários, obrigações de margem de futuros perpétuos abertos e instalações de dívida corporativa. A maioria das atestações publicadas cobre apenas depósitos spot.
Considere uma exchange com 10.000 BTC em depósitos spot de usuários. A exchange também carrega um empréstimo corporativo de 2.000 BTC devido a um credor institucional e um déficit de margem oculto de 1.000 BTC de contas liquidadas. Os passivos totais são iguais a 13.000 BTC.
Se a exchange possui 10.000 BTC em carteiras frias na corrente, uma atestação padrão relata ativos de 10.000 BTC contra passivos de 10.000 BTC. A razão ativo-passivo aparece como 100%. Na realidade, os passivos totais são 13.000 BTC, o que significa que a exchange possui apenas 76,9% dos ativos necessários para cobrir suas obrigações totais.
Worth knowing
As assinaturas na corrente provam apenas a posse de chaves no bloco de snapshot. Elas não impedem que a exchange use esses mesmos ativos como garantia para contratos de rehipotecação fora da corrente três minutos após o fechamento do snapshot.
Snapshots estáticos trimestrais incentivam a manipulação do balanço. Como as atestações ocorrem em alturas de bloco pré-anunciadas, as exchanges podem emprestar fundos temporariamente para inflar as reservas relatadas.
Uma exchange subcapitalizada que possui 8.000 BTC contra 10.000 BTC de obrigações de usuários enfrenta um déficit de 2.000 BTC. Para passar em um snapshot futuro na altura de bloco 800.000, a exchange empresta 2.000 BTC de uma facilidade de crédito fora da corrente às 23h50 UTC.
O credor transfere 2.000 BTC para a carteira da exchange. Às 00h00 UTC, o snapshot captura 10.000 BTC em reservas na corrente. A exchange assina a mensagem de verificação, prova 100% de cobertura e devolve os 2.000 BTC ao credor às 00h10 UTC. A taxa do empréstimo por vinte minutos de capital equivale a uma fração de por cento, enquanto a atestação publicada afirma cobertura total por noventa dias.
| Modelo de Attestação | Método de Verificação de Ativos | Escopo de Passivos Coberto | Risco de Empréstimo de Snapshot |
|---|---|---|---|
| Snapshot Auto-Relatado | Listas de endereços não assinadas | Apenas saldos spot de usuários | Alto (temporização não monitorada) |
| Árvore de Merkle + Assinaturas | Assinatura de chave criptográfica | Apenas saldos spot de usuários | Alto (empréstimos específicos de bloco) |
| Attestação de Terceiros | Chaves verificadas por auditor | Contas spot e futuros | Médio (amostragem periódica) |
| Conhecimento Zero Contínuo | Provas de conhecimento zero em tempo real | Todos os estados de conta e margem | Baixo (atualizações de estado automatizadas) |
Ao escolher onde manter posições de futuros perpétuos, avalie a estrutura técnica dos relatórios de reservas de uma exchange em vez de releases de marketing.
Procure por quatro critérios em uma atestação:
What to do instead
Verifique seu hash individual diretamente na árvore de Merkle após cada snapshot publicado e rejeite atestações que não declarem explicitamente que saldos de usuários negativos são excluídos do cálculo de passivos totais.
Prova que uma exchange possuía as chaves privadas para carteiras específicas na corrente em uma altura de bloco definida e que seu saldo de conta foi incluído na raiz de Merkle publicada. Não prova que esses ativos estão livres de empréstimos fora da corrente ou que os passivos totais foram divulgados com precisão.
Uma exchange pode emprestar ativos logo antes do bloco de snapshot para inflar temporariamente os saldos das carteiras ou criar sub-contas internas com saldos negativos ocultos para reduzir artificialmente os passivos de usuários relatados.
Uma prova de reservas é um snapshot pontual da propriedade de ativos na corrente versus saldos de usuários relatados. Uma auditoria financeira completa avalia a dívida fora do balanço, empréstimos corporativos, despesas operacionais e controles internos durante um período de contabilidade estendido.
Os saldos de futuros perpétuos flutuam continuamente com base no lucro e prejuízo não realizados, alavancagem e acordos de funding de posições. Verificar perps requer auditar requisitos de margem dinâmicos em todas as posições ativas, em vez de depósitos de carteira estáticos.