Quantum Audit Logo
Launch App

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

Is CZ Terminal Token Safe?

CZTBNB 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/10Governance8/10Upgrades10/10Checks passed5 of 5Findings1 High · 2 Medium · 2 Low · 1 Info6
SummaryAI Copilot

This audit covers the provided partial source code for the CZTerminalToken contract.

Read the full analysis
What raised the score
  • Liquidity < $50k
  • Token age < 30 days
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact factors
  • Liquidity < $50k ($40,054 across 1 pairs — thin market)
  • Token age < 30 days (still settling)
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 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
7.6%10.6%Wallets81.8%Everyone else
7.6%10.6%81.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
18.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking7.6%
  • Walletsanonymous holders, free to sell10.6%
  • Everyone elsethe rest of the supply81.8%
Effective concentrationwhat the score reads13.6%
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$40.1K

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$40.1KShare of depth100.0%
LP Locked100.0% · Null Address, PinkLock02
Unlocked LP held by
0x7703…a1a2

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

Security Findings

1 High2 Medium2 Low1 Info
High

Incomplete Anti-Whale/Transaction Limit Implementation

The contract declares maxBuyAmount, maxSellAmount, and maxWalletAmount variables, indicating an intention to implement anti-whale or transaction limit mechanisms. However, the provided _transfer, _mint, and _burn functions, which are the core logic for token movement, do not contain any checks or enforcement logic for these limits. Without proper implementation, these limits are ineffective and can be bypassed, potentially leading to market manipulation or concentrated holdings.H-01

Issue

The contract declares maxBuyAmount, maxSellAmount, and maxWalletAmount variables, indicating an intention to implement anti-whale or transaction limit mechanisms. However, the provided _transfer, _mint, and _burn functions, which are the core logic for token movement, do not contain any checks or enforcement logic for these limits. Without proper implementation, these limits are ineffective and can be bypassed, potentially leading to market manipulation or concentrated holdings.

Fix

Implement comprehensive checks within the _transfer, _mint, and _burn functions (or their respective hooks like _beforeTokenTransfer) to enforce maxBuyAmount, maxSellAmount, and maxWalletAmount for all relevant transactions. Ensure these checks cover both direct transfers and transfers via transferFrom.

Status

Unresolved

Medium

Potential Reentrancy in DEX Interactions (Truncated Code)

The contract includes a swapping flag, which is a common pattern for reentrancy protection. However, the full implementation of functions interacting with IDexRouter (e.g., swapExactTokensForETHSupportingFeeOnTransferTokens) is not provided. If external calls to the DEX router are made within critical state-changing functions without proper reentrancy guards (e.g., using the swapping flag correctly, Checks-Effects-Interactions pattern), it could expose the contract to reentrancy attacks.M-01

Issue

The contract includes a swapping flag, which is a common pattern for reentrancy protection. However, the full implementation of functions interacting with IDexRouter (e.g., swapExactTokensForETHSupportingFeeOnTransferTokens) is not provided. If external calls to the DEX router are made within critical state-changing functions without proper reentrancy guards (e.g., using the swapping flag correctly, Checks-Effects-Interactions pattern), it could expose the contract to reentrancy attacks.

Fix

Ensure that all functions involving external calls, especially to IDexRouter, are protected against reentrancy. Verify that the swapping flag is correctly set before external calls and reset afterwards, and that all state changes occur before any external calls. Consider using OpenZeppelin's ReentrancyGuard for robust protection.

Status

Unresolved

Medium

Unverified Fee-on-Transfer Logic (Truncated Code)

The IDexRouter interface includes swapExactTokensForETHSupportingFeeOnTransferTokens, implying that the token might implement a fee-on-transfer mechanism. While _beforeTokenTransfer and _afterTokenTransfer hooks are present, their implementation is empty in the provided code. Without the full logic, it's impossible to verify if fees are correctly handled, especially for transfers to/from DEX liquidity pools, to prevent issues like liquidity drain, failed swaps, or incorrect accounting for fee-exempt addresses.M-02

Issue

The IDexRouter interface includes swapExactTokensForETHSupportingFeeOnTransferTokens, implying that the token might implement a fee-on-transfer mechanism. While _beforeTokenTransfer and _afterTokenTransfer hooks are present, their implementation is empty in the provided code. Without the full logic, it's impossible to verify if fees are correctly handled, especially for transfers to/from DEX liquidity pools, to prevent issues like liquidity drain, failed swaps, or incorrect accounting for fee-exempt addresses.

Fix

Thoroughly implement and test the fee-on-transfer logic within _beforeTokenTransfer or _afterTokenTransfer. Ensure that transfers to/from the DEX router and other critical protocols (e.g., staking contracts) are properly exempted from fees to maintain compatibility and prevent unexpected behavior. Document the fee mechanism clearly.

Status

Unresolved

Low

Centralization Risk with Owner Privileges

The contract uses the Ownable pattern, granting the owner address exclusive control over sensitive functions (e.g., transferOwnership, renounceOwnership). While standard, this introduces a single point of failure. If the owner's private key is compromised, a malicious actor could gain full control over these administrative functions, potentially leading to severe consequences for the protocol.L-01

Issue

The contract uses the Ownable pattern, granting the owner address exclusive control over sensitive functions (e.g., transferOwnership, renounceOwnership). While standard, this introduces a single point of failure. If the owner's private key is compromised, a malicious actor could gain full control over these administrative functions, potentially leading to severe consequences for the protocol.

