Zum Inhalt springen
ethexplorer.org

Technischer Leitfaden · Verifizierter Code · Proxys

Ethereum Smart Contracts prüfen: lesen Sie den Code, der Ihr Geld verwahrt

Verifizierter Quellcode, Read- und Write-Tabs, ABI, Proxys, Events und Admin-Keys, verständlich erklärt. Zum Schluss ein Fünf-Schritte-Check, den Sie auf jede Adresse anwenden können.

Regulierte Börse seit 2013

  • Etherscan · Sourcify · Blockscout
  • EIP-1967-Proxys
  • Traces mit Tenderly & Phalcon

Von Redaktion ethexplorer.org Aktualisiert 12 Min. Lesezeit

Jeder Token, jede NFT-Kollektion, jeder Lending-Markt und jede Bridge auf Ethereum ist ein Smart Contract: Bytecode, der unter einer Adresse gespeichert ist und von jedem Node exakt so ausgeführt wird, wie er geschrieben wurde. Ein Ethereum Smart Contract Explorer ist der Teil eines Block-Explorers, der diesen Bytecode wieder in etwas verwandelt, das Sie untersuchen können. Er zeigt Ihnen den Quellcode, sofern der Autor ihn veröffentlicht hat, lässt Sie Funktionen aufrufen, ohne eine Zeile Code zu schreiben, listet die Events auf, die der Vertrag ausgelöst hat, und verrät, wer ihn deployt hat.

Um Ethereum Smart Contracts prüfen zu können, müssen Sie kein Solidity-Entwickler sein. Wer weiß, was „verifiziert“ tatsächlich bedeutet, wie man einen Proxy erkennt und wo die Admin-Keys stecken, umgeht bereits einen Großteil der typischen Risiken. Dieser Leitfaden geht die Contract-Seite Tab für Tab durch und endet mit einer Fünf-Schritte-Routine, die Sie vor jeder Token-Freigabe und jeder Einzahlung in ein DeFi-Protokoll anwenden können. Für token-spezifische Prüfungen wie Holder-Konzentration und Honeypots gibt es unseren ergänzenden Leitfaden zum Token-Explorer.

Was „verifizierter Quellcode“ auf Etherscan, Sourcify und Blockscout bedeutet

Unter einer Vertragsadresse liegt nur Bytecode. Jeder kann behaupten, eine bestimmte Solidity-Datei habe ihn erzeugt; die Verifizierung ist der Weg, auf dem ein Explorer diese Behauptung überprüft. Der Autor reicht die Quelldateien, die Compiler-Version, die Optimizer-Einstellungen und die Konstruktor-Argumente ein. Der Explorer kompiliert alles selbst und vergleicht das Ergebnis mit dem Bytecode auf der Chain. Stimmen beide überein, wird der Quellcode neben dem Contract veröffentlicht, meist mit einem grünen Häkchen.

Etherscan unterscheidet zwischen einem Exact Match, bei dem Code und Konstruktor-Argumente des Autors den deployten Contract exakt reproduzieren, und einem Similar Match. Diesen vergibt Etherscan automatisch, wenn der Bytecode eines neuen Contracts einem bereits verifizierten entspricht. Similar Matches sind praktisch für Klone, die über eine Factory entstehen, ignorieren aber die Konstruktor-Argumente, und genau die können das Verhalten eines Vertrags verändern. Wenn viel auf dem Spiel steht, sollten Sie einem Exact Match den Vorzug geben.

Sourcify, ein quelloffener Verifizierungsdienst, der ursprünglich bei der Ethereum Foundation entstanden ist, nutzt die Metadaten-Datei, die der Solidity-Compiler als Hash ans Ende des Bytecodes hängt. Die beiden möglichen Ergebnisse heißen dort inzwischen exact match und match; in vielen Tools begegnen Ihnen aber noch die alten Bezeichnungen „full“ und „partial“. Ein Exact Match bedeutet, dass alles, einschließlich Kommentaren und Dateipfaden, Byte für Byte identisch ist. Ein Match bedeutet, dass der ausführbare Code identisch ist, die Metadaten aber abweichen. Beides belegt die Logik; umbenannt wurde nur, weil „partial“ viele glauben ließ, der Contract sei gar nicht verifiziert. Blockscout bietet eigene Verifizierungswege (geflatteter Quellcode, Standard-JSON-Input, Plugins für Hardhat und Foundry) und ist mit Sourcify verzahnt, sodass ein auf Sourcify verifizierter Contract auch auf Blockscout als verifiziert erscheinen kann. Unser Blockscout-Test geht darauf genauer ein.

