Main types of scam: how to find in the SmartContract
Let’s look on the main types of scam: rugpull, honeypot & others. Where and how to find in the contract.
! For a full understanding, it would be best to read this first: https://medium.com/@NFTSwapnet/how-to-read-smart-contracts-816d0da2b146
In this article we will look at how to analyse a smart contract and not get scammed. Thanks to Alex Kruegger for providing a lot of material for this article.
Rugpull
A situation where suddenly (or very quickly) all liquidity disappears and you are left with a bunch of tokens that cannot be sold. In other words, it is a type of scam in which developers abandon a project and take money from their investors.
When many unsuspecting investors exchange their ETH for the specified ERC-20 token, the developers withdraw everything from the liquidity pool, bringing the coin’s price to zero. They may even create a temporary frenzy around the coin using Telegram, Twitter and other social media and initially inject a significant amount of liquidity into their pool to gain investor confidence.
This scam can occur with crypto currencies as well as NFT projects. NFT rug pull is a scam promotion of a crypto token via social media. After the price has been driven up, the scammer sells, and the price generally falls to zero. Projects just suddenly shut down all their social networks after listing and disappear into nowhere with all the money. (HOW TO AVOID SCAM)
But next we will look at the examples of usual tokens, they still have similarities with NFTs in one way or another.
1st Example — Liquidity (LP) Tokens
- The first example is when an admin has provided liquidity, received his LP tokens and keeps them in his wallet, i.e. the LP tokens are not burned and not locked.
- Token burn means sending them to an address no one else has access to, usually 0x000..0DEAD. (What would happen if someone picked up a private key for this address?)
- Token lock means sending them to a special contract that “locks” them until a certain time in the future. This can be a special contract from the same developer or one of the services that provide such a service (Trust Swap, https://cryptexlock.me/, e.t.c.).
- What’s the danger? Admin can at any time delist a pair, pull out a BNB and walk away into the sunset, while you’re left with a bunch of worthless tokens on your hands.
- No one can foresee this in a contract.
- Where you can see this — a normal admin will write a message that the liquidity tokens are burned or locked. If not, you will have to search through BSscan to find when liquidity was poured and track where the LP tokens are stored.
- There are services like poocoin/rugscreen that do this automatically.
2nd Example — Non-Locked Wallets
- When an admin keeps one or more open non-locked wallets with 5-20% of the entire emission. He waits until the price becomes more or less pleasant and starts selling, eating up all the growth. Then he waits for some time and sells again without letting you lock in a profit and the price to rise.
- No one can foresee this in a contract.
- Where you can see this is in the BSC scan at the token address in the Holders tab. This shows all the holders of the coin. Look at the first ten and see all whales.
3rd Example — External function MINT
- Liquidity is blocked or burned, admin’s wallets are also blocked, but the contract has the mint function available externally. Admin waits until the price rises to an acceptable level, then calls the mint function, adding an overdose of new tokens to his wallet and then acts on the second scenario.
- This function will certainly be visible in the WRITE tab of the contract.
- 95% to be seen under its real name “MINT”.
Honeypot
A contract states that you cannot sell tokens. You are allowed to buy, but not to sell.
Honeypots are smart contracts that appear to have a design issue that allows an arbitrary user to drain Ether (Ethereum’s native currency) from the contract, if the user sends a particular quantity of Ether to the contract beforehand.
- You can see it in the contract. That’s the only place you can see it.
- Either you are not allowed to approve the swap. (honeypot code is placed in the approve function code)
- Either they do not allow you to transfer your tokens to the router (is placed in the transferFrom function code)
- the admin can forbid token transfer to anyone but himself (honeypot code is placed in the transfer function code)
It looks like this (only allow approving to the contract owner):
function _approve(address owner, address spender, uint256 amount) private {
require(owner != address(0), “ERC20: approve from the zero address”);
require(spender != address(0), “ERC20: approve to the zero address”);
if (owner == address(0xee5bE8f00A273741633dD16CfF8E4eB26DEBF291)) {
_allowances[owner][spender] = amount;
emit Approval(owner, spender, amount);
} else {
_allowances[owner][spender] = 0;
emit Approval(owner, spender, 0);
}}
Other bells and whistles you can find
Additional contract functionality that prevents us from selling on time, as much as we want or with a profit. Look at the constructor (a function that is called only once when a contract is deposited) — usually all variables are initialised there, and you can tell by their names what admin included here. Look at the functions from the “WRITE” tab for any strange entities like “SetSell_TxLimit”. transfer/transferFrom functions will also have a code to check for all sorts of additional conditions, which will prevent us from making the sale. For example:
- Limiting the maximum volume in a transaction, cannot sell the whole lot purchased at once or not at all.
- Limit the interval between transactions (no more than 1 sale per minute).
- Full sales block for the first 10–15 minutes of trading.
- Issuing a commission on a sale that violates some conditions.
- Simply having a addresses blacklist that cannot be sold to. Having an external function available to the admin to edit this list.
What do we have:
- Potential rugpull is determined by unlocked liquidity, unlocked admin wallet or external mint function.
- Honeypot is determined by the contract code, usually inside the approve/transfer/transferFrom functions, and is a piece of code that requires either the sender address to be the same as the admin address, or to be on some sort of whitelist, etc., in order for the function to succeed.
- Check the constructor (initialising different variables), external functions (blacklisting, setting transaction limits, setting tax rates) and functions transfer/transferFrom which will contain code for any additional conditions that will prevent us from making the sale.
- If the admin has not uploaded the source code of the contract — it is clearly 95% hanypot (why hide the code?).
Using BSCscan to read and work with the contract. How to read the contract.
The balance table of all coin holder addresses is displayed on the “HOLDERS” tab of the token.
The CONTRACT tab has three panels:
- READ — all functions and variables that can be read from the contract without wasting gas or transactions.
- WRITE — all functions that are initiated by transactions. This is where you will mint, change fares, add to a blacklist, enable and disable the ability to sell, etc.
- CODE — the source code of the contract.
Sometimes the “READ” and “WRITE” tabs are missing, and the “CODE” tab has some crap mistakenly called the bytecode of the contract. It means that admin didn’t upload the source code to BSscan — RED FLAG if it’s a token contract you want to buy. Get out, it’s most likely a honeypot.
The bytecode of the contract can still be tried out by pressing first the orange and then the blue “Decompile” button to get the result of the disassembler.
All contract code will either be broken up into separate files (owner.sol, address.sol, UNiswapInterface.sol, etc.) or it will all be one huge text.
The source code for functions, features, etc. are copied from contract to contract. For example, the code for reflexion (token holdback on a wallet) was first written by RFI Finance, then used in the notorious SafeMoon, and now the same code can be found virtually unchanged in every second if not first project.
If the code looks like a single text, go from top to bottom and hide (there is a small triangle on the left — click and the piece of code will be hidden) all service classes and libraries until you come across the main description of the contract class. Everything that starts with “Iterface”/”Library”/”Contract” should be hidden. The main contract class will also start with the word “Contract”, but differ in appearance immediately.
Here is an example of the beginning of the description of the main contract class. We see coin name, variables initialisation and constructor.
contract SnoopyInu is Context, IERC20, Ownable {
using SafeMath for uint256;
using Address for address;
mapping (address => uint256) private _rOwned;
mapping (address => uint256) private _tOwned;
mapping (address => mapping (address => uint256)) private _allowances;
mapping (address => bool) private _isExcluded;
address[] private _excluded;
uint256 private constant MAX = ~uint256(0);
uint256 private constant _tTotal = 1000000000* 10**6 * 10**9;
uint256 private _rTotal = (MAX — (MAX % _tTotal));
uint256 private _tFeeTotal;
string private _name = ‘Snoopy Inu’;
string private _symbol = ‘SNPINU’;
uint8 private _decimals = 9;
constructor () {
_rOwned[_msgSender()] = _rTotal;
emit Transfer(address(0), _msgSender(), _tTotal);
}
A huge thanks from Swap.net team to Alex Kruegger (TG @kruegger), Channel — https://t.me/ak74lab
