ElonTech Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

De.Fi's REKT database lists ElonTech (ELONTECH) 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 0x69b956b4…8b4945, a stored address newun is blocked as a destination: transfer and transferFrom both run require(to != newun, "please wait"). The first transferFrom call with a non-zero from assigns newun = to, and the owner can reassign it with transfernewun.

If that address is the exchange pair, every sell and every later liquidity deposit reverts, while buys, which send tokens out of the pair, still work. The contract's header comment promises 2% reflection, 2% auto liquidity and 1% burn, but the source implements no fee. The listing gives no loss figure, so what happened on the chain is taken from De.Fi's listing only.

How it happened

  1. The constructor sets symbol = "ELONTECH"; name = "ElonTech"; decimals = 8; _totalSupply = 100000000000000000000; and assigns the whole supply with balances[owner] = _totalSupply;, where owner is the deployer (owner = msg.sender;).
  2. The state variable address public newun; starts at the zero address. The first transferFrom call hits if(from != address(0) && newun == address(0)) newun = to; and records the recipient to as newun; the tokens still move, because that branch has no require. When this first transferFrom is the liquidity deposit, newun becomes the pair address (this is the pattern the cited blog post describes for other tokens).
  3. From then on every transferFrom takes the else branch, else require(to != newun, "please wait");, and transfer starts with require(to != newun, "please wait");. Any transfer whose recipient is newun reverts, whoever the sender is. A router sell moves the seller's tokens to the pair with transferFrom, so it reverts with "please wait". A buy sends tokens from the pair to the buyer, whose address is not newun, so it passes.
  4. The owner can change the target: function transfernewun(address _newun) public onlyOwner { newun = _newun; }. Pointing it at an address that is never used as a recipient lifts the block. Setting it back to the zero address re-arms capture, because the next transferFrom with a non-zero from assigns newun = to again. The owner can also point it at any other address to block transfers into it.
  5. ElonTech adds function clearCNDAO() public onlyOwner() { address payable _owner = msg.sender; _owner.transfer(address(this).balance); }, which sends any BNB held by the token contract to the caller. The derived contract declares function() external payable { }, so the contract can receive BNB. This does not touch holders' token balances.
  6. Ownership uses transferOwnership and acceptOwnership; no function renounces it. The header comment promises 2% reflection, 2% auto liquidity, 1% burn and locked liquidity, but transfer and transferFrom move the full amount (balances[to] = balances[to].add(tokens);) with no fee logic.
  7. The source shows these powers but not how they were used: no transaction was opened showing transfernewun being called, what newun held, or which holders were blocked. 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 ELONTECH

Evidence

Same attack technique

Browse all hacks →
BNB Chain Binance-Peg Polygon Loss not disclosed Ethereum SuperSwap Loss not disclosed BNB Chain KitKat Loss not disclosed BNB Chain SHINGEKINOTOKEN 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