RAICHU TOKEN | raichutoken.com Honeypot

What happened

RAICHU TOKEN (raichutoken.com) is an ERC20 token on Ethereum, deployed on 2021-06-20 as contract 0xe18cccde…d35dd4. De.Fi's REKT database lists it as an exit scam / honeypot in which the owner could stop holders from selling. The verified source supports that: transferFrom, the call a DEX router uses to pull a seller's tokens into a pool, reverts unless allow[_from] == true.

Only the deployer is set to true in the constructor; every other holder is false until a single hard-coded address calls addAllow. Plain transfer, which is how a pool pays out a buyer, has no such check.

How it happened

1. The constructor gives the whole supply to the deployer and whitelists only that address: balances[msg.sender] = totalSupply; allow[msg.sender] = true;. The mapping allow is mapping(address => bool), so every other address starts at false.
2. transferFrom contains the gate: require(allow[_from] == true); alongside the usual balance and allowance checks. _from is the holder whose tokens are being moved.
3. A sell on a DEX has the router call transferFrom(holder, pool, amount). For an ordinary holder allow[holder] is false, so the call reverts even when the holder has approved the router and has enough balance. transfer has no allow check, so a pool can still send tokens to a buyer. The result is that holders can buy but cannot sell through the router unless whitelisted.
4. The gate is controlled by function addAllow(address holder, bool allowApprove) external onlyOwner { allow[holder] = allowApprove; }. The modifier is modifier onlyOwner() {require(msg.sender == address(0x8c1442F868eFE200390d9b850264014557A38B45));_;}: it compares against a hard-coded address, not the owner state variable, and that address differs from the deployer 0xEe80ba78…F77076. Which party controls 0x8c1442F8…A38B45 is not shown by the code.
5. transferOwnership is itself onlyOwner, but it only rewrites the owner variable, which no other function reads, so it does not move the addAllow power. Because the check is a constant, the power cannot be transferred or renounced by any function in the contract.
6. The code has no mint function and no function that touches a liquidity pool. No source opened here shows whether sells actually failed, who was whitelisted, or what happened to the liquidity.

Protocol details

Classification Token

Protocol Type Exit Scam/Honeypot

Affected asset / contract RAICHU | @raichutoken

Evidence

• report @Token_Sniffer incident report twitter.com
• address RAICHU TOKEN verified source on Etherscan (contract 0xe18cccde4c795e505c2edf1b3c50405849d35dd4) etherscan.io
• analysis RAICHU TOKEN Sourcify match repo.sourcify.dev