Skip to main content
Estas páginas fazem quatro afirmações repetidamente: que um cálculo de margem pode ser verificado isoladamente, que qualquer pessoa pode recalcular uma seleção de desalavancagem automática, que o funding é derivado e não decidido, e que dois nós honestos produzem resultados idênticos byte a byte. Uma afirmação com esta forma não vale nada até alguém de fora do protocolo a ter executado. Esta página é o como. Cada verificação nomeia as entradas, de onde vêm e — tão importante quanto — o que não estabelece.
Apenas aritmética
Dados públicos, qualquer nó
Um nó completo seu
Um requisito de margem
Um preço de liquidação
Uma seleção de ADL
Um pagamento de funding
Um bloco, byte a byte
Dois dos cinco não precisam de rede nenhuma: são funções puras sobre um registo de escalões publicado.

1 · Um requisito de margem

Do que precisa: um registo de escalões de alavancagem e um tamanho de posição. Nada mais. Sem nó, sem rede, sem conta. A margem inicial e a de manutenção são funções puras do nocional e do registo de escalões; as fórmulas e o arredondamento exato estão em Alavancagem: IM=nocional×im_leverage×10exponent\text{IM} = \text{nocional} \times \text{im\_leverage} \times 10^{\text{exponent}} MM=max⁡ ⁣(nocional×mm_leverage×10exponent−deduc¸a˜o,  0)\text{MM} = \max\!\left(\text{nocional} \times \text{mm\_leverage} \times 10^{\text{exponent}} - \text{dedução},\; 0\right) Os registos de escalões são publicados no grupo DEX Config da referência da API — im_leverage, mm_leverage, o exponent partilhado e o deduction de cada escalão. Escolha um nocional, avalie ambas as expressões no papel e compare com o que o local cobra à mesma posição. O que prova: o requisito é uma função publicada de parâmetros públicos, não um juízo conta a conta. O que não prova: que o registo de escalões esteja bem escolhido. Isso é uma questão de governação, não de aritmética.
O arredondamento faz parte da especificação, não é uma tolerância. Se o seu inteiro diferir numa unidade do do local, um dos dois está errado — veja as regras de arredondamento na página Câmara de compensação antes de concluir qual.

2 · Um preço de liquidação

Do que precisa: o mesmo registo de escalões, mais o seu saldo e a sua posição. O limiar é um rácio, definido em Liquidações: raˊcio=margem de manutenc¸a˜ocolateral lıˊquido\text{rácio} = \frac{\text{margem de manutenção}}{\text{colateral líquido}} O colateral líquido é o saldo mais o P&L não realizado, menos o que as ordens em livro reservaram. Resolva para o preço de marcação a que o rácio atinge o seu gatilho e tem o preço a que o protocolo vai agir — antes de agir. O que prova: o gatilho é derivável antecipadamente a partir dos seus próprios números. O que não prova: o preço a que será efetivamente fechado, que depende do livro nesse momento e é limitado pelo preço de falência.

3 · Uma seleção de desalavancagem automática

Do que precisa: as posições abertas e os preços de marcação de um mercado, a partir de qualquer nó completo. A seleção é uma pontuação, definida em Desalavancagem automática: pontuac¸a˜o=% de lucro na˜o realizado×alavancagem efetiva\text{pontuação} = \text{\% de lucro não realizado} \times \text{alavancagem efetiva} Puxe as posições de um mercado do grupo Accounts e o preço certificado do grupo Oracle, calcule a pontuação de cada posição do lado com lucro e ordene. Essa ordenação é a fila. Compare o topo da fila que calculou com o indicador de ADL que a interface mostra. O que prova: a fila é uma função de estado público. Ninguém escolhe, e não há nela uma posição que a sua própria aritmética não consiga encontrar. O que não prova: que a desalavancagem não o vá alcançar. Uma fila que sabe calcular continua a ser uma fila em que pode estar.

4 · Um pagamento de funding

Do que precisa: o livro de ordens e o índice certificado da ronda de cobrança, mais a sua posição. A taxa constrói-se em três passos em Funding — um prémio ponderado pela profundidade, escalado ao intervalo do mercado e depois contido: P=max⁡(0,  compra DW−ıˊndice)  −  max⁡(0,  ıˊndice−venda DW)ıˊndiceP = \frac{\max(0,\; \text{compra DW} - \text{índice}) \;-\; \max(0,\; \text{índice} - \text{venda DW})}{\text{índice}} F=F8h×segundos do intervalo28,800Ffinal=clamp⁡ ⁣(F,  Fmin⁡,  Fmax⁡)F = F_{8h} \times \frac{\text{segundos do intervalo}}{28{,}800} \qquad F_{\text{final}} = \operatorname{clamp}\!\left(F,\; F_{\min},\; F_{\max}\right) Depois a cobrança em si: pagamento de funding=tamanho da posic¸a˜o×prec¸o de marcac¸a˜o×taxa de funding\text{pagamento de funding} = \text{tamanho da posição} \times \text{preço de marcação} \times \text{taxa de funding} O livro vem do grupo Markets, o índice certificado de Oracle, e o pagamento que o protocolo realmente fez do endpoint de pagamentos de funding no grupo Accounts. Recalcule e compare. O que prova: a taxa foi derivada do livro e do índice, não foi fixada por um operador. O que não prova: que o índice estivesse certo. Ver o que o oráculo garante e não garante.

5 · Um bloco, byte a byte

Do que precisa: um nó completo seu. Qualquer pessoa pode correr um — ver Correr um nó.
É a única verificação desta página que hoje não está disponível. A rede está numa testnet privada até abrir o acesso público, por isso as quatro primeiras podem ser feitas já e esta passa a poder sê-lo então. Está aqui porque as outras quatro valem o que valer esta.
É a verificação em que assentam as outras quatro. Pegue num bloco confirmado e no seu estado anterior, execute-o e compare o seu resultado com o da rede. O determinismo aqui é imposto e não esperado: o caminho de execução não lê relógio, nem entropia em tempo de execução, nem vírgula flutuante, nem ordens de iteração aleatorizadas por hash — uma divergência é portanto um defeito e não uma tolerância. Ver Porque o resultado é reproduzível. Duas propriedades fazem disto um teste a sério e não uma cerimónia. O ordenamento é um objeto confirmado pelo consenso, pelo que a sequência que reexecuta é a que um quórum assinou e não a que o seu nó inferiu. E os preços são confirmados pelas mesmas assinaturas, de modo que não existe janela em que pudesse reexecutar contra um preço que a rede não certificou. O que prova: que o estado que lhe é servido foi produzido pelas regras tal como publicadas, sobre entradas que a rede confirmou. O que não prova: que as regras estejam livres de defeitos. Reproduzir um bug exatamente continua a ser reproduzir um bug — é por isso que ao lado disto existem as auditorias e o bug bounty.

O que nada disto cobre

A verificação limita o que tem de ser aceite por confiança; não o elimina. O que resta — o conjunto de validadores, o quórum de preços, o alcance da governação sobre os parâmetros e a ponte — está enumerado em Pressupostos de confiança. Leia essa página a seguir se veio à procura dos limites e não das garantias.

Para onde ir a seguir

Pressupostos de confiança

O que sobra depois de verificado tudo o que é verificável.

Correr um nó

Hardware, sincronização e o que um validador executa de facto.

IntentionKernel

Os quatro fechos que dão sentido à reexecução.

Referência da API

Detalhe ao nível do campo para cada entrada referida acima.