Quantum Audit Logo

Is Test Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

Test TST
0x86bb…6429
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The audit of the Token contract, an ERC-20 compliant token with custom transfer restrictions, identified a High-severity issue related to the irreversible nature of its transfer mode. Once the token's transfer mode is set to 'NORMAL', it cannot be reverted to a restricted state, which significantly impacts the project's ability to manage token transfers post-launch. Other findings include centralized control and a missing event for mode changes.

1 High1 Medium1 Low1 Informational
Volume 24h
$38.1K
Liquidity
$868.6K
Price
$0.017
Token Age
1y
Top 10 Holders
87.7%

Security Findings

1 High1 Med1 Low1 Info
High

Irreversible Transfer Mode Change

H-01The `setMode` function contains a condition `if (_mode != MODE_NORMAL) { _mode = v; }`. This logic dictates that once the token's transfer mode (`_mode`) is set to `MODE_NORMAL` (0), it can never be changed again. This means that any transfer restrictions (e.g., `MODE_TRANSFER_RESTRICTED` or `MODE_TRANSFER_CONTROLLED`) cannot be re-enabled after the token has been set to fully transferable. This significantly limits the project's ability to adapt to future needs, such as implementing vesting schedules, preventing market manipulation, or responding to security incidents by temporarily restricting transfers.
IssueThe `setMode` function contains a condition `if (_mode != MODE_NORMAL) { _mode = v; }`. This logic dictates that once the token's transfer mode (`_mode`) is set to `MODE_NORMAL` (0), it can never be changed again. This means that any transfer restrictions (e.g., `MODE_TRANSFER_RESTRICTED` or `MODE_TRANSFER_CONTROLLED`) cannot be re-enabled after the token has been set to fully transferable. This significantly limits the project's ability to adapt to future needs, such as implementing vesting schedules, preventing market manipulation, or responding to security incidents by temporarily restricting transfers.
FixIf the intention is to allow flexible control over transfer restrictions, remove the `if (_mode != MODE_NORMAL)` condition from the `setMode` function. This would allow the owner to switch between all defined modes as needed. If the irreversible nature is intentional, ensure this design choice is clearly documented and understood by all stakeholders, acknowledging the permanent loss of control once `MODE_NORMAL` is activated.
StatusUnresolved
Medium

Centralized Control by Owner

M-01The contract utilizes the `Ownable` pattern, granting the deployer (owner) exclusive control over critical functions such as `setMode` and initial token minting. While common, this centralization introduces a single point of failure. A compromised owner key could lead to unauthorized changes in transferability or other malicious actions, impacting the token's integrity and user trust.
IssueThe contract utilizes the `Ownable` pattern, granting the deployer (owner) exclusive control over critical functions such as `setMode` and initial token minting. While common, this centralization introduces a single point of failure. A compromised owner key could lead to unauthorized changes in transferability or other malicious actions, impacting the token's integrity and user trust.
FixConsider implementing a multi-signature wallet for ownership of critical functions to distribute control and reduce the risk associated with a single compromised key. For future iterations, explore decentralized governance mechanisms if the project aims for community-driven control over such parameters.
StatusUnresolved
Low

Initial Transfer Restriction Requires Owner Action

L-01In the constructor, the `_mode` is initialized to `MODE_TRANSFER_RESTRICTED`. This means that immediately after deployment, no token transfers are possible until the owner explicitly calls `setMode` to change it to `MODE_NORMAL` or `MODE_TRANSFER_CONTROLLED`. While this might be an intentional design choice for a controlled launch, it could lead to user confusion or operational delays if not clearly communicated and managed.
IssueIn the constructor, the `_mode` is initialized to `MODE_TRANSFER_RESTRICTED`. This means that immediately after deployment, no token transfers are possible until the owner explicitly calls `setMode` to change it to `MODE_NORMAL` or `MODE_TRANSFER_CONTROLLED`. While this might be an intentional design choice for a controlled launch, it could lead to user confusion or operational delays if not clearly communicated and managed.
FixEnsure that the initial transfer restriction is clearly communicated to users and the community. Provide clear instructions and a timeline for when the owner intends to change the mode to enable transfers. Consider emitting an event in the constructor to explicitly state the initial mode.
StatusUnresolved
Info

Missing Event for Mode Change

I-01The `setMode` function, which modifies the critical `_mode` state variable controlling token transferability, does not emit an event. Without an event, it is difficult for off-chain applications, block explorers, and users to track changes to the token's transfer status programmatically or to verify when and by whom the mode was changed.
IssueThe `setMode` function, which modifies the critical `_mode` state variable controlling token transferability, does not emit an event. Without an event, it is difficult for off-chain applications, block explorers, and users to track changes to the token's transfer status programmatically or to verify when and by whom the mode was changed.
FixAdd an event to the `setMode` function to log the old and new mode values. For example: `event ModeChanged(uint256 oldMode, uint256 newMode);` and emit it after `_mode` is updated.
StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract implements a standard ERC-20 token with OpenZeppelin's Ownable pattern. The core functionality is sound, utilizing `unchecked` blocks appropriately after boundary checks (7.2 Code Security). However, a significant technical flaw exists in the `setMode` function, which prevents the owner from re-enabling transfer restrictions once `MODE_NORMAL` is activated (7.3 Access Control). This design choice introduces an irreversible state change that limits future operational flexibility.

GovernanceMedium5/10

The token's economic model is heavily influenced by the `_mode` variable, which dictates transferability (7.4 Economic). The contract relies on a single owner for critical operations, including setting the transfer mode (7.5 Governance). The irreversible nature of setting the mode to `MODE_NORMAL` means that once full transferability is enabled, the project loses the ability to impose any future restrictions, which could be a significant economic risk if market conditions or project phases require such control. The initial `MODE_TRANSFER_RESTRICTED` state requires explicit owner action to enable transfers.

UpgradesLow10/10

The contract is not designed as an upgradeable proxy (7.7 Upgrades). Therefore, there are no upgrade-specific risks or vulnerabilities to address. Any changes to the contract logic would require a new deployment and migration of assets.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

87.7% in top 10
84.1% in wallets3.6% in contracts
Effective Concentration85.5%

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

$1.12M across 7 pairs
Pancakeswap v3WBNBanalysed$868.6K77.6%Pancakeswap v2WBNB$234.8K21.0%Pancakeswap v3mubarak$14.7K1.3%Pancakeswap v3USDT$6560.1%Squadswap v2WBNB$6110.1%Pancakeswap v2USDT$120.0%
Show 1 more pairShow less
Pancakeswap v3USDT$00.0%

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 Burned1.8%
LP Locked96.8% · Dead Address, GoPlus SafeToken Locker
Top-1 Unlocked Holder2.8%

Key Addresses

9 addresses
Deployer
0x1a11…66f4
Unlocked LP Held By
0x556b…d59e0x6e97…88ae0x9dc8…f6530x12e3…eb970x5ad1…2cb00x5e91…fac10x8e0a…76c10xb262…eeed

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

What Raised This Score

4 factors
  • Top-10 concentration > 70% (87.7% total → 85.5% effective; 84.1% in EOAs, 3.6% in contracts — extreme)
  • 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

Related Audits

6 more on the record
The Final Form Bull (CZ)Medium RiskLABMedium RiskKoma Inu (KOMA)Medium RiskFLORKMedium RiskBaby Asteroid (BABYASTEROID)Medium RiskDecentrawood (DEOD)Medium Risk

Would You Like a More Detailed Audit of Test?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit