--- title: "Honeypot-Token erkennen" description: "Praxischeck für Token, die gekauft, aber nicht verkauft werden können: Vertragsidentität, Transferbeschränkungen, Administratorrechte, Simulation, Liquidität und kleiner Rundlauf." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Honeypot-Token erkennen > Nur zu Bildungszwecken, keine Anlageberatung. Krypto-Assets können ihren gesamten Wert verlieren. ## Direkte Antwort Ein Honeypot-Token ist so gestaltet oder konfiguriert, dass Händler ihn erwerben, aber nicht normal verkaufen können oder nur gegen eine extreme Gebühr. Die Sperre kann in Transferlogik, externem Vertrag, Adressliste, Handelsschalter, Transaktionslimit oder aktualisierbarer Implementierung liegen. Kein einzelnes Scannergebnis beweist Sicherheit. Prüfen Sie unabhängig die exakte Chain und Vertragsadresse, verifizierten Code und privilegierte Rollen; simulieren Sie den gesamten Verkaufspfad aus der vorgesehenen Wallet; untersuchen Sie reale Verkäufe und Poolliquidität; und erwägen Sie erst dann einen kleinen Rundlauf, dessen Totalverlust tragbar ist. Ein steigender Chart ist schwache Evidenz. Können die meisten Inhaber nicht verkaufen, zeigt die Historie Käufe ohne wettbewerblichen Verkaufsfluss; der angezeigte Preis sagt wenig darüber aus, wie viel Wert den Pool tatsächlich verlassen kann. ## Funktionsweise ERC-20 standardisiert Funktionen wie `transfer` und `transferFrom`, schreibt aber keine identische Tokenpolitik vor. Eigene Implementierungen dürfen Bedingungen zu Absender, Empfänger, Betrag, Blockzustand oder anderen Verträgen ergänzen. Code kann Einzahlungen in einen Pool erlauben, auf dem Verkaufspfad aber zurücksetzen, fast alles einbehalten oder Ausgänge selektiv blockieren. Prüfen Sie den gesamten Ausführungspfad, nicht nur Funktionsnamen. Ein AMM-Verkauf kann Allowance, Router, mehrere Pools und die Transferlogik umfassen. Suchen Sie nach eigentümer- oder rollengesteuerten Funktionen für Handelspausen, Gebühren und Limits, Positiv- oder Sperrlisten, Austausch von Router oder Paar, Prägung und Abhängigkeiten. Ein Eigentumsverzicht ist nicht abschließend. Andere Rollen oder externe Controller können Rechte behalten; ein Proxy kann bei gleicher Adresse die Implementierung wechseln. OpenZeppelin weist darauf hin, dass privilegierte Funktionen prägen, Transfers einfrieren oder Upgrades ausführen können. Ein Timelock gibt vor einer geplanten Änderung Zeit zur Prüfung und zum Ausstieg. Simulationen sind nützlich, aber begrenzt. `eth_call` führt im Zustand eines gewählten Blocks aus, ohne eine Transaktion anzulegen; auch `eth_estimateGas` fügt sie nicht der Chain hinzu. Setzen Sie tatsächlichen Absender, Route, Betrag und aktuellen Blockkontext. Erfolg beschreibt diesen Aufruf in diesem Zustand, nicht den nächsten Block oder spätere Adminaktionen. ## Prüfablauf - Bestätigen Sie Netzwerk und vollständige Vertragsadresse aus unabhängigen offiziellen Quellen. Prüfen Sie im Explorer, ob Bytecode und veröffentlichter Quellcode übereinstimmen und ob die Adresse ein Proxy ist. - Verfolgen Sie `transfer` und `transferFrom` einschließlich Vererbung und externer Aufrufe. Ermitteln Sie Gebührensteller, Handelsschalter, Wallet- und Transaktionsmaxima, Listen, Ausnahmen, Rollen, Proxyadmins und Verzögerungen. - Untersuchen Sie jüngste On-Chain-Verkäufe unabhängiger Adressen. Bestätigen Sie das erwartete Ausgangsasset statt nur eines Erfolgsstatus. Vergleichen Sie Ein- und Ausgang, Events, effektive Gebühr, Preiseffekt und Reserven. - Simulieren Sie den exakten Verkauf aus der vorgesehenen Wallet im aktuellen Zustand. Vergleichen Sie bei wichtigen Ergebnissen mindestens zwei unabhängige Tools oder RPC-Anbieter; Revert, unerklärte Ausgabe oder große Abweichung sind Stoppsignale. - Sind alle Prüfungen zufriedenstellend, testen Sie Kauf und Verkauf mit einem vollständig verzichtbaren Betrag. Prüfen Sie Endsalden und Transaktionsbelege. Erhöhen Sie Slippage nicht wiederholt, um eine unerklärte Transaktion zu erzwingen. Ökonomisch zählt der erzielbare Wert, nicht der angezeigte Walletsaldo: Erzielbarer Wert = erwartete Swap-Ausgabe - Preiseffekt - Protokollgebühr - Tokengebühr - Netzwerkgebühr Auch bei legitimen Token können Poolreserven den Ausstieg erschweren. Schätzen Sie die Ausgabe für die beabsichtigte Positionsgröße; ein winziger Verkauf beweist nicht, dass ein größerer nahe dem angezeigten Preis abgewickelt wird. ## Warnsignale und Grenzen - Verkäufe schlagen laufend fehl, Käufe gelingen, oder nur privilegierte und ausgenommene Adressen dürfen verkaufen. - Die effektive Verkaufsgebühr ist extrem, verschwiegen, walletspezifisch oder sofort änderbar. - Verifizierter Code fehlt, deckt die aktive Proxyimplementierung nicht ab oder hängt von einem unverifizierten externen Vertrag ab. - Liquidität ist dünn, unter einem Controller konzentriert oder ohne sinnvolle Sperre beziehungsweise Governanceverzögerung entfernbar. - Simulatoren widersprechen sich, die Route funktioniert nur in der Projektoberfläche oder aktuelle unabhängige Verkaufsbelege fehlen. Stoppen Sie bei unklarer Identität, unerklärlichem Verkauf, nicht aufzählbaren Rechten oder Verlust über dem Testbudget. Nachkaufen ist keine Diagnose. Mehr Gas kann Aufnahme fördern, aber keine Vertragssperre umgehen; mehr Slippage akzeptiert nur einen schlechteren Preis und erhöht womöglich den Verlust. Auch eine saubere Prüfung und ein erfolgreicher Rundlauf belegen nur einen Zeitpunkt. Reserven, Sperrlisten, Gebühren, Abhängigkeiten und aktualisierbare Logik können sich ändern. Prüfen Sie vor jeder wesentlichen Ausweitung erneut und nehmen Sie an, dass keine Checkliste Vertrags- oder Liquiditätsrisiken beseitigt. ## Häufige Irrtümer - **„Verifizierter Quellcode bedeutet sicher.“** Verifizierung verbindet Quelle und Bytecode; sie beweist weder gutartige Logik noch begrenzte Privilegien. - **„Nach Eigentumsverzicht kann niemand Regeln ändern.“** Andere Rollen, Controller oder Proxyadmins können Rechte behalten. - **„Der Scanner meldet verkäuflich, also klappt der nächste Verkauf.“** Zustand, Absender, Route, Block, Liquidität und Implementierung können abweichen. - **„Ein kleiner Verkauf beweist den Ausstieg der Gesamtposition.“** Gebührenstufen, Walletlimits, Preiseffekt und endliche Reserven können bei größerem Umfang völlig andere Ergebnisse liefern. ## Verwandte Themen - [Risiko von Token mit Transfergebühr](/de/crypto/fee-on-transfer-token-risk/) - [Token-Vertragsadresse prüfen](/de/crypto/token-contract-verification/) - [Transaktionssimulation](/de/crypto/transaction-simulation/) - [Rug Pulls](/de/crypto/rug-pull/) - [DEX-Slippage- und Routencheckliste](/de/crypto/dex-slippage-route-checklist/) ## Quellen - [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (abgerufen: 2026-08-20) - [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (abgerufen: 2026-08-20) - [Zugriffskontrolle](https://docs.openzeppelin.com/contracts/5.x/access-control) - OpenZeppelin (abgerufen: 2026-08-20) - [Proxy-Upgrade-Muster](https://docs.openzeppelin.com/upgrades-plugins/proxies) - OpenZeppelin (abgerufen: 2026-08-20) Source: https://wiki.fcontext.com/de/crypto/honeypot-token-detection/index.mdx