Skip to main content
Ces pages avancent quatre affirmations à répétition : qu’un calcul de marge se vérifie isolément, que n’importe qui peut recalculer une sélection de réduction automatique du levier, que le financement est dérivé et non décidé, et que deux nœuds honnêtes produisent des résultats identiques au bit près. Une affirmation de cette forme ne vaut rien tant que quelqu’un d’extérieur au protocole ne l’a pas exécutée. Cette page explique comment. Chaque contrôle nomme les entrées, leur provenance et — tout aussi important — ce qu’il n’établit pas.
Rien que de l’arithmétique
Données publiques, n’importe quel nœud
Votre propre nœud complet
Une exigence de marge
Un prix de liquidation
Une sélection ADL
Un paiement de financement
Un bloc, octet par octet
Deux des cinq ne demandent aucun réseau : ce sont des fonctions pures d’un barème de paliers publié.

​
1 · Une exigence de marge

Ce qu’il vous faut : un barème de paliers de levier et une taille de position. Rien d’autre. Aucun nœud, aucun réseau, aucun compte. La marge initiale et la marge de maintien sont des fonctions pures du notionnel et du barème, avec les formules et l’arrondi exact sur Levier : IM=notionnel×im_leverage×10exponent\text{IM} = \text{notionnel} \times \text{im\_leverage} \times 10^{\text{exponent}} MM=max⁡ ⁣(notionnel×mm_leverage×10exponent−deˊduction,  0)\text{MM} = \max\!\left(\text{notionnel} \times \text{mm\_leverage} \times 10^{\text{exponent}} - \text{déduction},\; 0\right) Les barèmes sont publiés dans le groupe DEX Config de la référence de l’API — im_leverage, mm_leverage, l’exponent partagé et le deduction propre à chaque palier. Choisissez un notionnel, évaluez les deux expressions sur papier, et comparez à ce que la place facture à la même position. Ce que cela prouve : l’exigence est une fonction publiée de paramètres publics, pas une appréciation compte par compte. Ce que cela ne prouve pas : que le barème soit bien calibré. C’est une question de gouvernance, pas d’arithmétique.
L’arrondi fait partie de la spécification, ce n’est pas une tolérance. Si votre entier diffère d’une unité de celui de la place, l’un des deux est faux — consultez les règles d’arrondi sur la page Chambre de compensation avant de conclure lequel.

​
2 · Un prix de liquidation

Ce qu’il vous faut : le même barème, plus votre solde et votre position. Le seuil est un ratio, défini sur Liquidations : utilisation de la marge=marge de maintenancecollateˊral net\text{utilisation de la marge} = \frac{\text{marge de maintenance}}{\text{collatéral net}} Le collatéral net, c’est le solde plus le P&L latent, moins ce que les ordres en carnet ont réservé. Résolvez pour le prix de marquage auquel le ratio atteint son déclencheur et vous tenez le prix auquel le protocole agira — avant qu’il n’agisse. Ce que cela prouve : le déclencheur se dérive à l’avance à partir de vos propres chiffres. Ce que cela ne prouve pas : le prix auquel vous serez effectivement clôturé, qui dépend du carnet à cet instant et est borné par le prix de faillite.

​
3 · Une sélection de réduction automatique du levier

Ce qu’il vous faut : les positions ouvertes et les prix de marquage d’un marché, depuis n’importe quel nœud complet. La sélection est un score, défini sur Réduction automatique du levier : score=% de gain latent×levier effectif\text{score} = \text{\% de gain latent} \times \text{levier effectif} Récupérez les positions d’un marché dans le groupe Accounts et le prix certifié dans le groupe Oracle, calculez le score de chaque position du côté gagnant, puis triez. Cet ordre est la file. Comparez la tête de votre file calculée à l’indicateur ADL affiché par l’interface. Ce que cela prouve : la file est une fonction d’un état public. Personne ne choisit, et aucune position n’y figure que votre propre arithmétique ne saurait trouver. Ce que cela ne prouve pas : que la réduction du levier ne vous atteindra pas. Une file que vous savez calculer reste une file dans laquelle vous pouvez être.

