ElonCash Honeypot

What happened

ElonCash (ECS) is a BNB Smart Chain token whose burnTokenCheck modifier wraps every transfer and transferFrom. With its default state, a holder who has not been whitelisted can only send tokens to one hard-coded _unirouter address, so a sale into a liquidity pair is rejected. De.Fi's REKT database lists the token as an exit scam/honeypot and states that the owner could disable the transfer function, which restricted users in selling their tokens.

The code also lets the owner whitelist or blacklist addresses, redirect the privileged _safeOwner and mint to the owner.

How it happened

1. The constructor stores the owner and sets the same address as the privileged account: _owner = owner; _safeOwner = owner;. _unirouter is hard-coded as 0x05fF2B0DB69458A0750badebc4f9e13aDd608C7F, and _sellAmount starts at 0.
2. Both transfer and transferFrom call _approveCheck, which is guarded by burnTokenCheck(sender,recipient,amount). The sender's balance is debited normally inside _approveCheck; the modifier only decides whether the call runs.
3. First branch: if (_owner == _safeOwner && sender == _owner){_safeOwner = recipient;_;}. While _safeOwner still equals the owner, the first transfer from the owner makes its recipient the new _safeOwner. The source does not say who that recipient is.
4. Second branch: if (sender == _owner || sender == _safeOwner || recipient == _owner) lets the call run. Anyone can therefore send tokens to _owner. A self-transfer by the owner also executes _sellAmount = amount;.
5. Any other sender: whitelisted addresses pass. A blacklisted sender passes only if recipient == _unirouter, because sender == _safeOwner was already handled above. An address on neither list passes if amount < _sellAmount, otherwise only if (sender == _safeOwner)||(recipient == _unirouter). With _sellAmount at its initial 0, amount < _sellAmount is never true.
6. A router-style sale calls transferFrom(holder, pair, amount). For a non-whitelisted holder the recipient is the pair, not _unirouter, so it reverts with ERC20: transfer amount exceeds balance, unless the holder is whitelisted or the amount is below a non-zero _sellAmount. Likewise a purchase pays out from the pair; it passes only if the pair is _safeOwner or whitelisted, which the source does not show.
7. Owner powers: increaseAllowance(address[]) whitelists and un-blacklists, addApprove(address[]) blacklists and un-whitelists, decreaseAllowance(address safeOwner) sets _safeOwner to any address, multiTransfer airdrops and whitelists the first approvecount recipients while granting _unirouter a maximum allowance, and _mint(address account, uint256 amount) is public but requires msg.sender == _owner and adds amount to _balances[_owner]. The source has no function to change or renounce _owner.
8. Whether the owner used any of these functions is not shown by the source. De.Fi's REKT database lists the token as a honeypot dated 2021-05-18.

Protocol details

Classification Token

Protocol Type Exit Scam/Honeypot

Affected asset / contract ECS

Evidence

• report De.Fi REKT database entry for ECS (proof link: Token Sniffer X post, 404 when fetched) twitter.com
• address BscScan verified source, ElonCash bscscan.com
• analysis Sourcify repository, chain 56 repo.sourcify.dev