Smart Contract Review Basics — Privileged Functions and Real Risk

Direct answer

Smart contract review assesses what a contract can do, who can do it, and whether that is disclosed. It examines privileged functions (mint, pause, blacklist, transfer fees), how the keys controlling them are held (single key, multisig, timelock), whether the contract is upgradeable, and whether transfer behaviour matches the standard. Privileged functions are not disqualifying; undisclosed ones are the actual problem.

What "safe" means here

A contract with no privileged functions is not automatically safer than one with them. It is simply less capable — and it may be unable to respond to an incident.

Pause functions have saved projects mid-exploit. Mint capability is required for many legitimate designs. Upgradeability lets a bug be fixed rather than becoming permanent.

So review asks a different question: is the power disclosed, and is it controlled proportionately?

The functions that matter

Function	What it enables	The follow-up question
`mint`	Creating new tokens	Who decides, and is there a cap?
`burn` (privileged)	Destroying others' balances	Why does this exist?
`pause` / `freeze`	Halting transfers	Under what documented circumstances?
`blacklist`	Blocking specific addresses	Who is on it, and who decides?
Transfer fee	Recipient gets less than sent	Symmetric? Can it be changed later?
Proxy upgrade	Replacing the implementation entirely	Who controls it, and is there a delay?

Key control is most of the risk

The same function carries very different risk depending on who can call it:

Single externally-owned account — one key, one compromise, immediate effect. The highest-risk arrangement.
Multisig — several independent keys required. One compromise is not enough.
Timelock — a delay between calling and taking effect, so holders can see it coming and react.
Multisig plus timelock — the strongest common arrangement.

A mint function behind a 4-of-7 multisig with a 48-hour timelock is a categorically different proposition from the same function behind one hot key. Any review that reports "has mint function" without reporting the control arrangement has reported almost nothing.

Transfer behaviour

Standard token transfers move exactly the amount sent. Several designs do not:

Fee on transfer — a percentage is taken, so the recipient receives less.
Reflection — a portion redistributes to holders.
Rebase — balances change without a transfer occurring.

None is inherently malicious, but all break an assumption most integrations make: that transferring X results in X arriving. For an exchange, that assumption underpins deposit crediting and balance reconciliation, which is why non-standard transfer behaviour must be declared before integration begins rather than discovered during it.

Asymmetric fees are the exception that is a red flag. A higher fee on sells than buys, or a fee the owner can raise after launch, is the honeypot pattern.

Upgradeability

An upgradeable contract sits behind a proxy that forwards calls to an implementation which can be replaced.

This is a legitimate and common pattern — it is how bugs get fixed. But it means the contract you reviewed is not necessarily the contract that will execute your transaction tomorrow. The questions are who controls the upgrade, whether a timelock applies, and whether upgrades are announced.

An immutable contract offers certainty and no path to fix anything. Neither choice is wrong; they trade different risks.

What an audit is and is not

An audit is evidence that competent people looked, and a record of what they found.

It is not a guarantee. Audited contracts have been exploited, both through issues the audit missed and through issues introduced after it.

Reading an audit usefully:

Which version was audited? If it is not the deployed one, the audit covers something else.
Were findings resolved? Unresolved medium-severity issues are survivable when explained. Silence is not.
What was in scope? Audits frequently cover the token contract and not the surrounding system.
Who performed it? An unnamed auditor is not evidence.

Critically: an audit cannot prevent liquidity removal or supply dumping, because neither is a code defect. A contract can be flawless and the project can still rug.

What review cannot see

Being explicit about the boundary:

Intent. Code shows capability, never motive.
Off-chain risk — team, legal, operational, or financial.
Future state, for anything upgradeable or with an active owner.
Whether anyone will trade it. A clean contract with no liquidity is still unusable. See what is token liquidity.

How to Verify a Smart Contract — the practical routine.
Smart Contract Safety FAQ
How to Pass Smart Contract Review — the same subject from a project's side.

Smart Contract Review Basics — What Reviewers Look For