Le robot de liquidation n’a pas de ciseaux : il emporte tout le coffre d’un coup. En voyant @BabylonLabs_io comment le testnet actuel conçoit chaque Vault comme un UTXO indépendant, j’ai compris que le double Vault n’était pas une jolie option de dépôt, mais un moyen de granuler les pertes de liquidation.
Dans la DeFi classique, le collatéral peut être prélevé au prorata, mais une transaction Bitcoin ne peut dépenser qu’une sortie en entier. Supposons qu’une position contienne 0,4 BTC ; la liquidation n’a besoin de traiter qu’environ 0,25 BTC. Si les 0,4 BTC sont tous enfermés dans un seul Vault, le protocole ne peut pas en extraire 0,25 BTC ; il ne peut que mettre tout le Vault en liquidation. La valeur excédentaire ne disparaît pas magiquement : le mécanisme d’équité réduit d’abord la dette restante de l’utilisateur, puis, s’il reste un surplus, le restitue en WBTC. Mais « recevoir une compensation équivalente » et « conserver du BTC natif dans sa propre position » ne sont clairement pas la même chose.
C’est là que le double Vault devient vraiment utile. Selon les paramètres publics actuels du testnet, le facteur de collatéralisation est de 78 % et le facteur de santé cible de 1,24 ; la documentation estime qu’au moment où une position déclenche tout juste une liquidation, la quantité ciblée à prélever représente environ 62 % de la valeur en BTC. Portal classe d’abord le Vault sacrifiable le plus volumineux en fonction des paramètres en temps réel, puis place le BTC restant dans le Vault de protection ; le programme de liquidation vérifie les Vaults un par un à partir de la tête de liste, s’arrête dès que le premier suffit, et laisse le second dans la position.
Ce n’est donc pas une « arme miracle anti-liquidation », mais plutôt une porte étanche dans la cale : en cas de problème, il y a toujours des pertes, mais on essaie d’éviter qu’elles n’engloutissent tout le navire. Si le marché chute trop vite, si la taille du Vault sacrificiel est insuffisante ou si l’ordre est mal configuré, le système peut quand même continuer à prélever le Vault suivant ; et le ratio 62/38 n’est pas une formule permanente : après un changement de paramètres, il faut revoir la répartition indiquée par Portal.
Je préfère appeler cette conception une gestion de la granularité des pertes. Pour l’emprunteur, ce qu’il faut surveiller, au-delà du facteur de santé, c’est aussi la taille de ses Vaults et leur ordre. Seriez-vous prêt à accepter une gestion de position plus complexe pour préserver un second Vault de BTC natif ?
#baby $BABY
Dans la DeFi classique, le collatéral peut être prélevé au prorata, mais une transaction Bitcoin ne peut dépenser qu’une sortie en entier. Supposons qu’une position contienne 0,4 BTC ; la liquidation n’a besoin de traiter qu’environ 0,25 BTC. Si les 0,4 BTC sont tous enfermés dans un seul Vault, le protocole ne peut pas en extraire 0,25 BTC ; il ne peut que mettre tout le Vault en liquidation. La valeur excédentaire ne disparaît pas magiquement : le mécanisme d’équité réduit d’abord la dette restante de l’utilisateur, puis, s’il reste un surplus, le restitue en WBTC. Mais « recevoir une compensation équivalente » et « conserver du BTC natif dans sa propre position » ne sont clairement pas la même chose.
C’est là que le double Vault devient vraiment utile. Selon les paramètres publics actuels du testnet, le facteur de collatéralisation est de 78 % et le facteur de santé cible de 1,24 ; la documentation estime qu’au moment où une position déclenche tout juste une liquidation, la quantité ciblée à prélever représente environ 62 % de la valeur en BTC. Portal classe d’abord le Vault sacrifiable le plus volumineux en fonction des paramètres en temps réel, puis place le BTC restant dans le Vault de protection ; le programme de liquidation vérifie les Vaults un par un à partir de la tête de liste, s’arrête dès que le premier suffit, et laisse le second dans la position.
Ce n’est donc pas une « arme miracle anti-liquidation », mais plutôt une porte étanche dans la cale : en cas de problème, il y a toujours des pertes, mais on essaie d’éviter qu’elles n’engloutissent tout le navire. Si le marché chute trop vite, si la taille du Vault sacrificiel est insuffisante ou si l’ordre est mal configuré, le système peut quand même continuer à prélever le Vault suivant ; et le ratio 62/38 n’est pas une formule permanente : après un changement de paramètres, il faut revoir la répartition indiquée par Portal.
Je préfère appeler cette conception une gestion de la granularité des pertes. Pour l’emprunteur, ce qu’il faut surveiller, au-delà du facteur de santé, c’est aussi la taille de ses Vaults et leur ordre. Seriez-vous prêt à accepter une gestion de position plus complexe pour préserver un second Vault de BTC natif ?
#baby $BABY
