Ein einzelner BTC verlässt von Anfang bis Ende nicht Bitcoin — doch Aave kann ihn als Sicherheit behandeln und verleihen. Noch unüblichere gegen den gängigen Konsens ist: In der Mitte gibt es nicht einmal ein handelbares „Shadow BTC“.
Ich habe die Integration von Aave v4 mit der @BabylonLabs_io einmal von vorn bis hinten durchgeprüft und festgestellt, dass der Adapter eher wie ein Übersetzer ist, der zwei Sprachen beherrscht. Beim Peg-in gelangt das native BTC in den Taproot Vault auf Bitcoin; nach der Aktivierung stellt der AaveAdapter für den Nutzer ein Position Proxy bereit. Dabei werden interne Sicherheiten im Verhältnis 1:1, präzise bis auf Satoshi, anhand der BTC-Menge erstellt und an den Babylon Core Spoke übergeben.
Diese Aufzeichnung nutzt eine ERC-20-ähnliche Schnittstelle, nur damit Aave den Sicherungswert lesen kann. Sie gelangt nicht in die Wallet des Nutzers, kann nicht an normale Adressen übertragen werden und besitzt keinen Sekundärmarkt. Das echte BTC bleibt weiterhin in den ursprünglichen UTXOs. Auf der Ethereum-Seite wird lediglich erfasst, wie viel Sicherheiten diese Vault für welche Position bereitstellt.
Der Borrow-Befehl geht vom Adapter in das Proxy und den Core Spoke, und holt dann Assets aus dem Aave v4 Hub heraus. Die Rückzahlung läuft in umgekehrter Richtung zurück in den Hub. In dem derzeit öffentlichen Testnetz sind USDC, USDT und WBTC allesamt simulierte Coins ohne echten Wert. Nach dem Erlöschen der Schuld zieht der Nutzer den Vault zurück, die Sicherheiten-Aufzeichnung wird geschlossen, und auf Bitcoin-Seite werden Beweise, Challenges und Payout gestartet.
Das heißt: Es ist nicht so, dass BTC in Aave „hineingebracht“ wird, sondern dass zwei Ledger rund um denselben Sicherungszustand miteinander abgeglichen werden. Aave kann das native BTC nicht anfassen, aber die Kette fügt den Adapter, das Proxy, den Spoke und die Orakel hinzu. Die Kryptografie schützt den BTC-Exit — ob Kreditaufnahme und -vergabe korrekt funktionieren, hängt weiterhin von den App-Verträgen und den Risk-Control-Parametern ab.
Nach dem Go-live im Mainnet sollte man vor allem verifizieren, nicht nur ob Geld ausgeliehen werden kann, sondern ob dieser „Übersetzer“ in hohem Durchsatz und extremen Marktphasen womöglich eine entscheidende Aussage falsch überträgt. #baby $BABY
Ich habe die Integration von Aave v4 mit der @BabylonLabs_io einmal von vorn bis hinten durchgeprüft und festgestellt, dass der Adapter eher wie ein Übersetzer ist, der zwei Sprachen beherrscht. Beim Peg-in gelangt das native BTC in den Taproot Vault auf Bitcoin; nach der Aktivierung stellt der AaveAdapter für den Nutzer ein Position Proxy bereit. Dabei werden interne Sicherheiten im Verhältnis 1:1, präzise bis auf Satoshi, anhand der BTC-Menge erstellt und an den Babylon Core Spoke übergeben.
Diese Aufzeichnung nutzt eine ERC-20-ähnliche Schnittstelle, nur damit Aave den Sicherungswert lesen kann. Sie gelangt nicht in die Wallet des Nutzers, kann nicht an normale Adressen übertragen werden und besitzt keinen Sekundärmarkt. Das echte BTC bleibt weiterhin in den ursprünglichen UTXOs. Auf der Ethereum-Seite wird lediglich erfasst, wie viel Sicherheiten diese Vault für welche Position bereitstellt.
Der Borrow-Befehl geht vom Adapter in das Proxy und den Core Spoke, und holt dann Assets aus dem Aave v4 Hub heraus. Die Rückzahlung läuft in umgekehrter Richtung zurück in den Hub. In dem derzeit öffentlichen Testnetz sind USDC, USDT und WBTC allesamt simulierte Coins ohne echten Wert. Nach dem Erlöschen der Schuld zieht der Nutzer den Vault zurück, die Sicherheiten-Aufzeichnung wird geschlossen, und auf Bitcoin-Seite werden Beweise, Challenges und Payout gestartet.
Das heißt: Es ist nicht so, dass BTC in Aave „hineingebracht“ wird, sondern dass zwei Ledger rund um denselben Sicherungszustand miteinander abgeglichen werden. Aave kann das native BTC nicht anfassen, aber die Kette fügt den Adapter, das Proxy, den Spoke und die Orakel hinzu. Die Kryptografie schützt den BTC-Exit — ob Kreditaufnahme und -vergabe korrekt funktionieren, hängt weiterhin von den App-Verträgen und den Risk-Control-Parametern ab.
Nach dem Go-live im Mainnet sollte man vor allem verifizieren, nicht nur ob Geld ausgeliehen werden kann, sondern ob dieser „Übersetzer“ in hohem Durchsatz und extremen Marktphasen womöglich eine entscheidende Aussage falsch überträgt. #baby $BABY