Honeypot žetoni: kupiš jih lahko, prodaš pa ne. Kako to počne pametna pogodba in kako to preizkusiš

Kaj je honeypot v enem stavku?

Honeypot je žeton, pri katerem ti pogodba omogoči nakup, prodajo pa tehnično onemogoči ali jo obremeni s tako visoko provizijo, da ti od prodaje ostane skoraj nič. Na grafu izgleda kot raketa, ki samo raste, ker skoraj nihče ne more prodati.

Pomembno: v tem besedilu opisujemo splošne vzorce v kodi in v podatkih, ne konkretnih projektov. Ne trdimo, da je katerikoli žeton prevara. Prikazujemo, kako mehanizem deluje in kako ga človek lahko sam preveri. Mehanika, ki jo tu navajamo, izhaja iz javne dokumentacije standarda ERC-20, jezika Solidity in dokumentacije decentraliziranih borz (Uniswap, PancakeSwap), na katero se sklicujemo v virih.

Kako to pogodba tehnično naredi?

Žeton na EVM verigah (Ethereum, BNB Chain in podobne) je zgolj pametna pogodba. Po standardu ERC-20 prenos žetona poteka skozi funkcijo transfer ali transferFrom (glej dokumentacijo ERC-20 in OpenZeppelin v virih). V telo te funkcije lahko ustvarjalec v Solidity zapiše poljubne pogoje. Nakup in prodaja pri tem nista dve različni funkciji, sta zgolj prenosa med tvojo denarnico in likvidnostnim parom (na primer na Uniswapu ali PancakeSwapu, katerih mehaniko parov opisuje njihova dokumentacija). To je ključ: pogodba zna razločiti, ali žetoni odhajajo k likvidnostnemu paru (prodaja) ali od para k tebi (nakup), in se glede na to obnaša drugače.

Najpogostejši vzorci, ki se v takih pogodbah pojavljajo:

Skupno je, da je logika pogojna in preklopljiva. Pogodba ni nujno honeypot od začetka. Lahko to postane v trenutku, ko ustvarjalec pokliče funkcijo, ki trgovanje omeji.

Kako to izgleda na konkretni številki?

Predstavljajmo si poenostavljen, čisto ilustrativen primer (ne gre za izmerjene podatke). V pogodbo vložiš 1 ETH in kupiš 1.000.000 žetonov. Nakup gre skozi brez težav, ker je davek na nakup nastavljen na 0 %.

Nato poskusiš prodati teh 1.000.000 žetonov nazaj. Nastopita dve tipični situaciji:

1. Trdi honeypot: transakcija sploh ne gre skozi. Denarnica javi, da je transakcija spodletela (revert). Tvoji žetoni ostanejo, ETH ne dobiš.
2. Mehki honeypot (davčni): prodaja gre skozi, a je davek na prodajo 99 %. Od vrednosti, ki ustreza 1 ETH, ti na račun pride ekvivalent 0,01 ETH. Formalno si "lahko prodal", v resnici pa si ostal skoraj brez vsega.

Razlika med tema dvema je pomembna: mehki honeypot pogosto prestane površen test, ker prodaja tehnično deluje. Šele pogled na končni znesek pokaže, da je davek pogoltnil skoraj celoten dobropis.

Kako to človek lahko preizkusi pred nakupom?

Obstaja več postopkov, ki delajo samo z javno dostopnimi podatki. Opisujemo jih kot orodja za preverjanje, ne kot jamstvo.

1. Simulacija prodaje

Nekatera orodja (honeypot checkerji, po možnosti simulatorji transakcij) v testnem okolju izvedejo simulirani nakup in takoj prodajo ter izmerijo, koliko bi se vrnilo. Izhod je običajno ocenjeni davek na nakup, davek na prodajo in informacija, ali prodaja sploh gre skozi. Omejitev: simulacija izhaja iz trenutnega stanja pogodbe. Če ustvarjalec logiko pozneje spremeni, rezultat morda ne velja več.

2. Branje preverjene izvorne kode

Na block explorerju (na primer Etherscan za Ethereum ali BscScan za BNB Chain, glej vire) je pri preverjenih pogodbah viden Solidity kod. Opazovani vzorci:

• funkcije, ki spreminjajo davke ali trgovalna pravila po namestitvi,
• pogoji require znotraj prenosa, ki se razlikujejo za nakup in prodajo,
• vloge tipa onlyOwner, ki lastniku omogočajo enostransko poseganje,
• seznami naslovov (_isBlacklisted in podobno).

Če pogodba ni preverjena (izvorna koda ni objavljena), se ne da prebrati, kaj počne. To samo po sebi ni dokaz ničesar, je pa informacija o tem, česa ne veš.

3. Pogled na dejanske prodaje na verigi

V zgodovini transakcij para se da ugotoviti, ali je sploh kdo uspešno prodal. Ko je tam veliko nakupov in skoraj nič prodaj, je to vzorec, ki si zasluži pozornost. Nasprotno je vrsta normalnih prodaj z različnih naslovov signal, da je prodaja v tistem trenutku delovala.

4. Kdo drži in kdo lahko spreminja

Koristno je pogledati razporeditev imetnikov in to, ali je lastništvo pogodbe odpovedano (renounced) ali ima lastnik še vedno pravico spreminjati parametre. Odpoved lastništva zmanjša tveganje naknadne spremembe pravil, a ne izključuje, da je honeypot logika že trdno zapisana v kodi.

Zakaj tudi čist test ni jamstvo?

Ker je stanje pogodbe spremenljivo v času. Tri konkretne pasti:

• Časovna sprememba: nakup in prodaja danes delujeta, jutri ustvarjalec pokliče funkcijo, ki prodajo blokira.
• Pragovni davki: davek se poviša šele po dosegu določenega obsega ali števila imetnikov.
• Proxy pogodbe: logiko se da zamenjati prek nadgradljivega proxyja, tako da koda, ki si jo prebral, morda ni več tista, ki se izvede.

Zato velja, da test pove, kako se je pogodba obnašala v trenutku testa, ne kako se bo obnašala pozneje. Prav zaradi teh pasti imamo rezultat simulacije in branja kode za močan namig, ne za gotovost.

Kaj bi zdaj moral znati in kaj ostaja negotovo

Po tej lekciji bi moral biti sposoben:

• razložiti, zakaj zna pogodba razločiti nakup od prodaje,
• poimenovati osnovne vzorce honeypota (blacklist, asimetrični davek, blokada prodaje, preklopni flag),
• razločiti trdi honeypot (prodaja ne gre skozi) od mehkega (prodaja gre skozi, a davek pobere skoraj vse),
• izvesti tri preveritve: simulacijo prodaje, branje preverjene kode in preveritev realnih prodaj na verigi.

Kaj ostaja negotovo in se tega ne da zanesljivo ugotoviti vnaprej: kako se bo ustvarjalec obnašal v prihodnosti, ali bo spremenil parametre in ali za proxy pogodbo ne bo zamenjal logike. Nobeno orodje ne daje stoodstotne gotovosti, ker dela s preteklim in sedanjim stanjem, ne s prihodnjim namenom.

To ni priporočilo, kaj početi z denarjem. Je opis mehanike in metod preverjanja, da se odločaš z odprtimi očmi.