$ICNT $BLESS
ich starre es an, aber es ist nicht einmal Liquidation selbst.
Es ist vielmehr diese Vault-Order innerhalb der Babylon Aave v4 Position, die sich still zur Loss-Order entwickeln kann. Der Health Factor fällt unter 1, und der Babylon Core Spoke berechnet, wie viel an Sicherheiten liquidiert werden muss.
saubere Zahl.
aber interessiert Bitcoin, wie sauber diese Zahl ist?
eher nicht.
eine Babylon Trustless Bitcoin Vault ist immer noch genau eine vollständige Taproot-Vault-UTXO. Die Bitcoin-Basisschicht kann nicht einfach die Hälfte davon freigeben, nur weil der Ethereum-seitige Fehlbetrag als eine nette Fraktion herausgekommen ist. Daher beginnt der Babylon-Liquidationsablauf bei der vorderen Position der vom Einzahler sortierten Vault-Liste und nimmt vollständige Vaults, bis das Liquidationsziel abgedeckt ist.
anscheinend war diese kleine Neuordnung nie nur kosmetisch.
sie hat bereits die Liquidationspriorität festgelegt.
vielleicht ist die erste Vault absichtlich kleiner und opfernd platziert, damit die größere geschützte Vault überleben kann.
klingt kontrolliert genug.
aber was, wenn die opfernde Vault nicht ausreicht? dann nimmt Babylon auch die nächste vollständige Vault. „Aave berechnet den Fehlbetrag. Bitcoin antwortet in ganzen UTXOs.“
der Schuldbetrag bleibt präzise.
der Verlust kommt immer noch in Babylon-Vault-großen Blöcken an, geformt durch eine früher getroffene Ordnungsentscheidung – vermutlich zu einem Zeitpunkt, als der Health Factor komplett in Ordnung aussah. Und das ist der Teil, der sich in meinem Kopf ein bisschen falsch anfühlt.
weil das Liquidationsereignis später kommt. aber die Reihenfolge des Schadens lag schon da, bevor irgendetwas kaputt wirkte. also: Wann begann das Liquidationsrisiko tatsächlich auf Babylon?
als der Health Factor unter 1 fiel?
oder als ich still eine Bitcoin-Vault platziert habe, die als Erstes dran wäre?
@BabylonLabs_io $BABY #baby
ich starre es an, aber es ist nicht einmal Liquidation selbst.
Es ist vielmehr diese Vault-Order innerhalb der Babylon Aave v4 Position, die sich still zur Loss-Order entwickeln kann. Der Health Factor fällt unter 1, und der Babylon Core Spoke berechnet, wie viel an Sicherheiten liquidiert werden muss.
saubere Zahl.
aber interessiert Bitcoin, wie sauber diese Zahl ist?
eher nicht.
eine Babylon Trustless Bitcoin Vault ist immer noch genau eine vollständige Taproot-Vault-UTXO. Die Bitcoin-Basisschicht kann nicht einfach die Hälfte davon freigeben, nur weil der Ethereum-seitige Fehlbetrag als eine nette Fraktion herausgekommen ist. Daher beginnt der Babylon-Liquidationsablauf bei der vorderen Position der vom Einzahler sortierten Vault-Liste und nimmt vollständige Vaults, bis das Liquidationsziel abgedeckt ist.
anscheinend war diese kleine Neuordnung nie nur kosmetisch.
sie hat bereits die Liquidationspriorität festgelegt.
vielleicht ist die erste Vault absichtlich kleiner und opfernd platziert, damit die größere geschützte Vault überleben kann.
klingt kontrolliert genug.
aber was, wenn die opfernde Vault nicht ausreicht? dann nimmt Babylon auch die nächste vollständige Vault. „Aave berechnet den Fehlbetrag. Bitcoin antwortet in ganzen UTXOs.“
der Schuldbetrag bleibt präzise.
der Verlust kommt immer noch in Babylon-Vault-großen Blöcken an, geformt durch eine früher getroffene Ordnungsentscheidung – vermutlich zu einem Zeitpunkt, als der Health Factor komplett in Ordnung aussah. Und das ist der Teil, der sich in meinem Kopf ein bisschen falsch anfühlt.
weil das Liquidationsereignis später kommt. aber die Reihenfolge des Schadens lag schon da, bevor irgendetwas kaputt wirkte. also: Wann begann das Liquidationsrisiko tatsächlich auf Babylon?
als der Health Factor unter 1 fiel?
oder als ich still eine Bitcoin-Vault platziert habe, die als Erstes dran wäre?
@BabylonLabs_io $BABY #baby
