Das Abwicklungs-Robotter hat keine Schere, es räumt einfach ganze Kisten weg. Als ich sah, dass das aktuelle Testnetz @BabylonLabs_io jedes Vault als eine eigenständige UTXO entwirft, wurde mir klar: Ein doppeltes Vault ist keine besonders hübsche Einlage-Option, sondern es zielt darauf ab, Verluste der Abwicklung in feinerem Granulat zu zerschneiden.
In normalem DeFi kann man Sicherheiten anteilig abtrennen, aber bei Bitcoin-Transaktionen kann man nur einen Output vollständig ausgeben. Nehmen wir an, eine Position enthält 0,4 BTC; für die Abwicklung muss nur etwa 0,25 BTC davon verarbeitet werden. Wenn jedoch 0,4 BTC komplett in ein einziges Vault gepackt sind, kann das Protokoll keine 0,25 BTC daraus „abschneiden“—es muss das gesamte Vault in die Abwicklung einbeziehen. Der „zu viel“ vorhandene Wert verschwindet dabei nicht einfach: Der faire Mechanismus reduziert zuerst die verbleibende Schuld des Nutzers; falls danach noch ein Rest übrig bleibt, wird dieser mit WBTC zurückerstattet. Aber „einen Gegenwert erhalten“ und „native BTC bleiben weiterhin in deiner eigenen Position“ sind offensichtlich nicht dasselbe.
Genau darin liegt der eigentliche Nutzen von zwei Vaults. Nach den Parametern des aktuellen öffentlich verfügbaren Testnetzes beträgt der Sicherheitenfaktor 78%, der Ziel-Health-Faktor 1,24. Die Dokumentation schätzt: Sobald die Position die Abwicklungsgrenze gerade erreicht, entspricht die Menge, die man als Ziel abgreift, etwa 62% des BTC-Werts. Portal ordnet anhand der aktuellen Parameter das größere Opfer-Vault zuerst ein; der verbleibende BTC-Teil wird in das Schutz-Vault gelegt. Der Abwicklungsprozess prüft die Liste der Reihe nach, Vault für Vault vom Listenanfang aus. Sobald das erste ausreicht, wird gestoppt; das zweite bleibt in der Position.
Daher ist es nicht wirklich ein „Anti-Abwicklungs-Wunderwerkzeug“, sondern eher wie eine Schott-Tür im Frachtraum: Es wird immer noch zu Verlusten kommen, aber man versucht, nicht den ganzen Schiffskörper zu verschlingen. Wenn der Markt zu schnell fällt, die Größe des Opfer-Vaults nicht ausreicht oder die Reihenfolge falsch ist, kann das System dennoch weiter das nächste Vault mitnehmen. Auch 62/38 ist keine dauerhafte Formel—nach Parameteränderungen muss man die Aufteilung, die Portal vorgibt, erneut neu betrachten.
Ich würde diese Gestaltung lieber „Management der Verlust-Granularität“ nennen. Worauf Kreditnehmer wirklich achten müssen, sind neben dem Health-Faktor auch die eigene Vault-Größe und die Anordnung. Würdest du eine komplexere Positionsverwaltung akzeptieren, um das zweite native BTC-Vault zu schützen?
#baby $BABY
In normalem DeFi kann man Sicherheiten anteilig abtrennen, aber bei Bitcoin-Transaktionen kann man nur einen Output vollständig ausgeben. Nehmen wir an, eine Position enthält 0,4 BTC; für die Abwicklung muss nur etwa 0,25 BTC davon verarbeitet werden. Wenn jedoch 0,4 BTC komplett in ein einziges Vault gepackt sind, kann das Protokoll keine 0,25 BTC daraus „abschneiden“—es muss das gesamte Vault in die Abwicklung einbeziehen. Der „zu viel“ vorhandene Wert verschwindet dabei nicht einfach: Der faire Mechanismus reduziert zuerst die verbleibende Schuld des Nutzers; falls danach noch ein Rest übrig bleibt, wird dieser mit WBTC zurückerstattet. Aber „einen Gegenwert erhalten“ und „native BTC bleiben weiterhin in deiner eigenen Position“ sind offensichtlich nicht dasselbe.
Genau darin liegt der eigentliche Nutzen von zwei Vaults. Nach den Parametern des aktuellen öffentlich verfügbaren Testnetzes beträgt der Sicherheitenfaktor 78%, der Ziel-Health-Faktor 1,24. Die Dokumentation schätzt: Sobald die Position die Abwicklungsgrenze gerade erreicht, entspricht die Menge, die man als Ziel abgreift, etwa 62% des BTC-Werts. Portal ordnet anhand der aktuellen Parameter das größere Opfer-Vault zuerst ein; der verbleibende BTC-Teil wird in das Schutz-Vault gelegt. Der Abwicklungsprozess prüft die Liste der Reihe nach, Vault für Vault vom Listenanfang aus. Sobald das erste ausreicht, wird gestoppt; das zweite bleibt in der Position.
Daher ist es nicht wirklich ein „Anti-Abwicklungs-Wunderwerkzeug“, sondern eher wie eine Schott-Tür im Frachtraum: Es wird immer noch zu Verlusten kommen, aber man versucht, nicht den ganzen Schiffskörper zu verschlingen. Wenn der Markt zu schnell fällt, die Größe des Opfer-Vaults nicht ausreicht oder die Reihenfolge falsch ist, kann das System dennoch weiter das nächste Vault mitnehmen. Auch 62/38 ist keine dauerhafte Formel—nach Parameteränderungen muss man die Aufteilung, die Portal vorgibt, erneut neu betrachten.
Ich würde diese Gestaltung lieber „Management der Verlust-Granularität“ nennen. Worauf Kreditnehmer wirklich achten müssen, sind neben dem Health-Faktor auch die eigene Vault-Größe und die Anordnung. Würdest du eine komplexere Positionsverwaltung akzeptieren, um das zweite native BTC-Vault zu schützen?
#baby $BABY