NETVRK Honeypot

Reported loss Not disclosed
Ethereum
Honeypot

What happened

De.Fi's REKT database lists NETVRK on Ethereum as an exit scam / honeypot, stating that the contract owner could disable the transfer function, which restricted users in selling their tokens. The verified source at 0x651255b4…dd340e shows a transfer filter, the modifier burnTokenCheck, that lets the owner, a privileged _safeOwner address and whitelisted addresses move tokens freely while other senders can only send to the hard-coded Uniswap V2 router address or to the owner. A normal sell sends tokens from the holder to a pair rather than to the router address, so it reverts with a balance-style error message.

Every switch is gated on _owner, and the contract has no function to change or renounce _owner. The deployer was 0xbd5748B0…69cB59 (deployment transaction 0x40bed187…a0d656).

How it happened

  1. The constructor sets _owner = owner; and _safeOwner = owner; and hard-codes address private _unirouter = 0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D;. _sellAmount starts at 0.
  2. Both transfer and transferFrom call _approveCheck, which runs the burnTokenCheck modifier before moving balances. The first branch is if (_owner == _safeOwner && sender == _owner){_safeOwner = recipient;_;}: while _safeOwner still equals the owner, the owner's first transfer passes and sets _safeOwner to that transfer's recipient.
  3. After that, transfers pass if sender == _owner || sender == _safeOwner || recipient == _owner, so holders can always send tokens to the owner, and the _safeOwner address can send freely. _whiteAddress[sender] == true also passes.
  4. Every other sender hits require((sender == _safeOwner)||(recipient == _unirouter), "ERC20: transfer amount exceeds balance") unless amount < _sellAmount. Because _sellAmount starts at 0, amount < _sellAmount is false for every amount, so a non-privileged sender can only send to the router address. A sell through a router moves tokens from the holder to a pair, which is neither the router address nor the owner, so it reverts. Whether the buy side works depends on whether the pair is whitelisted or equals _safeOwner, which the code alone does not show.
  5. The owner can reshape this with owner-only functions whose names suggest ERC-20 allowance helpers: increaseAllowance(address[] receivers) whitelists addresses, addApprove(address[] receivers) blacklists them, decreaseAllowance(address safeOwner) replaces _safeOwner, and multiTransfer can whitelist recipients and approve the router for them. A self-transfer by the owner (if (sender == _owner && sender == recipient){_sellAmount = amount;}) sets _sellAmount; after that, non-blacklisted senders may send amounts below it to any recipient, and a recipient equal to _safeOwner flips the sender onto the blacklist (_blackAddress[sender] = true;).
  6. Separately, _mint(address account, uint256 amount) is public and checks only msg.sender == _owner, then credits _balances[_owner], so the owner can increase supply at any time.
  7. What the code allows is separate from what happened: no transaction was opened showing the owner calling any of these functions or who was unable to sell, so the outcome rests on De.Fi's listing.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain FULLMOON Loss not disclosed Ethereum Kwikswap Loss not disclosed BNB Chain BOMB Token Loss not disclosed BNB Chain SAFEOXYGEN Token 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