Ich bin immer wieder an einem Detail in Babylons Aave-V4-Vorschlag hängen geblieben: Liquidation löst tatsächlich keinen Bitcoin ein. Es sieht nur so aus.
Wenn eine mit BTC besicherte Position liquidiert wird, tauscht ein permissionless Liquidator die beschlagnahmte Vault-Position gegen WBTC zu einem kleinen Aufschlag und begleicht so die Schulden des Borrowers auf Ethereum sofort. Aber der echte Bitcoin hat sich noch nicht irgendwohin bewegt.
Eine separate Gruppe von Arbitrageuren kauft anschließend die escrowed Vault, erstattet das WBTC zurück und erst danach löst sie den nativen BTC auf der eigenen Bitcoin-Chain ein, sobald das Fraud-Proof-„Challenge“-Fenster abgelaufen ist. Zwei verschiedene Akteure, zwei verschiedene Zeitpläne, ein einziges Liquidationsereignis.
Was mich interessiert, ist, warum diese Aufteilung überhaupt existiert: Bitcoin kann nicht in Ethereum-Geschwindigkeit abwickeln, also musste das Protokoll „die Schuld wird zurückgezahlt“ von „BTC wechselt tatsächlich den Besitzer“ trennen. Das ist eine nachvollziehbare Umgehung für eine echte Einschränkung, aber es bedeutet auch, dass der Liquidator, der WBTC-Exposure übernimmt, eine Einlösung finanziert, deren Timing er nicht kontrolliert. Schnelle Abwicklung für die eine Partei, Timing-Risiko der nativen Chain still und leise an eine andere weitergereicht.
Noch niemand preist diese Lücke ein, weil die Funktion noch gar nicht ausgeliefert wurde—das ist immer noch ein Temp Check im Forum von Aave. Aber das Mechanismus-Design ist das Interessante, nicht die Ankündigung.
„Liquidation in zwei Zeitlinien aufzuteilen beseitigt die Verzögerung nicht, es entscheidet nur, wer dafür warten muss.“
@BabylonLabs_io #baby $BABY $1000SATS $HOME
Wer soll Babylons BTC-Liquidationsverzögerung tragen?
Wenn eine mit BTC besicherte Position liquidiert wird, tauscht ein permissionless Liquidator die beschlagnahmte Vault-Position gegen WBTC zu einem kleinen Aufschlag und begleicht so die Schulden des Borrowers auf Ethereum sofort. Aber der echte Bitcoin hat sich noch nicht irgendwohin bewegt.
Eine separate Gruppe von Arbitrageuren kauft anschließend die escrowed Vault, erstattet das WBTC zurück und erst danach löst sie den nativen BTC auf der eigenen Bitcoin-Chain ein, sobald das Fraud-Proof-„Challenge“-Fenster abgelaufen ist. Zwei verschiedene Akteure, zwei verschiedene Zeitpläne, ein einziges Liquidationsereignis.
Was mich interessiert, ist, warum diese Aufteilung überhaupt existiert: Bitcoin kann nicht in Ethereum-Geschwindigkeit abwickeln, also musste das Protokoll „die Schuld wird zurückgezahlt“ von „BTC wechselt tatsächlich den Besitzer“ trennen. Das ist eine nachvollziehbare Umgehung für eine echte Einschränkung, aber es bedeutet auch, dass der Liquidator, der WBTC-Exposure übernimmt, eine Einlösung finanziert, deren Timing er nicht kontrolliert. Schnelle Abwicklung für die eine Partei, Timing-Risiko der nativen Chain still und leise an eine andere weitergereicht.
Noch niemand preist diese Lücke ein, weil die Funktion noch gar nicht ausgeliefert wurde—das ist immer noch ein Temp Check im Forum von Aave. Aber das Mechanismus-Design ist das Interessante, nicht die Ankündigung.
„Liquidation in zwei Zeitlinien aufzuteilen beseitigt die Verzögerung nicht, es entscheidet nur, wer dafür warten muss.“
@BabylonLabs_io #baby $BABY $1000SATS $HOME
Wer soll Babylons BTC-Liquidationsverzögerung tragen?
Liquidator
60%
Arbitrageur
40%
Split via premium
0%
Bad design
0%
5 Stimmen • Abstimmung beendet