Was ist ein Honeypot in einem Satz?
Ein Honeypot ist ein Token, bei dem dir der Contract den Kauf erlaubt, den Verkauf aber technisch unmöglich macht oder ihn mit so hohen Gebühren belastet, dass dir vom Verkauf fast nichts bleibt. Im Chart sieht das aus wie eine Rakete, die nur steigt, weil fast niemand verkaufen kann.
Wichtig: In diesem Text beschreiben wir allgemeine Muster im Code und in den Daten, nicht konkrete Projekte. Wir behaupten nicht, dass irgendein Token ein Betrug ist. Wir zeigen, wie der Mechanismus funktioniert und wie man ihn selbst überprüfen kann. Die hier dargestellte Mechanik basiert auf der öffentlichen Dokumentation des ERC-20-Standards, der Sprache Solidity und der Dokumentation dezentraler Börsen (Uniswap, PancakeSwap), auf die wir in den Quellen verweisen.
Wie macht der Contract das technisch?
Ein Token auf EVM-Chains (Ethereum, BNB Chain und ähnliche) ist nur ein Smart Contract. Nach dem ERC-20-Standard läuft der Token-Transfer über die Funktion transfer oder transferFrom (siehe ERC-20-Dokumentation und OpenZeppelin in den Quellen). In den Körper dieser Funktion kann der Ersteller in Solidity beliebige Bedingungen schreiben. Kauf und Verkauf sind dabei keine zwei verschiedenen Funktionen, es sind nur Übertragungen zwischen deiner Wallet und dem Liquiditätspaar (zum Beispiel auf Uniswap oder PancakeSwap, deren Paar-Mechanik in ihrer Dokumentation beschrieben ist). Das ist der Schlüssel: Der Contract kann unterscheiden, ob Tokens zum Liquiditätspaar wandern (Verkauf) oder vom Paar zu dir (Kauf), und sich entsprechend anders verhalten.
Die häufigsten Muster, die in solchen Contracts auftauchen:
| Muster | Was es tut | Wie es sich zeigt |
|---|---|---|
| Blacklist / Whitelist | Nur erlaubte Adressen können übertragen | Dein Verkauf revertiert (schlägt fehl) |
| Asymmetrische Steuer | Kauf 0 %, Verkauf 99 % | Du verkaufst, bekommst aber nur Krümel |
| Blockade beim Verkauf ans Paar | require, das fehlschlägt, wenn der Empfänger ein Liquidity Pool ist |
Verkauf geht gar nicht durch |
| Umschaltbares Flag | Der Ersteller schaltet den Handel nachträglich ab | Kauf funktionierte, Verkauf hörte später auf |
| Max transaction / cooldown | Limit so niedrig, dass der Verkauf nicht durchgeht | Transaktion revertiert am Limit |
Gemeinsam ist, dass die Logik bedingt und umschaltbar ist. Der Contract muss nicht von Anfang an ein Honeypot sein. Er kann es in dem Moment werden, in dem der Ersteller eine Funktion aufruft, die den Handel einschränkt.
Wie sieht das an einer konkreten Zahl aus?
Stellen wir uns ein vereinfachtes, rein illustratives Beispiel vor (es handelt sich nicht um gemessene Daten). Du legst 1 ETH in den Contract und kaufst 1 000 000 Tokens. Der Kauf geht problemlos durch, weil die Kaufsteuer auf 0 % eingestellt ist.
Dann versuchst du, diese 1 000 000 Tokens zurückzuverkaufen. Es treten zwei typische Situationen auf:
- Harter Honeypot: Die Transaktion geht gar nicht durch. Die Wallet meldet, dass die Transaktion fehlgeschlagen ist (Revert). Deine Tokens bleiben, ETH bekommst du keine.
- Weicher Honeypot (steuerbasiert): Der Verkauf geht durch, aber die Verkaufssteuer beträgt 99 %. Von einem Wert, der 1 ETH entspricht, kommt auf deinem Konto das Äquivalent von 0,01 ETH an. Formal "konntest du verkaufen", real hast du fast alles verloren.
Der Unterschied zwischen diesen beiden ist wichtig: Ein weicher Honeypot besteht oft einen oberflächlichen Test, weil der Verkauf technisch funktioniert. Erst der Blick auf den resultierenden Betrag zeigt, dass die Steuer fast den gesamten Betrag verschlungen hat.
Wie kann man das vor dem Kauf testen?
Es gibt mehrere Vorgehensweisen, die nur mit öffentlich verfügbaren Daten arbeiten. Wir beschreiben sie als Werkzeuge zur Überprüfung, nicht als Garantie.
1. Verkaufssimulation
Einige Tools (Honeypot-Checker beziehungsweise Transaktionssimulatoren) führen in einer Testumgebung einen simulierten Kauf und gleich darauf einen Verkauf durch und messen, wie viel zurückkäme. Das Ergebnis ist meist eine geschätzte Kaufsteuer, Verkaufssteuer und die Information, ob der Verkauf überhaupt durchgeht. Einschränkung: Die Simulation geht vom aktuellen Zustand des Contracts aus. Wenn der Ersteller die Logik später ändert, muss das Ergebnis nicht mehr gelten.
2. Lesen des verifizierten Quellcodes
Auf einem Block-Explorer (zum Beispiel Etherscan für Ethereum oder BscScan für BNB Chain, siehe Quellen) ist bei verifizierten Contracts der Solidity-Code sichtbar. Zu beobachtende Muster:
- Funktionen, die Steuern oder Handelsregeln nach dem Deployment ändern,
require-Bedingungen innerhalb der Übertragung, die sich für Kauf und Verkauf unterscheiden,- Rollen vom Typ
onlyOwner, die dem Eigentümer einseitiges Eingreifen erlauben, - Adresslisten (
_isBlacklistedund ähnliche).
Wenn der Contract nicht verifiziert ist (der Quellcode nicht veröffentlicht ist), lässt sich nicht lesen, was er tut. Das ist an sich kein Beweis für irgendetwas, aber es ist eine Information darüber, was du nicht weißt.
3. Blick auf tatsächliche Verkäufe auf der Chain
In der Transaktionshistorie des Paares lässt sich herausfinden, ob überhaupt jemand erfolgreich verkauft hat. Wenn dort viele Käufe und fast keine Verkäufe sind, ist das ein Muster, das Aufmerksamkeit verdient. Umgekehrt ist eine Reihe normaler Verkäufe von verschiedenen Adressen ein Signal, dass der Verkauf in diesem Moment funktionierte.
4. Wer hält und wer kann ändern
Nützlich ist ein Blick auf die Verteilung der Halter und darauf, ob das Eigentum am Contract abgetreten (renounced) ist oder ob der Eigentümer weiterhin das Recht hat, Parameter zu ändern. Der Verzicht auf das Eigentum senkt das Risiko einer nachträglichen Regeländerung, schließt aber nicht aus, dass die Honeypot-Logik bereits fest im Code verankert ist.
Warum ist selbst ein sauberer Test keine Garantie?
Weil der Zustand des Contracts über die Zeit veränderlich ist. Drei konkrete Fallen:
- Zeitgesteuerte Änderung: Kauf und Verkauf funktionieren heute, morgen ruft der Ersteller eine Funktion auf, die den Verkauf blockiert.
- Schwellensteuern: Die Steuer steigt erst nach Erreichen eines bestimmten Volumens oder einer bestimmten Anzahl von Haltern.
- Proxy-Contracts: Die Logik lässt sich über einen upgradebaren Proxy austauschen, sodass der Code, den du gelesen hast, nicht mehr der sein muss, der ausgeführt wird.
Deshalb gilt: Der Test sagt aus, wie sich der Contract im Moment des Tests verhalten hat, nicht wie er sich später verhält. Gerade wegen dieser Fallen betrachten wir das Ergebnis von Simulation und Codelektüre als starkes Indiz, nicht als Gewissheit.
Was du jetzt können solltest und was ungewiss bleibt
Nach dieser Lektion solltest du in der Lage sein:
- zu erklären, warum ein Contract Kauf von Verkauf unterscheiden kann,
- die grundlegenden Honeypot-Muster zu benennen (Blacklist, asymmetrische Steuer, Verkaufsblockade, umschaltbares Flag),
- einen harten Honeypot (Verkauf geht nicht durch) von einem weichen (Verkauf geht durch, aber die Steuer nimmt fast alles) zu unterscheiden,
- drei Überprüfungen durchzuführen: Verkaufssimulation, Lesen des verifizierten Codes und Kontrolle der realen Verkäufe auf der Chain.
Was ungewiss bleibt und sich nicht zuverlässig im Voraus feststellen lässt: wie sich der Ersteller in Zukunft verhält, ob er Parameter ändert und ob er hinter einem Proxy-Contract die Logik austauscht. Kein Tool gibt hundertprozentige Sicherheit, weil es mit dem vergangenen und gegenwärtigen Zustand arbeitet, nicht mit der zukünftigen Absicht.
Dies ist keine Empfehlung, was du mit deinem Geld tun sollst. Es ist eine Beschreibung der Mechanik und der Überprüfungsmethoden, damit du mit offenen Augen entscheidest.