~$ crypto-under-the-hood

# The machinery behind the coins

~/notes / reading on-chain data

Reading Smart Contract Code Without Being a Developer

You do not need to write Solidity to check the four things that matter. Each one is findable by searching the source for a keyword.

Ivan Kruse · · 2 min

Verified contract source is published on block explorers. Most people never open it, assuming it requires a developer. Four specific checks do not.

Check zero: is it verified at all

If the explorer shows bytecode rather than source, nobody can inspect what the contract does. That is sufficient reason to stop.

Verification means the published source compiles to the deployed bytecode, which the explorer has confirmed. It does not mean the code is good, only that you can read what is running.

Check one: can someone create more tokens

Search the source for mint.

A mint function restricted to the contract’s own constructor is fine. A mint function callable by an owner address, with no cap, means supply can be increased at will.

Look at what precedes it. A modifier such as onlyOwner tells you exactly who can call it.

Check two: can someone stop you selling

Search for pause, blacklist, blocklist, and canTransfer.

A pause function that halts all transfers is common and sometimes legitimate, as an emergency control. A function that blocks specific addresses from transferring is the mechanism behind honeypots, where you can buy and cannot sell.

The question to answer is who can call it and whether they can target individuals.

Check three: can the fee be changed

Search for fee, tax, and setFee.

Some tokens take a percentage on each transfer. That is a design choice. The concern is a fee that an owner can change after launch, because a fee that can be set to a very high value is a sell-blocking mechanism in another form.

Check whether there is a maximum enforced in the code, and whether the setter is restricted.

Check four: can the contract be replaced

Search for upgradeable, proxy, implementation, and delegatecall.

An upgradeable contract means the logic you read today can be replaced tomorrow by whoever controls the upgrade mechanism. The code you inspected is not a permanent commitment.

This is not automatically bad, since upgradeability allows bug fixes. It does mean your assessment of the contract is an assessment of the current version and of whoever holds the keys.

Check five: who is the owner

Search for owner and check the address on the explorer.

If it is a single externally owned account, one person controls every privileged function. If it is a multi-signature wallet, several parties are required. If ownership has been renounced, meaning the owner is the zero address, no privileged functions can be called at all, which is a strong commitment and also means bugs cannot be fixed.

The realistic assessment

These five checks take about ten minutes and catch the overwhelming majority of tokens designed to take money.

They do not catch subtle logic errors, economic design flaws, or a well-hidden backdoor. For those, an audit by a specialist firm is the answer, and audits themselves vary enormously in rigour.

But the tokens that lose retail money are rarely subtle. They have an unlimited mint, a transfer blocker, or an owner who can change the fee, and all three are findable by searching for a word.

# Corrections and technical nitpicks are welcome. Send them over. They get published with the fix.

contractsdue-diligencepractical

# related notes