Die Tabs „Read Contract“ und „Write Contract“ richtig nutzen

Sobald ein Contract verifiziert ist, kennt der Explorer seine ABI und baut daraus zwei Formulare. Read Contract listet alle view- und pure-Funktionen auf. Ein Aufruf kostet nichts, braucht kein Wallet und liefert den aktuellen Wert direkt von der Chain: das totalSupply() eines Tokens, den owner() eines Vaults, ob ein Protokoll gerade paused() ist. So beantworten Sie Sachfragen zu einem Contract am schnellsten, ohne dem Dashboard irgendeines Anbieters vertrauen zu müssen.

Write Contract listet die Funktionen, die den Zustand verändern. Der Explorer fordert Sie auf, ein Wallet zu verbinden, trägt die Parameter in eine echte Transaktion ein und übergibt sie Ihrem Wallet zur Signatur. Das ist wirklich nützlich, wenn die Website eines Projekts ausgefallen ist und Sie trotzdem abheben müssen, oder wenn Sie eine Freigabe ohne Drittanbieter-Seite widerrufen möchten. Es ist aber auch der Ort, an dem Fehler passieren: Beträge werden in der kleinsten Einheit des Tokens angegeben, 1 USDC ist also 1000000 und 1 WETH ist 1000000000000000000. Für Nicht-Entwickler ist der Write-Tab eher zum Lesen als zum Klicken da: Die Liste der zustandsverändernden Funktionen verrät Ihnen, was der Owner und was die Nutzer tun können. Findet sich dort etwa eine Funktion mint, blacklist oder setFee, wissen Sie sofort, welche Hebel der Betreiber in der Hand hat.

ABI und Funktionsselektoren, einfach erklärt

Die ABI (Application Binary Interface) ist eine JSON-Beschreibung der Funktionen und Events eines Contracts: Namen, Parametertypen und Rückgabetypen. Explorer verwenden sie, um Transaktionen zu dekodieren. Wenn Sie eine Transaktion an einen Contract senden, beginnen deren Input-Daten mit einem vier Byte langen Funktionsselektor, den ersten vier Bytes des Keccak-256-Hashs der Funktionssignatur. Alles danach sind die Argumente, jeweils auf 32 Bytes aufgefüllt.

// Drei ERC-20-Funktionen und ihre 4-Byte-Selektoren
function transfer(address to, uint256 amount) external returns (bool);   // 0xa9059cbb
function approve(address spender, uint256 amount) external returns (bool); // 0x095ea7b3
function balanceOf(address account) external view returns (uint256);     // 0x70a08231

// Selektor = erste 4 Bytes von keccak256("transfer(address,uint256)")
// Calldata eines Transfers:
// 0xa9059cbb
//   000000000000000000000000<Empfängeradresse, 20 Bytes>
//   <Betrag als vorzeichenlose 32-Byte-Ganzzahl>

Deshalb kann ein Explorer die Transaktion an einen unverifizierten Contract trotzdem mit transfer beschriften: Er erkennt 0xa9059cbb aus öffentlichen Signaturdatenbanken, auch ohne die ABI des Vertrags zu kennen. Das erklärt zugleich einen beliebten Phishing-Trick. Selektoren sind nur vier Bytes lang, Angreifer können also Funktionen mit sinnlosen Namen konstruieren, die mit bekannten Selektoren kollidieren, oder eine bösartige Funktion schlicht claimRewards nennen. Dekodierte Namen sind Hinweise; die Wahrheit steht im verifizierten Quellcode. Wie Sie Input-Daten an einer echten Transaktion dekodieren, zeigt unsere Anleitung zum Thema Ethereum-Transaktion prüfen.

Proxys: EIP-1967, UUPS und die Implementierungsadresse

Contracts lassen sich nach dem Deployment nicht mehr bearbeiten. Upgradefähige Systeme teilen sich deshalb in zwei Teile: einen kleinen Proxy, der den Zustand hält und die Adresse ist, mit der die Nutzer interagieren, und einen Implementierungs- oder Logik-Contract, der den eigentlichen Code enthält. Der Proxy leitet jeden Aufruf per delegatecall weiter. Ein Upgrade bedeutet, den Proxy auf eine neue Implementierung zeigen zu lassen. USDC ist ein gutes Praxisbeispiel: 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 ist ein Proxy, und die Token-Logik liegt in einem separaten Implementierungsvertrag, den Circle austauschen kann.

