SHINGEKINOTOKEN Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

De.Fi's REKT database lists SHINGEKINOTOKEN (TITAN) on BNB Smart Chain as an exit scam / honeypot, stating that the contract owner could disable the transfer function and so restrict users from selling their tokens. In the verified source for 0x38bea899…e66e4d, transferFrom requires allow[_from] == true, and the allow mapping is set to true only for the deployer in the constructor. Holders default to false, so a sell that pulls their tokens with transferFrom (for example a router swap) reverts, while plain transfer is unrestricted.

A hard-coded address can flip any holder's flag with addAllow and overwrite any balance with mint. The listing gives no loss figure and no transaction, so what happened on the chain is taken from De.Fi's listing only.

How it happened

  1. The constructor sets balances[msg.sender] = totalSupply; and allow[msg.sender] = true;. No other address is given allow = true in the constructor, so every other address starts with allow unset (false).
  2. transfer has no allow check: require(balances[msg.sender] >= _value); followed by the balance update, so holders can send tokens directly and a pair can send tokens out to a buyer.
  3. transferFrom adds the line require(allow[_from] == true); on the token owner (_from). Any sell that relies on a spender pulling the holder's tokens, such as a router swap after the holder approves it, reverts for a holder whose allow flag is false. approve is unrestricted, so the approval succeeds and only the sale fails.
  4. addAllow(address holder, bool allowApprove) writes allow[holder] = allowApprove; and can be called only through the onlyOwner modifier, which is require(msg.sender == address(1080614020421183795110940285280029773222128095634)), a hard-coded address that is 0xbd486897…439192 in hexadecimal. It is not the owner variable and differs from the deployer 0xe13133C2…094699 given in the deployment data. That address can enable selling for chosen holders and disable it again for any of them.
  5. The same address can call mint(address miner, uint256 _value), whose body is balances[miner] = _value;. It overwrites the balance of any address with any value (including zero) without changing totalSupply.
  6. transferOwnership changes only the unused owner variable and is itself behind the hard-coded onlyOwner check, so access to addAllow and mint cannot be moved or renounced in this source.
  7. The source shows these powers but not how they were used: no transaction was opened showing addAllow or mint being called. The header comment promises 6% of trades to liquidity and 4% to holders, but the source contains no fee logic. De.Fi's REKT database lists the token as an exit scam / honeypot.

Protocol details

Classification Token
Protocol Type Exit Scam/Honeypot
Affected asset / contract TITAN

Evidence

Same attack technique

Browse all hacks →
BNB Chain ElonTech Loss not disclosed BNB Chain KitKat Loss not disclosed Ethereum Goldfinch Finance Loss not disclosed Ethereum element.fi Loss not disclosed

Build your security review skills

Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.

Start Free Trial Explore attack classes