Derzeit ist im öffentlichen Testnetz nur eine registrierte Anwendung verfügbar: Aave v4. Diese Tatsache reicht zwar aus, um zu verstehen, wie eine Vault App-gebunden wird, sie trägt jedoch nicht aus, um eine ganze Vision mit mehreren Anwendungen zu stützen. Die Trustless Bitcoin Vaults (TBV) von @BabylonLabs_io fixieren die Anwendungsbeziehung bereits bei der Erstellung des Vaults; danach kann derselbe Vault nicht direkt auf eine andere Anwendung migriert werden. Der klare Rahmen hat den Vorteil, dass sich der Sicherungsstatus, die Berechtigungen und die Verantwortlichkeiten nicht willkürlich zwischen verschiedenen Integrationen verschieben. Der Preis dafür ist ebenfalls sehr direkt: Nutzer verlieren die Flexibilität, während des Betriebs frei die Anwendung zu wechseln.
Bis hierher ist das, was sich eindeutig bestätigen lässt, bereits vollständig. Der bestehende Aave-Vault kann nicht so beschrieben werden, dass er künftig per Ein-Klick auf Stablecoins, Versicherungen oder andere Szenarien umgeschaltet werden kann. Ebenso lässt sich nicht im Voraus behaupten, dass die neue Anwendung zwingend aus wie vielen Bitcoin-Transaktionen bestehen wird, wie hoch die Kosten sind oder wie viele Wiederherstellungsunterlagen nötig sein werden. Die zweite Anwendung ist noch nicht live; wie genau der Anschluss und der Ausstieg funktionieren, sind bislang keine verifizierbaren Tatsachen.
Für alle, die einen Vault erstellen wollen, ist die derzeit nützlichste Einschätzung daher nicht, zukünftige Auswahlmöglichkeiten vorherzusagen, sondern anzuerkennen, dass die Bindung an eine Anwendung eine Vorentscheidung ist. Wenn man Aave v4 wählt, ist die Zugehörigkeit dieser Vault-Anwendung bereits bei der Erstellung festgelegt—danach kann man die Bindung nicht direkt umstellen. Diese Einschränkung bringt eine klarere Trennung der Anwendungen mit sich und verlangt von den Nutzern, vor dem Aufbau ihrer Position noch einen Schritt weiterzudenken. Für Verantwortliche im institutionellen Finanzmanagement beeinflusst die Wahl der Anwendung außerdem interne Berechtigungen und die Ausstiegsplanung—sie darf nicht als jederzeit änderbare Präferenz behandelt werden.
Diese Art von Zurückhaltung ist für den Inhalt von #baby wichtig. Über die Ausrichtung der Plattform kann man diskutieren, doch der aktuelle Stand muss dort enden, wo es die Evidenz zulässt.
Die Anzahl der Anwendungen, die noch nicht existieren, im Voraus in die Erzählung von $BABY zu schreiben, hat keine faktische Bedeutung. Erst wenn eine neue Integration tatsächlich aufschlägt, gibt es verifizierbare Fakten darüber, wie man aussteigt, neu aufbaut, wer wofür verantwortlich ist und welche Kosten anfallen. Wenn künftig neue Anwendungen hinzukommen, müssen deren neue Kosten und die zusätzliche verwaltungstechnische Last durch die dann vorhandenen Dokumente und On-Chain-Pfade belegt werden. Was sich jetzt sicher sagen lässt, ist: Es ist nicht migrierbar. Was sich jetzt nicht sicher sagen lässt, ist: Wie sich das Zeitalter mit mehreren Anwendungen konkret entwickeln wird. Erst wenn man beides trennt, beantwortet man nicht Visionen mit Realität.
Bis hierher ist das, was sich eindeutig bestätigen lässt, bereits vollständig. Der bestehende Aave-Vault kann nicht so beschrieben werden, dass er künftig per Ein-Klick auf Stablecoins, Versicherungen oder andere Szenarien umgeschaltet werden kann. Ebenso lässt sich nicht im Voraus behaupten, dass die neue Anwendung zwingend aus wie vielen Bitcoin-Transaktionen bestehen wird, wie hoch die Kosten sind oder wie viele Wiederherstellungsunterlagen nötig sein werden. Die zweite Anwendung ist noch nicht live; wie genau der Anschluss und der Ausstieg funktionieren, sind bislang keine verifizierbaren Tatsachen.
Für alle, die einen Vault erstellen wollen, ist die derzeit nützlichste Einschätzung daher nicht, zukünftige Auswahlmöglichkeiten vorherzusagen, sondern anzuerkennen, dass die Bindung an eine Anwendung eine Vorentscheidung ist. Wenn man Aave v4 wählt, ist die Zugehörigkeit dieser Vault-Anwendung bereits bei der Erstellung festgelegt—danach kann man die Bindung nicht direkt umstellen. Diese Einschränkung bringt eine klarere Trennung der Anwendungen mit sich und verlangt von den Nutzern, vor dem Aufbau ihrer Position noch einen Schritt weiterzudenken. Für Verantwortliche im institutionellen Finanzmanagement beeinflusst die Wahl der Anwendung außerdem interne Berechtigungen und die Ausstiegsplanung—sie darf nicht als jederzeit änderbare Präferenz behandelt werden.
Diese Art von Zurückhaltung ist für den Inhalt von #baby wichtig. Über die Ausrichtung der Plattform kann man diskutieren, doch der aktuelle Stand muss dort enden, wo es die Evidenz zulässt.
Die Anzahl der Anwendungen, die noch nicht existieren, im Voraus in die Erzählung von $BABY zu schreiben, hat keine faktische Bedeutung. Erst wenn eine neue Integration tatsächlich aufschlägt, gibt es verifizierbare Fakten darüber, wie man aussteigt, neu aufbaut, wer wofür verantwortlich ist und welche Kosten anfallen. Wenn künftig neue Anwendungen hinzukommen, müssen deren neue Kosten und die zusätzliche verwaltungstechnische Last durch die dann vorhandenen Dokumente und On-Chain-Pfade belegt werden. Was sich jetzt sicher sagen lässt, ist: Es ist nicht migrierbar. Was sich jetzt nicht sicher sagen lässt, ist: Wie sich das Zeitalter mit mehreren Anwendungen konkret entwickeln wird. Erst wenn man beides trennt, beantwortet man nicht Visionen mit Realität.