J’ai suivi le flux réel du testnet TBV au lieu d’en lire simplement le fonctionnement, et je me suis retrouvé bloqué à une étape à laquelle je ne m’attendais pas : juste après le dépôt, l’application n’ouvre pas une seule voûte (vault). Elle recommande d’en créer deux : une voûte « sacrificielle », dimensionnée pour couvrir tout ce que le protocole s’attend à saisir en premier, et une voûte « protégée » qui contient le reste. La voûte sacrificielle est liquidée en premier, dans cet ordre, avant que la voûte protégée ne soit jamais touchée.
Ce n’est pas comme je supposais que la liquidation fonctionnait ici. Sur un marché Aave normal, la liquidation ne fait que consommer une tranche de votre position en collatéral unique, proportionnellement.
Ça m’a rappelé le fait de préparer un vol avec un bagage que vous êtes pleinement prêt à perdre. Vous ne répartissez pas vos objets de valeur de façon égale dans deux valises en espérant que tout se passe bien. Vous mettez ce que vous pouvez vous permettre de perdre dans celui qui part en soute, et vous gardez ce qui compte vraiment sur vous. TBV vous fait faire ça avec du BTC avant même d’avoir emprunté quoi que ce soit : vous décidez à l’avance ce qui est « expendable », de sorte que si quelque chose tourne mal, seul le « bagage en soute » soit pris.
Voici la partie qui m’a surpris : avec les paramètres actuels du testnet, la voûte sacrificielle est en fait la plus grande des deux, pas la plus petite. Le protocole ne vous demande pas de risquer un montant de jetons dès le départ — il vous demande de mettre un poids réel derrière le leurre (décoy).
Ça devient logique une fois qu’on réfléchit au « pourquoi ». Débloquer (unwinding) le BTC sur Bitcoin n’est pas instantané, contrairement à un appel de liquidation sur un EVM — il n’y a pas de façon propre de déboucler partiellement une voûte partagée au milieu d’une crise. Deux voûtes distinctes signifient que le protocole s’en va avec la plus petite, sans problème de liquidation partielle à gérer, et sans devoir se battre avec des délais de confirmation en plein milieu de la liquidation.
On dirait moins une gestion du risque et plus un séquençage du risque, décidé par le déposant plutôt que par le protocole.
Je me demande combien de personnes vont réellement dimensionner délibérément cette voûte sacrificielle, plutôt que d’accepter le split par défaut de l’application et de découvrir ce à quoi elles se sont engagées pendant leur première liquidation — est-ce un manque côté UX, ou est-ce que forcer la décision dès le départ est justement le but ?
@BabylonLabs_io $BABY #baby $KOMA $AKE
Ce n’est pas comme je supposais que la liquidation fonctionnait ici. Sur un marché Aave normal, la liquidation ne fait que consommer une tranche de votre position en collatéral unique, proportionnellement.
Ça m’a rappelé le fait de préparer un vol avec un bagage que vous êtes pleinement prêt à perdre. Vous ne répartissez pas vos objets de valeur de façon égale dans deux valises en espérant que tout se passe bien. Vous mettez ce que vous pouvez vous permettre de perdre dans celui qui part en soute, et vous gardez ce qui compte vraiment sur vous. TBV vous fait faire ça avec du BTC avant même d’avoir emprunté quoi que ce soit : vous décidez à l’avance ce qui est « expendable », de sorte que si quelque chose tourne mal, seul le « bagage en soute » soit pris.
Voici la partie qui m’a surpris : avec les paramètres actuels du testnet, la voûte sacrificielle est en fait la plus grande des deux, pas la plus petite. Le protocole ne vous demande pas de risquer un montant de jetons dès le départ — il vous demande de mettre un poids réel derrière le leurre (décoy).
Ça devient logique une fois qu’on réfléchit au « pourquoi ». Débloquer (unwinding) le BTC sur Bitcoin n’est pas instantané, contrairement à un appel de liquidation sur un EVM — il n’y a pas de façon propre de déboucler partiellement une voûte partagée au milieu d’une crise. Deux voûtes distinctes signifient que le protocole s’en va avec la plus petite, sans problème de liquidation partielle à gérer, et sans devoir se battre avec des délais de confirmation en plein milieu de la liquidation.
On dirait moins une gestion du risque et plus un séquençage du risque, décidé par le déposant plutôt que par le protocole.
Je me demande combien de personnes vont réellement dimensionner délibérément cette voûte sacrificielle, plutôt que d’accepter le split par défaut de l’application et de découvrir ce à quoi elles se sont engagées pendant leur première liquidation — est-ce un manque côté UX, ou est-ce que forcer la décision dès le départ est justement le but ?
@BabylonLabs_io $BABY #baby $KOMA $AKE
