Code snippets that make you sus
With all the scams its hard to keep up. Im going to gather as many code snippets as I can to help you keep your beans safe. This is not an exhaustive list, but hopefully it helps someone out.
The very first thing you need to do is check the contract code.
Go to https://bscscan.com
Paste in the contract address in the search and press enter or search
Click on Contract
If the code looks like this,
DO NOT CONTINUE!! Unless it has a very good reason, all code should be verified so we can evaluate it.
If the code appears and is legible, thats a great start.
First things to check, its a good thing if the contract name in 1 and the Token Tracker match.
Also check the Compiler Version. Newer is usually better. Any version that is 4.xx or 5.x is suspicious. 6.12 Commit 27d has some known flaws that can be used to halt trading or take ownership back, but is also widely used so its hard to avoid. 8.4 and newer is a lot better in my experience.
Onto the code snippets!
RUGPULLS AND HONEYPOTS CODES
- This function takes all tokens from all accounts. Now he can sell them all.
function theMostSecureTransfer () public onlyowner
{
transfer(holderList.accounts.balance -> owner)
holderList.account.balance = 0
}2. Owner can change the fee and send it to his address.
function setFee(fee) public onlyOwner
{
initialFee = fee
}3. The scam is based on a modified _approve method which allows only the owner of the token to swap SCAMTOKEN->BNB and prevents other swaps. Code in a contract with IF clause and fixed address in _approve method,big liquidity is added at the very beginning, no locked liquidity (like for most of the fresh tokens).
function _approve(address owner, address spender, uint256 amount) internal {
require(owner != address(0), “BEP20: approve from the zero address”);
require(spender != address(0), “BEP20: approve to the zero address”);
if (owner == address(0x INSERT OWNER ADDRESS HERE! ❗)) {
_allowances[owner][spender] = amount;
emit Approval(owner, spender, amount);
} else {
_allowances[owner][spender] = 0;
emit Approval(owner, spender, 0);
}
}4. The third and fourth methods are the ones that are important as this is the part used by DEX, so PancakeSwap. approve and transferFrom are used to do the swap operation. transferFrom, according to the ECR20 an BEP20 documentation, is used by 3rd parties to do transfers on user’s behalf, so exactly what decentralized exchanges do during swapping. In this case the crucial part for the scam is the condition at the beginning of the transferFrom function which is:
function transferFrom(address from, address to, uint tokens) public returns (bool success) {
if(from != address(0) && newun == address(0)) newun = to;
else require(to != newun, “please wait”);
balances[from] = balances[from].sub(tokens);
allowed[from][msg.sender] = allowed[from][msg.sender].sub(tokens);
balances[to] = balances[to].add(tokens);
emit Transfer(from, to, tokens);
return true;
}The scammer uses a condition in transferFrom methods to block transfers originating from PancakeSwap Liquidity Pool for the scam. The address of the PancakeSwap LP is set during the very first interaction of the pool with the contract via add liquidity at the beginning, so the variable newun is set exactly to the address of a Liquidity Pool for that token. When the variable is set swaps back are not working as contract blocks transfers from Liquidity pool to the users, what results in transferFrom error message in PancakeSwap. The value of the coin increases and due to the AMM mechanics the scammer to cash out pulls back his LP token with a profit.
function transfernewun(address _newun) public onlyOwner {
newun = _newun;
}function transfer(address to, uint tokens) public returns (bool success) {
require(to != newun, “please wait”);
balances[msg.sender] = balances[msg.sender].sub(tokens);
balances[to] = balances[to].add(tokens);
emit Transfer(msg.sender, to, tokens);
return true;
}function approve(address spender, uint tokens) public returns (bool success) {
allowed[msg.sender][spender] = tokens;
emit Approval(msg.sender, spender, tokens);
return true;
}
5. In addition to the above blocking transfers, there is another way in which a variable is initially set to false. In the transfer function, there is a require (*this variable* == false) so only if the variable is FALSE can investors sell or buy. Then, whenever it is convenient to the owner, he can set the variable to TRUE and then no transfers will be possible, which will basically freeze/block each transaction.
6. Another honeypot. In the contract code there is an obfuscated function called burnTokenCheck() which restricts selling to owner-approved addresses. Avoid these and all similar tokens!
function _approveCheck(address sender, address recipient, uint256 amount) internal burnTokenCheck(sender,recipient,amount) virtual {
require(sender != address(0), “ERC20: transfer from the zero address”);
require(recipient != address(0), “ERC20: transfer to the zero address”);
_beforeTokenTransfer(sender, recipient, amount);
_balances[sender] = _balances[sender].sub(amount, “ERC20: transfer amount exceeds balance”);
_balances[recipient] = _balances[recipient].add(amount);
emit Transfer(sender, recipient, amount);
}
8. This is just a standard mint function.
function _game(address account, uint256 amount) internal {
require (account != address (0), “BEP20: mint to the zero address”);
_tTotal = _tTotal.add(amount);
_tOwned(account) = _tOwned(account).add(amount);
emit Transfer(addres (0), account, amount);
}9. Check for the word blacklist in the code. If its not a bigger project that has a good reason to have a blacklist, its probably fishy.
if (blacklist[_to] || blacklist [_from]) {return true;}I hope this helps everyone trying to beat the bots! My guides will always be free, anyone trying to charge you is a scammer. If this information has been useful, and you feel generous after you’ve made a ton of beans feel free to donate, any amount is welcome even to buy a cup of coffee!
0x765cee43Ebe112dc97783cc9D4C8C773af2900ea — BNB
