News
Stellar Development Foundation veröffentlicht verbindliche Sicherheitsstandards für DeFi-Protokolle
Von KryptoRatgeber · veröffentlicht 27. Juli 2026
Die Stellar Development Foundation (SDF) hat einen Katalog mit Sicherheits- und Risikostandards für dezentrale Finanzprotokolle auf der Stellar-Blockchain veröffentlicht. Das Dokument, verfasst von SDF-Mitarbeiter Justin Rice, richtet sich an Protokoll-Entwickler im Stellar-Ökosystem — und kommt zu einem Zeitpunkt, an dem die dortigen DeFi-Anwendungen nach eigenen Angaben der SDF bereits hunderte Millionen Dollar an Nutzergeldern verwalten. Für deutsche Nutzer und Entwickler, die Stellar-DeFi nutzen oder aufbauen wollen, liefert das Dokument erstmals einen konkreten Maßstab dafür, was die Stiftung als professionelle Mindestsicherheit erwartet.
Fünf Prozent Puffer, öffentliche Audits, 48-Stunden-Meldepflicht: Die SDF-Empfehlungen im Detail
Das Dokument, abrufbar im Stellar Development Foundation Blog (Stellar), gliedert die Empfehlungen in mehrere konkrete Bereiche:
Kapitalreserven: Als Richtwert nennt die SDF einen Puffer von rund fünf Prozent der nutzerseitigen Verbindlichkeiten — also der Gelder, für die ein Protokoll gegenüber seinen Nutzern haftet. Bei einem Protokoll mit 100 Millionen Dollar in dieser Größenordnung entspräche das etwa fünf Millionen Dollar in liquiden Mitteln, die als Verlustpuffer bereitstehen sollen.
Sicherheitsaudits: Bevor ein Protokoll nennenswerte Nutzerfonds annimmt, soll eine unabhängige Drittfirma den Code geprüft haben. Der vollständige Bericht — einschließlich aller gefundenen Schwachstellen und deren Behebungsstatus — soll öffentlich einsehbar sein. Die SDF betont dabei, dass die Häufigkeit von Folgeaudits von der Änderungsrate des Codes abhängt, nicht von einem fixen Kalenderrhythmus.
Bug-Bounty-Programme: Die Prämie für kritische Sicherheitsfunde soll laut SDF im Verhältnis zum möglichen Schaden eines Angriffs wettbewerbsfähig sein — sodass ein Forscher einen echten Anreiz hat, die Lücke zu melden statt auszunutzen.
Transparenz und Reaktionszeit: Protokolle sollen eine öffentlich zugängliche „Risk Page" führen, die Audit-Historie, bekannte Risiken und externe Abhängigkeiten auflistet. Nach einem entdeckten Sicherheitsvorfall empfiehlt die SDF einen vorläufigen Bericht innerhalb von rund 48 Stunden. Ergänzend fordert die Stiftung sogenannte Timelocks — zeitliche Verzögerungen bei nicht dringenden Systemänderungen — sowie Multisig-Kontrolle mit geografisch verteilten Unterzeichnern, um einzelne Ausfallpunkte zu vermeiden.
Empfehlung statt Pflicht — was das Dokument wirklich wert ist
Wer die Überschrift liest, könnte meinen, Stellar-DeFi-Protokolle müssten diese Standards ab sofort einhalten. Das stimmt nicht. Die SDF ist eine gemeinnützige Stiftung, kein Gesetzgeber. Ihre Vorgaben sind Empfehlungen — weder rechtlich durchsetzbar noch von einer unabhängigen Aufsichtsbehörde kontrolliert. Ein Protokoll, das die Checkliste ignoriert, riskiert allenfalls Reputationsschaden im Ökosystem, aber keine Sanktion.
Das schmälert den praktischen Nutzen trotzdem nicht zwingend — wenn man die Perspektive wechselt. Für deutsche Nutzer, die überlegen, einem Stellar-DeFi-Protokoll Geld anzuvertrauen, funktioniert das Dokument wie eine öffentliche Erwartungsliste: Gibt es einen vollständig veröffentlichten Auditbericht? Ist ein Bug-Bounty-Programm aktiv und ausreichend dotiert? Existiert eine Risk Page mit bekannten Abhängigkeiten? Wer diese Fragen an ein Protokoll stellt und keine befriedigenden Antworten bekommt, hat damit bereits eine belastbare Information.
Bemerkenswert ist auch der Hinweis der SDF auf KI-gestützte Angriffe: Wer einen Auditbericht veröffentlicht, in dem Schwachstellen nicht vollständig behoben wurden, liefert potenziellen Angreifern heute eine verwertbare Angriffsfläche — automatisiert und skalierbar. Das ist ein struktureller Druck, der über Stellar hinausgeht und das gesamte DeFi-Ökosystem betrifft.
Was das Dokument nicht leistet: Es löst das Grundproblem nicht, dass Nutzer kaum prüfen können, ob ein Protokoll die Empfehlungen tatsächlich umsetzt — oder nur vorgibt, es zu tun.
Wenn Nutzergelder wachsen, wächst die Verantwortung
DeFi — kurz für Decentralized Finance, also dezentrale Finanzanwendungen — bezeichnet Plattformen, die klassische Bankdienstleistungen wie Verleihen, Tauschen oder Verzinsen ohne traditionelle Mittelsleute direkt auf einer Blockchain abwickeln. Die Regeln sind dabei in sogenannten Smart Contracts festgeschrieben: automatisch ausführbare Programme, die niemand nachträglich einfach abschalten kann.
Genau das macht Smart-Contract-Audits so wichtig: Weil Fehler im Code nicht mal eben korrigiert werden können, solange Nutzergelder drin stecken, prüfen unabhängige Sicherheitsfirmen den Quellcode vorab auf Schwachstellen.
Stellar ist eine Blockchain, die ursprünglich vor allem auf internationale Zahlungen ausgerichtet war. In den vergangenen Jahren ist dort auch ein DeFi-Ökosystem gewachsen — mit Anwendungen, die Nutzern das Tauschen von Token oder das Bereitstellen von Liquidität ermöglichen. Je mehr echtes Geld in solche Protokolle fließt, desto attraktiver werden sie als Angriffsziel — und desto dringlicher wird die Frage, welche Sicherheitsstandards gelten.
Häufige Fragen
Sind diese Sicherheitsstandards für Stellar-Protokolle verpflichtend?
Nein. Das SDF-Dokument enthält Empfehlungen, keine rechtlich durchsetzbaren Vorschriften. Die Stellar Development Foundation ist eine gemeinnützige Stiftung, keine Aufsichtsbehörde. Protokolle können die Standards ignorieren — allerdings macht die SDF damit deutlich, was sie künftig als Mindestmaß professioneller Sicherheit erwartet. Für Nutzer ist das dennoch praktisch relevant: Die Empfehlungen bieten einen Maßstab, anhand dessen sie einzelne Protokolle kritisch einschätzen können.
Warum muss der vollständige Auditbericht öffentlich sein — inklusive aller gefundenen Lücken?
Laut SDF sollen Auditberichte vollständig veröffentlicht werden, einschließlich der gefundenen Schwachstellen und deren Behebungsstatus. Der Grund: Angreifer setzen bereits KI-gestützte Werkzeuge ein, um veröffentlichte Berichte und offenen Quellcode systematisch auf unvollständig behobene Lücken zu durchsuchen. Ein Bericht, der nur ein „bestanden" vermerkt, ohne den Behebungsstand offenzulegen, schützt Nutzer nicht — er verbirgt lediglich, ob gefundene Probleme tatsächlich geschlossen wurden. Transparenz zwingt Protokolle also, Lücken wirklich zu beheben, nicht nur zu dokumentieren.