Ich bin in einem Cross-Chain-Bridge-Shared-Pool auf die Schnauze gefallen – andere Benutzer haben durch ihre Handlungen Liquidationsschritte ausgelöst und mir einen Teil meiner Position mitgenommen. Es war nicht viel Geld, aber dieses Gefühl von „Die Probleme anderer kaufe ich mit“ werde ich bis heute nicht los.
Seitdem frage ich bei jedem BTC-zu-DeFi-Plan zuerst: Gibt es im System etwas, das das Risiko dort bei „anderen“ einkapselt und nicht zu mir herüberlaufen lässt?
Als ich die Babylon-Dokumentation durchging, bin ich auf etwas namens ApplicationRegistry gestoßen. Das ist ein Smart Contract auf Ethereum, der speziell DeFi-Anwendungen registriert, die durch Governance genehmigt wurden und ein Treasury annehmen dürfen. Neue Anwendungen müssen erst einen Governance-Audit-Prozess durchlaufen und zusätzlich ihren eigenen Adapter-Contract bereitstellen. Derzeit ist nur der Aave v4 Adapter registriert. Man kann sich also nicht einfach „anschließen“.
Meine erste Reaktion war: Ach, eine Whitelist – man will verhindern, dass schlechte Projekte reinkommen.
Beim zweiten Lesen habe ich dann eine Details übersehen, die mir aufgefallen ist: Die ApplicationRegistry bindet nicht „die Anwendung“, sondern „den Adapter-Contract, der zur Anwendung gehört“. Nach der Registrierung werden die Regeln eingefroren; sie werden nicht heimlich angepasst, ohne dass du es mitbekommst.
Da hat es bei mir erst klick gemacht – ich dachte vorher, es gehe nur darum, „wer reindarf“, aber in Wahrheit macht es „die Regeln festzuschweißen“. Wenn bei Aave etwas schiefgeht, betrifft das nur den Aave-Adapter. Wenn bei GoMining etwas schiefgeht, betrifft das nur den GoMining-Adapter. Dein BTC-Treasury ist von der Anwendung entkoppelt; Störungen auf Anwendungsebene können nicht auf die Asset-Ebene übergreifen.
Dieses Design-Gefühl kann ich nachvollziehen. Der Preis ist aber auch ziemlich klar: Jede neue Anwendung muss durch den Governance-Prozess, wodurch sich die Ausbaurate im Vergleich zu Lösungen, bei denen „jeder sich einfach anschließen kann“, deutlich verlangsamt.
Was mich allerdings zurückhaltend macht, ist die Effizienz des „Zulassungssystems“ im großen Maßstab: Wenn Dutzende Anwendungen anstehen, kann die Governance-Rhythmik dann stabil bleiben? Ich sehe aktuell noch nicht genug belastbare Testdaten aus der Praxis.
Aber eine Sache hat sich bei mir tatsächlich geändert: Früher fand ich „Risiko isolieren“ ziemlich abstrakt – die ApplicationRegistry hat mir aber eine konkrete Vorgehensweise gezeigt: Jede Anwendung wird zu einem eigenen Steckmodul, ein falscher Steckversuch verbrennt nur den betreffenden Teil, nicht gleich das ganze Haus.
Findest du dieses Design eher „langsam“ oder eher „stabil“?
$BABY @BabylonLabs_io #baby
Seitdem frage ich bei jedem BTC-zu-DeFi-Plan zuerst: Gibt es im System etwas, das das Risiko dort bei „anderen“ einkapselt und nicht zu mir herüberlaufen lässt?
Als ich die Babylon-Dokumentation durchging, bin ich auf etwas namens ApplicationRegistry gestoßen. Das ist ein Smart Contract auf Ethereum, der speziell DeFi-Anwendungen registriert, die durch Governance genehmigt wurden und ein Treasury annehmen dürfen. Neue Anwendungen müssen erst einen Governance-Audit-Prozess durchlaufen und zusätzlich ihren eigenen Adapter-Contract bereitstellen. Derzeit ist nur der Aave v4 Adapter registriert. Man kann sich also nicht einfach „anschließen“.
Meine erste Reaktion war: Ach, eine Whitelist – man will verhindern, dass schlechte Projekte reinkommen.
Beim zweiten Lesen habe ich dann eine Details übersehen, die mir aufgefallen ist: Die ApplicationRegistry bindet nicht „die Anwendung“, sondern „den Adapter-Contract, der zur Anwendung gehört“. Nach der Registrierung werden die Regeln eingefroren; sie werden nicht heimlich angepasst, ohne dass du es mitbekommst.
Da hat es bei mir erst klick gemacht – ich dachte vorher, es gehe nur darum, „wer reindarf“, aber in Wahrheit macht es „die Regeln festzuschweißen“. Wenn bei Aave etwas schiefgeht, betrifft das nur den Aave-Adapter. Wenn bei GoMining etwas schiefgeht, betrifft das nur den GoMining-Adapter. Dein BTC-Treasury ist von der Anwendung entkoppelt; Störungen auf Anwendungsebene können nicht auf die Asset-Ebene übergreifen.
Dieses Design-Gefühl kann ich nachvollziehen. Der Preis ist aber auch ziemlich klar: Jede neue Anwendung muss durch den Governance-Prozess, wodurch sich die Ausbaurate im Vergleich zu Lösungen, bei denen „jeder sich einfach anschließen kann“, deutlich verlangsamt.
Was mich allerdings zurückhaltend macht, ist die Effizienz des „Zulassungssystems“ im großen Maßstab: Wenn Dutzende Anwendungen anstehen, kann die Governance-Rhythmik dann stabil bleiben? Ich sehe aktuell noch nicht genug belastbare Testdaten aus der Praxis.
Aber eine Sache hat sich bei mir tatsächlich geändert: Früher fand ich „Risiko isolieren“ ziemlich abstrakt – die ApplicationRegistry hat mir aber eine konkrete Vorgehensweise gezeigt: Jede Anwendung wird zu einem eigenen Steckmodul, ein falscher Steckversuch verbrennt nur den betreffenden Teil, nicht gleich das ganze Haus.
Findest du dieses Design eher „langsam“ oder eher „stabil“?
$BABY @BabylonLabs_io #baby