Is Pro Token (PRO) Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 High1 Med1 Low1 Info

Critical

Excessive Centralization of Control

C-01The `owner` and `governance` roles possess extensive power over the contract's functionality and economic parameters. The `owner` can set `targetPool`, `treasury`, `targetRatio`, `transferStatus`, `add/removeWhitelist`, and `transferGovernance`. The `governance` can set `feeReceiver`, `sellRatio`, and call `balancePool`. This high degree of centralization creates a single point of failure, where a compromised or malicious privileged account could manipulate the token's economics, halt trading, or transfer administrative control without warning. For example, the `owner` can instantly transfer `governance` to any address via `transferGovernance`.

IssueThe `owner` and `governance` roles possess extensive power over the contract's functionality and economic parameters. The `owner` can set `targetPool`, `treasury`, `targetRatio`, `transferStatus`, `add/removeWhitelist`, and `transferGovernance`. The `governance` can set `feeReceiver`, `sellRatio`, and call `balancePool`. This high degree of centralization creates a single point of failure, where a compromised or malicious privileged account could manipulate the token's economics, halt trading, or transfer administrative control without warning. For example, the `owner` can instantly transfer `governance` to any address via `transferGovernance`.

FixImplement a multi-signature wallet (e.g., Gnosis Safe) for both the `owner` and `governance` roles. For highly sensitive functions, consider adding a time-lock mechanism to introduce a delay before changes take effect, allowing for community oversight and reaction.

StatusUnresolved

High

Critical Parameter Manipulation without Timelocks

H-01Key economic and operational parameters such as `targetPool`, `targetRatio`, `sellRatio`, `feeReceiver`, and `transferStatus` can be changed instantly by the `owner` or `governance` roles. This immediate effect allows for rapid and potentially malicious alterations to the token's behavior, such as drastically increasing the sell tax, disabling transfers from the pool, or changing the liquidity pool address, without any grace period for users or external systems to react. For instance, `setSellRates` can change the sell tax up to 30% instantly.

IssueKey economic and operational parameters such as `targetPool`, `targetRatio`, `sellRatio`, `feeReceiver`, and `transferStatus` can be changed instantly by the `owner` or `governance` roles. This immediate effect allows for rapid and potentially malicious alterations to the token's behavior, such as drastically increasing the sell tax, disabling transfers from the pool, or changing the liquidity pool address, without any grace period for users or external systems to react. For instance, `setSellRates` can change the sell tax up to 30% instantly.

FixIntroduce a time-lock mechanism for all functions that modify critical parameters. This would enforce a delay between the initiation of a parameter change and its actual activation, providing transparency and an opportunity for stakeholders to review and react to proposed changes.

StatusUnresolved

Medium

Incomplete Validation for `setFeeReceiver`

M-01The `_update` internal function correctly includes a `require(feeReceiver != address(0) && feeReceiver != targetPool, "invalid fee receiver");` check to prevent issues with fee distribution. However, the `setFeeReceiver` function, which is callable by `onlyGovernance`, only checks `_newReceiver != address(0)`. It does not prevent setting `_newReceiver` to `targetPool`. If `feeReceiver` is set to `targetPool`, any subsequent token transfers to the pool (sells) would revert due to the check in `_update`, effectively halting selling functionality.

IssueThe `_update` internal function correctly includes a `require(feeReceiver != address(0) && feeReceiver != targetPool, "invalid fee receiver");` check to prevent issues with fee distribution. However, the `setFeeReceiver` function, which is callable by `onlyGovernance`, only checks `_newReceiver != address(0)`. It does not prevent setting `_newReceiver` to `targetPool`. If `feeReceiver` is set to `targetPool`, any subsequent token transfers to the pool (sells) would revert due to the check in `_update`, effectively halting selling functionality.

FixAdd a check in the `setFeeReceiver` function to ensure that `_newReceiver` is not equal to `targetPool`. This will prevent the `feeReceiver` from being set to an invalid address that would cause future transactions to revert. Example: `if (_newReceiver == address(0) || _newReceiver == targetPool) revert InvalidAddress();`

StatusUnresolved

Low

Missing Mint Function Implementation

L-01The state variable `treasury` is documented with the comment `/// @dev Treasury address authorized to mint tokens`. However, no `mint` function or similar functionality that allows the `treasury` address to create new tokens is present in the provided contract snippet. This creates a discrepancy between the contract's documentation and its actual implementation, leading to confusion about the intended capabilities of the `treasury` role.

