Zum Inhalt springen

DeFi

Dezentralisierte Finanzen (DeFi) bezeichnen eine Gruppe blockchainbasierter Protokolle, die mithilfe von Smart Contracts Dienste wie Handel, Kreditvergabe, Kreditaufnahme und Vermögensverwaltung anbieten. Dieser Leitfaden erklärt, wie DeFi funktioniert, warum Komponierbarkeit wichtig ist, wie Hebelwirkung durch viel beachtete Kennzahlen verschleiert werden kann und welche technischen, marktbezogenen, Governance- und Nutzerrisiken sorgfältig geprüft werden müssen.

Aktualisiert

Nur zu Bildungszwecken; keine Anlageberatung. Anlagen können zu Verlusten führen.

Direkte Antwort

Dezentralisierte Finanzen (DeFi) sind ein weit gefasster Bereich von Anwendungen, die Blockchains, digitale Vermögenswerte und Smart Contracts nutzen, um Finanzfunktionen bereitzustellen. Typische Beispiele sind dezentrale Börsen, überbesicherte Kreditmärkte, Derivate, Zahlungen und automatisierte Vermögensverwaltungsstrategien.

DeFi soll die Abhängigkeit von traditionellen Intermediären verringern, beseitigt jedoch weder Vermittlung noch Vertrauen. Nutzer können weiterhin von Entwicklern, Governance-Abstimmenden, Administratoren, Oracle-Betreibern, Anbietern von Benutzeroberflächen, Stablecoin-Emittenten, Bridges und der zugrunde liegenden Blockchain abhängig sein. Entscheidend ist daher nicht nur, ob ein Protokoll „dezentralisiert“ ist, sondern wer es ändern oder pausieren, kritische Daten bereitstellen oder den Zugangsweg eines Nutzers kontrollieren kann.

Typische DeFi-Systeme bestehen aus vier Ebenen:

  • Eine Blockchain zeichnet Transaktionen auf und setzt Zustandsänderungen durch.
  • Digitale Vermögenswerte bilden die Einheiten, die übertragen, gehandelt oder als Sicherheit hinterlegt werden.
  • Smart-Contract-Protokolle legen Regeln für Märkte, Verwahrung, Zinssätze und Liquidationen im Code fest.
  • Wallets und Anwendungsoberflächen ermöglichen es Nutzern, Transaktionen zu signieren und diese Protokolle aufzurufen.

Der Zugang kann auf der Vertragsebene genehmigungsfrei sein, während Websites, Schnittstellen zwischen Fiatgeld und Kryptowerten oder bestimmte Rechtsordnungen weiterhin Beschränkungen unterliegen.

Funktionsweise

  1. Der Nutzer erteilt eine Anweisung. Eine Wallet zeigt eine Transaktion oder Signaturanfrage an. Der Nutzer kann einen Vermögenswert übertragen, einem Vertrag die Ausgabe eines Tokens genehmigen oder eine Protokollfunktion aufrufen.

  2. Das Protokoll wendet die einprogrammierten Regeln an. Validatoren führen die Transaktion aus, und der Smart Contract aktualisiert Guthaben nur, wenn seine Bedingungen erfüllt sind. Ein Kreditprotokoll kann beispielsweise Zinsen berechnen, Besicherungsgrenzen prüfen und eine Liquidation auslösen, ohne dass ein Kreditsachbearbeiter jede Aktion genehmigt.

  3. Externe Abhängigkeiten liefern fehlende Eingaben. Viele Verträge benötigen Preis-Oracles, Stablecoins, Bridges, Frontends, Keeper oder Governance-Entscheidungen. Diese Abhängigkeiten bringen Vertrauensannahmen und Ausfallwege mit sich, die am Hauptvertrag allein nicht erkennbar sind.

  4. Komponierbarkeit verbindet Protokolle miteinander. Ein von einem Protokoll ausgegebener Token kann in einem anderen als Sicherheit oder Liquidität dienen. Dadurch lassen sich neue Produkte schnell zusammenstellen, doch ein Ausfall eines Vermögenswerts oder Protokolls kann sich auf jede davon abhängige Position ausbreiten.

Die Abwicklung auf einer Blockchain ist grundsätzlich endgültig und kann nicht von einer Kundenservicestelle rückgängig gemacht werden. Öffentlich einsehbarer Code und Transaktionsdaten können die Transparenz verbessern, doch Transparenz ist nicht gleichbedeutend mit Sicherheit: Nutzer benötigen weiterhin Fachwissen und geeignete Werkzeuge, um Code, Berechtigungen, Rechnungslegung und Marktpositionen zu beurteilen.

Beispiel

Angenommen, ein Nutzer hinterlegt ETH im Wert von $20,000 in einem Kreditprotokoll und leiht sich 14,000 USDC. Die anfängliche Beleihungsquote beträgt 70%, berechnet mit LTV = V_debt / V_collateral. Anschließend hinterlegt der Nutzer die geliehenen 14,000 USDC in einem anderen Protokoll.

