Review what privileged accounts can do, not just whether a token has an owner. Different powers create different risks, and they may belong to separate roles or upgrade authorities.
Map each relevant capability
| Power | Question for a swap user |
|---|---|
| Pause transfers | Can trading stop while I hold the token? |
| Address restrictions | Can my account or route be blocked? |
| Change transfer fees | Can selling become materially more expensive? |
| Mint supply | Can supply increase beyond my assumption? |
| Upgrade implementation | Can the rules themselves change? |
OpenZeppelin’s access-control documentation explains ownership and role-based permissions. Its proxy documentation describes upgrade mechanisms. These capabilities are implementation-specific; a token may implement some, none or custom variations.
Identify who controls the power
A single key, multisignature and timelock create different operational constraints. Read the actual threshold, delay and scope rather than assuming the word governance means users can veto every action.
Also check whether roles can be granted again and whether an admin can change the controls. Renouncing one ownership function does not automatically remove all independent powers.
Connect the finding to your decision
Administrative controls can serve legitimate issuer or emergency purposes. Their presence is not by itself proof of fraud. The useful conclusion is what must remain trusted and what can change after your transaction, especially the ability to transfer or sell.
Sources & verification (3)
Source-check date is recorded in the article details. URLs are provided for manual verification. Use Copy to keep this page open.
- Access Control | OpenZeppelin Docs
Ownership, independent roles, admin roles and governance controls.
https://docs.openzeppelin.com/contracts/5.x/access-control - Proxy | OpenZeppelin Docs
Proxy implementation upgrades and authorization boundaries.
https://docs.openzeppelin.com/contracts/5.x/api/proxy - ERC20 | OpenZeppelin Docs
ERC-20 implementation behavior, zero-first approval compatibility and pausable token extension.
https://docs.openzeppelin.com/contracts/5.x/api/token/erc20