Publié
Every perp exchange I've built a liquidation calculator for so far shares one design: breach maintenance margin on a position, and that position closes. All of it, usually with a penalty on top. BULK's perpetual DEX, which leaned hard into "portfolio-wide risk management" as its pitch this year, does something different — it computes the smallest amount of notional it needs to trim, anywhere in the account, to get equity back above the maintenance requirement, and stops there. I built a calculator around that mechanism and ran two portfolios through it to see exactly how much smaller "smallest amount" actually is, and where it stops being small.
Cas 1 : la brèche légère — 10,53% fermée, 89,47% survit
Compte : une position longue sur BTC de 60 000 $ ( effet de levier 15x, marge affichée de 4 000 $ ) en baisse de 5 %, passant d'une entrée de 60 000 $ à 57 000 $ , et une position longue sur ETH de 40 000 $ ( également 15x, marge affichée de 2 666,67 $ ) en baisse de 2 %, passant de 3 000 $ à 2 940 $ . Les deux portent un taux de maintenance de 3 %. Total des garanties comptabilisées : 6 666,67 $ . Perte nette latente : - 3 800,00 $ ( 3 000 $ sur BTC, 800 $ sur ETH). Capitaux propres du compte : 2 866,67 $ . Besoin total de maintenance : 1 800 $ ( BTC) + 1 200 $ ( ETH) = 3 000,00 $. Ratio de santé : 2 866,67 ÷ 3 000 = 0,9556x — en dessous du minimum de 1,0x, les déclencheurs de liquidation.
Un échange de liquidation complète ferme la totalité de la position en BTC de 60 000 $ ici (c'est celui qui a violé), ou dans certains modèles, l'ensemble du compte de 100 000 $ . Le moteur de coupe de cheveux cible plutôt un rapport restauré de 1,02x : M_target = 2,866.67 ÷ 1.02 = $2,810.46, il faut donc qu'il perde 3,000 − 2,810.46 = $189.54 de l'exigence de maintenance. Étant donné que le taux de maintenance de BTC est de 3 %, c'est 189.54 ÷ 0.03 = $6,318.08 de BTC notionnel — 10,53% du poste. Les 89,47 % restants de BTC restent ouverts. La position de l'ETH, le plus petit perdant, n'est pas touchée du tout.
Cas 2 : la violation grave — la position « gagnante » est également supprimée
Même forme, moins bons chiffres. Une position longue de 100 000 $ sur le BTC (20x, marge de 5 000 $ ) chute de 8 %, passant de 60 000 $ à 55 200 $ , perdant 8 000 $ . Une position longue ETH de 50 000 $ ( 20x, marge de 2 500 $ ) gagne en fait 2 %, en hausse de 1 000 $ . Garantie : 7 500 $ . PnL net : - 7 000 $ . Capitaux propres : 500,00 $ . Exigence de maintenance : 2 500 $ ( BTC) + 1 250 $ ( ETH) = 3 750,00 $Ratio santé 0,1333x — une violation grave, pas marginale.
Cibler un besoin de ratio restauré de 1,05x M_target = 500 ÷ 1.05 = $476.19, un manque à gagner de 3,750 − 476.19 = $3,273.81 à perdre. La capacité totale de maintenance requise de BTC n'est que de 2 500 $ ( sa position entière), de sorte que le moteur se ferme 100 % de la position de 100 000 $ BTC — prend la totalité des 2 500 $ — et a toujours $773.81 du manque à gagner restant. Il passe ensuite à ETH, la seule capacité restante, et ferme 773.81 ÷ 0.025 = $30,952.38 Pas vraiment. 61,90 % d'une position rentable au début de la liquidation. Total notionnel clôturé sur l'ensemble du compte : 130 952,38 $ — 130,95 % de la position initiale du BTC à elle seule, soit environ 87 % du compte combiné initial de 150 000 $ .
| Scénario | Ratio santé | BTC fermé | ETH closed | Total notionnel fermé |
|---|---|---|---|---|
| Cas 1 — léger | 0,9556x | 10,53 % (6 318,08 $ ) | 0% | 6 318,08 $ |
| Case 2 — severe | 0,1333x | 100 % (100 000 $ ) | 61,90 % (30 952,38 $ ) | 130 952,38 $ |
La partie qui n'est pas intuitive : le perdant se ferme en premier, toujours
The engine I modeled works worst-loss-first — it fully exhausts the maintenance-requirement capacity of the biggest loser before touching anything else. That's why ETH survives untouched in Case 1 despite also being a loser: BTC alone had enough capacity ($1,800 of requirement, more than the $189.54 needed) to cover the shortfall. It's also why ETH gets cut in Case 2 even though it was profitable at the moment of liquidation — BTC's entire $2,500 of capacity wasn't enough, and closing notional reduces the maintenance requirement by notional × maintenance_rate indépendamment du fait que ce notionnel appartienne à une transaction gagnante ou perdante. Une position rentable dans le même compte n'est pas protégée contre un déficit grave, suffisamment important ailleurs dans le portefeuille.
Le seul cas où aucun de ces calculs n'aide : l'équité à zéro ou en dessous de zéro avant le début de toute coupe. Les deux scénarios ci-dessus avaient des capitaux propres positifs (2 866,67 $ et 500,00 $ ) — le mécanisme de coupe de cheveux ne fonctionne que dans la gamme où il y a encore quelque chose à restaurer. En dessous de zéro, il s'agit d'une insolvabilité pure et simple, et l'ensemble du compte fonctionne, exactement comme un échange de liquidation complète. Exécutez votre propre compte à deux positions en utilisant le même calcul de la pire perte d'abord sur le calculateur de liquidation partielle de marge de portefeuille — il montre la même table de cascade d'où proviennent ces deux cas, avec vos propres chiffres.