Wie man Smart Contracts prüft, bevor man die Wallet verbindet

📖 Warum die Analyse von Smart Contracts wichtig ist

Ziel dieser Anleitung ist eine klare Prüfroutine für Einsteiger: welchen Block-Explorer man öffnet, welche Stellen im Quellcode wichtig sind, welche Warnsignale besonders häufig vorkommen und wie man das Risiko vor einer Signatur oder einem approve reduziert.

🔍 Prüfung des Quellcodes eines Smart Contracts

Der erste Schritt ist die Code-Verifizierung im Block-Explorer, etwa Etherscan, BscScan oder Polygonscan. Ein verifizierter Contract zeigt, dass die hochgeladenen Quellen zum deployten Bytecode passen. Dadurch können Nutzer die Tabs Read Contract und Write Contract, die ABI und die Dateistruktur prüfen.

Öffnen Sie die Contract-Adresse, gehen Sie in den Tab Contract und prüfen Sie den Status Verified. Auch ohne Entwicklerwissen ist das ein wichtiger Filter: veröffentlichter Code lässt sich mit Scannern prüfen, unveröffentlichter Code bleibt eine Blackbox.

🔑 Kritische Funktionen und Berechtigungen: approve, transferFrom, permit

approve(spender, amount) ist die Standardfunktion, mit der ein Contract das Recht erhält, Token auszugeben. Danach kann er über transferFrom den genehmigten Betrag bewegen, ohne dass der Nutzer jede einzelne Bewegung erneut bestätigt. Besonders riskant sind unbegrenzte Approvals oder SetApprovalForAll bei NFTs.

Die praktische Regel lautet: nur den notwendigen Betrag freigeben, unbegrenzte Genehmigungen vermeiden, den Empfänger der Berechtigung prüfen und alte Berechtigungen nach der Nutzung widerrufen.

🔄 Proxys und Upgrades: warum das ein Risiko ist

Proxy-Contracts erlauben, dass die Adresse gleich bleibt, während die eigentliche Implementierung ausgetauscht wird. Das ist für große Protokolle praktisch, schafft für Nutzer aber zusätzliches Vertrauen in Admins, Multisigs oder Governance-Prozesse.

🛠️ Analyse-Tools: von statischen Scannern bis Browser-Erweiterungen

Ein einzelnes Tool reicht selten. Kombinieren Sie mehrere Quellen, weil sie unterschiedliche Risikoklassen abdecken:

• Slither findet typische Solidity-Fehler und gibt konkrete Hinweise.
• MythX kombiniert statische Analyse, symbolische Ausführung und Heuristiken.
• Remix IDE eignet sich für einfache Tests und Plugin-basierte Checks direkt im Browser.
• Token Sniffer prüft Token auf bekannte Scam-Muster und Honeypot-Signale.
• GoPlus Security bewertet Tokenrisiken, Phishing-Signale und gefährliche Aktionen.
• De.Fi Scanner liefert auch für Nicht-Entwickler verständliche Reports zu Schwachstellen und Rug-Pull-Indikatoren.
• Zusätzlich: Honeypot.is, Revoke-Dienste sowie Wallet Guard oder Pocket Universe für Signatur-Simulationen.

🚩 Typische Scam-Muster im Token-Code

Betrügerische Token nutzen häufig wiederkehrende Tricks:

• Honeypot: Kaufen ist möglich, Verkaufen wird für normale Adressen blockiert.
• Dynamische Sperren: Trading kann ein- oder ausgeschaltet werden, einzelne Adressen landen auf Blacklists.
• Variable Gebühren: Der Owner kann Steuern oder Gebühren auf extreme Werte setzen.
• Unbegrenztes Minting: Zusätzliche Token können ohne harte Obergrenze erzeugt werden.
• Liquiditätsabzug: LP-Token sind nicht gesperrt oder werden plötzlich entfernt.

Scanner erkennen viele dieser Muster automatisch. Die endgültige Entscheidung bleibt trotzdem beim Nutzer: Wenn mehrere rote Flaggen zusammenkommen, nicht verbinden.

⚠️ Versteckte Risiken: Owner-Rechte, pausable, Backdoors

Das Muster Ownable gibt dem Owner Sonderrechte. Das ist nicht automatisch Scam, aber der Umfang dieser Rechte ist entscheidend.

• Änderung kritischer Parameter wie Gebühren, Limits oder Empfängeradressen.
• Pausable: Transfers oder Trading können komplett gestoppt werden.
• mint oder burnFrom: Erzeugen neuer Token oder Verbrennen fremder Guthaben.
• Versteckte Methoden mit harmlosen Namen, die als Backdoor dienen.