EIP-1967 hat standardisiert, wo Proxys diesen Zeiger ablegen: Die Implementierungsadresse steht in Storage-Slot 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc, der Admin in 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103. Weil die Slots fest definiert sind, können Explorer Proxys automatisch erkennen und die Tabs „Read as Proxy“ und „Write as Proxy“ anbieten, die die ABI der Implementierung verwenden. Bei einem Transparent Proxy liegt die Upgrade-Funktion im Proxy selbst, und nur der Admin darf sie aufrufen. Bei einem UUPS-Proxy (aus ERC-1822) sitzt die Upgrade-Funktion in der Implementierung, was den Proxy schlank hält, aber bedeutet, dass eine fehlerhafte Implementierung künftige Upgrades unmöglich machen kann. Beacon-Proxys schließlich lassen viele Proxys auf einen gemeinsamen Beacon zeigen, der die Implementierung benennt.

Für Ihre Sicherheitsprüfung zählt ein einfacher Punkt: Wenn Sie einen Proxy lesen, lesen Sie nicht den Code, der tatsächlich läuft. Klicken Sie sich zur Implementierung durch, prüfen Sie, ob sie verifiziert ist, und finden Sie dann heraus, wer das Upgrade aufrufen darf. Wer diesen Schlüssel kontrolliert, kontrolliert jeden Token im Contract.

Events, Logs und Bytecode

Contracts lösen Events aus, um festzuhalten, was passiert ist: Transfer, Approval, OwnershipTransferred, Upgraded, Paused. Jedes Event wird zu einem Log in der Transaktionsquittung, mit bis zu vier indizierten Topics und einem Datenfeld. Der Events-Tab einer Contract-Seite ist ein chronologischer Feed dieser Logs, und für die Sicherheit ist er Gold wert. Ein Upgraded-Event vor zwei Tagen, ein neues RoleGranted an eine unbekannte Adresse oder ein OwnershipTransferred an eine frisch angelegte Wallet sind genau die Art von Änderungen, die Vorfällen häufig vorausgehen.

Der Bytecode-Tab zeigt den rohen, deployten Code. Bei unverifizierten Contracts ist das alles, was Sie haben. Decompiler machen daraus groben Pseudocode, und unsere Open-Source-Empfehlungen wie Otterscan und andere selbst gehostete Explorer können ihn auf Ihrem eigenen Node tracen. Seit dem Pectra-Upgrade im Mai 2025 gibt es einen weiteren Fall, den Sie erkennen sollten: Eine gewöhnliche Wallet-Adresse mit einem kurzen Code aus 0xef0100 gefolgt von einer Adresse ist eine EIP-7702-Delegation. Dieses Konto führt dann gerade den Code eines anderen Contracts aus. Moderne Explorer kennzeichnen das, und es verdient dieselbe Aufmerksamkeit wie jeder andere Contract.

Contract Creator und Erstellungstransaktion

Jede Contract-Seite zeigt, wer den Vertrag erstellt hat und in welcher Transaktion. Diese eine Zeile beantwortet erstaunlich viele Fragen. Wurde er vom bekannten Deployer des Teams veröffentlicht oder von einer Adresse, die erst eine Stunde vorher von einer Börse aus mit ETH versorgt wurde? Entstand er direkt oder über einen Factory-Contract, wie bei Uniswap-Pools oder Safe-Wallets? Welche Konstruktor-Argumente wurden übergeben? Ein Klick auf den Ersteller zeigt außerdem, was diese Adresse sonst noch deployt hat; eine Historie verlassener Tokens ist ein Muster, kein Zufall. Wie Sie eine Wallet schnell durchleuchten, erklärt unser Leitfaden Ethereum-Adresse prüfen.

Einen Contract in 5 Schritten prüfen

