Et Honeypot-token er en ondsindet kryptovaluta skabt af udviklere, der med vilje indsætter begrænsninger eller bagdøre i den smarte kontrakt. Dette giver almindelige brugere mulighed for at købe tokenet, men forhindrer dem i at sælge det (eller gør salg underlagt ekstremt høje gebyrer/sortlistemekanismer), hvilket effektivt fanger deres penge i deres tegnebøger. På overfladen kan sådanne tokens virke legitime - de kan have likviditetspar, token-logoer og aktiv fællesskabspromovering - men når en bruger køber tokenet på en decentral børs, opdager de hurtigt, at salget afvises, eller at transaktionsgebyrerne er så høje, at det bliver umuligt at genvinde deres investering.
Hvordan man undgår tab, og hvordan man tjekker
Du kan indtaste tokenets kontraktadresse i en blockchain explorer såsom OKLINK (som vist i eksemplet nedenfor). Hvis tokenet er en Honeypot, vil det normalt blive markeret i overensstemmelse hermed. ,
2. Da nye tokens lanceres på blockchain hver dag, og opdagelsesrejsende muligvis ikke opdaterer i tide, kan du udføre en manuel selvkontrol ved hjælp af følgende metoder. , Tjek i fanen Læs kontrakt:
owner() — Hvis det returnerer en anden værdi end 0x000..., betyder det, at ejeren stadig har kontrol.
totalSupply() og balanceOf() — Bekræft den indledende tokenfordeling.
Se efter funktioner eller variabler såsom isExcludedFromFee(adresse), isBlacklisted(address), maxTxAmount() og tradingEnabled() (forskellige kontrakter kan bruge forskellige navne, men de tjener lignende formål). , I fanen Skriv kontrakt (kun tilgængelig, hvis du har tilladelse):
Tjek om der er følsomme skrivefunktioner som f.eks setFeePercent, setBlacklist, renounceOwnership eller setTradingEnabled. Hvis disse findes og kun kan kaldes af ejeren, indebærer tokenet høj risiko. , Søg i kildekoden efter følgende søgeord (der skelnes mellem store og små bogstaver eller med understregninger): blacklist, isBot, onlyOwner, setFee, maxTx, excludedFromFee, trading, swapAndLiquify, transferFrom, approve, mint, burn, renounce Ownership, liquidity.
Vær særlig opmærksom på implementeringen af "transfer", "_transfer" og "transferFrom" - tjek, om de håndterer "to == pair" eller "from == pair" forskelligt (for at skelne mellem køb og salg).
Hvis du finder kode som f.eks
require(!_er sortlistet[fra]); hvis (til == par) { gebyr = 99; }
dette er et klart rødt flag. , Tjek, om kontrakten kalder en router (f.eks. Pancake/Uniswap Router), og om swap-processen indeholder kompleks logik såsom lockTheSwap eller _tax, som kan forhindre normal swapping.