​
4 · Un paiement de financement

Ce qu’il vous faut : le carnet d’ordres et l’indice certifié du tour de règlement, plus votre position. Le taux se construit en trois temps sur Financement — une prime pondérée par la profondeur, mise à l’échelle de l’intervalle du marché, puis bornée : P=max⁡(0,  acheteur pondeˊreˊ−indice)  −  max⁡(0,  indice−vendeur pondeˊreˊ)indiceP = \frac{\max(0,\; \text{acheteur pondéré} - \text{indice}) \;-\; \max(0,\; \text{indice} - \text{vendeur pondéré})}{\text{indice}} F=F8h×intervalle en secondes28,800Ffinal=clamp⁡ ⁣(F,  Fmin⁡,  Fmax⁡)F = F_{8h} \times \frac{\text{intervalle en secondes}}{28{,}800} \qquad F_{\text{final}} = \operatorname{clamp}\!\left(F,\; F_{\min},\; F_{\max}\right) Puis le prélèvement lui-même : paiement de financement=taille de la position×prix de marquage×taux de financement\text{paiement de financement} = \text{taille de la position} \times \text{prix de marquage} \times \text{taux de financement} Le carnet vient du groupe Markets, l’indice certifié d’Oracle, et le paiement réellement effectué par le protocole du point de terminaison des paiements de financement dans le groupe Accounts. Recalculez et comparez. Ce que cela prouve : le taux a été dérivé du carnet et de l’indice, il n’a pas été fixé par un opérateur. Ce que cela ne prouve pas : que l’indice était juste. Voir ce que l’oracle garantit et ne garantit pas.

​
5 · Un bloc, octet par octet

Ce qu’il vous faut : un nœud complet à vous. N’importe qui peut en faire tourner un — voir Faire tourner un nœud.
C’est le seul contrôle de cette page qui n’est pas disponible aujourd’hui. Le réseau est sur un testnet privé jusqu’à l’ouverture de l’accès public : les quatre premiers se font dès maintenant, celui-ci deviendra exécutable à ce moment-là. Il figure ici parce que les quatre autres ne valent que ce que vaut celui-ci.
C’est le contrôle sur lequel reposent les quatre autres. Prenez un bloc validé et son état antérieur, exécutez-le, et comparez votre résultat à celui du réseau. Le déterminisme est ici imposé et non espéré : le chemin d’exécution ne lit ni horloge, ni entropie d’exécution, ni virgule flottante, ni ordre d’itération randomisé par hachage — une divergence est donc un défaut, pas une tolérance. Voir Pourquoi le résultat est reproductible. Deux propriétés en font un vrai test plutôt qu’une cérémonie. L’ordonnancement est un objet validé par le consensus : la séquence que vous rejouez est celle qu’un quorum a signée, pas celle que votre nœud a déduite. Et les prix sont validés par les mêmes signatures, si bien qu’il n’existe aucune fenêtre où vous pourriez rejouer contre un prix que le réseau n’a pas certifié. Ce que cela prouve : que l’état qui vous est servi a été produit par les règles telles que publiées, sur des entrées que le réseau a validées. Ce que cela ne prouve pas : que les règles sont exemptes de défauts. Reproduire un bogue à l’identique, c’est encore reproduire un bogue — d’où l’existence, à côté de ceci, des audits et du bug bounty.

​
Ce que rien de tout cela ne couvre

La vérification borne ce qu’il faut prendre pour argent comptant ; elle ne l’élimine pas. Ce qui reste — l’ensemble des validateurs, le quorum de prix, la portée de la gouvernance sur les paramètres, et le bridge — est énuméré sur Hypothèses de confiance. Lisez cette page ensuite si vous êtes venu chercher les limites plutôt que les garanties.

​
Pour aller plus loin

Hypothèses de confiance

Ce qui subsiste une fois vérifié tout ce qui est vérifiable.

Faire tourner un nœud

Matériel, synchronisation, et ce qu’un validateur exécute réellement.

IntentionKernel

Les quatre clôtures qui donnent un sens au rejeu.

Référence de l'API

Le détail au niveau des champs pour chaque entrée citée ci-dessus.