Privileged Functions in Token Contracts: What to Audit

If you have ever lost money to a token that suddenly stopped trading, had its supply doubled overnight, or blacklisted your wallet for no reason, you have already met privileged functions in token contracts. They are the parts of the code that are not subject to the rules everyone else has to follow. Before you put a single dollar into a presale or a freshly listed token, you should know how to find them and how to read them.

This guide walks through the privileged functions that show up most often, what they actually let the deployer do, and the practical questions to ask before assuming “decentralized” means anything.

Why this matters more than the whitepaper

Whitepapers describe intent. The contract describes what the team can actually do regardless of intent. According to SlowMist’s 2024 annual security report, rug pulls and contract-level exit scams accounted for a substantial share of retail losses last year, and almost all of them were technically legal under the contract’s own rules — the team simply used a function the buyers never read.

A short reality check: the verified Solidity on Etherscan is the source of truth. Marketing copy is not. If a project tells you their token is “fully decentralized” but the contract has an onlyOwner mint function and the owner is an externally-owned account, the marketing copy is wrong. Full stop. For a broader walkthrough of how to read a contract, see our guide to reading a token contract before buying.

The functions worth looking for

Mint

A mint or _mint function lets the holder of a privileged role create new tokens out of nothing. Some tokens need this — algorithmic stablecoins, rebase tokens, reward emissions. Many do not.

What to check:

• Is mint gated by onlyOwner, a role from OpenZeppelin’s AccessControl, or no gate at all?
• Is there a hard cap (MAX_SUPPLY) enforced inside the function?
• Is the owner an EOA, a multisig, or a timelock?

An unrestricted mint controlled by a single private key is the cleanest version of “the team can dilute you to zero.”

Pause / unpause

A pause function freezes transfers. Legitimate uses include emergency response after an exploit. Illegitimate uses include freezing the market while insiders sell on a different venue, or simply locking buyers in until a presale unlock cliff has passed.

If a token is pausable, verify who can call it and whether there is a maximum pause duration. Most retail-friendly contracts do not enforce a maximum, which is itself worth noting.

Blacklist / freeze

Common in centralized stablecoins. USDT and USDC both have the ability to freeze specific addresses, and Tether publishes the freeze events on its transparency page. That is acceptable for a regulated stablecoin issuer. It is much less acceptable for a “community” memecoin where the deployer can blacklist a whale who is about to sell.

Search the contract for blacklist, isBlacklisted, _blacklist, or setBlocked. If the function exists and the owner is not renounced, the deployer can choose who is allowed to sell.

Fee modification

Many tokens implement a buy/sell tax. The danger is when the fee is mutable and uncapped. A setFee function with no upper bound means the team can raise the sell tax to 99% the moment a holder tries to exit. This is one of the most common honeypot patterns documented across chain analysis vendors.

Look for a hard-coded MAX_FEE constant checked inside the setter. If you do not see one, assume the fee can be changed to whatever the deployer chooses.

Upgradeability (proxies)

OpenZeppelin’s upgradeable contracts use a proxy pattern: the token address you interact with delegates calls to an implementation contract that the admin can replace. This is documented openly in the OpenZeppelin Upgrades plugin and is widely used by serious projects.

The catch: today’s audited code is not necessarily what executes tomorrow. Upgradeability is not bad on its own, but it should be paired with a timelock — typically 24 to 72 hours — so holders have time to exit if a malicious upgrade is queued. A proxy admin that is a single EOA with instant upgrade rights is functionally a key to print, freeze, or drain whenever the holder wishes.

Owner privileges and renouncement

Ownable from OpenZeppelin gives a single address sweeping rights. “Renouncing” ownership transfers it to the zero address, permanently disabling owner-only functions. This is verifiable on-chain.

Be careful: renouncing ownership on a proxy does not remove the proxy admin. They are separate roles. Several rug pulls have publicized “ownership renounced” while keeping full upgrade rights through the proxy admin slot.

A practical audit checklist

Before buying, take ten minutes and answer these questions:

1. Is the contract verified on the relevant block explorer?
2. List every function with onlyOwner, onlyRole, or a custom modifier.
3. Is the owner an EOA, a multisig, or a timelock? Check the address on the explorer.
4. Does mint exist? Is there a supply cap?
5. Is the contract pausable, blacklistable, or fee-mutable? Are there hard caps on the mutable values?
6. Is the contract a proxy? If yes, who is the proxy admin, and is there a timelock?
7. Has there been a third-party audit, and does the audit cover the deployed version?

For wallets that help surface this information automatically, our shortlist of wallets for presale buyers flags some that integrate basic contract scanning. For a deeper dive on multisig configurations specifically, see the multisig vs single-key custody guide.

What “could not verify” looks like in practice

Sometimes the contract is unverified, or the team uses a custom non-standard pattern that automated tools cannot parse. That is itself information. An unverified token contract held by retail buyers should be treated as opaque-by-default. Our presale scoring methodology treats unverified contracts as an automatic deduction, and we keep a running list of recent presale teardowns where this came up.

Honest summary

Privileged functions are not inherently malicious — every real protocol has some — but they are the mechanism through which most retail losses actually happen. A team that has documented its privileged functions, capped them, gated them behind a multisig with a timelock, and published audits of the deployed version has done the basic homework. A team that has not done these things is asking you to trust them personally, and personal trust in pseudonymous founders has a poor historical track record. Read the contract before you read the roadmap.