Gehen Sie diese Routine bei jedem Contract durch, bevor Sie Token freigeben oder Geld einzahlen. Auf Etherscan oder Blockscout dauert das etwa fünf Minuten.

  1. 1 STEP 01

    Adresse und Ersteller bestätigen

    Holen Sie sich die Adresse aus der offiziellen Dokumentation des Projekts und öffnen Sie sie dann in einem Explorer. Prüfen Sie den Contract Creator und die Erstellungstransaktion: Wer hat den Vertrag deployt, wann, und über welche Factory?

  2. 2 STEP 02

    Verifizierungsstatus prüfen

    Suchen Sie nach einem Exact Match bzw. einer vollständigen Übereinstimmung auf Etherscan, Sourcify oder Blockscout. Ohne verifizierten Quellcode vertrauen Sie Bytecode, den Sie nicht lesen können.

  3. 3 STEP 03

    Den Proxy auflösen

    Kennzeichnet der Explorer einen Proxy, öffnen Sie die Implementierungsadresse und lesen Sie deren Code. Notieren Sie, wer ein Upgrade auslösen darf.

  4. 4 STEP 04

    Die Admin-Rechte finden

    Prüfen Sie unter „Read Contract“ owner(), die Rollen und den Proxy-Admin. Ist das eine einzelne Wallet, ein Multisig oder ein Timelock mit Verzögerung?

  5. 5 STEP 05

    Events lesen und simulieren

    Durchsuchen Sie die jüngsten Events nach Upgrades, Rollenwechseln und Pausen, und simulieren Sie Ihre eigene Transaktion vor dem Signieren in einem Tool wie Tenderly.

Sicherheitsprüfung: Admin-Keys, Timelocks und Audits

Die meisten großen Verluste in DeFi gehen nicht auf exotische Mathefehler zurück, sondern auf Schlüssel. Nachdem Sie den Proxy aufgelöst haben, schauen Sie sich also an, wer die Macht hat. Rufen Sie owner() auf, prüfen Sie Rollen wie DEFAULT_ADMIN_ROLE, MINTER_ROLE oder PAUSER_ROLE und ermitteln Sie den Proxy-Admin. Öffnen Sie dann jede dieser Adressen. Ein Externally Owned Account bedeutet, dass ein einziger privater Schlüssel das ganze System verändern kann. Ein Safe-Multisig ist besser, und seine Seite zeigt die Signatur-Schwelle, etwa 4 von 7. Noch besser ist ein Timelock-Contract: Änderungen müssen eingereiht werden und eine öffentliche Wartezeit abwarten, oft 24 bis 48 Stunden oder länger, bevor sie ausgeführt werden. Das verschafft Nutzern Zeit zum Aussteigen. Eingereihte Operationen sehen Sie als Events auf der Seite des Timelocks selbst.

Audits sind die nächste Ebene. Ein Audit-Bericht sollte den genauen Commit oder die geprüften Vertragsadressen nennen; vergleichen Sie das mit dem, was tatsächlich deployt ist, denn auditierter Code, der danach verändert wurde, ist nicht auditierter Code. Achten Sie darauf, dass der Bericht auf der Website des Auditors selbst zu finden ist und nicht nur beim Projekt. Ein Bug-Bounty-Programm und eine offen kommunizierte Vorfallshistorie sind weitere Signale. Nichts davon macht einen Contract risikofrei, und deshalb sollte die Größe Ihrer Position immer dem entsprechen, was Sie im schlimmsten Fall verlieren können.

Tiefer einsteigen: Tenderly, Phalcon und Trace-Explorer

Ein Standard-Explorer zeigt den Aufruf auf oberster Ebene und die Events. Komplexe Transaktionen wie Flash Loans, Multi-Hop-Swaps und Exploits spielen sich in internen Aufrufen ab, die Sie nur in einem Trace sehen. Tenderly spielt jede Transaktion mit vollständigem Call Tree, Zustandsänderungen und zeilenweisem Debugger erneut ab und kann auch eine Transaktion simulieren, die Sie noch gar nicht gesendet haben. Das ist die mit Abstand beste Angewohnheit, bevor Sie etwas Großes signieren. Der Phalcon Explorer von BlockSec konzentriert sich auf Aufrufablauf, Geldfluss und Saldenänderungen; Sicherheitsforscher nutzen ihn intensiv, um Angriffe zu rekonstruieren. Beide vergleichen wir mit weiteren Optionen in unserer Übersicht der Etherscan-Alternativen.

