Einmal habe ich TBV falsch verstanden und dachte, es sei ähnlich wie viele „On-Chain-Tresor“-Produkte: BTC wird in einen großen Pool geworfen, gemeinsam betrieben, und über einheitliche Protokoll-Logik werden Gelder koordiniert, um Renditen zu erzielen. Später habe ich mir die Doku zur @BabylonLabs_io genau angesehen und gemerkt, dass es überhaupt nicht so ist. Dieses Missverständnis hätte beinahe meine Einschätzung der eigenen Position beeinflusst – und es hat mir auch klar gemacht, dass ich bei solchen Produkten zuvor eine Art blinden Fleck in meinem Verständnis hatte.
In TBV werden die BTC jedes einzelnen Nutzers über eigene, von ihm erstellte Bitcoin-Skripte separat in Verwahrung genommen. Das ist eine völlig andere Architektur als das „Fonds-/Pool-Modell“, bei dem Vermögenswerte vermischt werden und das Protokoll sie zentral koordiniert. Der Unterschied dieser beiden Definitionen wird in der offiziellen Dokumentation tatsächlich ausdrücklich getrennt: Die eine Variante ist, dass jede Person einen eigenen, unabhängigen „Safe“ hat; die andere ist, dass alle ihr Geld in einen gemeinsamen Pool geben und das Protokoll Strategien darauf ausführt. Das Risiko des Pool-Modells liegt darin, dass im Fall eines Problems in der Protokoll-Logik oder bei einem Angriff alle Vermögenswerte gemeinsam betroffen sein können. In der Vergangenheit sind bei vielen DeFi-Tresor-Produkten, wenn es zu Zwischenfällen kam, häufig alle Pool-Teilnehmer gemeinsam für den Verlust eingestanden. Bei TBV mit dieser isolierenden (segregierten) Konstruktion ist es theoretisch so, dass der gesperrte Zustand des einzelnen Nutzers unabhängig von den anderen Teilnehmern ist. Selbst wenn bei einem konkreten Schritt etwas schiefgeht, kommt es nicht in der gleichen Weise zu „Kettenreaktionen“, wie es beim Pool-Ansatz der Fall wäre.
Nachdem ich diesen Unterschied einmal wirklich verstanden hatte, habe ich mir die Integrationslogik von TBV erneut im Detail angesehen – zusammen mit Aave und Gomining. Diese externen Protokolle greifen im Grunde eine Funktion auf Ebene der Verwahrungs-/Sperr-Belegschicht zu: Nutzer nehmen den Beleg, der aus dem gesperrten BTC erzeugt wurde, um an Kreditgeschäften oder der Verteilung von Mining-Erträgen teilzunehmen. Stattdessen werden die zugrunde liegenden BTC-Fonds nicht einfach an das externe Protokoll übergeben, sodass dieses sie frei verwalten bzw. beliebig disponieren könnte. Das bedeutet, dass mein anfänglicher Eindruck vom Risiko zu hoch war: Das Risiko-Exposure ist vermutlich etwas geringer. Selbst wenn es bei Aave an irgendeiner Stelle zu extremen Situationen im Kreditgeschäft käme, sollte vor allem die Logik auf der Ebene der Belege und der Kreditvergabe betroffen sein – die Sicherheitsgrenze der zugrunde liegenden BTC-Sperre ist theoretisch relativ unabhängig. Natürlich ist das nur meine Interpretation auf Basis der Dokumentation. Ob es in der realen Code-Implementierung oder historisch tatsächlich zu solchen Grenzfällen gekommen ist, muss noch durch mehr Auditberichte und On-Chain-Daten verifiziert werden.
Diese Fehlannahme erinnert mich außerdem daran, dass ich vor der Bewertung solcher Projekte zuerst die Architektur der Basis-Assets und die Pfade der Risikoübertragung genau klären sollte. Das ist deutlich wichtiger, als Marketing-Claims zu hören oder einfach „trustless“ und ähnliche Etiketten naiv anzuwenden #baby $BABY
In TBV werden die BTC jedes einzelnen Nutzers über eigene, von ihm erstellte Bitcoin-Skripte separat in Verwahrung genommen. Das ist eine völlig andere Architektur als das „Fonds-/Pool-Modell“, bei dem Vermögenswerte vermischt werden und das Protokoll sie zentral koordiniert. Der Unterschied dieser beiden Definitionen wird in der offiziellen Dokumentation tatsächlich ausdrücklich getrennt: Die eine Variante ist, dass jede Person einen eigenen, unabhängigen „Safe“ hat; die andere ist, dass alle ihr Geld in einen gemeinsamen Pool geben und das Protokoll Strategien darauf ausführt. Das Risiko des Pool-Modells liegt darin, dass im Fall eines Problems in der Protokoll-Logik oder bei einem Angriff alle Vermögenswerte gemeinsam betroffen sein können. In der Vergangenheit sind bei vielen DeFi-Tresor-Produkten, wenn es zu Zwischenfällen kam, häufig alle Pool-Teilnehmer gemeinsam für den Verlust eingestanden. Bei TBV mit dieser isolierenden (segregierten) Konstruktion ist es theoretisch so, dass der gesperrte Zustand des einzelnen Nutzers unabhängig von den anderen Teilnehmern ist. Selbst wenn bei einem konkreten Schritt etwas schiefgeht, kommt es nicht in der gleichen Weise zu „Kettenreaktionen“, wie es beim Pool-Ansatz der Fall wäre.
Nachdem ich diesen Unterschied einmal wirklich verstanden hatte, habe ich mir die Integrationslogik von TBV erneut im Detail angesehen – zusammen mit Aave und Gomining. Diese externen Protokolle greifen im Grunde eine Funktion auf Ebene der Verwahrungs-/Sperr-Belegschicht zu: Nutzer nehmen den Beleg, der aus dem gesperrten BTC erzeugt wurde, um an Kreditgeschäften oder der Verteilung von Mining-Erträgen teilzunehmen. Stattdessen werden die zugrunde liegenden BTC-Fonds nicht einfach an das externe Protokoll übergeben, sodass dieses sie frei verwalten bzw. beliebig disponieren könnte. Das bedeutet, dass mein anfänglicher Eindruck vom Risiko zu hoch war: Das Risiko-Exposure ist vermutlich etwas geringer. Selbst wenn es bei Aave an irgendeiner Stelle zu extremen Situationen im Kreditgeschäft käme, sollte vor allem die Logik auf der Ebene der Belege und der Kreditvergabe betroffen sein – die Sicherheitsgrenze der zugrunde liegenden BTC-Sperre ist theoretisch relativ unabhängig. Natürlich ist das nur meine Interpretation auf Basis der Dokumentation. Ob es in der realen Code-Implementierung oder historisch tatsächlich zu solchen Grenzfällen gekommen ist, muss noch durch mehr Auditberichte und On-Chain-Daten verifiziert werden.
Diese Fehlannahme erinnert mich außerdem daran, dass ich vor der Bewertung solcher Projekte zuerst die Architektur der Basis-Assets und die Pfade der Risikoübertragung genau klären sollte. Das ist deutlich wichtiger, als Marketing-Claims zu hören oder einfach „trustless“ und ähnliche Etiketten naiv anzuwenden #baby $BABY