It's audited.

„Ist auditiert“ beendet mehr Diskussionen als jeder andere Satz in Krypto.

Er stimmt erstaunlich oft. Und er sagt viel weniger, als er klingt.

Das ist Teil zwei unserer Reihe „Safe, they said.“ Zehn Sätze, mit denen Projekte dich beruhigen, jede Woche einer. Hier ist der zweite, auseinandergenommen.

Was ein Audit ist, in einem Absatz

Ein Projekt bezahlt eine Sicherheitsfirma dafür, seinen Code zu lesen. Die Firma bekommt eine feste Fassung dieses Codes und eine feste Zeit. Sie sucht Fehler, schreibt sie mit einer Schwere auf, und das Projekt antwortet auf jeden. Das Ergebnis ist ein Bericht mit einem Datum.

Ein Audit ist also eine Aussage über eine Fassung eines Codes, zu einem Zeitpunkt, von Menschen, die etwas übersehen können. Ein guter Bericht sagt das selbst, meist gegen Ende.

Grenze eins: der Umfang

Der Bericht deckt ab, was die Firma bekommen hat. Meist sind das die Contracts. Meist nicht die Website, nicht die Server, nicht die Einstellungen, mit denen die Contracts laufen, und nicht die Schlüssel, die sie steuern.

„Auditiert“ ohne das Wort „was“ ist ein halber Satz.

Grenze zwei: das Datum

Code ändert sich. Ein Contract, der sich aktualisieren lässt, kann am Tag nach dem Bericht ersetzt werden. Dann beschreibt der Bericht etwas, das nicht mehr läuft.

Die Frage ist nicht „wurde es auditiert?“, sondern „ist das, was heute läuft, das, was gelesen wurde?“

Grenze drei: gefunden ist nicht behoben

Ein Bericht listet Funde, und neben jedem steht ein Status. „Resolved“ oder „fixed“ heißt: Der Fehler ist weg. „Acknowledged“ heißt: Das Projekt hat ihn gelesen und so gelassen. Mit beidem kann ein Projekt „auditiert“ sagen.

Grenze vier: die Schlüssel

Das ist die Grenze, die am meisten Geld kostet.

Am 1. April 2026 verlor ein großes Handelsprotokoll auf Solana rund 285 Millionen Dollar, nach der Zählung der Sicherheitsfirma Cyfrin. Cyfrin und das Protokoll selbst sagen beide: Es wurde kein Fehler in den Contracts ausgenutzt.

Die Admin-Rechte des Protokolls lagen bei einem Multisig, bei dem zwei von fünf Unterschriften genügten. Nach den vorläufigen Erkenntnissen des Protokolls haben Angreifer rund sechs Monate lang Vertrauen zu Mitwirkenden aufgebaut, persönlich, auf Konferenzen. Sie haben wahrscheinlich Geräte kompromittiert und Unterschriften für Transaktionen bekommen, deren wahren Inhalt die Unterzeichner nicht sehen konnten. Diese wurden zurückgehalten und später ausgeführt. Das Abräumen dauerte rund zwölf Minuten.

Kein Lesen des Codes hätte das finden können. Der Code tat genau das, was gültige Unterschriften ihm sagten.

Ein Audit prüft, ob das Schloss funktioniert. Es prüft nicht, wer die Schlüssel hält und wie sie geschützt sind.

So prüfst du es bei jedem Token

Dafür musst du keiner Website vertrauen, auch unserer nicht.

1. Such den Bericht auf der Seite des Auditors, nicht nur auf der des Projekts.
2. Vergleiche die Adresse oder die Code-Fassung im Bericht mit der, die heute benutzt wird.
3. Lies den Status jedes Fundes. Zähle „resolved“ und „acknowledged“ getrennt.
4. Lies den Umfang. Such, was nicht drinsteht: Admin-Schlüssel, Upgrades, die Bridge, die Website.
5. Frag, ob der Contract noch geändert werden kann, und von wem. Wenn ja, hat der Bericht ein Ablaufdatum, das niemand daraufgedruckt hat.

Wo SHIBC steht

Der Token-Contract von SHIBC wurde im Dezember 2024 von Hashlock auditiert. Der Bericht ist auf der Seite von Hashlock öffentlich. Die Bewertung ist „Secure“, mit einem Fund geringer Schwere, einem Gas-Hinweis und vier Qualitätshinweisen.

Alle sechs tragen den Status „Acknowledged“, nicht „Resolved“. Sie sind geringfügig. Die Eigentümerschaft des Contracts ist abgegeben, deshalb kann niemand seinen Code mehr ändern. Was der Auditor 2024 gelesen hat, läuft heute.

Hashlock hat eine höhere Bewertung für Projekte mit einem Bug-Bounty oder einer On-Chain-Überwachung. Beides ist geplant: ein Meldeprogramm mit veröffentlichtem Umfang und eine Überwachung.

Das Audit deckt den Token-Contract ab. Was darum herum gebaut wird, hat eigene Hürden vor dem Mainnet. Für die Bridge stehen sie in unserem Whitepaper, Abschnitt 7.6. Die Einzelheiten zum Audit stehen in Abschnitt 8.7.

Was wir daraus mitnehmen

Ein Audit ist ein Beleg, keine Garantie. Es beantwortet „ist dieser Code, was er vorgibt zu sein?“ Es beantwortet nicht „wer kann ihn ändern, und wer kann die Mittel bewegen?“

Unsere Sicht, wie ein Token geführt werden sollte: Sag, was gelesen wurde, von wem und wann. Sag, was so gelassen wurde. Und behandle die Schlüssel als die größere Frage, denn das sind sie.

Nächste Woche, Teil drei: „We have a multisig.“