Für den Alltag bleiben Sie dennoch meist bei Etherscan oder Blockscout. Etherscan hat den größten Bestand an verifizierten Contracts und Labels, und unser Etherscan-Test beleuchtet die Contract-Werkzeuge ausführlich. Blockscout ist source-available (bis Version 10.2 GPL-3.0, seit v11.0.0 vom 22. April 2026 unter der eigenen Blockscout Software License) und bietet derzeit eine API ohne Schlüssel. Das ist nützlich, wenn Sie Prüfungen automatisieren möchten, wie unser Leitfaden zu Explorer-APIs erklärt. Und für einen ersten schnellen Blick auf eine beliebige Adresse, ob Contract, verifiziert oder Proxy, liefert unser kostenloser Ethereum Explorer die Antwort in Sekunden.

Gewohnheiten, die Contract-Seiten leicht lesbar machen

Beginnen Sie jede Prüfung mit der Adresse, niemals mit dem Namen. Lesen Sie die Implementierung hinter dem Proxy, nicht den Proxy selbst. Betrachten Sie einen Similar Match und fehlende Verifizierung als Gründe, langsamer zu werden. Schauen Sie sich die Events der letzten Wochen an, bevor Sie in den Code gehen, denn in jüngsten Änderungen verstecken sich die Überraschungen. Und wenn eine Transaktion komplex oder wertvoll ist, simulieren Sie sie zuerst. Mit diesen Gewohnheiten ist ein Smart-Contract-Explorer keine Wand aus Hexadezimalzahlen mehr, sondern die ehrlichste Dokumentation, die ein Protokoll überhaupt haben kann.

Ein letzter Praxistipp: Legen Sie sich für Protokolle, die Sie regelmäßig nutzen, eine kleine Notiz mit Proxy-Adresse, Implementierung, Admin und Timelock-Dauer an. Ändert sich einer dieser Werte, sehen Sie es beim nächsten Blick in den Explorer sofort. Wer zusätzlich die Freigaben der eigenen Wallet im Auge behält, schließt die zweite große Lücke, über die Drainer an Guthaben gelangen, denn eine alte, unbegrenzte Approval an einen inzwischen ausgetauschten Contract ist genau die Art von Risiko, die man nicht bemerkt, bis es zu spät ist.

Häufige Fragen

01

Was ist ein Ethereum Smart Contract Explorer?

Das ist die Contract-Ansicht eines Block-Explorers: Quellcode, ABI, Read- und Write-Tabs, Events, Bytecode, Ersteller und Erstellungstransaktion zu jeder Vertragsadresse. Etherscan und Blockscout bieten diese Ansicht beide an, und unser Live-Explorer zeigt Ihnen, ob ein Contract verifiziert oder ein Proxy ist.
02

Was bedeutet „verifizierter Contract“ auf Etherscan?

Der Explorer hat den vom Autor eingereichten Quellcode mit derselben Compiler-Version und denselben Einstellungen kompiliert und dabei exakt den Bytecode erhalten, der unter dieser Adresse liegt. Damit ist bewiesen, dass der Code, den Sie lesen, auch der Code ist, der ausgeführt wird. Ob dieser Code sicher oder ehrlich ist, beweist die Verifizierung nicht.
03

Was ist der Unterschied zwischen „exact match“ und „match“ bei Sourcify?

Ein Exact Match (früher „full“ oder „perfect“) bedeutet, dass der neu kompilierte Bytecode inklusive Metadaten-Hash identisch ist, also sogar Kommentare und Dateinamen übereinstimmen. Ein Match (früher „partial“) bedeutet, dass der ausführbare Code identisch ist, die Metadaten aber abweichen, etwa bei Kommentaren oder Variablennamen. Beides belegt die Logik.
04

Wie finde ich die Implementierung eines Proxy-Contracts?

Explorer erkennen Standard-Proxys und zeigen die Implementierungsadresse zusammen mit den Tabs „Read as Proxy“ und „Write as Proxy“ an. Bei EIP-1967-Proxys steht die Adresse in Slot 0x3608…2bbc, und jedes Upgrade erzeugt ein Upgraded(address)-Event, das Sie in den Logs sehen.
05

Ist der Write-Contract-Tab sicher?

Er ist genau so sicher wie die Transaktion, die Sie signieren. Der Tab verbindet Ihr Wallet und sendet eine echte Transaktion an den Contract, ein falscher Parameter kann also Geld kosten. Nutzen Sie ihn nur bei Verträgen, denen Sie vertrauen, prüfen Sie die Einheiten doppelt (die meisten Token haben 18 Dezimalstellen) und simulieren Sie vorher, wenn es um nennenswerte Beträge geht.

Weiterlesen