Tokeny honeypot: kupisz, ale nie sprzedasz. Jak robi to smart kontrakt i jak to przetestować

Czym jest honeypot w jednym zdaniu?

Honeypot to token, przy którym kontrakt umożliwia ci zakup, ale sprzedaż technicznie uniemożliwia albo obciąża ją tak wysoką opłatą, że ze sprzedaży nie zostaje ci prawie nic. Na wykresie wygląda to jak rakieta, która tylko rośnie, bo prawie nikt nie może sprzedać.

Ważne: w tym tekście opisujemy ogólne wzorce w kodzie i w danych, a nie konkretne projekty. Nie twierdzimy, że jakikolwiek token jest oszustwem. Pokazujemy, jak mechanizm działa i jak można go samodzielnie sprawdzić. Mechanika, którą tu przedstawiamy, wywodzi się z publicznej dokumentacji standardu ERC-20, języka Solidity oraz dokumentacji zdecentralizowanych giełd (Uniswap, PancakeSwap), do której odsyłamy w źródłach.

Jak kontrakt robi to technicznie?

Token na łańcuchach EVM (Ethereum, BNB Chain i podobnych) to tylko smart kontrakt. Zgodnie ze standardem ERC-20 transfer tokenu przechodzi przez funkcję transfer lub transferFrom (patrz dokumentacja ERC-20 i OpenZeppelin w źródłach). W ciele tej funkcji twórca może w Solidity zapisać dowolne warunki. Zakup i sprzedaż nie są przy tym dwiema różnymi funkcjami, to tylko transfery między twoim portfelem a parą płynnościową (na przykład na Uniswapie lub PancakeSwapie, których mechanikę par opisuje ich dokumentacja). To jest klucz: kontrakt potrafi rozróżnić, czy tokeny odchodzą do pary płynnościowej (sprzedaż), czy od pary do ciebie (zakup), i w zależności od tego zachować się inaczej.

Najczęstsze wzorce, które pojawiają się w takich kontraktach:

Wspólne jest to, że logika jest warunkowa i przełączalna. Kontrakt nie musi być honeypotem od początku. Może się nim stać w chwili, gdy twórca wywoła funkcję ograniczającą handel.

Jak to wygląda na konkretnej liczbie?

Wyobraźmy sobie uproszczony, czysto ilustracyjny przykład (nie chodzi o zmierzone dane). Do kontraktu wpłacasz 1 ETH i kupujesz 1 000 000 tokenów. Zakup przechodzi bez problemu, bo podatek od zakupu jest ustawiony na 0 %.

Potem próbujesz sprzedać te 1 000 000 tokenów z powrotem. Powstają dwie typowe sytuacje:

1. Twardy honeypot: transakcja w ogóle nie przechodzi. Portfel zgłasza, że transakcja się nie powiodła (revert). Twoje tokeny zostają, ETH nie dostaniesz.
2. Miękki honeypot (podatkowy): sprzedaż przechodzi, ale podatek od sprzedaży wynosi 99 %. Z wartości odpowiadającej 1 ETH na konto trafia ci ekwiwalent 0,01 ETH. Formalnie "mogłeś sprzedać", realnie straciłeś prawie wszystko.

Różnica między tymi dwoma jest ważna: miękki honeypot często przechodzi powierzchowny test, bo sprzedaż technicznie działa. Dopiero spojrzenie na wynikową kwotę pokaże, że podatek pochłonął niemal całe saldo.

Jak można to przetestować przed zakupem?

Istnieje kilka procedur, które pracują tylko na publicznie dostępnych danych. Opisujemy je jako narzędzia do weryfikacji, a nie jako gwarancję.

1. Symulacja sprzedaży

Niektóre narzędzia (honeypot checkery, ewentualnie symulatory transakcji) wykonują w środowisku testowym symulowany zakup i od razu sprzedaż oraz mierzą, ile by się zwróciło. Wynikiem bywa szacowany podatek od zakupu, podatek od sprzedaży i informacja, czy sprzedaż w ogóle przejdzie. Ograniczenie: symulacja wychodzi z aktualnego stanu kontraktu. Jeśli twórca później zmieni logikę, wynik może już nie obowiązywać.

