How to check a smart contract before you sign

What verification actually proves

A contract deployed on Ethereum or any EVM chain is bytecode. It is deterministic, auditable in principle, and unreadable in practice.

Verification is the process of submitting the original Solidity or Vyper source, along with the exact compiler version and optimisation settings used, so that anyone can recompile it and confirm the output matches the bytecode actually on chain. Etherscan performs that check and then publishes the source.

What this establishes is narrow and important: the code you are reading is the code that will run. It removes the possibility that a project published one thing and deployed another, which is a real and historically common form of fraud.

What it does not establish is that the code does anything reasonable. A verified contract can contain an unlimited mint function, an owner who can pause all transfers, a fee that can be raised to a hundred per cent, or a function that transfers everyone's tokens to a single address. All of that is perfectly verifiable and perfectly hostile.

So "verified on Etherscan" has become a first-order safety question across the ecosystem, asked by people who have never read Solidity, and it answers a considerably narrower question than they think. It is a precondition for judging a contract, not a judgement.

Proxies, and reading the wrong code

Most significant contracts today are proxies. The address you interact with is a thin, permanent shell that delegates all logic to a separate implementation contract, and that implementation can be replaced by whoever holds the upgrade permission.

This pattern exists for good reasons — bugs can be fixed, features added — and it fundamentally changes the security question. The code you audit today is not necessarily the code that runs tomorrow.

A naive explorer shows you the proxy's own bytecode, which is about forty lines of delegation boilerplate and tells you nothing at all. Etherscan detects the common proxy patterns, resolves the implementation, and offers a "Read as Proxy" toggle. Several competitors do not, and the failure is silent: you are looking at real, verified code and drawing a conclusion about the wrong contract.

The questions to ask are who can upgrade, and whether there is a timelock. An upgrade controlled by a single externally owned account with no delay means one compromised key changes everything. An upgrade controlled by a multisig with a forty-eight-hour timelock means people have warning.

Both arrangements are visible on the explorer, in the proxy's admin functions and in the owner address. Whether the owner is a multisig or a single key is itself readable — a multisig has contract code, a single key does not.

Owner privileges: the functions that matter

If you read nothing else in a contract, read the functions guarded by an owner or admin check. They are where the power sits.

Mint. Can new tokens be created after deployment, and by whom? An unlimited mint function held by a single address means the supply is whatever that address decides, whenever it decides. This is the mechanism behind a large share of token collapses.

Pause or blacklist. Can transfers be stopped, generally or for specific addresses? Legitimate stablecoins have this and use it to comply with legal orders, which is defensible. A meme token having it is a different proposition entirely.

Fee adjustment. Can a transfer fee be changed after launch? A contract with a fee that starts at zero and can be raised to ninety-nine per cent is a trap with a delay fuse.

Arbitrary transfer. Can a privileged address move tokens it does not own? Rare, unambiguous, and disqualifying.

None of these is automatically malicious. Context decides. A regulated stablecoin needs the ability to freeze; a community token claiming to be decentralised does not. The point is to know which exist before you commit funds rather than after.

The approval you are actually granting

Most losses do not come from a contract's own logic. They come from approvals, and the approval is the thing you actually sign.

When you use a decentralised exchange, you grant its contract permission to move a specific token from your address. That permission is usually unlimited in amount and unlimited in duration, and it persists until you revoke it — long after you have forgotten the protocol existed.

Two years later, that protocol is exploited. The exploit does not need to break your wallet; it only needs to use a permission you already granted. The people who lose money are frequently those who interacted once, years earlier, and never thought about it again.

The wallet prompt tells you what you are approving, and almost nobody reads it. The two fields that matter are the spender — which contract is being authorised — and the amount. Many wallets now let you set a finite amount rather than unlimited, and the small extra cost of approving per transaction is worth it for anything you do not fully trust.

Both Etherscan and BscScan have token approval checkers that list every live approval on an address and let you revoke. Checking quarterly is the highest-value security habit available on any EVM chain, and approvals are per-chain, so each network needs checking separately.

A practical sequence before you interact

This takes about three minutes and catches most of what is catchable without reading Solidity.

Start by confirming the contract address against the project's own documentation or its verified social accounts. Not the name shown in a wallet, not a link from a message — the address, from a source the project controls. Names and symbols are arbitrary and freely reusable, and impersonation is the most common attack of all.

Then open that address on an explorer and check it is verified. Unverified is not automatically malicious — plenty of legitimate contracts are unverified, particularly on smaller chains — but it does mean you are trusting without the ability to check.

Check whether it is a proxy and, if so, resolve the implementation. Read the owner address and establish whether it is a multisig or a single key.

Scan the function list for the privileged operations above. You do not need to understand the implementation; you need to know whether the function exists.

And when the wallet prompt appears, read the spender and the amount. That prompt is the last point at which any of this is reversible.

What this will not protect you from

Being honest about the limits of a three-minute check matters more than pretending it is sufficient.

It will not find a subtle logic bug. Professional audits miss those, repeatedly, and reading a contract on an explorer is not an audit. What it finds is the obvious category — the functions that let someone take everything, stated plainly in the code.

It will not tell you whether a project is economically sound, whether its treasury is real, or whether the people behind it intend to stay. Those are questions the chain cannot answer.

And it will not help on chains without this tooling. The whole approach described here is EVM-specific. On Cardano native assets are ledger objects with no approval mechanism at all. On Sui packages publish with type information and upgrade explicitly. On Solana the equivalent question is which program owns an account and what delegate authority exists.

The general principle transfers even where the mechanics do not: find out what the thing you are about to interact with is permitted to do, before you permit it.