Die Übersichten der beiden Protokolle können nun zusammen bereitgestellte Vermögenswerte von $34,000 ausweisen, obwohl der Nutzer zugleich 14,000 USDC schuldet. Vor Gebühren, Zinsen und Preisänderungen beträgt sein Nettovermögen weiterhin $20,000; das zusätzliche Bruttoengagement entstand durch Hebelwirkung, nicht durch neues Vermögen.

Wenn der Wert der ETH-Sicherheit auf $16,000 fällt und die Verbindlichkeit bei 14,000 USDC bleibt, steigt die Beleihungsquote auf 87.5%. Je nach Liquidationsschwelle des Protokolls kann die Position liquidiert werden, wobei eine Vertragsstrafe und Ausführungskosten anfallen. Überlastung, geringe Liquidität, verzögerte Oracle-Daten oder eine Aufhebung der USDC-Dollarbindung können das tatsächliche Ergebnis verschlechtern.

Deshalb sollte der Total Value Locked (TVL) nicht als Nettokapital, Solvenz oder Sicherheit interpretiert werden. Bei der Analyse eines Protokolls sollten auch Nettoeinlagen, Auslastung, Konzentration der Sicherheiten, Liquidationsparameter, der Umgang mit notleidenden Forderungen, durch Anreize finanzierte Renditen, Administratorrechte und die verfügbare Ausstiegsliquidität untersucht werden.

Risiken

  • Smart-Contract- und Upgrade-Risiko. Code kann Fehler enthalten, und ein Upgrade-Mechanismus oder ein kompromittierter Administratorschlüssel kann ein ansonsten geprüftes Verhalten verändern.
  • Markt-, Hebel- und Liquidationsrisiko. Volatile Sicherheiten, konzentrierte Positionen oder automatische Liquidationen können aus einer Preisbewegung schnell einen Verlust machen und Marktstress verstärken.
  • Oracle- und Abhängigkeitsrisiko. Falsche, verzögerte oder manipulierte Daten können nachteilige Geschäfte oder Liquidationen auslösen; Stablecoins, Bridges und eingebundene Protokolle können ihre eigenen Ausfälle übertragen.
  • Liquiditäts- und Rücknahmerisiko. Ein ausgewiesenes Guthaben oder eine angegebene Rendite garantiert nicht, dass eine Position zum angezeigten Preis aufgelöst werden kann, insbesondere bei Überlastung oder einem Ansturm auf Rücknahmen.
  • Governance- und Betriebsrisiko. Stimmrechte können konzentriert sein, Notfallbefugnisse können missbraucht werden und Frontends oder Keeper können ausfallen, obwohl die Kernverträge weiterlaufen.
  • Wallet-, Genehmigungs- und Betrugsrisiko. Phishing, bösartige Signaturanfragen, unbegrenzte Token-Genehmigungen, gefälschte Vermögenswerte und verlorene Schlüssel können ohne einen Angriff auf das Protokoll zu irreversiblen Verlusten führen.

Je nach Tätigkeit und Rechtsordnung können zudem rechtliche, steuerliche, sanktionsbezogene, offenlegungsrechtliche oder verbraucherschutzrechtliche Folgen entstehen. Ein genehmigungsfreier Zugang macht eine Transaktion nicht überall rechtmäßig und bietet nach einem Verlust keinen garantierten Rechtsbehelf.

Häufige Irrtümer

Mythos 1: Dezentralisiert bedeutet, dass niemand etwas kontrolliert

Kontrolle kann auf mehreren Ebenen liegen. Prüfen Sie Upgrade-Schlüssel, Pausenfunktionen, die Konzentration der Governance, die Auswahl der Oracles, das Hosting des Frontends und die Kontrolle über Protokolleinnahmen, anstatt sich auf eine Bezeichnung zu verlassen.

Mythos 2: Der effektive Jahreszins ist eine garantierte Rendite

Kreditnachfrage, Auslastung, Token-Anreize und Vermögenspreise verändern sich. Ein angezeigter effektiver Jahreszins kann Gasgebühren, sonstige Gebühren, Slippage, vorübergehende Verluste, Liquidationsverluste, Steuern und die Möglichkeit eines Wertverlusts der Prämien außer Acht lassen.

Mythos 3: Ein höherer TVL bedeutet ein sichereres Protokoll

Der TVL kann steigen, weil Vermögenspreise zugelegt haben, Anreize kurzfristige Einlagen angezogen haben oder dasselbe Kapital protokollübergreifend wiederverwendet wurde. Er misst weder Codequalität und Solvenz noch die Qualität der Governance oder tatsächlich verfügbare Ausstiegsliquidität.

Mythos 4: Ein Audit macht ein Protokoll sicher

Ein Audit bezieht sich auf eine bestimmte Codeversion, einen festgelegten Prüfumfang und einen bestimmten Zeitpunkt. Es kann weder beweisen, dass jeder Fehler gefunden wurde, noch vor späteren Upgrades, Mängeln im ökonomischen Design, kompromittierten Schlüsseln, Oracle-Vorfällen oder Ausfällen eingebundener Protokolle schützen.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...