Prüfen Sie Events wie OwnershipTransferred, RoleGranted und Paused. Achten Sie auch darauf, ob Ownership wirklich abgegeben wurde oder ob ein Owner weiterhin aktiv ist.

💰 DeFi-Contracts: Liquidität, Lending, Farming

Bei DeFi interagiert man nicht nur mit Token, sondern auch mit Pools, Lending-Protokollen und Farmen. Wichtige Checks:

• DEX-Pools: seriöse DEXes bevorzugen; Custom-Forks können versteckte Gebührenlogik enthalten.
• Lending: Audits, Caps, Liquidationsmechanik und Oracles prüfen.
• Farming/Staking: Emissionsrate, Einzahlungsgrenzen und Owner-Rollen bei MasterChef-ähnlichen Contracts ansehen.
• Allgemein: Bug Bounty, Multisig-Administration, TVL und Incident-Historie vergleichen.

🖼️ NFTs und Mints (ERC-721/1155): grundlegende Checks

Vor einem Mint oder Trade sollten mindestens diese Punkte stimmen:

• Offizielle Adresse: Contract-Adresse mit Projektquellen und Marktplätzen abgleichen.
• Supply Cap: maxSupply und Mint-Regeln prüfen.
• Gefährliche Berechtigungen: Dritte Seiten sollten kein SetApprovalForAll für “alles” verlangen.
• Metadaten: IPFS oder Arweave sind robuster als rein zentrale CDNs.

🧩 OpenZeppelin und erkennbare Templates

OpenZeppelin-Contracts sind ein positives Signal, weil viele Standards bereits geprüft und breit genutzt werden. Suchen Sie in verifizierten Quellen nach import "@openzeppelin/..." und vergleichen Sie mit bekannten Templates. Vorsicht bleibt trotzdem nötig: Oft steckt die Falle nicht im Template, sondern in wenigen zusätzlichen Zeilen.

🐳 Token-Features: Steuern, Blacklists, Anti-Whale

Manche Mechaniken sind nicht automatisch Betrug, verändern aber Risiko und Nutzbarkeit:

• Taxes/Fee: Kauf- und Verkaufsgebühren reduzieren das Ergebnis. Kritisch wird es, wenn der Owner sie stark erhöhen kann.
• Blacklist: Kann als Anti-Bot-Maßnahme dienen, aber auch gegen Holder eingesetzt werden.
• Anti-Whale: Limits für Transaktionen oder Guthaben können Liquidität schützen, aber auch Transfers erschweren.
• Reflections/Rewards: Automatische Umverteilung klingt attraktiv, macht den Code aber komplexer.

🔗 Was im Block-Explorer wichtig ist: Historie, Calls, Events

Der Block-Explorer ist das wichtigste Werkzeug für Due Diligence:

• Timeline: Deploy-Datum, Interaktionsfrequenz und Muster der Aktivität prüfen.
• Holder: Konzentration bei Top-Adressen, Owner-Anteil und Exchange-Adressen ansehen.
• Liquidität: LP-Lock, Laufzeit und Besitzer der LP-Token prüfen.
• Read/Write Contract: Funktionen direkt auslesen und verstehen, ohne sich nur auf das Frontend zu verlassen.
• Kommentare/Labels: Nicht beweisend, aber als Warnsignal nützlich.
• Events: Transfer von 0x0, Approval, OwnershipTransferred und Paused beachten.

📋 Checkliste vor dem Verbinden

1. Adresse im Explorer prüfen: Code-Verifizierung, Deploy-Datum, Holder, verdächtige Transaktionen, Labels.
2. Scanner nutzen: Token Sniffer, De.Fi Scanner, GoPlus. Bei kritischen Warnungen nicht verbinden.
3. Frontend verifizieren: URL prüfen, Analysen suchen, Geschenk-Links meiden.
4. Burner-Wallet verwenden: eigene Adresse mit kleinem Guthaben für den ersten Kontakt.
5. Approvals minimieren: kein ∞, wenn eine begrenzte Freigabe ausreicht.
6. Transaktion simulieren: vor der Signatur prüfen, was sich wirklich ändert.
7. Revoke bereit halten: alte Berechtigungen regelmäßig entfernen.

🚫 Was eine Prüfung nicht garantiert

• Frontend-Ehrlichkeit: Ein Interface kann Adresse oder Daten ersetzen.
• Team-Integrität: Sauberer Code schützt nicht vor Off-Chain-Rug-Pulls.
• Ökonomie: Ein technisch korrekter Token kann trotzdem auf null fallen.
• Zukünftige Updates: Upgradeable Contracts verändern ihr Risiko über Zeit.
• Social Engineering: Code-Checks schützen nicht vor Phishing oder Seed-Phrase-Leaks.