Thread by @RobotDefi

Now that we've discussed how to check if liquidity is locked in a project, let's talk more about how to vet a smart contract.

First, we'll start with the block explorer.

🧵/1

The block explorer is where you can see all of those immutable transactions on the blockchain.
Each chain has it's own (bscscan, etherscan, ftmscan, snowtrace, etc)

You can go to the explorer and plug the contract address into the search bar.

🧵/2

A good place to start is to check out the contract creator's address.

Also, click on the total txn number of the contract and then click to the Last page. This will show you the first txns on the contract.

🧵/3

Here you can look for the usual and normal transactions such as the addition of liquidity etc.

Also you can look for suspicious txns.
For example, txns from the rewards wallet will always have the contract address in the "To" column. Otherwise it'll have a regular address.

🧵/4

This can be a little confusing, so stick with just looking for "transfers" or "swaps"
This will help you track where money is coming in and going out.

🧵/5

Now to use some tools.
Aside from @MoonarchApp (which I mentioned in the last thread), there are a couple more useful ones.

@Token_Sniffer and @StaySAFUOrg are software tools that scan smart contracts for suspicious code.

🧵/6

These tools help you to see if there are malicious commands, such as transfer blocks, or other suspicious lines of code like hidden mint.

🧵/7

This is another reason why so many new protocols are considered "risky" because many don't provide a contract address until the moment of launch.

IF they get a contract audit before launch, this may not be so bad.

🧵/8

But, without an audit and only providing the contract address upon launch, you are stuck with a hard choice.

Lose out on being first to swipe cheap tokens/#Nodes OR do the research and miss out on great prices.

🧵/9

It sucks missing out, but we protect ourselves from a bad situation when we require protocols be transparent and safe.

So, my advice before aping into a #Node protocol, new token, or any other project...

🧵/10

1. Require the txn for liquidity lock/burn (even if it's only locked for a short period, at least be able to verify that).
2. Require either a contract address (so you can do your own 'audit' using the tools I mentioned above) or a contract audit BEFORE launch.

🧵/11

If you can't at least get these assurances from a project, you're probably better off steering clear.

In my opinion, contract safety is more important than KYC and doxx.

People can deceive you, but code is law.

🧵/finis

@PreExponential @DazaiCrypto @VirtualKenji I share more vetting tools here in case you are interested. :)