Onchain Wizard - Smart Contract Red Flags and Staying Safu
Free content for you all today. Will be going into very basic etherscan / smart contract red flags and other best practices for you to stop getting rugged, scammed, etc. Will also do a bonus post on how to mint an NFT directly through the contract next week for fun. Paid content next week will dive into the Iron Finance exploit.
Getting Started:
Why does this stuff matter? Developing basic skills into smart contract reading can keep you from getting rugged, while better security practices can help you avoid being hacked/exploited. At a very high level, smart contracts work like legal contracts - except they provide a way to automate complex transactions when certain predetermined conditions are met on the blockchain via code. The very basic smart contract methods you are all likely used to (on the user front-end) are approve, send, receive, swap or mint.
Before I dive in here, I think one of the most important “functions” that people need to be very careful with on user interfaces when dealing with on-chain crypto funds, is the “Approve” function. If you are an on-chain degen, you have clicked this numerous times on a DEX like Uniswap for example (below are examples from Curve).
You need to be very careful with what websites you click “approve” on, what you are actually approving, and how much you have approved. If you are approving a transaction, you are giving access of X amount of funds (USDC, ETH, etc) to a contract or to somebody else. I have had people in my DM’s that have signed transactions where the “Granted to:” line is to another wallet, and they did not adjust the approval limit, so it was set to “unlimited USDT” and their account was drained. If the Granted to: line is not a contract, but somebody’s wallet, you obviously should not approve this transaction!
As best practice, if you are going to do degen stuff on-chain, it is best to use funds/a wallet (or many wallets) separate from your main stack. This avoids any wipe out / rug risk in case you do something stupid. Additionally, you should (1) always glance through what you are approving access to (look at the contract - and make sure it matches with the protocol you are trying to interact with), (2) watch the amount you are giving permission to spend (you can adjust this in metamask), and (3) be regularly revoking token approvals from protocols (especially sketchy ones). When you “revoke” approvals, you are un-granting access of your funds to a contract/protocol or somebody else. You can do this very easily though etherscan’s token approval function link here: https://etherscan.io/tokenapprovalchecker. Here you will also be able to see prior approvals, and it will tell you how much of your ETH, USDC, etc is at risk.
Remember: if you are approving a transaction on some random website someone you don’t know just sent you, they are almost certainly trying to steal your funds, by having you approve access.
Don’t believe me? Think its no big deal? Here is a recent example of someone that was tricked into setting an “approval for all” where the operator address was the scammer’s wallet (the scammer got them to approve the transaction on a random 3rd party website). One click, and $1.5mm is gone.
Reading Etherscan:
With that out of the way, lets start diving into contracts. You can do basic contract reading through etherscan (or similar chain’s block explorers), which can tell you the nuts and bolts of the code of a project.
The Basics:
If you are unfamiliar, etherscan can give you valuable information about a project. You can retrieve max supply, number of holders and current holder base data (good for finding wallets, and watching what is going on with key project wallets). I’m going to start with very basic stuff and start working my way up the difficulty ladder. For the basic overview, lets use Will Smith Inu as an example. When we go to etherscan, we can start digging thru high level information about the project.
You can see the transaction that created the project (and the creator’s wallet). If you are doing diligence on a project, you can see what the dev has done prior, and if they deployed or were involved in any prior rugs (massive red flag).
You can see all of the nonsense the creator wallet did (they also seem to have created a Dave Chappelle Inu) - you will also see the “update marketing wallet” transaction, which we will dive into in a second (note this was the “marketing wallet” address 0x963006e05c3a2a3e6583641a5FE11Df613d44A5e):
To ramp it up, we can go into “Read Contract” for a glimpse under the hood at the high level functions of the contract. In Read Contract, etherscan will give you certain functions that you can read without diving into or trying to read the actual Solidity code.
Some of the crazy ones in this example (and to look out for in other projects) were a 3% “Marketing” buy fee and a 16% “Marketing” sell fee
Where do these funds go? Well they go the marketing wallet of course! Rest assured, none of the funds were actually going to marketing, and instead provided the owner a way to make hay on every transaction. This marketing wallet 0x963 (which was blank when the project was started) made a total of ~$678k in ETH (at prices back then) which is incredible, while the project ultimately went to zero!
If wanting to dig further, you have to dig into the actual source code which can be found under contract → code in etherscan.
I am not an expert when in comes to reading code, but I will try to dive into where problems usually arise and things to look out for. However, the best first step you can take if you don’t have the technical know-how, is to look at any audits done on the project (or run it through Rug Doc), to see if they brought up any high risk problems within the source code.
Smart Contract Red Flags
Again, I am not an expert, so I’m just trying to focus on things you can spot to save you money. There are courses available out there to really dive into how to read solidity (I’ll post some resources at the bottom). But instead of trying to dive into how to actually read the code (which is complicated), I will give you some high level things to look for to know if the project is unsafe (search the code for these). Its important to remember that there are 2 main ways you are going to get rugged on a project (outside of just approving your funds away): (1) a hard rug by a malicious team or (2) an exploit. To a non-technical person, spotting #1 is easier. Here are some things to look out for on newer, less established tokens.
There are exceptions for each of these scenarios, but this is at least what I look for, and what other folks smarter than me roughly suggest) - if you want a bunch of examples start here
Is the contract unverified? When you look at your block explorer (ex etherscan) and look at contract, it will have a green checkmark and say “verified” if the code is verified. What does it mean if its not? Usually this implies the code is unreadable, and has a high probability of being malicious. If the code is not verified, its not worth aping.
Is there a migrator function ? This can give the contract owner the ability to drain all funds from the contract at any time (search the code for “migrator”). And is there a timelock (search for “timestamp” or “timelock”). If not, this combination leads to plenty of rugs, as no timelock allows the contract owners to migrate funds immediately in certain situations.
Watch out for upgradeable proxy. Upgradeable proxy can allow a project to upgrade its contract to whatever it wants, including a malicious upgrade (search “upgradable”).
Mint functions: A function that creates new tokens. This can be fine, but if there is a way to mint outside of a standard liquidity pool reward contract, then it can lead to massive problems (search “function mint”).
EOA vs. multi sig: does a single account/address hold all of the control over executive functions of a contract, or is it a multi-sig? Having a single account in control is much more risky vs. multi sig (which requires 2 or more private key signers to execute owner functions).
You can find this in etherscan by going contract →read contract → owner (should look something like this)
If you familiarize yourself with these functions, you already are doing more research than 90% of crypto apes. You can also paste the contract into tools like TokenSniffer, RugDoc or HoneyPot checker to get a view on the safety of the project’s code. Each of the red flags I brought up can have nuances where it is fine, and I am not a smart contract expert. If you come across any of these you can bring it up to someone that is sharp with smart contracts, or ask the team directly to see if it is a critical issue or not.
I will have to dedicate another post to smart contract design flaws (which creates exploits), but some great reading to get started is going through Blocksec’s twitter feed on various exploits/attacks to get at least a high level overview of why certain vulnerabilities exist and how they are exploited: https://twitter.com/BlockSecTeam.
Wrapping up contracts
Even if you skip all of the meat of this post, the main take away is to (1) not interact with random websites with your wallet, and (2) be paranoid about your approvals. I’ve provided how to read etherscan and certain functions to look out for in the actual code of projects, but you need to do the work yourself to find what works best for you. If you want to learn more about reading smart contracts, I would check out the following resources:
https://cryptozombies.io/
https://twitter.com/BowTiedPickle
https://twitter.com/RugDocIO
This should serve as a starting point for your smart contract literacy journey, as understanding contract logic flaws, timelocks, mints, migrates, and the like can be quite complicated. If you got value out of this, please feel free to share broadly and give me a shout out on twitter!
Disclaimer: This content is for informational purposes only, you should not construe any such information or other material as legal, tax, investment, financial, or other advice.
This is incredibly important information for everyone using crypto. Thank You
I come here again to express my gratitude for the work you have been doing and how it has contributed positively to my learning. thanks