Quantum Audit Logo
Launch App

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

Is Test Safe?

TSTBNB Chain
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical9/10Governance5/10Upgrades10/10Checks passed5 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
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.

Read the full analysis
What raised the score
  • Top-10 concentration > 70%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
3.6%84.1%Wallets12.3%Everyone else
3.6%84.1%Wallets12.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
87.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking3.6%
  • Walletsanonymous holders, free to sell84.1%
  • Everyone elsethe rest of the supply12.3%
Effective concentrationwhat the score reads85.5%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$1.12M across 7 pairs
Show 1 more pair

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$868.6KShare of depth77.6%
LP Burned1.8%
LP Locked96.8% · Dead Address, GoPlus SafeToken Locker
Top-1 Unlocked Holder2.8%
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.

Security Findings

1 High1 Medium1 Low1 Info
High

Irreversible Transfer Mode Change

The 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.H-01

Issue

The 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.

Fix

If 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.

Status

Unresolved

Medium

Centralized Control by Owner

The 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.M-01

Issue

The 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.

Fix

Consider 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.

Status

Unresolved

Low

Initial Transfer Restriction Requires Owner Action

In 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.L-01

Issue

In 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.

Fix

Ensure 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.

Status

Unresolved

Info

Missing Event for Mode Change

The 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.I-01

Issue

The 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.

Fix

Add 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical9/10Low risk

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.

Governance5/10Medium risk

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.

Upgrades10/10Low risk

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.

Final RecommendationWhat to do about this score

It is strongly recommended to review the setMode logic to ensure it aligns with the intended long-term operational strategy for token transferability.

If flexibility is desired, the condition preventing mode changes from MODE_NORMAL should be removed or modified. Additionally, consider emitting an event when the transfer mode is changed to enhance transparency and on-chain monitoring. Ensure clear communication to users regarding the initial transfer restrictions and any subsequent mode changes.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age1y
Contract0x86bb…6429
Deployer0x1a11…66f4
Badge for your website
Test security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202625Low
  2. Aug 11, 202627Low

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

Frequently Asked Questions

What is the TST contract address?

The Test (TST) contract on BNB Chain is 0x86bb94ddd16efc8bc58e6b056e8df71d9e666429. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Test a scam?

Quantum Audit's risk score for Test is 25/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is TST liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $1.12M.

Who holds TST?

As of Sep 4, 2026, the 10 largest holders own 87.7% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
The Final Form BullCZ · BNB Chain25Low4StockBNB Chain25LowLABBNB Chain26LowKoma InuKOMA · BNB Chain26LowFLORKBNB Chain26LowZhao Cai Mao招财猫 · BNB Chain26Low

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 Is this your token? Publish your own audit on this page