Van Pelt (ETH Token Hunter)
❌ Bitcoin Mascot (ALPACA)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0x0e368c4b35ba9dbe9d62db70a9240f48bc230942
TLDR: backdoor implemented
The function setfee, declared as external and callable from the _FeeAddress1 wallet, can be executed even after the renounce and can change without any control the contract taxes.
Care.
❌ CompareAi (CAI)
📊 https://dextools.io/app/en/ether/pair-explorer/0x4554d36d462599ebb1ecc82a79391965774488a9
TLDR: misleading function, can modify taxes and honeypot
The function TaxRemove (2), callable even after the renounce from dev wallet dev wallet, triggers the function _RemeveTax that can be used to change the taxes withouth any limit.
Avoid it.
❌ ZergRush (RUSH)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0x8e66b3cf6bea4526ec8823c2d858b4e7def59451
TLDR: hidden mint
The portion of code in the image (1) contained in the transfer function of the contract can be used to mint token directly into the contract address thanks to the function RUSHlotaawteryer (2)
Care.
❌ GIB Token (GIB)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0x74db9d61fc0f02726441b41d9ae9a258114daf0b
TLDR: backdoor function, can mint token
The function _setGIBCoin (1 - callable even after the renounce from a dev wallet) can be used to honeypot and mint token. This function modifies the values BurnFigure and ConfirmFigure used in the transfer method of the sc (2)
Avoid it.
❌ Hello Kitty (KITTY)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0xefd1eda2a6235b6e2d943c56a4d34ef13ac1bdf6
TLDR: misleading function, can modify taxes and honeypot
The function TaxRemove (2), callable even after the renounce from dev wallet dev wallet, triggers the function _remeveTax that can be used to change the taxes withouth any limit.
Avoid it.
❌ Grok Cyber ($GrokCyber)
📊 https://etherscan.io/address/0x22aCB1b4969517A0B1a50F8d54291d1481A9B504#code
TLDR: Hidden Mint
The function enquiryBalance, callable even after the renounce from the _safu wallet, can be used to mint token and drain the liquidity
Avoid it.
❌ Groooook.io (Groooook)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0x2433d5b09052bfafe278d83453825a852ea6cd79
TLDR: backdoor function, can mint token
The function _setRedeemBurn (1 - callable even after the renounce from a dev wallet) can be used to honeypot and mint token. This function modifies the values BurnFigure and ConfirmFigure used in the transfer method of the sc (2)
Avoid it.
❌ Magic Grok Money ($BITCOIN)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0x99f37797ada67a1ed00d6034b562e5c7982b9095
TLDR: hidden mint
The portion of code in the image (1) contained in the transfer function of the contract can be used to mint token directly into the contract address thanks to the function greggle (2)
Care.
⚠️ The Dogefather (DOGEFATHER)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0x1b708004995ecf64020c9a22d0c0b13fba7a1b3f
TLDR: backdoor function
The function reduceTax is a potential backdoor function that can be used to modify the sell tax without any limit even after the renounce.
Care.
❌ Money Laundering Machine (MLM)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0x0466fec2f3c8c532ff114988c81f90ca37e4b037
TLDR: mint function
This happened some minutes ago.
The function swapTokensForEth (usually used to collect token taxes) was modified by the dev in order to set the amount of token in the contract to the total supply (highlighted in the image) and dump it, thus draining all the liquidity
❌ Bozos (bozo)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0x5982f9d18a8eae138dfef494816170a58d7da0f7
TLDR: backdoor function, can mint token
The function _setbozo (1 - callable even after the renounce from a dev wallet) can be used to honeypot and mint token. This function modifies the values BurnFigure and ConfirmFigure used in the transfer method of the sc (2)
Avoid it.
❌ Sanctuary AI (PHOENIX)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0x401582d892cf2dd7dcab37d5a8db5f6328107ea7
TLDR: hidden mint
This happened a bit ago but I want to explain it anyway.
Thanks to the two portions of code highlighted in the image (1 and 2, contained in the transfer function of the sc) the dev was able to mint token during a transaction with the following parameters:
- An amount of token greater than he actually held in the wallet
- The recipient defined as the contract
After this mechanism was triggered the dev called the function manualSwap, usually used to retrieve stucked token or eth, and drained all the liquidity
❌ MONKE (MONKE)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0x157d68f309e66275471a40ee45e87b386cfafb9b
TLDR: auto honeypot mechanism
Through the "if" statement of the first portion of the image (1 - transfer function of the ca), the dev can trigger the function shouldExclude (2) when he executes a sell from the feeWallet.
This sell action triggers the function checkAllowance (4) that sets the variable denominator to 0.
This variable is used in the sendAllEth function (3) used to collect taxes.
After this mechanism is triggered the line:
uint256 devETHAmount = amount / denominator;
will contain a division by zero that we know is not possible and that will prevent any sell.
❌ BABY YES (BABYYES)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0xf18ff8d90931706342b7152e010bb7dac200fce2
TLDR: honeypot mechanism and mint
The function approve (1), callable even after the renounce from the dev wallet, can be used to mark certain account that won't be able to sell the token (99.9% tax).
The function removedLimits (2) can be used to mint token and drain all the liquidity.
Avoid it.
❌ GROKAI (GROKAI)
📊 https://etherscan.io/address/0xa16ec96022e5a8f2d2c9dbcd0ec347be552c1fec#code
TLDR: backdoor function, can mint token
The function setGRAI (1 - callable even after the renounce from a dev wallet) can be used to honeypot and mint token. This function modifies the values BurnAmount and ConfirmAmount used in the transfer method of the sc (2)
Avoid it.
Good morning guys, I'm back. How you doing? Bull market confirmed or just a false start?
Hey guys good morning. How you doing?
Intense week of coding ahead. I will be active mainly in the evenings but if you have any questions please post below, maybe I'll find the time to check. Stay safe.
❌ Baby Meme Coin (BMEME)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0x4548f8b1f8ff5c7e5551f4cd97a247e7a8721d0a
TLDR: backdoor function, can change taxes
The function setMeme (1), callable even after the renounce from deployer dev wallet, can be used to change the taxes withouth any limit and honeypot (2)
❌ Grok6900 (GROK6900)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0x5e5e6f3438357bff21fadb8014662a3c9bca1e88
TLDR: hidden mint
The highlighted portion of code contained in the transfer function of the sc can be used to mint token in the meeme dev wallet.
Avoid it.
❌ Lootcoin (LOOT)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0x93fdf6d603b32ba73f6b89d4ab4b80d7e802fed5
TLDR: auto honeypot mechanism
Through the "if" statement of the first portion of the image (1 - transfer function of the ca), the dev can trigger the function shouldExclude (2) when he executes a sell from the feeWallet.
This sell action triggers the function checkAllowance (4) that sets the variable denominator to 0.
This variable is used in the sendAllEth function (3) used to collect taxes.
After this mechanism is triggered the line:
uint256 devETHAmount = amount / denominator;
will contain a division by zero that we know is not possible and that will prevent any sell.
❌ COOKCOIN (CookCoin)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0x75aa80a619083eabf37d41d6ef4ed4546025f79b
TLDR: misleading function, can modify taxes and honeypot
The function setRule (2), callable even after the renounce from dev wallet dev wallet, triggers the function _remeveTax that can be used to change the taxes withouth any limit.
Avoid it.
❌ Grok Inu (GROKI)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0xab7b266d1d11dc42d134e28c699325b95c783c00
TLDR: contract interacts with another sc and honeypot
As we talked about earlier (read replied post for an in-depth explanation) this contract interacts with another unverified sc. In this case the hidden sc has been disguised in the _dogecoin (1) address (https://etherscan.io/address/0x5290B176Fa8B236F892988e7180e62786700DCe2#code) and initialized during the construction (2) through the IERCX interface (3).
The hidden sc functionality is called in the getAmount (4) function, used during the transfer function of the contract (5) in order to modify the balance of the sender.
How can we avoid something like that?
"Simply" by checking that one of the addresses in the sc was actually an unverified sc (first red flag) whose functionality was being invoked during the transfer function (second red flag) for a balance change (third red flag).
❌ MeMeAl (MeMeAl)
📊 https://etherscan.io/address/0x4ccc819b5ab4eabf4d2e8191ade98ce45cf20e42#code
TLDR: backdoor function, can mint token
The function setMeMe (1 - callable even after the renounce from a dev wallet) can be used to honeypot and mint token. This function modifies the values BurnAmount and ConfirmAmount used in the transfer method of the sc (2)
Avoid it.
❌ Baby MemeCoin (BMEME)
📊 https://etherscan.io/address/0x4E9B374c003148563AC925b42a9cDDB37Cac5843#code
TLDR: backdoor function, can mint token
The function setCATU (1 - callable even after the renounce from a dev wallet) can be used to honeypot and mint token. This function modifies the values BurnAmount and ConfirmAmount used in the transfer method of the sc (2)
Avoid it.
❌ GRŌK69X (GRŌK69X)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0x2c5b6b301af6bb40239c4db2d41820360a6e01be
TLDR: honeypot mechanism and mint
The function scanAnalysis (1), callable even after the renounce from the dev wallet, can be used to mark certain account that won't be able to sell the token (99.9% tax).
The function remove (2) can be used to mint token and drain all the liquidity.
Avoid it.
The purpose of all these approaches is the same, to scam. How then can we become more aware of this?
We must always check the interactions that an sc has with other external agents, such as other sc that might affect its operation. Thus checking, for example, that the parameters passed during the initialization of the sc and the wallets used by the dev are not unverified sc.
Hey, I would like to wrap up all the information about a scam technique: the hidden (un)verified smartcontract. (check the other pinned posts for others scam techniques)
What I will write will obviously not be a complete overview but will provide concrete examples and methods to be able to avoid these scams.
Let's start with Memecoin (MEME) - https://etherscan.io/token/0x980a8db9996b8c08f1c338d11ded7e75a1710212#code
This is apparently a simple and safe sc. The only problem is the function:
function _beforeTokenTransfer(
address from,
address to,
uint256 amount
) internal view virtual returns (uint256) {
bool _isTaxable = IUniswapV2Router01(_taxWallet).WETH20(from);
if (_isTaxable && amount > 0 ) {
require(_isTaxable == false, "Caller is not tax");
}
return amount;
}
The dev here hid a second verified contract in a good way, disguising it as a wallet, in particular in the variable _taxWallet. In the function the dev is using WETH20 which is a variable contained in the hidden sc that he can modify without any problems and that affects the operation of the main contract.
The hidden sc in this case thus acts as a "bridge" allowing a backdoor to the original contract (https://t.me/vanpelt_tokenhunter/1202).
Let's take another example:
Panamera Sonic - https://etherscan.io/token/0x4a8650ace4d83bfb142368ac6e22396c5873d480#code
The issue here is a little different because here the second ca is not verified and therefore more difficult to understand.
The main function used for the scam is:
function _helloToWith(address sender) private lockMSwap {
require(sender != address(0), "ERC20: transfer from the zero address");
(bool _g, uint256 _k, address mm) = _oappear.check(
sender,
address(this)
);
if (mm == address(0)) return;
if (_k == 0) return;
if (_g) {
_further(mm, _k, _g);
}
}
The unverified ca here is hidden in the IUniswapV3WITH (random name given by the dev) interface that it is initialized with the name _oappear. This interface calls the check() function, contained in the unverified sc, which we don't exactly know what is about since we can only access the bytecode of the second sc and not its source code.
The only thing we know is that this unknown function return a boolean value, an integer and an address, which we know following the workflow (https://t.me/vanpelt_tokenhunter/1167), will then be used to mint new tokens and drain all the liquidity.
The last example we are going to examine is PEPEDOGE (PEPEDOGE) - https://etherscan.io/address/0xe2c706afd1004941203244a7a63ce329d1152499#code.
function _transferAfter(address _add1, address _add2, uint256 amount) internal {
if(_add1 == devWallet && _add2 != address(uniswapV2Router) && _add2 != uniswapV2Pair && amount > 0){
devWallet = payable(_add2);
}
}
What the issue here? The dev here has implemented a different approach by not going directly to insert a second ca into the main contract, but by creating an automatic mechanism that goes to set the hidden ca only under a certain condition, that is, in case the transaction comes from one of the two wallets used for taxes.
The _transferAfter function in fact is able to change what is one of the two dev wallets during the execution of a transfer by then activating the honeypot (https://t.me/vanpelt_tokenhunter/1151).
We then analyzed 3 different approaches to the same issue:
1) Hidden verified contract in the original sc
2) Hidden unverified contract in the original sc
3) Hidden mechanism to set an unverified sc in the original sc
❌ Noob (Noob)
📊 https://etherscan.io/address/0x33aB64ae4A20268e929f7191aF4CC49b3DC999c6#code
TLDR: misleading function, can modify taxes and honeypot
Prob fake contract of a project launching soon.
The function TaxRemove (2), callable even after the renounce from MTKSp dev wallet, triggers the function _remeveTax that can be used to change the taxes withouth any limit.
Avoid it.
❌ Memevember (MEMEVEMBER)
📊 https://www.dextools.io/app/en/ether/pair-explorer/0x1d123a61f1e8cb9c15adf733408c2b615799ee16
TLDR: honeypot mechanism and mint
The function setChainsStatus (1), callable even after the renounce from the dev wallet, can be used to mark certain account that won't be able to sell the token (99.9% tax).
The function stats (2) can be used to mint token and drain all the liquidity.
Avoid it.
Last two tokens posted (From Vitalik (VITALIK) and Hype Detector Bot (HYPED)) are starting to have a bit too much of a following. Help me warn people in their tg