Die kurze Antwort
Verifizierung belegt, dass der veröffentlichte Quellcode zu dem auf der Chain liegenden Bytecode kompiliert. Über die Redlichkeit dieses Codes sagt sie nichts. Prüfen Sie vor dem Signieren: ob der Vertrag verifiziert ist, ob er auf die Implementierung zeigt, die Sie erwarten, welche Rechte sein Eigentümer hat und welche Erlaubnis Sie gerade erteilen.
Was Verifizierung tatsächlich belegt
Ein auf Ethereum oder einer beliebigen EVM-Chain veröffentlichter Vertrag ist Bytecode. Deterministisch, im Grundsatz prüfbar und in der Praxis unlesbar.
Verifizierung ist der Vorgang, den ursprünglichen Solidity- oder Vyper-Quellcode einzureichen, samt der genauen Compiler-Version und den Optimierungseinstellungen, damit jeder neu kompilieren und bestätigen kann, dass das Ergebnis dem Bytecode auf der Chain entspricht. Etherscan führt diese Prüfung durch und veröffentlicht den Quellcode.
Belegt wird damit etwas Schmales und zugleich Wichtiges: Der Code, den Sie lesen, ist der Code, der laufen wird. Das schließt aus, dass ein Projekt das eine veröffentlicht und das andere ausgerollt hat — eine reale und historisch verbreitete Betrugsform.
Nicht belegt wird, dass der Code irgendetwas Vernünftiges tut. Ein verifizierter Vertrag kann eine unbegrenzte Mint-Funktion enthalten, einen Eigentümer, der alle Übertragungen anhalten kann, eine Gebühr, die sich auf hundert Prozent anheben lässt, oder eine Funktion, die sämtliche Token aller Halter an eine einzige Adresse überträgt. All das ist tadellos verifizierbar und tadellos feindselig.
So ist „auf Etherscan verifiziert" ökosystemweit zur ersten Sicherheitsfrage geworden, gestellt von Menschen, die nie Solidity gelesen haben — und sie beantwortet eine erheblich engere Frage, als diese glauben. Sie ist eine Voraussetzung dafür, einen Vertrag zu beurteilen, und nicht das Urteil.
Proxys, und der falsch gelesene Code
Die meisten bedeutenden Verträge sind heute Proxys. Die Adresse, mit der Sie umgehen, ist eine dünne, dauerhafte Hülle, die sämtliche Logik an einen getrennten Implementierungsvertrag delegiert — und der lässt sich von demjenigen austauschen, der die Upgrade-Berechtigung hält.
Dieses Muster hat gute Gründe — Fehler lassen sich beheben, Funktionen ergänzen — und es verändert die Sicherheitsfrage grundlegend. Der Code, den Sie heute prüfen, ist nicht zwingend der Code, der morgen läuft.
Ein naiver Explorer zeigt Ihnen den Bytecode des Proxys selbst: rund vierzig Zeilen Delegations-Rumpf, die überhaupt nichts aussagen. Etherscan erkennt die gängigen Proxy-Muster, löst die Implementierung auf und bietet einen Umschalter „Read as Proxy". Mehrere Wettbewerber tun das nicht, und das Versagen ist lautlos: Sie betrachten echten, verifizierten Code und ziehen einen Schluss über den falschen Vertrag.
Zu fragen ist, wer aktualisieren darf und ob es eine Zeitsperre gibt. Ein Upgrade, das eine einzelne extern verwaltete Adresse ohne Verzögerung auslösen kann, heißt: ein kompromittierter Schlüssel verändert alles. Ein Upgrade unter einer Multisig mit achtundvierzig Stunden Zeitsperre heißt: Die Leute sind vorgewarnt.
Beide Konstruktionen sind auf dem Explorer sichtbar, in den Admin-Funktionen des Proxys und an der Eigentümeradresse. Ob der Eigentümer eine Multisig oder ein einzelner Schlüssel ist, lässt sich ebenfalls ablesen — eine Multisig hat Vertragscode, ein einzelner Schlüssel nicht.
Eigentümerrechte: die Funktionen, auf die es ankommt
Wenn Sie in einem Vertrag nur eines lesen, dann die Funktionen hinter einer Eigentümer- oder Admin-Prüfung. Dort sitzt die Macht.
Mint. Können nach dem Ausrollen neue Token entstehen, und durch wen? Eine unbegrenzte Mint-Funktion in der Hand einer einzelnen Adresse heißt, dass das Angebot ist, was diese Adresse beschließt, wann immer sie es beschließt. Das ist der Mechanismus hinter einem großen Teil aller Token-Zusammenbrüche.
Pause oder Blacklist. Lassen sich Übertragungen anhalten, allgemein oder für einzelne Adressen? Seriöse Stablecoins haben das und nutzen es, um gerichtlichen Anordnungen nachzukommen — vertretbar. Ein Meme-Token mit derselben Fähigkeit ist etwas völlig anderes.
Gebührenanpassung. Lässt sich eine Übertragungsgebühr nach dem Start ändern? Ein Vertrag mit einer Gebühr, die bei null beginnt und auf neunundneunzig Prozent steigen kann, ist eine Falle mit Zeitzünder.
Beliebige Übertragung. Kann eine privilegierte Adresse Token bewegen, die ihr nicht gehören? Selten, eindeutig und disqualifizierend.
Nichts davon ist automatisch bösartig. Der Zusammenhang entscheidet. Ein regulierter Stablecoin braucht die Möglichkeit einzufrieren; ein Gemeinschafts-Token, der sich als dezentral ausgibt, nicht. Der Punkt ist, vor der Bindung von Mitteln zu wissen, welche davon existieren — und nicht danach.
Die Freigabe, die Sie tatsächlich erteilen
Die meisten Verluste entstehen nicht aus der Logik eines Vertrags. Sie entstehen aus Freigaben — und die Freigabe ist das, was Sie tatsächlich signieren.
Wenn Sie eine dezentrale Börse nutzen, erteilen Sie deren Vertrag die Erlaubnis, einen bestimmten Token von Ihrer Adresse zu bewegen. Diese Erlaubnis ist meist unbegrenzt in Betrag und Dauer, und sie besteht fort, bis Sie sie widerrufen — lange nachdem Sie vergessen haben, dass es das Protokoll gibt.
Zwei Jahre später wird dieses Protokoll ausgenutzt. Der Angriff muss Ihre Wallet nicht knacken; er muss nur eine Erlaubnis nutzen, die Sie längst erteilt haben. Wer dabei Geld verliert, hat häufig ein einziges Mal interagiert, Jahre zuvor, und nie wieder daran gedacht.
Der Wallet-Dialog sagt Ihnen, was Sie freigeben, und fast niemand liest ihn. Die zwei Felder, auf die es ankommt, sind der Empfänger — welcher Vertrag wird ermächtigt — und der Betrag. Viele Wallets lassen inzwischen einen endlichen Betrag statt „unbegrenzt" zu, und die geringen Mehrkosten einer Freigabe je Transaktion lohnen sich bei allem, dem Sie nicht vollständig vertrauen.
Sowohl Etherscan als auch BscScan haben Prüfwerkzeuge, die jede aktive Freigabe einer Adresse auflisten und widerrufen lassen. Diese Prüfung vierteljährlich zu machen ist die wertvollste Sicherheitsgewohnheit auf jeder EVM-Chain — und weil Freigaben je Chain gelten, muss jedes Netz getrennt geprüft werden.
Eine praktische Abfolge vor dem Zugriff
Das dauert etwa drei Minuten und findet das meiste, was sich ohne Solidity-Kenntnisse finden lässt.
Beginnen Sie damit, die Vertragsadresse gegen die Dokumentation des Projekts oder seine bestätigten Kanäle abzugleichen. Nicht den in einer Wallet angezeigten Namen, nicht einen Link aus einer Nachricht — die Adresse, aus einer Quelle, die das Projekt kontrolliert. Namen und Symbole sind beliebig und frei wiederverwendbar, und Nachahmung ist der häufigste Angriff überhaupt.
Öffnen Sie dann diese Adresse auf einem Explorer und prüfen Sie, ob sie verifiziert ist. Unverifiziert ist nicht automatisch bösartig — viele seriöse Verträge sind es nicht, besonders auf kleineren Chains —, bedeutet aber, dass Sie ohne Prüfmöglichkeit vertrauen.
Prüfen Sie, ob es ein Proxy ist, und lösen Sie gegebenenfalls die Implementierung auf. Lesen Sie die Eigentümeradresse und stellen Sie fest, ob es eine Multisig oder ein einzelner Schlüssel ist.
Überfliegen Sie die Funktionsliste nach den oben genannten privilegierten Operationen. Sie müssen die Implementierung nicht verstehen; Sie müssen wissen, ob die Funktion existiert.
Und wenn der Wallet-Dialog erscheint, lesen Sie Empfänger und Betrag. Dieser Dialog ist der letzte Punkt, an dem irgendetwas davon umkehrbar ist.
Wovor das nicht schützt
Die Grenzen einer Dreiminutenprüfung offen zu benennen ist wichtiger, als sie für hinreichend auszugeben.
Sie findet keinen feinen Logikfehler. Professionelle Audits übersehen solche wiederholt, und einen Vertrag auf einem Explorer zu lesen ist kein Audit. Was sie findet, ist die offensichtliche Kategorie — die Funktionen, mit denen jemand alles nehmen kann, im Code klar benannt.
Sie sagt Ihnen nicht, ob ein Projekt wirtschaftlich tragfähig ist, ob seine Kasse echt ist oder ob die Leute dahinter zu bleiben gedenken. Das sind Fragen, die die Chain nicht beantworten kann.
Und sie hilft nicht auf Chains ohne dieses Werkzeug. Der ganze hier beschriebene Ansatz ist EVM-spezifisch. Auf Cardano sind native Assets Ledger-Objekte ganz ohne Freigabemechanismus. Auf Sui werden Pakete mit Typinformationen veröffentlicht und ausdrücklich aktualisiert. Auf Solana lautet die entsprechende Frage, welches Programm ein Konto besitzt und welche Delegationsbefugnis besteht.
Der allgemeine Grundsatz überträgt sich auch dort, wo die Mechanik es nicht tut: Finden Sie heraus, was das, womit Sie gleich umgehen, tun darf — bevor Sie es erlauben.
Häufige Fragen
Heißt verifiziert, dass ein Vertrag sicher ist?
Nein. Verifizierung belegt, dass der veröffentlichte Quellcode zum ausgerollten Bytecode passt. Über die Redlichkeit des Codes sagt sie nichts, und verifizierte Verträge mit unbegrenzter Mint-Funktion sind verbreitet.
Was ist ein Proxy-Vertrag?
Eine dauerhafte Adresse, die ihre Logik an einen getrennten, austauschbaren Implementierungsvertrag delegiert. Das heißt, der heute laufende Code ist womöglich nicht der morgige — prüfen Sie, wer aktualisieren darf und ob es eine Zeitsperre gibt.
Wie widerrufe ich eine Token-Freigabe?
Nutzen Sie das Freigabe-Prüfwerkzeug auf Etherscan oder das Pendant Ihrer Chain, verbinden Sie Ihre Wallet und widerrufen Sie. Freigaben gelten je Chain, also muss jedes Netz getrennt geprüft werden.
Warum ist ein Vertrag als unverifiziert ausgewiesen?
Weil niemand den Quellcode eingereicht hat. Das ist nicht automatisch bösartig — viele seriöse Verträge sind unverifiziert, besonders auf kleineren Chains —, doch Sie vertrauen dann ohne Prüfmöglichkeit.
Was ist eine unbegrenzte Freigabe, und sollte ich sie meiden?
Die Erlaubnis für einen Vertrag, einen beliebigen Betrag eines Tokens zeitlich unbegrenzt von Ihrer Adresse zu bewegen. Bequem — und ein Dauerrisiko. Viele Wallets lassen stattdessen einen endlichen Betrag zu, was sich bei allem lohnt, dem Sie nicht vollständig vertrauen.