Fix

Consider implementing a multi-signature wallet (e.g., Gnosis Safe) for the owner address to distribute control and reduce the risk associated with a single point of failure. Alternatively, explore a time-locked ownership transfer mechanism for critical operations.

Status

Unresolved

Low

Standard ERC20 approve Front-Running Vulnerability

The standard ERC20 approve function is susceptible to a known front-running vulnerability. If a user approves an amount, then decides to decrease that allowance and sends a decreaseAllowance transaction, a malicious actor could front-run the decreaseAllowance by spending the original approved amount. This allows the attacker to spend the original allowance, and then the decreaseAllowance transaction will still execute, potentially allowing the attacker to spend the new (lower) allowance as well.L-02

Issue

The standard ERC20 approve function is susceptible to a known front-running vulnerability. If a user approves an amount, then decides to decrease that allowance and sends a decreaseAllowance transaction, a malicious actor could front-run the decreaseAllowance by spending the original approved amount. This allows the attacker to spend the original allowance, and then the decreaseAllowance transaction will still execute, potentially allowing the attacker to spend the new (lower) allowance as well.

Fix

While increaseAllowance and decreaseAllowance mitigate this for most use cases, users should be advised to set allowances to zero before increasing them if they are concerned about this specific front-running vector with the base approve function. For critical operations, consider a two-step approval process.

Status

Unresolved

Info

Missing Specific Events for Minting and Burning

The _mint and _burn functions emit standard Transfer events (from address(0) for mint, to address(0) for burn). While technically correct according to ERC20, having specific Mint and Burn events (e.g., event Mint(address indexed to, uint256 amount);) could provide clearer and more granular off-chain monitoring and indexing capabilities for these distinct token lifecycle operations.I-01

Issue

The _mint and _burn functions emit standard Transfer events (from address(0) for mint, to address(0) for burn). While technically correct according to ERC20, having specific Mint and Burn events (e.g., event Mint(address indexed to, uint256 amount);) could provide clearer and more granular off-chain monitoring and indexing capabilities for these distinct token lifecycle operations.

Fix

Consider adding dedicated Mint and Burn events within the _mint and _burn functions, respectively. This would enhance transparency and simplify off-chain analysis of token supply changes.

Status

Unresolved

Analysis

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

This audit covers the provided partial source code for the CZTerminalToken contract. The contract implements a standard ERC20 token with Ownable access control and integrates with a DEX router. Key features include anti-whale mechanisms (maxBuyAmount, maxSellAmount, maxWalletAmount) and a 'swapping' flag, though the full implementation details for these features and potential fee-on-transfer logic are not available in the truncated code. The core ERC20 logic appears robust, utilizing OpenZeppelin patterns and safe unchecked blocks. However, the absence of complete code for critical tokenomic features and DEX interactions prevents a comprehensive assessment of their security and effectiveness.

Technical9/10Low risk

The contract utilizes OpenZeppelin's Context and ERC20 implementations, providing a solid foundation for token functionality (7.1 Architecture, 7.2 Code Security). Solidity 0.8.x's default overflow/underflow checks are leveraged, with unchecked blocks used safely after explicit require checks. However, the provided code is truncated, leaving critical parts of the token's logic, such as the enforcement of maxBuyAmount, maxSellAmount, and maxWalletAmount, unverified (7.2 Code Security). The presence of a swapping flag suggests reentrancy protection, but its full implementation and coverage for DEX interactions are not visible, posing a potential risk (7.2 Code Security).

Governance8/10Low risk

The contract employs the Ownable pattern, granting the deployer significant control over the contract's parameters and potentially critical functions (7.3 Access Control). This introduces a centralization risk, as a compromised owner key could lead to severe consequences (7.5 Governance). The contract defines maxBuyAmount, maxSellAmount, and maxWalletAmount to implement anti-whale or transaction limits, which are crucial for the token's economic model (7.4 Economic). However, the enforcement logic for these limits is not present in the provided code, making their effectiveness uncertain and potentially bypassable (7.4 Economic).

Upgrades10/10Low risk

The contract is not designed as an upgradeable proxy, as indicated by is_proxy: false in the prefill. Therefore, upgrade safety concerns are not applicable to this specific deployment (7.7 Upgrades). Any future changes would require deploying a new contract and migrating assets, which is a standard approach for non-upgradeable contracts.

Final RecommendationWhat to do about this score

It is crucial to complete the implementation of all intended tokenomic features, particularly the enforcement of maxBuyAmount, maxSellAmount, and maxWalletAmount.

Thoroughly review and test the full contract code, especially any logic related to DEX interactions and fee-on-transfer mechanisms, to ensure proper reentrancy protection and economic stability. Consider implementing a multi-signature wallet for ownership to mitigate centralization risks associated with the Ownable pattern.

Contract & Record

1 audit on record
TypeCZTerminalToken
NetworkBNB Chain
Token age14d
Contract0x9385…798c
Deployer0x7703…a1a2
Badge for your website
CZ Terminal Token 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, 202619Low
  2. Jul 28, 202613Low

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

Related Audits

6 more on the recordAll audits
Everlyn TokenLYN · BNB Chain19LowIBSBNB Chain20LowBEMBNB Chain18LowBENBNB Chain18LowBREWBNB Chain18Low1000XBNB Chain20Low

Would You Like a More Detailed Audit of CZ Terminal Token?

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