IssueThe state variable `treasury` is documented with the comment `/// @dev Treasury address authorized to mint tokens`. However, no `mint` function or similar functionality that allows the `treasury` address to create new tokens is present in the provided contract snippet. This creates a discrepancy between the contract's documentation and its actual implementation, leading to confusion about the intended capabilities of the `treasury` role.

FixEither implement the `mint` function with appropriate access control for the `treasury` address, or remove the `treasury` variable and its associated documentation if token minting is not an intended feature of the contract. Ensure the contract's code accurately reflects its intended functionality.

StatusUnresolved

Info

Non-Standard ERC20 Decimals

I-01The `decimals()` function is overridden to return `9`. While technically valid for an ERC20 token, the most common standard for fungible tokens in the EVM ecosystem is 18 decimals. Using a non-standard decimal count like 9 can sometimes lead to compatibility issues or require custom handling when integrating with existing DeFi protocols, exchanges, or wallets that might implicitly assume 18 decimals.

IssueThe `decimals()` function is overridden to return `9`. While technically valid for an ERC20 token, the most common standard for fungible tokens in the EVM ecosystem is 18 decimals. Using a non-standard decimal count like 9 can sometimes lead to compatibility issues or require custom handling when integrating with existing DeFi protocols, exchanges, or wallets that might implicitly assume 18 decimals.

FixEnsure that all external systems, such as exchanges, wallets, and DeFi protocols, are explicitly aware of and correctly configured to handle the token's 9 decimals. Clearly document this choice in all public-facing materials. If possible and without significant disruption, consider migrating to 18 decimals for broader compatibility.

StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract's architecture (7.1) is straightforward, extending OpenZeppelin's ERC20 and Ownable. Code security (7.2) is generally good with Solidity 0.8+ preventing common integer issues, and custom transfer logic in `_update` handles tax and restrictions. However, access control (7.3) is highly centralized, with `owner` and `governance` roles having extensive power over critical functions like `setTargetPool` and `setSellRates`. The `_update` function's check for `feeReceiver` is robust, but `setFeeReceiver` lacks a corresponding check, creating a potential for future reverts.

GovernanceHigh3/10

The economic model (7.4) relies on a sell tax and a liquidity pool balancing mechanism, which can be significantly influenced by privileged roles. Governance (7.5) is highly centralized, with `owner` and `governance` having immediate control over all critical parameters, including `sellRatio`, `targetRatio`, and `transferStatus`. This centralization introduces a high risk of economic manipulation or single point of failure. The `treasury` role is mentioned for minting, but no corresponding function is provided, creating an ambiguity in the economic model. External (7.6) interactions are limited to `IPancakePair.sync()`, which is generally safe.

UpgradesHigh3/10

The contract is not designed as an upgradeable proxy (7.7). Therefore, there are no upgrade-specific risks. Any changes to the contract logic would require a new deployment and migration of assets, which is a standard practice for non-upgradeable contracts.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedPass

Not a ProxyPass

Holder Composition

91.7% in top 10

12.9% in wallets78.7% in contracts

Effective Concentration44.4%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$78.05M

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Key Addresses

5 addresses

Deployer

0x7d38…c623

Unlocked LP Held By

0x0ed9…97060xfba5…924f0x01e7…5d2d0x0e00…8a59

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

7 factors

Ownership NOT renounced — owner is an EOA (single private key)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 30% (91.7% total → 44.4% effective; 12.9% in EOAs, 78.7% in contracts — moderate)
1 Critical finding(s) from audit
1 High finding(s) from audit
1 Medium finding(s) from audit
1 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Final Recommendation

AI Copilot

To mitigate the identified risks, it is strongly recommended to implement a multi-signature wallet for the `owner` and `governance` roles, especially for functions that modify critical parameters or transfer administrative control.…

Read the verdictHide

Additionally, consider introducing time-locks for sensitive parameter changes (e.g., `setSellRates`, `setTargetRatio`, `setTargetPool`, `setTransferState`) to provide a window for community review and reaction. Ensure all critical functions, especially those related to the `treasury` and minting, are fully implemented and their access controls are robustly defined and documented.

Contract

TypeToken

Audit History

1 audit on record

Jul 2275Jul 2364

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Not Signed In

Is Pro Token Safe?

Security Findings

Excessive Centralization of Control

Critical Parameter Manipulation without Timelocks

Incomplete Validation for `setFeeReceiver`

Missing Mint Function Implementation

Non-Standard ERC20 Decimals

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Pro Token?