Sifchain Finance Honeypot

Reported loss $208K
Ethereum
Honeypot

What happened

A token named Sifchain Finance (EROWAN) at 0x2f2F344E…c25C10 was deployed on 2021-01-04 by 0x347e33C8…725082. De.Fi's REKT database lists it as an exit scam / honeypot on 2021-01-06 with a loss of 207,718 USD, and says the owner could disable the transfer function so that users could not sell. The source has no single transfer switch; the controls that can make a sell fail or pay nothing are an owner-filled blacklist that silently swallows transfers, a sell-side fee that is read from an external contract, and a developer flag that bypasses allowances and fees.

On-chain, per Etherscan: the deployer added 160 ETH and 50,000,000 EROWAN to a new Uniswap V2 pool in 0x43659257…6be02c (2021-01-04 19:17 UTC), and on 2021-01-06 at 01:06 UTC the same address called removeLiquidityETH in 0x079782c0…2761db and received 310.08 ETH and about 25.93 million EROWAN. The page shows that the pool held more ETH at removal than the deployer had added; whether any holder was blocked from selling in between is not shown by the opened pages.

How it happened

  1. What the code allows: the constructor credits the full supply to the deployer, sets allowance[msg.sender][router] = uint256(-1); and derives the Uniswap pair address (UNI = pairFor(weth, address(this));), so the deployer can list the token immediately.
  2. What the code allows: function block(address[] memory _to) onlyOwner public payable returns (bool) writes blacklist[to] = true; for each address. In transferFrom, balanceOf[_from] -= _value; runs first and then if (blacklist[_to] || blacklist[_from]) {return true;}. A transfer involving a blacklisted address therefore returns success, debits the sender, credits nobody and emits no Transfer event. If the pair address were blacklisted, every buy and every sell would burn the holder's tokens without payment.
  3. What the code allows: sells through the pair are charged by getFee: if (paid && _to == UNI && _from != owner && developer[_from] == 0) { return Management(manager).getFee(address(this), UNI, _value); }. The amount comes from a separate contract at the hard-coded address 0x0F450Ddc…A22Fa6, whose code is not part of this evidence, and the token applies no cap: balanceOf[_to] += (_value - fee); while the seller was already debited the full _value. The gate flag flips with function () payable external {paid = true;} (any ETH sent to the token) or with block.
  4. What the code allows: batchSend sets developer[to] = 1; for recipients, and the allowance check is skipped when developer[tx.origin] is set (if (msg.sender != _from && developer[tx.origin] == 0)), so a developer-flagged transaction origin can call transferFrom on any holder's balance without an approval. Developers are also exempt from the sell fee. delegate(address a, bytes memory b) onlyOwner runs arbitrary code in the token's storage context, so the owner can rewrite any of this later.
  5. What was recorded: the deployer funded the pool with 160 ETH and 50,000,000 EROWAN, then removed liquidity two days later for 310.08 ETH and about 25.93 million EROWAN in 0x079782c0…2761db. Removing liquidity needs no token-code control, only ownership of the LP tokens.

Protocol details

Classification Exchange (DEX)
Protocol Type Exit Scam/Honeypot
Affected asset / contract EROWAN

Evidence

Same attack technique

Browse all hacks →
Ethereum Galaxy DeFi $39K lost Ethereum EASYPump $3K lost Ethereum Stable Yield Credit $494K lost Ethereum Harvester Network $6K lost

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