2. Czytanie zweryfikowanego kodu źródłowego

Na block explorerze (na przykład Etherscan dla Ethereum lub BscScan dla BNB Chain, patrz źródła) przy zweryfikowanych kontraktach widoczny jest kod Solidity. Śledzone wzorce:

• funkcje, które zmieniają podatki lub reguły handlu po wdrożeniu,
• warunki require wewnątrz transferu, które różnią się dla zakupu i sprzedaży,
• role typu onlyOwner, które pozwalają właścicielowi jednostronnie ingerować,
• listy adresów (_isBlacklisted i podobne).

Jeśli kontrakt nie jest zweryfikowany (kod źródłowy nie jest opublikowany), nie da się odczytać, co robi. Samo w sobie nie jest to dowodem niczego, ale jest to informacja o tym, czego nie wiesz.

3. Spojrzenie na rzeczywiste sprzedaże w łańcuchu

W historii transakcji pary da się ustalić, czy ktokolwiek w ogóle udanie sprzedał. Kiedy jest tam wiele zakupów i prawie żadnych sprzedaży, to wzorzec wart uwagi. Odwrotnie, szereg normalnych sprzedaży od różnych adresów to sygnał, że sprzedaż w tamtej chwili działała.

4. Kto trzyma i kto może zmieniać

Przydatne jest przyjrzenie się rozkładowi posiadaczy oraz temu, czy właściciel zrzekł się kontraktu (renounced), czy właściciel wciąż ma prawo zmieniać parametry. Zrzeczenie się własności zmniejsza ryzyko dodatkowej zmiany reguł, ale nie wyklucza, że logika honeypota jest już na stałe w kodzie.

Dlaczego nawet czysty test nie jest gwarancją?

Bo stan kontraktu jest zmienny w czasie. Trzy konkretne pułapki:

• Zmiana czasowa: zakup i sprzedaż dziś działają, jutro twórca wywoła funkcję, która zablokuje sprzedaż.
• Podatki progowe: podatek wzrośnie dopiero po osiągnięciu określonego wolumenu lub liczby posiadaczy.
• Kontrakty proxy: logikę da się wymienić przez aktualizowalny proxy, więc kod, który czytałeś, może już nie być tym, który się wykona.

Dlatego obowiązuje, że test mówi, jak kontrakt zachowywał się w momencie testu, a nie jak zachowa się później. Właśnie z powodu tych pułapek uznajemy wynik symulacji i czytania kodu za silną przesłankę, a nie za pewność.

Co teraz powinieneś umieć i co pozostaje niepewne

Po tej lekcji powinieneś być w stanie:

• wyjaśnić, dlaczego kontrakt potrafi rozróżnić zakup od sprzedaży,
• nazwać podstawowe wzorce honeypota (blacklist, asymetryczny podatek, blokada sprzedaży, przełączalna flaga),
• odróżnić twardy honeypot (sprzedaż nie przechodzi) od miękkiego (sprzedaż przechodzi, ale podatek zabiera prawie wszystko),
• przeprowadzić trzy weryfikacje: symulację sprzedaży, czytanie zweryfikowanego kodu i kontrolę realnych sprzedaży w łańcuchu.

Co pozostaje niepewne i nie da się tego wiarygodnie ustalić z góry: jak twórca zachowa się w przyszłości, czy zmieni parametry i czy za kontraktem proxy nie wymieni logiki. Żadne narzędzie nie daje stuprocentowej pewności, bo pracuje na przeszłym i obecnym stanie, a nie na przyszłym zamiarze.

To nie jest rekomendacja, co robić z pieniędzmi. To opis mechaniki i metod weryfikacji, abyś podejmował decyzje z otwartymi oczami.