Many users in the Defi space have fallen victim to exploits used within Token Contracts that in turn lead to them losing a lot of money. This is most commonly seen on Uniswap, due to anyone being allowed to launch a Contract, as long as they have the technical know how and the Ethereum to afford it. Unfortunately, this leads to the creation of many Contracts that are malicious in nature.
Thankfully, a vast majority of scammers can be identified by using Etherscan. The following steps can be used to determine whether or not a Contract is malicious. In order to show the difference between a good contract and a bad one, this tutorial will first give an example of what a clean contract looks like, and then malicious examples will be given.
CLEAN CONTRACT EXAMPLE:
1. Go to etherscan.io
2. Enter the Contract Address into the search bar (double check you have the correct address)
2a. if you do not know the Contract Address, you can obtain it through Dextools, CMC, or CG
2b. remember that the Token Address page and the Contract Address page are different, make sure to be on the Contract Address page.
Below is an example of the Token Address page for Bondly:
This is an example of the Contract Address page for Bondly (the address highlighted in yellow above):
3. Click on the Contract button highlighted in yellow above
4. Select Read Contract as shown below:
5. You now have access to read the contract functions that are available, they should look like this:
What to do now?
This is the part where it gets tricky, because there are an infinite number of possible functions that could be included into a smart contract. In the example for Bondly above, there are only 8 functions present for the main token, which is a sign of a clean contract. All 8 of those functions are necessary for the token to exist on the blockchain, and they aren’t functions that could rug the user.
In the case that you’re searching for a different token, you can still use these exact same steps to read the contract. There are a few red flags that are common in scam contracts, and these will be outlined below. Now that we know how to access and look at the contract functions, we can determine which are potentially malicious. There will not be any contract addresses shared in the examples because someone might just buy it anyways.
MALICIOUS CONTRACT EXAMPLES:
1. Mint function - this function allows the minting of more tokens, thus increasing the supply and potentially allowing the minter to dump those tokens on the market. This is one of the most common rugs that crashes a price. Disclaimer: Some tokens have mint functions that are dependent upon elastic supplies, but unless a reason for minting, or a programmed rule set, is present, there should not be a mint function. It is important to check who the owner of the mint function is: if the owner is the dev, that’s obviously a red flag; if the minter is a contract based on volume/price, that would be decentralized and significantly less likely to be a scam.
2. Whitelist function - this function should really only be present if the project has a randomized presale that requires the whitelisting of addresses to ensure there is not oversubscription. If the project did not have a presale, and still has this function in the contract, it can be potentially be used to prevent any address not on that whitelist to be unable to sell. I.e. you can buy but cannot sell.
3. Freeze function - this function does as the name implies, and can physically freeze trading of the asset at any time. Although simple, it effectively prevents people from selling the pooled tokens, locking the Ethereum and the secondary token until unfrozen.
3a. if there is also a Transfer Ownership function, and the Contract Creator has control of the freeze function, then they could potentially freeze the contract and then send the ownership to the burn address. This effectively kills the Eth and the other token, leaving them to the burn pool forever.
4. Not a specific function, but the more functions that a token has, the more likely that one can be used as an attack vector. Unless the token’s project has a need for the function, it should not just be arbitrarily added to the code.
Non-Contract Red Flags:
1. An overwhelming large max supply, or, one address with an overwhelming large percentage of the supply. It’s common to see the address that deployed the contract have most of the supply, which is a large red flag.
2. A Univ2 pool that is significantly smaller than the largest individual holder (this does not include staking contracts because they are the accumulation of a multitude of address inputs). This is a sign of skewed distribution, and the potential for a whale to wreck the ecosystem gets higher.
Note: The difference between a normal address and a contract address is this symbol next to the address:
*The symbol highlighted in yellow indicates that the address is a contract. If the symbol is not there, then the address is a personal address. If contracts appear that have large quantities of tokens, it’s important to know what they are for (like staking, or vesting, or locked team tokens, etc.)
3. An anonymous team can be a red flag, but anonymity should be looked at through the lens of the product. If the product is sound, safeguards are in place, and the developers are transparent about the code/answer questions effectively, then anonymity shouldn’t be a negative factor. In the case of anonymity and the presence of other red flags, the risk increases significantly.
Overall, Defi contracts on Ethereum are definitely high risk in comparison to investments anywhere else. However, knowing the basics of how contracts function, and being able to recognize the red flags that signal a potential scam, can help reduce that risk. There is always risk when interacting on the blockchain, but investing in contracts that don’t have malicious code will prevent more losses, and will likely help your gains in the long run.