Ich höre: „Die Coins aus der Verpfändung kann man noch verpfänden und für Kredite nutzen“, und meine erste Reaktion ist: Lässt sich diese Rechnung irgendwie glattziehen? Auf der einen Seite ist die Verpfändung: Die Coins sind im Script gesperrt und erwirtschaften Rendite. Auf der anderen Seite ist die Verpfändung für den Kredit: Die Coins müssen dem Kredit-Position als Sicherheit dienen. Dieselben Coins machen zwei Dinge gleichzeitig – irgendwie fühlt es sich an, als ob man auf demselben Grundstück zwei verschiedene Kulturen anbaut, und die Ernten würden sich gegenseitig stören.
Nachdem ich das Whitepaper @BabylonLabs_io durchgeblättert habe, stelle ich fest, dass die Buchhaltung so funktioniert: Der Treasury (Kabinett/„Vault“) hat drei Auszahlungsbedingungen – Rückredeem (Rücknahme), Liquidation und der Abzug/„Slashing“ bei einem Double-Sign. Die Verpfändungsrendite und die Kredit-Sicherheiten sind nicht „gleichzeitig mit genau diesen Coins“ im Einsatz, sondern „alle drei Schicksale dieser Coins sind per Script fest verdrahtet“. Solange der Preis die Schwelle nicht unterschreitet, kannst du zurücknehmen und zurückzahlen; wenn der Preis unter die Schwelle fällt, hat der Liquidator das Recht, die Coins zu verwerten; und wenn die Übeltäter mit Double-Sign handeln, wird die Slashing-Regel ausgelöst. Die drei Bedingungen greifen unabhängig voneinander – jede hat ihre eigene Trigger-Logik.
Das wirklich kontraintuitive daran ist Folgendes: In herkömmlichen Krediten ist das Sicherheiten-Asset nach dem Sperren nicht mehr beweglich. TBV bringt jedoch die Sicherheit in die Verpfändung ein – der Trick besteht darin, die Regel „wer darf diese Coins verwenden“ vorab eindeutig im Code festzulegen. Die drei Bedingungen entsprechen drei Pfaden; diese Pfade überlappen sich nicht. Welcher Pfad zuerst triggert und damit wirksam wird – das ist keine „zwei Grundstücke zusammenlegen und doppelt bepflanzen“, sondern „die Grundstücksurkunde in drei Teile zerlegen“ und das Script erzwingt die Ausführung; es braucht keinen menschlichen Schiedsrichter. Die Rechnung wird nicht eingespart, sie wird aufgeteilt: Jeder Rolle ist klar zugewiesen, wie viel sie wann bekommt – das Script hat das bereits vorbereitet.
Aber um es ehrlich zu sagen: Das ist der Design-Blueprint aus dem Whitepaper; das Testnetz ist noch nicht vollständig verifiziert. Ich habe das Dokument ein paar Mal gelesen, und ich finde keinen Eintrag wie „staked Treasury im Test erfolgreich“ – die drei Bedingungen sind zwar sehr klar beschrieben, aber der Abschnitt „Verifizierungsstatus“ ist nach wie vor leer. Also halte ich in meinem Buch fest: Mechanik funktioniert nach Design, Verifizierungsstatus steht noch aus.
Die Richtung der Kapital-Effizienz ist grundsätzlich richtig – aber „Design ist gültig“ und „läuft durch in der Praxis“ sind zwei verschiedene Dinge. $BABY zu den entsprechenden Projekten, die sich mit dem neuen Mechanismus beschäftigen: Erst die Grundlagen trennen – ist das nur auf Papier gezeichnet oder läuft es bereits auf der Kette? Wenn du diese Rechnung sauber auseinanderhältst, wirst du nicht von der Erzählung in die Irre geführt. #baby
Nachdem ich das Whitepaper @BabylonLabs_io durchgeblättert habe, stelle ich fest, dass die Buchhaltung so funktioniert: Der Treasury (Kabinett/„Vault“) hat drei Auszahlungsbedingungen – Rückredeem (Rücknahme), Liquidation und der Abzug/„Slashing“ bei einem Double-Sign. Die Verpfändungsrendite und die Kredit-Sicherheiten sind nicht „gleichzeitig mit genau diesen Coins“ im Einsatz, sondern „alle drei Schicksale dieser Coins sind per Script fest verdrahtet“. Solange der Preis die Schwelle nicht unterschreitet, kannst du zurücknehmen und zurückzahlen; wenn der Preis unter die Schwelle fällt, hat der Liquidator das Recht, die Coins zu verwerten; und wenn die Übeltäter mit Double-Sign handeln, wird die Slashing-Regel ausgelöst. Die drei Bedingungen greifen unabhängig voneinander – jede hat ihre eigene Trigger-Logik.
Das wirklich kontraintuitive daran ist Folgendes: In herkömmlichen Krediten ist das Sicherheiten-Asset nach dem Sperren nicht mehr beweglich. TBV bringt jedoch die Sicherheit in die Verpfändung ein – der Trick besteht darin, die Regel „wer darf diese Coins verwenden“ vorab eindeutig im Code festzulegen. Die drei Bedingungen entsprechen drei Pfaden; diese Pfade überlappen sich nicht. Welcher Pfad zuerst triggert und damit wirksam wird – das ist keine „zwei Grundstücke zusammenlegen und doppelt bepflanzen“, sondern „die Grundstücksurkunde in drei Teile zerlegen“ und das Script erzwingt die Ausführung; es braucht keinen menschlichen Schiedsrichter. Die Rechnung wird nicht eingespart, sie wird aufgeteilt: Jeder Rolle ist klar zugewiesen, wie viel sie wann bekommt – das Script hat das bereits vorbereitet.
Aber um es ehrlich zu sagen: Das ist der Design-Blueprint aus dem Whitepaper; das Testnetz ist noch nicht vollständig verifiziert. Ich habe das Dokument ein paar Mal gelesen, und ich finde keinen Eintrag wie „staked Treasury im Test erfolgreich“ – die drei Bedingungen sind zwar sehr klar beschrieben, aber der Abschnitt „Verifizierungsstatus“ ist nach wie vor leer. Also halte ich in meinem Buch fest: Mechanik funktioniert nach Design, Verifizierungsstatus steht noch aus.
Die Richtung der Kapital-Effizienz ist grundsätzlich richtig – aber „Design ist gültig“ und „läuft durch in der Praxis“ sind zwei verschiedene Dinge. $BABY zu den entsprechenden Projekten, die sich mit dem neuen Mechanismus beschäftigen: Erst die Grundlagen trennen – ist das nur auf Papier gezeichnet oder läuft es bereits auf der Kette? Wenn du diese Rechnung sauber auseinanderhältst, wirst du nicht von der Erzählung in die Irre geführt. #baby