Honeypot tokeni: kupiš, ali ne prodaješ. Kako to radi smart ugovor i kako to sam testirati

Što je honeypot u jednoj rečenici?

Honeypot je token kod kojeg vam ugovor omogućuje kupnju, ali prodaju tehnički onemogući ili je opterećuje tako visokom naknadom da vam od prodaje ne ostane gotovo ništa. Na grafu to izgleda kao raketa koja samo raste, jer gotovo nitko ne može prodati.

Važno: u ovom tekstu opisujemo opće obrasce u kodu i u podacima, ne konkretne projekte. Ne tvrdimo da je bilo koji token prijevara. Pokazujemo kako mehanizam funkcionira i kako ga čovjek može provjeriti sam. Mehanika koju ovdje navodimo proizlazi iz javne dokumentacije standarda ERC-20, jezika Solidity i dokumentacije decentraliziranih burzi (Uniswap, PancakeSwap), na koju upućujemo u izvorima.

Kako to ugovor tehnički napravi?

Token na EVM lancima (Ethereum, BNB Chain i slično) samo je smart ugovor. Prema standardu ERC-20 prijenos tokena prolazi kroz funkciju transfer ili transferFrom (vidi dokumentaciju ERC-20 i OpenZeppelin u izvorima). U tijelo te funkcije autor može u Solidityju upisati proizvoljne uvjete. Kupnja i prodaja pritom nisu dvije različite funkcije, one su samo prijenosi između vaše novčanice i likvidnosnog para (na primjer na Uniswapu ili PancakeSwapu, čiju mehaniku parova opisuje njihova dokumentacija). To je ključ: ugovor može razlikovati odlaze li tokeni prema likvidnosnom paru (prodaja) ili od para prema vama (kupnja) i sukladno tome ponašati se drukčije.

Najčešći obrasci koji se u takvim ugovorima pojavljuju:

Zajedničko je da je logika uvjetovana i preklopljiva. Ugovor ne mora biti honeypot od početka. Može to postati u trenutku kad autor pozove funkciju koja ograniči trgovanje.

Kako to izgleda na konkretnoj brojci?

Zamislimo pojednostavljen, čisto ilustrativan primjer (nije riječ o mjerenim podacima). U ugovor uložite 1 ETH i kupite 1 000 000 tokena. Kupnja prođe bez problema, jer je porez na kupnju postavljen na 0 %.

Zatim pokušate prodati tih 1 000 000 tokena natrag. Nastaju dvije tipične situacije:

1. Tvrdi honeypot: transakcija uopće ne prođe. Novčanica javlja da transakcija nije uspjela (revert). Vaši tokeni ostaju, ETH ne dobijete.
2. Meki honeypot (porezni): prodaja prođe, ali porez na prodaju iznosi 99 %. Od vrijednosti koja odgovara 1 ETH na račun vam dođe ekvivalent od 0,01 ETH. Formalno ste "mogli prodati", stvarno ste ostali skoro bez svega.

Razlika između te dvije situacije je važna: meki honeypot često prođe površan test, jer prodaja tehnički funkcionira. Tek pogled na konačan iznos pokaže da je porez progutao gotovo cijeli saldo.

Kako to čovjek može testirati prije kupnje?

Postoji nekoliko postupaka koji rade samo s javno dostupnim podacima. Opisujemo ih kao alate za provjeru, ne kao jamstvo.

1. Simulacija prodaje

Neki alati (honeypot checkeri, odnosno simulatori transakcija) u testnom okruženju izvrše simuliranu kupnju i odmah prodaju te izmjere koliko bi se vratilo. Rezultat je obično procijenjeni porez na kupnju, porez na prodaju i informacija hoće li prodaja uopće proći. Ograničenje: simulacija polazi od trenutnog stanja ugovora. Ako autor logiku kasnije promijeni, rezultat više ne mora vrijediti.

2. Čitanje verificiranog izvornog koda

Na block exploreru (na primjer Etherscan za Ethereum ili BscScan za BNB Chain, vidi izvore) kod verificiranih ugovora vidljiv je Solidity kod. Praćeni obrasci:

• funkcije koje mijenjaju poreze ili pravila trgovanja nakon postavljanja,
• uvjeti require unutar prijenosa koji se razlikuju za kupnju i prodaju,
• uloge tipa onlyOwner, koje vlasniku omogućuju jednostrano zahvaćanje,
• popisi adresa (_isBlacklisted i slično).

Ako ugovor nije verificiran (izvorni kod nije objavljen), ne može se pročitati što radi. To samo po sebi nije dokaz ničega, ali je informacija o tome što ne znate.

3. Pogled na stvarne prodaje na lancu

U povijesti transakcija para može se utvrditi je li uopće netko uspješno prodao. Kad je tamo mnogo kupnji i gotovo nijedna prodaja, to je obrazac koji zaslužuje pozornost. Suprotno tome, niz normalnih prodaja s različitih adresa signal je da je prodaja u tom trenutku funkcionirala.

4. Tko drži i tko može mijenjati

Korisno je pogledati raspodjelu držatelja i to je li vlasništvo nad ugovorom napušteno (renounced) ili vlasnik i dalje ima pravo mijenjati parametre. Napuštanje vlasništva smanjuje rizik naknadne promjene pravila, ali ne isključuje da je honeypot logika već čvrsto ugrađena u kod.

Zašto ni čist test nije jamstvo?

Zato što je stanje ugovora promjenjivo kroz vrijeme. Tri konkretne zamke:

• Vremenska promjena: i kupnja i prodaja danas rade, sutra autor pozove funkciju koja blokira prodaju.
• Pragovni porezi: porez se poveća tek nakon dostizanja određenog volumena ili broja držatelja.
• Proxy ugovori: logika se može zamijeniti preko nadogradivog proxyja, pa kod koji ste čitali više ne mora biti onaj koji se izvrši.

Zato vrijedi da test govori kako se ugovor ponašao u trenutku testa, ne kako će se ponašati kasnije. Upravo zbog tih zamki rezultat simulacije i čitanja koda smatramo snažnom indicijom, ne sigurnošću.

Što biste sada trebali znati i što ostaje neizvjesno

Nakon ove lekcije trebali biste biti sposobni:

• objasniti zašto ugovor može razlikovati kupnju od prodaje,
• imenovati osnovne obrasce honeypota (blacklist, asimetrični porez, blokada prodaje, preklopljiv flag),
• razlikovati tvrdi honeypot (prodaja ne prođe) od mekog (prodaja prođe, ali porez uzme skoro sve),
• provesti tri provjere: simulaciju prodaje, čitanje verificiranog koda i kontrolu stvarnih prodaja na lancu.

Što ostaje neizvjesno i ne može se pouzdano utvrditi unaprijed: kako će se autor ponašati u budućnosti, hoće li promijeniti parametre i neće li iza proxy ugovora zamijeniti logiku. Nijedan alat ne daje stopostotnu sigurnost, jer radi s prošlim i sadašnjim stanjem, ne s budućom namjerom.

Ovo nije preporuka što raditi s novcem. To je opis mehanike i metoda provjere, kako biste odluke donosili otvorenih očiju.