Scanner findings and control logic

Centralization warnings, owner controls, and market-integrity controls are not automatically proof of malicious behavior. If a label is serious, the technical basis should be specific.

Back to overview Evidence log

Centralization warnings are not malicious behavior

Scanner systems may identify centralization, owner-control, or market-control warnings. Those warnings may provide useful information. But they are not automatically proof of malicious behavior.

CIGO does not dispute that visible administrative controls exist where they appear in verified source code. Question is whether a specific control is actually malicious, excessive, or unsafe — and if so, which one.

Comparable administrative and market-integrity controls exist across many major token ecosystems and protocols people trade daily: emergency pause powers, allowlist or denylist logic, fee parameters, anti-abuse limits, treasury reserves, and other protective mechanisms. Existence of a control is not proof of malice. What matters is whether each control is disclosed, bounded, and used responsibly.

Calling a token malicious without identifying exact function, permission, rule, data source, transaction behavior, or remediation path converts risk review into opaque accusation.

What CIGO asks reviewers to identify

Specific source-code function being flagged.
Specific owner/admin permission considered unsafe.
Scanner rule or third-party data source behind warning.
Transaction behavior or liquidity condition being relied upon.
Exact remediation path required for reconsideration.

CertiK-style findings: warning categories versus malicious findings

CIGO’s position is that scanner-identified controls should be disclosed and reviewed specifically, not automatically converted into a malicious designation.

Reported warning or finding	Meaning	CIGO position
Modifiable tax settings	Privileged roles may modify token tax settings.	Disclose limits and purpose. A modifiable setting is a control; it is not automatically malicious.
Blacklist capability	Privileged roles may block addresses.	Review scope and governance. A defensive blacklist should be evaluated by use case, not assumed to be fraud.
Transfer pause capability	Privileged roles may pause transfers.	Emergency controls can protect holders during abuse or attack. If excessive, identify specific risk.
Anti-whale mechanisms	Token has limits designed to restrict oversized activity.	Anti-whale controls are defensive market-integrity tools, especially during early liquidity formation.
Ownership not renounced	Owner/admin privileges remain active.	Non-renounced ownership is a centralization issue to disclose. It is not by itself proof of malicious behavior.
Major holder concentration	A large percentage of supply is held by major wallets.	Holder concentration should be disclosed and explained, especially treasury and distribution reserves.
Honeypot risk not found	Scanner did not identify honeypot behavior.	This is directly relevant when a wallet applies a malicious label without specific explanation.
Token is open source	Source code is publicly available for review.	A verified public contract can be inspected. An unexplained malicious label cannot.
Mintable function not found	No detected mint function.	This weakens any vague claim that supply can be secretly inflated.
Hidden owner not found	No detected hidden owner pattern.	This matters because hidden authority is a common malicious-contract concern.
Self-destruct function not found	No detected self-destruct function.	This should be distinguished from actual rug-pull mechanics.
Cannot modify balances	Privileged roles cannot directly modify token balances.	This is a material safety finding and should not be buried beneath vague warnings.
No withdrawal functions found	No detected function for privileged token withdrawal.	This should be part of any fair review of malicious-risk claims.
Buy tax 0% / Sell tax 0%	Reported transaction taxes are zero.	Zero current taxes should be distinguished from modifiable emergency settings.

If a project is going to be labeled malicious, the reviewer should identify the exact function, permission, rule, data source, behavior, or threshold being relied upon — not simply collapse all visible controls into one reputational verdict.